@stormi Thanks. I appreciate it. But unfortunately, I'm unable to move workloads off the master in order to take it offline because of this situation. If the solution is to turn off a host while it has live workloads, then I'm just going to shutdown the 8.2.1 slave and upgrade it to 8.3. Then I have 2 members in the pool and it's fully upgraded. Let me tell you another edge case I encountered. There are some clear mistakes in here that I made, but it is related to this issue. When I took C offline and upgraded it to 8.3, I took the opportunity to convert it to UEFI boot. That meant reformatting the boot drive, not upgrading it. I wasn't worried about that. I took it out of the pool, reformatted it, and created a one-node 8.3 pool that has just node C in it. No biggie, right? I'll just have it join the pool with the 8.3 master and all is well. No, that's not going to work. Can I at least move some workloads onto it? Nope. When you do a fresh install, pool-enable-certificate-verification defaults to yes. When you upgrade a pool, pool-enable-certificate-verification defaults to no. So I have a half-upgraded pool with 2 nodes with certificate verification disabled, and a single-node 8.3 pool with certificate verification enabled. If I try to enable certificate verification on my half-upgraded pool? Our good friend NOT_SUPPORTED_DURING_UPGRADE() comes back to say "hi". As far as I can tell, it is not possible to disable certificate verification on the single-node 8.3 pool. So I have a one-node pool where I can't turn verification off and a 2-node, half-upgraded pool where I can't turn it on. That makes it really difficult for the two pools to interoperate. If I have to be known for something, let me be known as a cautionary tale.

No pun, just wait for everyone to get back from our yearly Vates internal event

Feel free to create a trial on an XOA, test stable and latest and tell us. It might be also related to your environment, but if it works at some commit and not later, it's weird. @florent & @bastien-nollet maybe?

Great! Keep us posted

@MathieuRA The context for my question is I created an app to control my VMs and though my app said a VM started it really didn't. When I went into the logs I noticed an error, so my thought is to be able to check the logs would be helpful to find out if there is an error or not. Let me update my app because I'm thinking I can get around not having access to the logs. Thank you for the prompt response! Have a blessed day!

In other words, you can safely remove them.

@dinhngtu Seems like an issue for this already exists: https://github.com/xcp-ng/xenadmin/issues/260 Added what I wrote above as a comment. Gnggi created this issue in xcp-ng/xenadmin open Showing wrong Virtualization state for VMs with Management agent 9.1.100 #260

@Forza you will have to switch to LATEST to profit from end month release STABLE is one version behind LATEST both are production ready.

okay weird. Let's see if there's other reports then

@ideal perhaps you could use advantage of dynamic memory https://docs.xcp-ng.org/vms/#dynamic-memory to oversubscribe memory and have all 4 VMs up at once... or reduce the allocated memory of your VMs, you seem to have a pretty big VM in terms of memory in comparison to the 2 others on your screenshot

Thanks Olivier! That is what we assumed, but with how the 3 hosts per pool was in there under the essentials licenses it was up for debate

But giving your feedback on how you solved it might help many people in the future Thanks!

I'm seeing something similar, not sure if its the same issue, but mine stops at 95% and just hangs there: [12:18 sto-xcp1 ~]# xe task-list uuid ( RO) : c1056d36-b195-056a-4121-e82d7fc851fb name-label ( RO): [XO] Importing content into VDI [ESXI]DEBIAN 12 fiona.iextreme.org-flat.vmdk on SR Local storage name-description ( RO): status ( RO): pending progress ( RO): 0.950 The nbdkit debug-log can be found here: https://mirror2.iextreme.org/temp/stderr Edit: some additional info Xen Orchestra, commit 1640a Master, commit 1640a

@ph7 Thank you!

@Bastien-Nollet Great, thanks!

@vhaelan Hello. What's the output of rpm -qa | grep intel-gpu-firmware ?

Figured it out after some digging, appears it's related to Netbox having ipv4 translated into ipv6 for that field, so to use IPv4 you have to have :ffff:x.x.x.x/128 as your IP address (the x's being your octet). Once you do this it works without issue.

@thomasp I'm struggling so much to find the time to do it, and my colleagues are equally busy, but I'll try to make it happen this week!