Hi @nasheayahu,

1/ are you running the latest XO from source ?
2/ did you follow this to create the ZFS volume => https://docs.xcp-ng.org/storage/#zfs ?
3/ did you try with "ext" type instead ? or your requirement is QCOW2 with ZFS ?

The "import QCOW2" is currently not yet implemented, hence the API error (it should have been not permitted actually); it should be merged in the next XO release.

Hi,
We are currently working on a tool to better industrialize VM import from VMware into the VMS stack, based on N8N (https://n8n.io). Stay tuned !!!

Hi @mdm,

Here is the response from a SME
1-

• XO get the VM metadata through soap api and create the vm /network
• XO use the nbdkit + nbdkit-vddk package , connecting to each disk
• XO connect through NBD to nbdkit
• XO list the allocated blocks
• XO create the disk
• XO read the block and import the data into the disk (though a vhd or qcow2 stream depending on the size)

2- though XO. There is a lot of disk transform occuring here

3- not anymore, it was too brittle, especially on when the disk are locked or not. Also it was not scaling too well
4- see 3- +
vddk transfer is overwhelmly faster that previous access through http, is compatible with VSAN and don't lock the disks.

(+ also see https://xen-orchestra.com/blog/xen-orchestra-5-110/ section "VMware to Vates (V2V)" where we made key improvements)

@abudef we'll add it in the near-term (June hopefully) as QCOW2 support is a major update in the VMS stack !

@ph7 said:

Xen Orchestra, commit 71fa8
With a snapshot attached to a VM, it is reported to use 0% of 100GB

And if I remove the snaphot

And that seems to be more accurate

Hi @ph7,
The VDI storage used space with snapshots has been fixed in XO 6.5 !

@escape222 said:

Slow booting on Debian 13 VM created from a template

I recently tried cloning a VM from a template (created from a full install of Debian 13). What was noticed was that the system takes forever to boot when the VM is created from XO-6. The issue does not happen in XO-5. The VM seems to hang at the TianoCore boot screen .

What I noticed is that when the VM is cloned with XO-6 the boot order somehow changes to Network boot as the first option

This does not happen (change of boot order) if the VM is cloned from XO-5 and there is no boot delay. The boot process seems to wait for more than 2 minutes before it fails network boot and then proceeds normally to boot from the Hard drive

Thanks

Hi @escape222,
For info boot order issue has been resolved in XO 6.5 !

@jr-m4 Thank you for this feedback. We'll try to make it better based on this !

@ph7 Thanks for those details, very helpful. We'll have a look.

OK, we'll have another look at it, sorry for this !

@ph7 said:

Xen Orchestra, commit 71fa8
With a snapshot attached to a VM, it is reported to use 0% of 100GB

And if I remove the snaphot

And that seems to be more accurate

Hi @ph7,
The VDI storage used space with snapshots has been fixed in XO 6.5 !

@escape222 said:

Slow booting on Debian 13 VM created from a template

I recently tried cloning a VM from a template (created from a full install of Debian 13). What was noticed was that the system takes forever to boot when the VM is created from XO-6. The issue does not happen in XO-5. The VM seems to hang at the TianoCore boot screen .

What I noticed is that when the VM is cloned with XO-6 the boot order somehow changes to Network boot as the first option

This does not happen (change of boot order) if the VM is cloned from XO-5 and there is no boot delay. The boot process seems to wait for more than 2 minutes before it fails network boot and then proceeds normally to boot from the Hard drive

Thanks

Hi @escape222,
For info boot order issue has been resolved in XO 6.5 !

@henri9813 said:

Hello,

I see also this behavior which is "new" since few weeks.

Previously, when a backup start:

• it stake a snapshot ( if there another one before, it delete it ).
• it upload the snapshot as a backup
• it coalesce the backup on the remote.
• end of the game.

Now, the old snapshots are not deleted anymore which can lead easily to some disk full.

Even with a retention of 1, the problem is present.

I observe this only in Backup job, not DR/CR job.

I just updated my XO to latest version, i will see if the issue is fixed.

Hi @henri9813 ,
Issue should be resolved in 6.5.x, can you confirm on your side ?
Thanks!

Hi @andrew
Can you provide some logs ? also assuming you have this issue in the "latest" branch only ?

@tonyp90 great, thanks !

Hi @tonyp90, can you confirm issue is resolved with the latest version ? (I saw 6a5eb1205 is from Oct 2025!). Thanks!

Hi @tonyp90, strange that this happened on your backup host as it is not supposed to, since we prevent VMs to auto-start when Incremental Replication target host is rebooted (see https://docs.xen-orchestra.com/xo5/incremental_replication).
Which XO version are you running ? Do you have a license so you could open a support ticket ?

@florent I think we discussed this and we thought it's not meaningful to have CR snapshots counted in the Dashboard (otherwise, we should maybe display standalone snapshots and snapshots from backups separately in 2 colmuns in XO6).