@gthvn1 Yeah, that works.
I can get the logs both from the same host and from the other one in the pool.

I managed to download from master now as well, with the same gzip complaint and the same "Forkhelpers.Subprocess_failed(1)" in the log

@andriy.sultanov I'm not seeing any errors after it stalls.

One funny thing is that the pool master usually stalls after approximately 135MB and the slave stalls after 230MB
/var/log on master is half the size of slave's so that may be why.

Another funny thing is that when I tried the slave once more it actually finished the download at 230MB but my subsequent "tar -xf" complained about "gzip: stdin: decompression OK, trailing garbage ignored"
And for some reason the files it extracted were 528MB whereas they're 498MB on the server.
Maybe that's a matter of my using XFS vs the server's ext3, though.

That "successful" download resulted in

xapi: [error||307417 :::80||backtrace] Xapi#getResource /host_logs_download R:51bd50ee890d failed with exception Forkhelpers.Subprocess_failed(1)

in xensource.log.
So it seems to fail to properly close the transfer session most of the time and the file compression seems to be somewhat buggy as well.
Maybe those things are related somehow.

@stormi Any hint on what to look for?

I see these entries when the download starts but no subsequent errors or anything else that stands out when the download stalls

xapi: [ info||1520711 HTTPS 10.x.y.z->:::80|task.create D:b06a0108fbb7|taskhelper] task Xapi#getResource /host_logs_download R:8ea91ee79d9a (uuid:a-b-c-d-e) created (trackid=18e32f90af09a295c704ca6099aaef26) by task D:b06a0108fbb7
xapi: [debug||1520711 :::80||xapi_logs_download] running logs-download handler
xapi: [ info||1520711 :::80||taskhelper] task Xapi#getResource /host_logs_download R:8ea91ee79d9a forwarded (trackid=18e32f90af09a295c704ca6099aaef26)
xapi: [debug||1520711 HTTPS 10.x.y.z->:::80|Xapi#getResource /host_logs_download R:8ea91ee79d9a|xapi_logs_download] send the http headers

Same problem here. In my case it downloads about 30MB before it stalls.

XCP-ng version : 8.2.1 with March updates
XO : I tried both 9c27b53df and the older 708b9b5bc
Browser : Firefox and Chrome in Linux

To run a command in the current directory you have to prepend it with ./
So try ./recover-account-cli.mjs

@AlexQuorum Does

openssl  x509  -noout -text -in /etc/xensource/xapi-ssl.pem | grep bit

show 2048 or more and did you remember to do a

systemctl restart xapi

after you replaced the cert?

@tony Is your storage thick or thin provisioned, if you click on the Advanced tab?
If it's a thin storage it could be that the amount "used" is the disk size you've specified when creating the VMs and the bar represents the actual number of GBs used right now.

@saneece said in XO Lite: building an embedded UI in XCP-ng:

Can you explain why the calling on HOST_URL/xolite.html did not work and why I needed your special URL

Yeah, I was just explaining why HOST_URL/xolite.html didn't work for you.
You only ran wget https://lite.xen-orchestra.com/
and that's why your log screenshots says that it's saving to index.html.

If you had run the entire command it would have said "Saving to /opt/xensource/www/xolite.html " and you would have been able to access it the "normal" way.

@saneece The XO Lite installing instructions say that you should run this command on your xcp-ng server

wget https://lite.xen-orchestra.com/ -O /opt/xensource/www/xolite.html

You seem to have omitted the -O /opt/xensource/www/xolite.html part, since your screenshot talks about "Saving as index.html", and that's why you can't go to HOST_URL/xolite.html

@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

closed 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.