Just updated my homelab server from XCP-ng 7.6 to XCP-ng 8.0 Beta, so far so good. I also tested the new experimental UEFI mode with Windows VM, seems good too. I also tested the new XOA deployment through the Web interface of my host, perfect ! We will see during the following week how it goes

@olivierlambert Yep cool, thanks for your help

@pdonias Thanks for confirming that this issue wasn't caused by the use of a 3rd party script.

Reviewed my server versions after rolling back to 7.6.3.20, that was a misunderstanding on my part. It's just 6.5 that we are primarily running that is now incompatible. I was mixing that up with another hypervisor's versioning system.

+1 640KiB for everyone

@Robert-COLIN That's great! Good luck :-).

Will do. Done.

Thanks for your feedback. We also took in consideration what people asked for the next UI

@axel said in USB Hard drives for VM exports: thx i will try it soon expect very. slow. data. transfer

That's why I thought. NEVER enable base repo. If you want a package from their, just enable it during the yum install command line.

Damn i guess this does not work (due to insufficent space?): May 8 19:07:34 xen-01-b SMGC: [8597] Set vhd-blocks = eJzt2LEJgEAMhtHS0tFvFMdwHC0FA9ENDkEJeO/Vge+vs+TtzGyZkT0xdU8+tc+1/SjuH8X9tTYPAAAAAAAAAAAAAMAzrXoAADCcbfA+AAAA8H/+D++5AMbVs9Q= for *ef6aa466[VHD](300.000G//300.504G|n) May 8 19:07:34 xen-01-b SMGC: [8597] Num combined blocks = 153555 May 8 19:07:34 xen-01-b SMGC: [8597] Coalesced size = 300.504G May 8 19:07:34 xen-01-b SMGC: [8597] Got other-config for b328d061[VHD](300.000G/242.496G/300.594G|n): {'leaf-coalesce': 'offline', 'content_id': 'c4cec5e9-e6f4-18a9-ad52-8db03ef0f2c9'} May 8 19:07:34 xen-01-b SMGC: [8597] No space to leaf-coalesce b328d061[VHD](300.000G/242.496G/300.594G|n) (free space: 254355177472) May 8 19:07:34 xen-01-b SMGC: [8597] ...but enough space if skip snap-coalesce May 8 19:07:34 xen-01-b SMGC: [8597] Set leaf-coalesce = offline for b328d061[VHD](300.000G/242.496G/300.594G|n) May 8 19:07:34 xen-01-b SMGC: [8597] Got sm-config for *ef6aa466[VHD](300.000G//300.504G|n): {'read-caching-reason-24097d1c-c678-417e-8a00-2257aee78fd2': 'SR_NOT_SUPPORTED', 'read-caching-enabled-on-24097d1c-c678-417e-8a00-2257aee78fd2': 'false', 'vdi_type': 'vhd', 'vhd-blocks': 'eJzt2LEJgEAMhtHS0tFvFMdwHC0FA9ENDkEJeO/Vge+vs+TtzGyZkT0xdU8+tc+1/SjuH8X9tTYPAAAAAAAAAAAAAMAzrXoAADCcbfA+AAAA8H/+D++5AMbVs9Q='} May 8 19:07:34 xen-01-b SMGC: [8597] No work, exiting May 8 19:07:34 xen-01-b SMGC: [8597] GC process exiting, no work left I dont fully understand that, nothing changed?!: May 8 19:07:34 xen-01-b SMGC: [8597] SR 646a ('Local SR R10 - 900GB') (2 VDIs in 1 VHD trees): showing only VHD trees that changed: May 8 19:07:34 xen-01-b SMGC: [8597] *ef6aa466[VHD](300.000G//300.504G|n) May 8 19:07:34 xen-01-b SMGC: [8597] b328d061[VHD](300.000G/242.496G/300.594G|n) May 8 19:07:34 xen-01-b SMGC: [8597]

Likely orphaned VDIs. Removing them should fix coalesce.

Thanks for the feedback!

I ran into something VERY similar with XCP-ng and\or XOA a while back - ended up with close to 200 new "clients" showing up on my Meraki gear. They weren't even "connected" long enough to register as IP clients, only MAC clients (ARP, possibly). I didn't think much about it at the time, as both the MAC addresses and hardware information didn't seem to be tied to any actual device by some manufacturer. I may be able to pull those out from my client history... EDIT: Here is a small section of that list:

Glad I was able to help.

@olivierlambert You're welcome. As a start, to prevent false positive message that the XOA VM is ready at some IP address, the script could check the power-state in the result of # xe vm-list name-label=XOA uuid ( RO) : e58ce2ec-4fe4-5a9f-70b1-f6a5ca204946 name-label ( RW): XOA power-state ( RO): running (whether running or not).

@maxcuttins oops

You can boot a VM on PXE by selecting the right boot order (enabling "Network" in boot order in XO for example) Then you need to setup a PXE server, you can fine various guides by googling "PXE server setup", eg this one)

@olivierlambert Yep for sure, and your support here is so good it's not a huge problem, but I more feel bad bothering you with stupid questions more than anything haha

Okay so maybe there is a race condition somewhere with zstd (gut feeling, about premature EOF and using ZSTD). @johnelse what do you think? Do you need better logs?