Posts made by peder

@tonyp90 I did file a feature suggestion, https://github.com/vatesfr/xen-orchestra/issues/4273 , but not a bug report.

I'm using the xsconsole on the xcp-ng server itself in the few cases where I need to re-attach an SR.

gitterdude created this issue in vatesfr/xen-orchestra

open Reattach SR icon is non-obvious #4273

@ccsmith Is Firefox's System Preferences > Keyboard > Input Sources set to U.S. , or whatever language you're using?

I don't know if it's related but some guy in https://support.mozilla.org/de/questions/1217111?&mobile=0 had set it to Unicode Hex and had problems with Option-Shift-Arrow

Can you ping the server reliably? Because it kind of seems like it's a network problem.

Start a CMD prompt on your XCP-ng Center PC and run ping -n 30 192.168.66.17 to see if you get packet losses.
If you do then it's probably a bad NIC or cable or switch port.

I don't know if it's the case here but one not-so-obvious thing in XO(A) is that you have to enable the slider to accept unverified certificates when you try to connect to the XCP-ng server.

The error here does suggest there's something else going on but make sure to check the above.

You should also install the XOA to make sure there's nothing wrong with your self-compiled XO.

Run this in a command shell on your XCP-ng server to install the appliance

bash -c "$(curl -s http://xoa.io/deploy)"

You can also run the vm-clone command on the XCP-ng server.
Something like

xe vm-clone new-name-label="clone name" vm="original name"

@jmccoy555 said in CEPH FS Storage Driver:

device-config:server=10.10.1.141,10.10.1.142,10.10.1.143

Are you sure that's supposed to work?
Try using only one IP-address and see if the command works as intended.

@x-rayd
If you have 3 VMs that each have a 5TiB disk and you want to back up all of them you need at least 3x5=15TiB on the SR for the initial snapshots. Then you also need some extra GiBs or TiBs for the deltas.

The workaround is to set up the SR as EXT, instead of LVM.
Then it's using thin provisioning, meaning that the snapshot only uses as much space as you have data in each 5TiB disk.
So if your VMs are only using 1,3 and 4 TiB of actual disk space then you only need an SR that's 1+3+4=8 TiB + the extra space for the deltas.

@dan2462
Plug the USB stick into your XCP-ng server and run

dmesg | tail 
# You should see "sdb: sdb1" or something similar at the bottom of the screen
mount /dev/sdb1 /mnt
cd /mnt
# Make sure you've mounted the correct device and partition :
df -h . 
# You should see that it's the expected USB size

If that's the case run the xe commands to save on the USB.
When that's done you run

cd /root
sync
umount /mnt

Then it's safe to remove the USB

@dan2462
I don't think you can do a CLI export to ova.
You couldn't in 2015, at least
https://discussions.citrix.com/topic/361151-how-to-export-to-ovaovf-with-command-line/

If you absolutely need ova you have to try and figure out why there's a communication failure.
My guess would be something network related, like a firewall between the XCP-ng server and your XCP-ng Center PC.
Or you're not using the correct setting on the Network page.

Someone said "To solve it I simply had to choose an unused static IP on the same subnet as the Network Management Console where the server pool resides."

I don't know what ports the transfer uses and a quick google search didn't show anything either.

@dan2462 Don't know what's causing the error but you can export the VHD by ssh:ing to your server or selecting "Local Command shell" on the console and running the following

xe vdi-list 
xe vdi-export uuid=the-uuid-of-your-VM filename=filename.vhd format=vhd 

Make sure the location you're saving to has enough space for the file.

If you have curl installed on your VirtualBox machine you can run

curl -u root:your-xcpng-root-password -X GET "server-name-or-IP/export_raw_vdi?vdi=your-vdi-uuid&format=vhd" -o filename.vhd

on it.

@dan2462 said in Cannot export VM in .ova file:

***Update:

So just updated the XCP-ng Center to the newest version of 20.03.00, and still get the same error on export of .ova

You still haven't posted what that error is.

When you export to OVA you need to make sure to configure the network correctly in the export wizard.
If you have multiple vlans on the server you have to select the correct one and so on.

@stormi Yes, that did it.
I suppose there's currently no way to show the actual filesystem, instead of the generic "Ext", in the xsconsole?
You have to resort to a shell and 'mount' or 'file -sL' to see that?

@dariosplit I made a new 8.1-RC1 install and had the installer set up the Local SR as LVM.
After the installation I ran the commands in my previous example and afterwards 'mount' and 'file -sL' show that it's ext4.

HOWEVER; xsconsole still claims "Type : Ext3" so the console seems to have hard coded that "ext = ext3".
Something for RC2 sort out.

@mortenchristensn Local storage is an SR.

The commands below will remove the SR named "Local storage" and create a new one with the same name on the same device

If you have a pool with several hosts you need to run these commands on each host and, as stormi points out in the comment below, you need to move any VMs out of the Local SR before removing it.

# Get the IDs and device path to the current Local SR :
# xe host-list | grep -B1 $HOSTNAME | grep ^uuid| cut -d\: -f2 | cut -d" " -f2 > HostUuid.txt
# xe pbd-list sr-name-label=Local\ storage host-uuid=`cat HostUuid.txt` | grep sr-uuid | cut -d\: -f2 | cut -d" " -f2 > SR-Uuid.txt
# xe pbd-list sr-name-label=Local\ storage host-uuid=`cat HostUuid.txt` | grep ^uuid | cut -d\: -f2 | cut -d" " -f2 > Uuid.txt
# xe pbd-list sr-name-label=Local\ storage host-uuid=`cat HostUuid.txt` | grep device-config| cut -d\: -f3 | cut -d" " -f2 > Device.txt
# Unplug and destroy the Local SR : 
# xe pbd-unplug uuid=`cat Uuid.txt | egrep "*-*-*-*-*" `
# xe sr-forget uuid=`cat SR-Uuid.txt | egrep "*-*-*-*-*" `
# Create the new Local SR : 
# xe sr-create content-type=user device-config:device=`cat Device.txt` host-uuid=`cat HostUuid.txt` name-label=Local\ storage shared=false type=ext

Stopping xo-server before compiling shouldn't be necessary unless someone tries to use XO while it's building.

That said, I would recommend building the source under /usr/src or ~/src or something and then moving the files ( mv * ) to something like /opt/xen-orchestra-DATE (or git revision)

Then use "stow" to create symlinks in /usr/local, like this
  stow -d   /opt/   -t   /usr/local   xen-orchestra-DATE

The stow command is in the CentOS repository or can be downloaded and compiled separately from any GNU mirror.

Make sure the /etc/xo-server/ config points to the relevant symlinks in /usr/local and restart xo-server

This way you can keep a number of different XO versions available in /opt and if there's a problem with any one of them you simply run
  stow -D  -d  /opt  -t    /usr/local    xen-orchestra-BADVERSION
to delete the symlinks to the bad version and
   stow -d   /opt   -t  /usr/local   xen-orchestra-GOODVERSION
to create links to the old, good one and then restart xo-server

When it's time to update the XO build go to the, now seemingly empty, source folder and run
  git reset HEAD --hard
to repopulate the working directory and then
  git pull && yarn && yarn build

Did you remember to restart xo-server after the build had finished?

If you're compiling the new version in the same directory as the old one it's good practice to save a copy of the old one first, before doing the git pull.

I did do it on my install, that's why I'm suggesting it.
The default values made me thing I had a semi-transparent film all over my display.

My install is on a physical machine (a laptop) so I don't know how I'd take a proper screenshot.
I don't think a phone photo would show the difference.

Unless it's an environmental decision to make the xsconsole as dim and washed out as possible, to save power, my humble suggestion would be to multiply the fgBright values by 1.249 to get 999,431,372, if my math is correct, and set fgNormal to something like 930,930,930

fgDark could either remain at its current values or be set to fbBright

I used tgt and no authentication before so I can't say.
I decided to try targetcli and authentication when I installed 8 beta.

No, it's probably not a blocker.

Connecting an iSCSI SR in xsconsole fails if there's a discovery password.
It works if I disable the authentication.

It works in XenOrchestra if I attach it as a new SR (With auth) AND have the same discovery username and password in the ACL of the iqn.
That still doesn't work in xsconsole.

My iscsi server uses targetcli-fb/LIO.