julienXOvates

@acomav We will actually propose to change the date and time format in XO6 settings, so you would be able to choose between :

• YYYY-MM-DD
• MM/DD/YYYY
• DD/MM/YYYY
  and 12h or 24h time format.
  Hopefully in one of the next 3 months !
  I hope that will answer your need, otherwise let me know !

@jr-m4 said:

@olivierlambert said:

Ah sorry I read it too quickly. This panel is only there in some occasions, but I see the point of only displaying it when we click on a relevant element. Feedback for you @julienxovates

While on the topic of the tree-view panel.
Have you noticed that the indentation changes if there is a chevron indicating that there are VMs on a host? Making it so that the hosts no longer are alinged vertically

Hi @jr-m4, it took some time but we corrected the identation in 6.7 (latest)

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 !

This issue should be fixed in the latest release (to be out today).

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