Here's a work in progress version of the FAQ that will go with the release. QCOW2 FAQ What storage space available do I need to have on my SR to have large QCOW2 disks to support snapshots? Depending on a thin or thick allocated SR type, the answer is the same as VHD. A thin allocated is almost free, just a bit of data for the metadata of a few new VDI. For thick allocated, you need the space for the base copy, the snapshot and the active disk. Must I create new SRs to create large disks? No. Most existing SR will support QCOW2. LinstorSR and SMBSR (for VDI) does not support QCOW2. Can we have multiples different type of VDIs (VHD and QCOW2) on the same SR? Yes, it’s supported, any existing SR (unless unsupported e.g. linstor) will be able to create QCOW2 beside VHD after installing the new sm package What happen in Live migration scenarios? preferred-image-formats on the PBD of the master of a SR will choose the destination format in case of a migration. source preferred-image-format VHD or no format specified preferred-image-format qcow2 qcow2 >2 TiB X qcow2 qcow2 <2 TiB vhd qcow2 vhd vhd qcow2 Can we create QCOW2 VDI from XO? XO hasn’t yet added the possibility to choose the image format at the VDI creation. But if you try to create a VDI bigger than 2TiB on a SR without any preferred image formats configuration or if preferred image formats contains QCOW2, it will create a QCOW2. Can we change the cluster size? Yes, on File based SR, you can create a QCOW2 with a different cluster size with the command: qemu-img create -f qcow2 -o cluster_size=2M $(uuidgen).qcow2 10G xe sr-scan uuid=<SR UUID> # to introduce it in the XAPI The qemu-img command will print the name, the VDI is <VDI UUI>.qcow2 from the output. We have not exposed the cluster size in any API call, which would allow you to create these VDIs more easily. Can you create a SR which only ever manages QCOW2 disks? How? Yes, you can by setting the preferred-image-formats parameter to only qcow2. Can you convert an existing SR so that it only manages QCOW2 disks? If so, and it had VHDs, what happens to them? You can modify a SR to manage QCOW2 by modifying the preferred-image-formats parameter of the PBD’s device-config. Modifying the PBD necessitates to delete it and recreate it with the new parameter. This implies stopping access to all VDIs of the SR on the master (you can for shared SR migrate all VMs with VDIs on other hosts in the pool and temporarily stop the PBD of the master to recreate it, the parameter only need to be set on the PBD of the master). If the SR had VHDs, they will continue to exist and be usable but won’t be automatically transformed in QCOW2. Can I resize my VDI above 2 TiB? A disk in VHD format can’t be resized above 2 TiB, no automatic format change is implemented. It is technically possible to resize above 2 TiB following a migration that would have transferred the VDI to QCOW2. Is there any thing to do to enable the new feature? Installing updated packages that supports QCOW2 is enough to enable the new feature (packages: xapi, sm, blktap). Creating a VDI bigger than 2 TiB in XO will create a QCOW2 VDI instead of failing. Can I create QCOW2 disks lesser than 2 TiB? Yes, but you need to create it manually while setting sm-config:image-format=qcow2 or configure preferred image formats on the SR. Is QCOW2 format the default format now? Is it the best practice? We kept VHD as the default format in order to limit the impact on production. In the future, QCOW2 will become the default image format for new disks, and VHD progressively deprecated. What’s the maximum disk size? The current limit is set to 16 TiB. It’s not a technical limit, it’s a limit that we corresponds to what we tested. We will raise it progressively in the future. We’ll be able to go up to 64 TiB before meeting a new technical limit related to live migration support, that we will adress at this point. The theoretical maximum is even higher. We’re not limited by the image format anymore. Can I import without modification my KVM QCOW2 disk in XCP-ng? No. You can import them, but they need to be configured to boot with the drivers like in this documentation: https://docs.xcp-ng.org/installation/migrate-to-xcp-ng/#-from-kvm-libvirt You can just skip the conversion to VHD. So it should work depending on different configuration.

@Tristis-Oris maybe a few comparative screenshots would help

@dinhngtu You rock - thank you!

Thank you every visitors and for those who did not had the chance to visit fosdem check this report: https://xcp-ng.org/blog/2026/02/19/fosdem-2026-follow-up/ [image: vates-xcp-ng-at-fosdem-2026-1.webp] One question, I promised to forward to the forum, how many VM are you running on XCP-ng ? Dozen, hundreds, thousands or more ?

If I remember some previous discussions, EVE-ng uses some features that doesn't work in nested mode with Xen.

@uberiain at this point, when I am uninstall the old XCP-ng center software, and install the new msi, I just realized the xcp-ng keeps the settings file in Roaming folder. (C:\Users\user\AppData\Roaming\XCP-ng) When I deleted it I could re-register the servers.

@psafont Sounds good on point #1. On point #2 I agree LLA shouldn't be the primary management IPv6 address on the interface, but you could run into trouble by not having a LLA address assigned at all. All of the IPv6 standards assume a LLA is assigned to an interface running IPv6 for things like NDP or RA to work ergo mysterious things could break as a result of an LLA address not being assigned. Just spitballing here, but if you're concerned that only an LLA would be assigned to an interface then perhaps there could be logic to disable IPv6 for said management interface if no non-LLA address is assigned, or IPv4 could be preferred if only LLA addresses as assigned?

XCP-ng 8.2 has just reached its end of life, but the adventure continues with XCP-ng 8.3 (and other versions to come). You can read the communication on this point on our blog: https://xcp-ng.org/blog/2025/09/16/xcp-ng-8-2-lts-reached-its-end-of-life/ To continue benefiting from updates and developments, we invite you, if you haven't already done so, to upgrade your systems to XCP-ng 8.3. A relevant thread has been around for quite some time if you want to participate in early testing of the updates: https://xcp-ng.org/forum/topic/9964/xcp-ng-8-3-updates-announcements-and-testing/

Yes, the old method should work

@TrapoSAMA All of mine are 2022, but saw this in previous driver versions with 2025. Low priority on this so I haven't fixed it yet.

@dinhngtu Thanks and good point. After my previous post I did stumble across some info (can't find the links) that suggested something similar. If I'm remembering correctly, the basic idea was the flash/NVRAM memory on the motherboard, which stores boot entries, is limited. If it's full, it's possible / may be necessary to do some cleanup using the bios itself or utilities available for Linux (efibootmgr) and Windows (bcdedit). I've not tried this myself as our install is working properly, but perhaps that can help someone else in the event they stumble across this particular issue.

@Danp Oh thanks, that makes sense, though I am not sure how I got it to work in the POC... Cold migration will be fine for the time being anyway

@yllar Maybe it was because of the loopdevice not being completely created indeed. No error for this GC run. Everything should be ok then

@MW6 You've lost two disks in a single array, you're data is lost. Time to restore from backup.

@olivierlambert The only place running XCP-ng on things like an RK3588 make sense is for home lab stuff, I probably wouldn't even build work lab stuff on these. Never enough ram (so far) and limited cores, plus almost everything will need to be running in virtual processor architecture. All that said, it might be neat to simulate these ARM processors in x86 so that we could create a VM of the Pi, etc.

On the VMware side, it's possible VMware doesn't set the right mode, so try to boot in BIOS or UEFI to see if it boots.