patch is released

@rniesen Do you mean occasional hangs? Yes, Server 2025 is known to hang if these options are not present.

@florent okay but at 3 days without reboot i'm like this : [image: 1772185233532-ff2692b9-ea32-4e91-b30b-cb3ac96398d6-image.png] still on XOA 6.1.2

Hello, I have hardware issues, specially on the disks. Unfortunately I don't have fully access to the machine to be able to confirm if is effectively disks( more likely ) or back-plane. Interestingly some of those VMs does work, I can boot them and work with them but cannot copy the disks. Since those are Windows server VM I have also tried the Windows backup tool and this failed as well to perform to finish the backup. So I'm closing this investigation as hardware issue.

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

@mjr99 I bypassed it weeks ago. Didn't have to downgrade netbox. At the time. I upgraded to the latest Xo from sources. Then netbox worked. I shall be upgrading xo soon again Thank you all.

The thing is that it works very well and doesn't need fixes… I know, not usual right? It was so stable that we left it like that waiting for people coming for bugs and nothing happened… We'll cut a 1.0 in the next weeks/months.

Instruction published: https://docs.xen-orchestra.com/sdn_controller#openssl-3--sdn-upgrade-path Any volunteer to test this along upcoming XCP-ng update ?

@afmart_dei could you share the /var/log/xensource.log of the joining host ? ideally the whole part after the host started (you could look at the file before rebooting and strip all lines before the last line you saw)

@Andrew This was the exact problem I was facing. The affected VMs still had the guest-tools.iso mounted in the virtual drive. Once I ejected the ISO, I was able to clear the errors and the backup jobs resumed normal operation. For anyone else hitting this "stuck delta" or VDI_IN_USE state, here is the exact workflow I followed to resolve it: Shut down the VM (Essential to release all storage locks). Eject the ISO/CD from the VM console or CLI. Delete all snapshots associated with the VM (including any old or "ghost" backup snapshots). Delete the VM's backup folder from the remote SR/Backup target to ensure a clean metadata start. Monitor the Coalesce process (via SMlog) and wait for it to finish flattening the VHD chain. Power the VM back on. Manually trigger a Backup Job. Following these steps, the first run was (as expected) a Full backup, but every subsequent run has been a successful Delta with no "hanging" snapshots left behind.

@florent Thanks, if there is something I need to do to coalesce the vdis to avoid disaster, that would be good to understand. I had been thinking it was just an XO issue that would not affect running vms and their vdis.

@nikade said in Every virtual machine I restart doesn't boot.: @DustinB yeah im guessing the VDI isn't attached to the VM for some reason, based on the screenshot. Im also wondering if he ever rebooted the VM's after installing them with PXE Right, it's a likely answer... but even then I would've expected his PXE server to just restart the installation process all over again... assuming that the disk is attached to the VM etc and that PXE boot isn't disabled automatically like it is with an ISO after first boot. haha

@benapetr said in Import from VMware err: name: AssertionError: Expected "actual" to be strictly unequal to: undefined: Hello, since this never had a clear resolution, here is explanation of the bug and why it happens: There is a bug in disk iteration in that XO vmware plugin (somewhere in that esxi.mjs I don't remember exact location) - it basically expects that all disks of VM exist in same datastore and if they don't it crashes as the next disk in unexpectedly missing (undefined) Workaround is rather simple - select the VM in vmware, migrate -> storage, disable DRS (important) and then select any DS that no disks current exist on. If you select and DS that is already used by same VM it will sometimes not get fixed! It also may happen even if VM is "apparently" looking like it's on single DS, even if it reports as such, still try to migrate it to another DS, and disable DRS so that really all files, even meta files are in same directory. Then run XO import again, it will magically work. thanks you for the input we were under the assumption that all the disk of a VM are in the same datastore the fix should be too hard now that you did the hard work edit: card created in our backlog, I will take a look after the release to see how hard it is to implement

Aha! I will move to prometheus in the future, but at the moment it is more basic. Thank you!

@pilow As I am completly new to this scripting and such I did reach out to Ai for assistance and believe the license check should be bypassed now. Again not suggested to use in production. Use at your own risk. still has its own branch for more testing before merging to main branch.

@florent So If my Mikrotik router is sitting between XO and the HITRON and the HITRON is power cycled, because the Mikrotik is the gateway as far as XO is concerned and the gateway is not down, will the 10 minute timeout apply or might it timeout faster than that?

@Cyrille

Hi, does anyone have any tips regarding getting the serial port to show up in xcp-ng? I imagine this normally should just work.. I am not sure why it doesnt show up in xcp-ng, while it shows enabled in the bios?