The workaround I have found at this point is to rebuild grub after migrating to XCP-NG. Adds a few minutes to each VM but I don't have that many. Boot to live iso in UEFI mode (I used Debian12 given it was a Debian12 vm) sudo su - mount /dev/mapper/????? /mnt mount /dev/xvda2 /mnt/boot mount /dev/xvda1 /mnt/boot/efi for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars chroot /mnt grub-install /dev/xvda update-grub exit shutdown now I'm using LVM so adjust the first mount to match your root partition. I shutdown so that I can remove iso and boot when I'm ready. Hope this saves somebody a bunch of frustration in the future.

So....................... it is dynamic memory causing me problems. I have have set the min/max and static memory to the be same. The system stays up fine. Now to figure our how/if I need dynamic memory to work on a Windows VM. I do not seem to be having problems with linux based workloads.

I recommend indeed Warm migration that doesn't need any 3rd party vendor tooling that are pushed by some shady accounts

A few things you could do -- Share the full error message (see entry in Setting > Logs) Switch to the "latest" release channel to see if issue also occurs there Review our Vmware migration checklist -- https://help.vates.tech/kb/en-us/37/133 HTH, Dan

Ok, Thank you!

@thomas-dkmt Our Hyper-V servers have no GUI and the process I use is: RDP to the Hyper-V host Open PowerShell Get a list of the VMs on the host Get-VM Stop the VM STOP-VM -Name <name of VM> Identify the VM's disk(s) for conversion Get-VMHardDiskDrive -VMName <name of VM> Convert the VHDX to VHD (destination file extension sets the type so use ".vhd") Convert-VHD -Path <source path> -DestinationPath <destination path> -VHDType Dynamic To transfer the newly created .vhd files to xcp-ng we use Putty via the cli

Hi! What's great is the fact we have -at the bottom of each doc page- a link to contribute to the documentation ("Edit this page"). That would be awesome if you can submit a change request and we could review it and finally merge it, so you'll have a better documentation that will help everyone

@McHenry Hey Whatever happened to this? Have you solved it? After looking at your comment I found this https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v/manage/manage-hyper-v-integration-services which explains how to disable those. I haven't done this before.

@McHenry +1. Never found how to do it....

@BenjiReis Got it, thank you.

That's a possibility. Can you try and report after rename?

On which XOA release channel were you when you imported it? Are you up to date? I think we recently fixed the memory settings doing VMware imports.

@vaewyn another reason for leaving vmware in would go for robocopy then.

I am new user to XCP-ng, Thanks @AtaxyaNetwork for the fast conventual way.

Thanks for re-pinging. This might be a "simple" mission to finance to a Python specialist. Let me add @AtaxyaNetwork in the loop.

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.