@olivierlambert said: Start the VM with xe vm-start uuid=<VM UUID> and see the error message there. Thanks , I believe I found the problem: [17:19 xcp-server1 ~]# xe vm-start uuid=4ba7c16c-f850-6001-830b-bf0f51e52a40 There are no suitable hosts to start this VM on. The following table provides per-host reasons for why the VM could not be started: xcp-server1 : Cannot start here [VM requires access to SR: da59d7a1-b08f-dd81-1258-65a380bd77d8 (Iso)] There were no servers available to complete the specified operation. I made changes to my Iso storage folder path: [image: 1782615502954-screenshot_20260627_160512.png] from: [image: 1782615535998-screenshot_20260626_220502.png] to: [image: 1782615681155-screenshot_20260627_210002.png] and when I tried to start my NTP VM, because I wanted to reinstall the OS is when I get the error message: [image: 1782616205507-screenshot_20260627_210723.png] Can you put the correct error message from the cli here instead of this generic one, because it causes far to much trouble shooting time? I knew directly where to go after seeing this part of the cli message: The following table provides per-host reasons for why the VM could not be started: xcp-server1 : Cannot start here [VM requires access to SR: da59d7a1-b08f-dd81-1258-65a380bd77d8 (Iso)] Also, I can start the NTP VM without the .iso as normal. However, I did find out why I lost control of the OSs as stated above. Since the latest updates, the keyboard does not work properly. I will come back with more details later. For now, my question is, is there a way to modify/edit the path to my Iso Storage without removing and redefining it, like you can with Cockpit, if not is/can this be a future feature added?: [image: 1782617180903-screenshot_20260627_212426.png]

@JamesG said: When I ask the system what it thinks the capabilities are, again I get Gen1x1: cat /sys/bus/pci/devices/0000:00:08.0/current_link_speed 2.5 GT/s PCIe cat /sys/bus/pci/devices/0000:00:08.0/current_link_width 1 cat /sys/bus/pci/devices/0000:00:08.0/max_link_speed 2.5 GT/s PCIe cat /sys/bus/pci/devices/0000:00:08.0/max_link_width 1 This information is actually crafted by QEMU, it doesn't represent the actual real device PCI state; you should check this from Dom0 which should be closer to reality.

Well you both just made my Friday! I can follow directions after all!

From what I can tell, the Netbox plugin in XO syncs VMs, interfaces and IPs, but it doesn't populate Netbox's separate Virtual Disks model yet, which is why you get the total disk space but an empty Virtual Disks tab. I don't think it's a permissions thing on your side, it looks more like a gap in what the plugin syncs today. There's already an open issue for disk-size sync (https://github.com/vatesfr/xen-orchestra/issues/7643), plus a few other Netbox requests in the tracker. If you want the per-disk sync added, the place it actually gets weighed is https://feedback.vates.tech, where the Netbox asks get prioritised together. It might also be worth a mention to @Team-XO-Backend, since they own the plugin and can say whether the newer Netbox virtual-disk model is on their radar. ecoutinho created this issue in vatesfr/xen-orchestra open Netbox plugin: Sync disk size error #7643

Evening @pierrebrunet My bad. I am now on commit b440f and the issue persist. I have written you a message with the link to the file. Regards, Marc

@yannsionneau Hi, is June still the target for the iso? Thanks

@niko thanks, that would help a ton!

mid 2026: you can't add a ipv6 address via XOA (XOA5) because the gui lacs the field for the v6 gateway-address XOA6 lacks feature to configure ips of the host the configuration of ipv6 (static) vie the "gui" on the host seems not be implemented yet (or i am missing something critical) command line configuration inside dom0 of the host is afaik not supported ? Some point looks like minor issues. it would be great to "address" pun intendet that as well

@Danp said: Smart Reboot option found on the host's Advanced tab does what you are asking Very nice!

Here is the log from when xen04 last crashed xen04-jun12-journalctl-crash-summary.txt

@Pilow pretty much

@olivierlambert said: I'm not sure it's a great idea, because even 64 hosts is huge in terms of VMs and fallout if you have a problem on your pool DB. Even if you drastically improve the current mechanism, the impact of a problem pool wide is far bigger with 64 hosts than 24 for example. It's more than purely tech, it's also a tech design/choice. Exactly, the failure domain just grows exponentially when going beyond a certain collective pool size. I was doing some more research and I found a few possible choices that Tesco may have moved too, but don't want to detract from this forum here.

@AlexanderK you could try to install perl-interpreter manually maybe? I happened to have a test host at hand that hasn't been updated since december, and the yum update went fine, perl interpreter was not installed before and yum update did install it on its own as a depency for openssl 3. Maybe others will have ideas as to why this would happen in your case.

@tuxen Doing some research, it doesn't look like the Xeon's I have are affected. But I'm willing to try the next time I need to reboot. Will report back after that.

Hello, Thanks for all !

@laszlobortel Hehe yeah, those are pretty old kernels. I'd say there's a good chance kernel upgrades will go a long way to alleviating the CPU hangs. I can't say it's exclusively a problem with lvmohba storage, that's just what we use because of our previous VMware infrastructure was block storage over fiber channel. We knew a physical infra overhaul wasn't in the cards for us for this migration so we stayed with our existing storage system. This bug bit us half way through the migration until we figured out upgrading the kernel generally fixed it.