@Danp

Thanks for the info about chrony being used, that made it much easier to resolve.
I simply had to modify the /etc/chrony.conf on the XCP-ng hosts and restart the service (chronyd) to make the hosts properly synchronize the time.
Apparently, this was already done on the XOA (/etc/chrony/chrony.conf), although I have no memory of ever changing that configuration...

BTW, using an internal NTP server (using a TRUSTED source), used by all internal servers so all servers maintain the same time, which was already in use in XOA, but was apparently missed in XCP-ng.

Hello,

I've recently begun experiencing problems with "Host time and XOA time are not consistent with each other".

According to the documentation here:
https://xen-orchestra.com/docs/xoa.html#setting-a-custom-ntp-server
XOA should have NTP (ntp(d)) enabled and using Debian default NTP servers, but that is not the case for me - the NTP service does not exist in XOA nor XCP-ng.

Would I be "invalidating" the (paid) support for XOA/XCP-ng if I installed, configured and enabled ntp(d) on both XOA and all XCP-ng hosts?
And why isn't this available, to configure NTP settings, from within the XOA UI?

XOA version 5.99.1
XCP-ng version 8.2.1

@rfx77

With the help of @florent, we got this working and I have now performed 40+ migrations from vSphere 7 without any serious issues.
The main issue was the NFS datastore, which should not be mounted as a storage in XO, but as a Remote (still haven't found any documentation about this).

@olivierlambert I'm afraid I'm still having some issues with migrations, and I'm hoping someone could clearify some things for me.

First, most of the migrations I've attempted, have started with shutting down the VM on the VMware side, resulting in an offline migration.
This does not seem correct, shouldn't the VM be shut down towards the end to synchronize changed data?

Secondly, I'm receiving random "Error: EACCES: permission denied" errors at the end of migrations, so the VM is not migrated.
In these cases, the source VM does not get shut down, which I'm guessing is the cause of the error?

Overall, I'm starting to think that the import from VMware is not near ready to be used, which is very sad.

@florent Thank you for the quick reply.

a 5.93.1 version has been released with a few fixes regarding the nfs import

• XOA is currently running version 5.93.1 (I missed the .1 in the original post).

to do a warm migration, the VM must have at least one snapshot . More than one snapshot work but means less speed

• The part about a snapshot being required I did not know, so I just tested it - only results in HTTP 500 errors, but the source VM is not shut down, at least.

the live conversion of the vmdk to vhd/xva format shouldn't be too hungry, but more resource are always welcome when time is the issue
Go to the XOA VM , click on the CPU count( 2x here ) , change its value, reboot the VM. You can add some more ram, it will always be useful

• As I said above, trying to change the CPU count on the XOA and choosing to reboot it, only shuts down the XOA (probably because it's own connection to itself if lost) and changes aren't applied. Catch 22.

what are you using on the server side ? XCP-ng or xenserver ?

• Server is running XCP-ng (8.2.1 with latest patches applied).

the process can be sped up by deploying a XO ( from source ) directly on the vmware cluster

• Interesting thought, running the XO on the VMware side, but how could that VM later be migrated to XCP-ng, to maintain pool/host/settings?

Do you have a proxy to reach internet ? we have a fix in the work https://github.com/vatesfr/xen-orchestra/pull/7551

• No proxy.

do you have multiple vmware datacenter we also have a fix in the works https://github.com/vatesfr/xen-orchestra/pull/7553

• Just a single VMware datacenter.

I can try opening a support ticket and hope they can find the issue and/or let know what to do

As time is running out to find an alternative to VMware vSphere, I've spent the last couple of weeks trying out various hypervisors, hoping to find one that works and that I myself like.
I finally decided to give XCP-ng and XOA a try, but there is one major issue that currently keeps me from switching over - live/warm migrations to vSphere/ESXi 7.

I have eagerly read all announcements and release notes, and was really hoping for a solution when Xen Orchestra 5.93 was released (announcing a work around using NFS).

So, setting up a NFS datastore, mounted in ESXi as <datastorename> and in XCP-ng as [VMWARE]<datastorename> I went forward with migrating VMs to the NFS datastore in VMware and started my attempt to migrate VMs - but no success.
The process immediately shuts down the VM on the VMware side and then starts migrating disks (at very slow speeds, mind you, I have 2 x 25Gbps from hosts to storage).
The slowness I could live with, but I cannot have the extended down time this requires, so I'm desperately looking for some assistance to get this working.

The environment currently consists of:

VMware: vSphere 7 Enterprise Plus (vCenter and ESXi running on the currently latest patches)
XCP-ng: 8.2.1 with XOA 5.93 (Premium trial)

Migration steps performed:

1. Import from VMware (connection to vCenter) with VMFS6 storage to NFS storage (fails).
2. Import from VMware (connection to vCenter) with NFS storage to NFS storage (fails).
3. Import from VMware (connection to vCenter) with VMFS5 storage to NFS storage (fails).
4. Import from VMware (connection to ESXi) with VMFS6 storage to NFS storage (fails).
5. Import from VMware (connection to ESXi) with NFS storage to NFS storage (fails).
6. Import from VMware (connection to ESXi) with VMFS5 storage to NFS storage (fails).

In all attempts, no live/warm migration is even being tried, the source VM is immediately shut down and an offline migration starts.

One thing I noticed is that the XOA CPU usage maxes out while a migration is in process (default deployment with 2 vCPU's).
Could increasing the XOA resources help out? If so, how can this be done?
When I try to increase the number of vCPU's/RAM of the XOA, it immediately shuts down (does not reboot) and then reverts to the default number of vCPU's and RAM.

Is there anything else I have missed?
I'm at a complete loss at how to get this working...
Any help and insights to get this working for me would be greatly appreciated!