I can confirm the warm migration work from OVHcloud Managed vSphere from both vSAN and NFS datastores.

We just need to follow these steps :

• make a snapshot of the VM on vSphere
• import from VMware on XOA with VM stop actions disabled
• once import is finished, remove open-vm-tools on active VM and gracefully stop the OS
• new import from VMware on XOA with VM stop actions disabled -> it detects the VM has already been imported and just sync the delta
• once import is finished, the VM can be started

There are still 2 drawbacks :

• the network interfaces naming differs (ens192/226/etc -> eth0/eth1/eth2) so it needs some reconfiguration
• the network remapping is global so in case a VM has multiple interfaces with different VLANs (ex : pfSense FW), you need to manually set networks before starting the VM

Anyway it works well and make the migration possible for us without waiting for QCOW2 because we don't have >2TB vdisks (we usually add disks and use LVM to grow FS).

Thanks @florent for your help

@florent sure, I've sent a download link by chat message.

@ronan-a we need to have CBT to use 3rd party backup & replication solution such as Veeam.

On the other hand, XOSTOR with VHD disk might be ok using Xen Orchestra backup & replication features but it needs more testing on our end to make sure it works good enough.
One big question is about the snapshot chain. Coming from VMware world where keeping snapshots may impact I/O performances, we're not very comfortable with it.

Also, we need to find solution for low-RPO replication. On our VMware infrastructure we use Zerto DR for this but XOA being more like Veeam using snapshots, low-RPO will be tough to achieve (unless making snapshots doesn't affect performances at all ?).

Any update from someone ? Not having the ability to enable CBT on XOSTOR is really complicated to make replication / DR scenarios.

At least to know if this is work in progress or not. If it's not we'll need to pause our PoC and post-pone production schedule waiting for significant update.

I can confirm the warm migration work from OVHcloud Managed vSphere from both vSAN and NFS datastores.

We just need to follow these steps :

• make a snapshot of the VM on vSphere
• import from VMware on XOA with VM stop actions disabled
• once import is finished, remove open-vm-tools on active VM and gracefully stop the OS
• new import from VMware on XOA with VM stop actions disabled -> it detects the VM has already been imported and just sync the delta
• once import is finished, the VM can be started

There are still 2 drawbacks :

• the network interfaces naming differs (ens192/226/etc -> eth0/eth1/eth2) so it needs some reconfiguration
• the network remapping is global so in case a VM has multiple interfaces with different VLANs (ex : pfSense FW), you need to manually set networks before starting the VM

Anyway it works well and make the migration possible for us without waiting for QCOW2 because we don't have >2TB vdisks (we usually add disks and use LVM to grow FS).

Thanks @florent for your help

@florent sure, I've sent a download link by chat message.

@florent one VM import is in progress. It triggered a VM stop action right away

@florent sorry I said PoC as reference to our XCP-ng pool cluster, not vddk migration process

Sure we've got a trial license to challenge the solution so we can open a tunnel on the XOA and eventually give some VMware credentials to make some migrations tests. We've got some non-critical VMs to make warm migrations tests on without impact.

Tunnel opened -> 35803

@florent said in What is the status/roadmap of V2V (Migrating from VMware to XCPng/XO) ?:

@afk said in What is the status/roadmap of V2V (Migrating from VMware to XCPng/XO) ?:

Great news ! Thanks @olivierlambert and @florent and let me know if you need some information on the vmware side.

yes we are prototyping with vddk , it should open some interesting possibilities. stay tuned, hopefully by the end of the summer (I am saying it again : for a prototype)

as a shameless plug, we are looking for users with VSAN to ensure we don't break thing for it

If you need some beta tester we have a running XCP-ng PoC and need to challenge V2V process from VMware with many VMs on vSAN.

The lack of warm migration is a big issue for us since it would require a significant downtime to migrate some customers' VMs.

We also have NFS datastores that could help but our VMware infrastructure being managed by OVHcloud, we cannot have direct access to NFS to setup XOA remote (unless we just can't figure out the settings to put).

@olivierlambert after disabling HA and trying to make many actions (VM deploys, start/stop/restart, VM console, etc), I cannot reproduce XOA's issue at all.

It looks like everything is smoother, starting with VM deploy/start actions.

@olivierlambert yes we do with XOSTOR as SR for a few VMs (this is a PoC on OVHcloud Baremetal servers).

Hello,

When we do usual task such as creating/removing/migrating VM or starting console, XOA gets disconnected for about 30s then comes back again.

We had many issues because our PoC Pool (hosted on OVHcloud Baremetal servers) was first installed using public IP then were re-configured to use private IPs :

• reconfigure management IP of every host
• changed reference master IP on /etc/xensource/pool.cfg
• generate new SSL certificates for every node of the pool

Maybe we missed some reconfiguration due to lack of documentation.

I might be wrong but when XOA looses connection, /var/log/xensource.log on pool's master node shows :

Dec 27 21:35:45 xcp-ng-317 xapi: [ info||160 /var/lib/xcp/xapi|session_check D:468110568dff|session_check] Session check failed: the client used an illegal or expired session ref 'OpaqueRef:f679a584-7f81-dc17-8dde-c3a575a072ba'
Dec 27 21:35:45 xcp-ng-317 xapi: [error||160 /var/lib/xcp/xapi|dispatch:VIF.get_by_uuid D:dd849736b2fb|backtrace] session_check D:468110568dff failed with exception Server_error(SESSION_INVALID, [ OpaqueRef:f679a584-7f81-dc17-8dde-c3a575a072ba ])
Dec 27 21:35:45 xcp-ng-317 xapi: [error||160 /var/lib/xcp/xapi|dispatch:VIF.get_by_uuid D:dd849736b2fb|backtrace] Raised Server_error(SESSION_INVALID, [ OpaqueRef:f679a584-7f81-dc17-8dde-c3a575a072ba ])
Dec 27 21:35:45 xcp-ng-317 xapi: [error||160 /var/lib/xcp/xapi|dispatch:VIF.get_by_uuid D:dd849736b2fb|backtrace] 1/4 xapi Raised at file ocaml/xapi/session_check.ml, line 88
Dec 27 21:35:45 xcp-ng-317 xapi: [error||160 /var/lib/xcp/xapi|dispatch:VIF.get_by_uuid D:dd849736b2fb|backtrace] 2/4 xapi Called from file ocaml/xapi/server_helpers.ml, line 75
Dec 27 21:35:45 xcp-ng-317 xapi: [error||160 /var/lib/xcp/xapi|dispatch:VIF.get_by_uuid D:dd849736b2fb|backtrace] 3/4 xapi Called from file ocaml/xapi/server_helpers.ml, line 97
Dec 27 21:35:45 xcp-ng-317 xapi: [error||160 /var/lib/xcp/xapi|dispatch:VIF.get_by_uuid D:dd849736b2fb|backtrace] 4/4 xapi Called from file ocaml/libs/log/debug.ml, line 250
Dec 27 21:35:45 xcp-ng-317 xapi: [error||160 /var/lib/xcp/xapi|dispatch:VIF.get_by_uuid D:dd849736b2fb|backtrace]
Dec 27 21:35:45 xcp-ng-317 xapi: [ info||160 /var/lib/xcp/xapi|session.login_with_password D:f354a161de1a|xapi_session] Session.create trackid=c5635894fdaa50bf600bcc507ae8a7e3 pool=false uname= originator= is_local_superuser=true auth_user_sid= parent=trackid=9834f5af41c964e225f24279aefe4e49

Is it normal that XOA often looses connection to pool / master ? Is there anything we can do to avoid this ?

Thanks in advance for your help !