@blueh2o said in Health check scripts. Where is the example?: xen-orchestra/backups/docs/healthcheck example/wait30seconds.sh that would be here https://github.com/vatesfr/xen-orchestra/tree/master/%40xen-orchestra/backups/docs

@jqueiroz said in Second IP for Hosts Interface: I have a situation where I would like to add a second IPv4 address to the management interface of a host. I am installing a host that will be used in another location and I would like to add the address of that location to the management interface before shipping the machine there. Is it possible to do this, or should I continue using the current procedure (making the necessary configurations and change the address shortly before shutting down the machine and packing it for transport)? there is a nuance between secondary IP and secondary MANAGEMENT IP if you have multiple NICS, you could add & configure the destination site IP on it, but it is not flagged management yet. once the server gets on the new site, you could access web ui by this IP address (or SSH) and then either go to web console/xs server or SSH and do the necessary to change management to the good PIF/IP ?

@MajorP93 It's being packaged at the moment. between this and the testing that needs to be done it might take a couple of weeks to be released, but I can't promise anything yet

Not sure If correct but the vhd-tool check seem quite basic. Looks like it only do kind of a "wrapper" check and not a full integrity check $ vhd-tool check 4156d2ea-d39d-436d-b89f-06ad64949c53.vhd 0 START of section 'footer_at_top' 1ff END of section 'footer_at_top' 200 START of section 'header' 5ff END of section 'header' 600 START of section 'BAT' 195ff END of section 'BAT' 67a00 START of section 'locator block 0' 67bff END of section 'locator block 0' 67c00 START of section 'locator block 1' 67dff END of section 'locator block 1' 67e00 START of section 'locator block 2' 67fff END of section 'locator block 2'

@dinhngtu Really appreciate the help finally got it working. In Debian 12 I was able to boot to it without issues even with 3GB (on both UEFI and BIO) but obviously not recommended for logs etc... Testing for Debian 13 now to see if there is something else affecting it and there is definitely weird issue with UEFI. BIOs boots up fine its the UEFI settings. This seem to affect the display as far as I can tell as I can ssh into the terminal without issue. I think part of the issue is to use only generic or genericcloud and avoid nocloud as its doesn't come with cloud-init install... They mention this on the site where we download it. Didn't quite understand until now...: azure: Optimized for the Microsoft Azure environment ec2: Optimized for the Amazon EC2 generic: Should run in any environment using cloud-init, for e.g. OpenStack, DigitalOcean and also on bare metal. genericcloud: Identical to generic but with a reduced set of hardware drivers in the kernel. If it does not work for your use case, you should use the generic images. nocloud: Does not run cloud-init and boots directly to a root prompt. Useful for local VM instantiation with tools like QEMU. (AVOID as it does not work with cloud init but it boot up so that was extremely deceiving...)

@whyberg Nope... that feature is part of the CPU. But is that the actual problem? Maybe... As that machine is too old to do any real work, it's a fine toy. There are better faster cheap test machines available.

@florent Delta backup is also leaving old snapshots on some VMs. It should only have one (current) snapshot for the nightly backup. This is an issue on 1 of 100 VMs. XCP (Jan 2026 update) and XO (91c5d) are current. [image: 1770510564402-30de9803-0b8d-488d-b160-57c623f66e78-image.png]

Edit: For anyone with this issue, stopping and starting the Openmetrics plugin after saving the password in XO fixed it. I keep getting the {"error":"Query authentication does not match server setting"} problem, is there something I'm missing? I run XO proxied through Nginx with HTTPS, is there some additional config required to get it working? I have set the key with openssl rand -hex 32 and have verified that is saved correctly in the plugin, and that I am using the same key for curl. I am able to obtain the /health endpoint as expected, I just cannot obtain the full metrics, only returns that error. Command: curl --insecure -H "Authorization: Bearer mytoken" https://xo.mydomain.local/openmetrics/metrics XO commit: 91c5d I should note that running the command inside my Docker container returns only the error, including the health endpoint. Do I need to expose 9004?