I have been migrating VMs from Xen on Debian 11/12 using the python2 script this past week and it worked best if I had ensured the VMs were booting on Debian using pygrub as the bootloader rather than the specified kernel from the Dom0. Then all I had to do after running the script was go into Xen Orchestra and change the "PV args" for the VM under "Advanced" to "root=/dev/xvda ro" (instead of "root=/dev/xvda2 ro" from the imported config), edit the "Network" config to match the MAC addresses used by the VM before, and mount the tools disk. The VM will then boot and I can edit the /etc/fstab file to use xvda and xvdb for the boot disk and swap respectively (instead of xvda2 and xvda1 that Debian had been using). I edited my VM's /etc/network/interfaces (because we have standardised on having the internal network as the first ethernet port rather than the second), then mounted the tools and ran 'sudo /mnt/Linux/install.sh' before rebooting. It is a pretty quick process once you've done a dozen or so!! I tried updating the script to use python3 but as I am not a python developer I decided it was safer to build python2.7 from sources to run on Debian 12, since unfortunately python 2 is no longer available from packages on Debian 12. Thanks for sharing your experience here, which I thought I would just add to as it may help others migrating to xcp-ng over coming months/years. All I can say is, "Do it!". The sooner the better! Once I have all the VM migrated in PV mode, I will then work on moving to HVM.

@Danp Thank you so much. I hadn't seen that article. I appreciate your assistance immensely! Darren

@flakpyro said in Switching to XCP-NG, want to hear your problems: @CodeMercenary I am using V4 on the XO-Server to our backup remotes and it seems to work just fine. However using V4 as a storage SR was nothing but problems, as @nikade mentioned we had tons of NFS Server not responding issues which would lock up hosts and VMs causing downtime. Since moving to v3 that hasn't happened. Checking a host's NFS retransmissions stats after 9 days of uptime i see we have had some retransmissions but they have not caused any downtime or even any timeout messages to appear in dmesg on the host. [xcpng-prd-02 ~]# nfsstat -rc Client rpc stats: calls retrans authrefrsh 268513028 169 268537542 From what a gather from this blog post from redhat (https://www.redhat.com/sysadmin/using-nfsstat-nfsiostat) it seems like that amount of retransmissions is VERY low and not an issue. Thats fine, we've got a lot more and I haven't seen any "nfs server not responding" in dmesg yet. Using NFS v3 for both SR and backups now for a couple of years and it's been great, I think I had issues once or twice in like 5-6 years on the backup SR where the vhd file got locked by dom0, Vates helped out there as always and it was resolved quickly.

The update in question can be cherry-picked without notable risk from the testing repository: yum update xcp-ng-release --enablerepo=xcp-ng-testing,xcp-ng-candidates

@jflaplante we had plenty of situations where it caused a bluescreen. I remember we had a 2012 server where we uninstalled the network card as well. It caused issues. U can install xentools prior to migration, it sometimes helps as well.

But even without my special use case it would be nice to actualy be able to have control of the last two steps (Snapshot & Boot). Because when you in a bigger envirement you probably have to follow a Change Management Process where you need to declare/get-approved the Migration of in Production Infrastructure. Normaly you would declare the Migration timeslot within the change window i.e. 00:00 - 03:00 and a exactly Service Impact timeslot (Where the Services are not availible) within the Migration Window i.e 02:00 - 02:30

If they don't care about their data, there's little you can do, but if you gave them some example on how things will go without more space, I'm sure they will decide to get more space

Ah great news!!

@DonZalmrol good to hear! Another good migration solved!

@chuckb1968 No, your approach sounds fine. Do you see the VDI under the VM's Disks tab? If so, then it should be visible to the installation routine.

Pinging @florent

1: Yes, I have seen some of @AtaxyaNetwork Proxmox posts. I'll go back and read them again. 2: No big deal, I only have like 5 vm's on Proxmox, V2V is my choice of tools!

@BGDev I'm not certain you're encountering a bug or a network issue (or something else). Given that you have a working production workload on ESXi and a Production XCP-ng environment, what I personally would suggest is to replication the data from the old to the new, schedule a final cut over day and perform a final replication. If this was a database drive or something that help system files then I'd dig further into why its not exporting successfully, but since it seems like its just a file share, replicating the individual files would be the simplest approach.

That's interesting, thanks for the feedback @sshughes and keep us posted!

The Xen / XCP-ng equivalent for VMXNET are Xen PV device drivers which either come from Citrix Xenserver, XCP-ng or the Xenserver project itself. Check the Wiki. It describes the installation pretty well: https://xcp-ng.org/docs/guests.html#windows As for 3D acceleration within the VM there is hardly a comparable option unless you do some PCIe pass through of a GPU.

PV is old and made sense when no HVM-supported hardware existed. You can also use PV shim. See https://xcp-ng.org/blog/2022/01/17/removing-support-for-32-bit-pv-guests/ for more details.

In the end it turned out the license was bound to the network card, we needed to recreate it with the original mac and the license server started again! Case closed!

Hi, First, I would test on XOA "Latest" than the sources, since there's already many moving pieces with VMware import, avoiding add another with a non-QA tested version vSAN import is slow but supported.

@irrelevant What's the specification of the hardware of both hosts and also what's the network speed. Especially for the management network interface, as this is the one through which VMs on XCP-ng are imported and also likely exported on VMware vSphere ESXi? The reason being if the hosts and/or network aren't that quick then the migration of the VMs from VMware to XCP-ng will take longer! If you can connect the management network to a faster interface then the migration won't take as long to complete.