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.

@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,
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 !

@acebmxer said:

Just updated to latest commit - 93909

Glade to see more progress on v6.

Yes, that's one of the next big pieces we're going to add to XO6 UI !

@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 !

@Greg_E well, UI is not ready yet (while REST API is), above screen is just the base !

@acebmxer said:

Just updated to latest commit - 93909

Glade to see more progress on v6.

Yes, that's one of the next big pieces we're going to add to XO6 UI !

We prioritized Network creation in Xen Orchestra as they are mostly Pool-level objects (supposedly with multiple hosts), but we will rework on XO-Lite soon, so you could perform all basic actions as well from XO-Lite.

@Hex said:

Here is a small usability suggestion. In the Resources dashboard, in Pool view and Host view, positions of CPU and RAM are swapped. I occasionally get a brain freeze when switching between Host and Pool dashboard.

Right, thanks! We'll change this !

@johnnezero
To add one more info on top of Mathieu's post : ACL (XO5 only) and RBAC (in REST API + XO6 soon) are completely separate, so better use RBAC as it gives much more flexibility !
Interesting plugin by the way !!!

@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!