@wgomes yup thanks for bumping this topic, still having the problem too

While I was updating all the pools, a micro-update for 5 packages was released again. They come out every week now. Same issue with basic migration. Now it impossible.

Come on everyone! Click Here to vote to support HP IPMI info in XO!

Yes indeed, that's expected. XAPI affinity is on VM boot, not in the VM life. Then, it's the work of the load balancer.

Ping @Team-XO-Backend

@acebmxer Yes, 22 or 24 should work correctly. Some early versions of 24 had issues, but not currently. I'm running 24 and it is working.

@dinhngtu Yeah, I suspected that as well. So I inspected the SR and it showed connected to both hosts (at least in the XO UI - I didn't drop to the CLI to really confirm). By altering my workflow a bit and slowing down, I seem to have found the right "sweet spot" of delay and the issue hasn't resurfaced. Here's what I'm doing now, when I need to revert the snapshots of all three VMs: In the XO VM list, I select the three VMs and power them off at the same time. I then start with VM1 and eject the ISO, VM2 and eject the ISO, then VM3 and eject the ISO. By the time I circle back to VM1 for the next step, about 10-15 secs have elapsed. I then start with VM1 and revert the snapshot, and repeat the same on VM2 and VM3. By the time I circle back to VM1 for the next step, another 10-15 secs have elapsed. I re-attach the ISO to all three VMs in sequence. Another 10-15 secs elapse. I then start with VM1 and power all three VMs sequentially. The entire workflow takes about 30-45 secs, and I'm finding that by doing this, the issue hasn't resurfaced.

Good question! Ping @pdonias I assume

Just go to Settings > Servers tab in XO and remove the entry associated with this pool.

@olivierlambert It's even older than that. https://github.com/vatesfr/xen-orchestra/blob/master/CHANGELOG.v5.md#5540-2020-12-29 https://xen-orchestra.com/blog/xen-orchestra-5-54/

@DustyArmstrong thats super-strange, i actually have the same setup at home, 2 hp z240 machines running xcp-ng in a small pool. xcp1 is always up and running, xcp2 is powered down when I dont need it, everything important is running on xcp1, maybe that's the reason I don't run into these issues.

@florent Thanks again for your assistance, greatly appreciated.

@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