@florent Thank you for reviewing the log file. You were absolutely correct! I increased the virtual machine's ram from 3gb to 5gb and it updated extremely fast and totally successful! I appreciate your time and effort. FYI ... I have a better idea where to look for the error in the log file now, do you have a link to a listing of error codes?

@Danp damned, i forget about this button) Now it works, thanks.

@olivierlambert great news, I had a feeling this was in the works! Thanks for the info.

i also have slow speeds. Checked network connections works perfect. Checked disk performance is really good. But on migration speed is around 25mb/s.

@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...)

I am running NVIDIA P40s on a DELL R720/R730 and a NVIDIA A2000 12GB on a DELL Optiplex 9010 in my playlab. Getting the GPUs to be accessible for VMs was quite easy: shutdown the XCP-ng host, install the GPUs, start the host again, activate the GPU in the advanced settings of the host in the PCI Devices section (“Passthrough enabled”). The host will restart at this point after displaying a warning. That's it – the GPU can now be assigned to a VM in the VMs advanced settings. I do use the GPUs for AI workloads under Debian though, so your use case might vary.

@olivierlambert okay, understood. it is small minor cosmetic problem as of now. need to get you an access to our internal developped app, to show you the potential of sub-xoas ^^' almost out of alpha phase

Something to document @thomas-dkmt

@olivierlambert so strange though. i have it enabled on 4 pools, that didn't propagte on hosts. still VM boots up when not needed as explained on fist post of the thread. i'll try différent combinations to see what's really going on

Thanks, we need to update this!

Hello All, This issue seem to completely go away on a older branch/tag if i build it from below for XO: xo-lite-v0.17.0 So the issue I would think is coming from the newer version of XO. Not sure best way to test this. So I am going back to an older commit. If anyone has any suggestion I can try helping as its an annoying issue.

@jkatz So everyone is cleared since I just experience the same issue not allowing me to create a new vm using the template. Before you use the Windows 11 Template and you have it with SYSPREP ready. You need to go down to advanced and make sure you delete the VTPM [image: 1769552292859-5d61aad5-013e-4cff-af7c-adbb4c4ca809-image.png] then create the Template. Once you create the vm again you will not receive the error and a vtpm will be created for the new VM with no issue. Hope this helps.

You can forget them, no issue.

@pdonias https://docs.xen-orchestra.com/users [...] Operator An operator can make everyday operations on assigned objects. For example, on a VM: eject a CD insert a CD (if he can view the ISO storage repository) start, restart, shutdown, suspend/resume it All other operations are forbidden. [...] As I understand it (I may be mistaken), changing the "Rate Limit" is already a configuration change and should not be available to an Operator.

Indeed, it's hosted in Lyon, so an issue could happen in many places in the middle ^^

I don't think stop will remove it, probably better to yum remove it. For Openmetrics, check: https://docs.xen-orchestra.com/advanced#openmetrics--prometheus-integration I switched our own production to that, so far it looks promising.

@Pilow the rrd ( the stats ) use the same code path as the backup . I am not sure if it's a feature or a bug, but at least it's a good canary the data volume of stats can be quite huge and have an impact on management. So it's a little justifiable to use the same network for backup and stats, at least until we can separate things more clealy . At least it helps a lot to check if the network is really reachable (sometimes because of third party filtering or ip configuration error , other to the xoa missing some network), and the downside is not to dangerous.

@bvitnik Thanks for giving more details. I will give a try with each of them (netplan, ..etc)

@acebmxer It's not pretty, but its failsafe. The proceedure looked like this in our case: Disable HA in the "old pool" Put a host in the "old pool" into maintenance mode Reinstall that host and connect it to XOA and then patch it Create a "new pool" from that host Create a new LUN or NFS share in the SAN for "new pool" and attach it to "new pool" Live migrate VM's over from "old pool" to "new pool" Once you've freed up another host you repeate step 2 and 3 and then join that host to "new pool". It is important that you patch it before joining it to the pool, that is done by going to Settings -> Servers in XOA and connect to it manually. And then just continue untill you're done. Live migration is pretty reliable now days, so this works pretty good and since we had 10G network its not taking as long as it used to do with 1G network. We did this after a major incident on our primary production site where 2 out of 4 hosts in a pool "suddenly" lost their NIC's after updating them. Since then we never updated the pools again. Standalone hosts are fine tho, they never did this. Luckily we had 2 other pools where we could migrate the VM's to, but we couldn't realy trust the updating after that.