I'm in the process of converting the last few on my XenServer VMs over to Hyper-V.
The majority of them have been Windows machines and I've done a backup and restore using Windows Backup. For some of the windows boxes I've used the XenServer export process to create and XVA file and I've then converted that to the VHDs that I could then use in Hyper-V.
Both ways have worked perfectly but when I attempted to the export and convert process for the a few linux boxes it didn't work as well.
I created the XVA, I used Xenconvert to convert and create the VHDs but when I attached these to a Hyper-V VM I just got a flashing cursor. Having done some research I believe it is because of the way the HDDs are named differently. For example the original machine in `/dev/` will show `xvda, xvda1.....` but in Hyper-V I believe these will be `sda, sda1......`
This is where I'm a little lost.... I booted one of the machines to the boot menu on a converted machine and looked at the menu and arguements options but I could see no reference to a `xvda`. So either my assumptions are wrong above or I'm looking in the wrong place or both?
Any help would be appreciated, even if the suggestion is to do this in a totally different way.
**EDIT1:** (Adding boot menu information)
If I select the first item on the boot menu and press `e` I'm presented with the following
```
root (hd0,0)
kernel /vmlinuz-2.6.32-573.12.1.e16.x86_64 ro root=dev/mapper/VolGroup-lv_root rd_NOLUKS LANG=en_US.UTF-8 rd_NO_MD console=hvc0 KEYTABLE=us rd_LVM_LV=VolGroup/lv_swap SYSFONT=latacyrheb-sun16 rhgb crashkernel=auto quiet rd_LVM_LV=VolGroup/lv_root rd_NO_DM
initrd /initramfs-2.6.32-573.12.1.e16.x86_64.img
```
**EDIT2:** (Linux Version and fstab)
The Linux Version is Centos 6.7
copy of /etc/fstab (I took a stab and tried changing the UUID to the UUID of the new disk but that didn't seem to work
Converting Linux machine from XenServer to Hyper-V
Re: Converting Linux machine from XenServer to Hyper-V
**EDITED ANSWER:**
I've been thinking about your problem, and I think that rsync or dd backup/restore might be your best bet. If you are using dynamically growing vhdds, then rsync is probably your best bet, and if you are using statically defined disks, then dd is probably your best bet.
**Option 1:**
First, you will have to create a samba or cfs share, or attach a physical drive by some other means to backup the data. Once you have a backup destination attached, you will have to run the rsync or dd command to backup the drive.
Rsync example (using Arch):
[https://wiki.archlinux.org/index.php/full_system_backup_with_rsync](https://wiki.archlinux.org/index.php/full_system_backup_with_rsync)
DD example:
[http://www.thegeekstuff.com/2010/10/dd-command-examples/](http://www.thegeekstuff.com/2010/10/dd-command-examples/)
I'm pretty sure you can pipe rsync into gzip if you want to create a portable file.
Then you must install Centos in a new hyper-v machine. Then you have to go through the task of restoring the backup image (which will differ depending on the command you used to create it).
**Option 2:**
Alternatively, you could create the new CentOS VM first, and then mount the other exported VHD file to the same virtual machine under Hyper-V. Since you will have both drives mounted to the same machine, you could go through the migration process at that point. Once you have mounted the backup drive and migrated your bootloader over to it, you can unmount the replacement VM drive. You could then re-use the same drive to migrate your other machines (rinse and repeat for each VM you need to migrate). If you have many machines you could attempt to script this process, or you might be able to find a backup script already out there.
**Option 3:**
Create the new VHD/VHDX file with hyper-V, and then attach and mount it to the Xenserver guest you wish to duplicate, and do the backup directly that way.
I know there are a lot of hoops to jump through, there are three solid options that will probably work without too much fuss. I'm kind of newb with Linux, but I've moved HD images around fairly easily with DD before, and I don't see why it wouldn't work nicely here.
**ORIGINAL ANSWER:**
If you are using LVM, then the HDDs shouldn't be causing the problem and HD links should be intact after conversion, but I am no expert. I have a fair amount of experience with Linux under Hyper-V, but not converting XenServer machines to Hyper-V. That being said, the error you are seeing suggests to me that it might be an issue with the linux kernel. It would be helpful to know which Linux distribution you are using.
XenServer has two VM types:
HVM VMs - these are equal to Hyper-V VMs and need no changes. These VMs can be converted to Hyper-V machines by conventional means (copy VHD or use System Center 2012 Virtual Machine Manager (VMM) as recommended by Microsoft).
PV VMs - these are 'para virtualized' VMs and don't have a full boot kernel. They are bound to the OS of the VM and share some of the bootloader to bootstrap the machine. You need to replace the PV kernel (kernel-xen) in the VM with the pae kernel (kernel-pae).
I don't know what linux distribution you are using, and that may have some effect on the actual solution, but, assuming the VMs are PV VMs, the following link has instructions on installing the PV kernel on the Linux box, so you want to **do the reverse** of these instructions, adapting for your Linux distribution. Then the export process should work:
[http://itproctology.blogspot.ca/2009/06/pv-enabling-hvm-from-vmware-on.html](http://itproctology.blogspot.ca/2009/06/pv-enabling-hvm-from-vmware-on.html)
This answer assumes you are using PV kernel on your Xenserver vms, and assumes that is the problem causing boot failure. It also assumes you have already tried using System Center 2012 Virtual Machine Manager (VMM) to convert the vms (as per Microsoft best practices, steps shown at the following link):
[https://technet.microsoft.com/en-ca/library/gg610672.aspx](https://technet.microsoft.com/en-ca/library/gg610672.aspx)
Final Notes:
- I might try disabling secure boot and seeing if that makes a difference.
- Make sure to follow Microsoft Best Practices for Linux VMs (depending on the distribution you are using). These can be found at the following links, and you could try making those change to the VM **prior to doing the export process** (be sure to back-up your virtual machine first):
Universal Linux VM under Hyper-V best practices:
[https://technet.microsoft.com/en-ca/library/dn720239.aspx](https://technet.microsoft.com/en-ca/library/dn720239.aspx)
Distribution specific Linux VM under Hyper-V best practices:
[https://technet.microsoft.com/en-ca/library/dn531030.aspx](https://technet.microsoft.com/en-ca/library/dn531030.aspx)
Lastly, here's what my Linux kernel params look like (Ubuntu/Debian) for my virtual machines (in /etc/default/grub, make sure to run sudo update-grub afterwards):
```
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=hyperv_fb:1366x768 elevator=noop numa=off"
```
The video=hyperv_fb option will only work once hyper-v integration tools are installed on the VM (distribution specific).
I've been thinking about your problem, and I think that rsync or dd backup/restore might be your best bet. If you are using dynamically growing vhdds, then rsync is probably your best bet, and if you are using statically defined disks, then dd is probably your best bet.
**Option 1:**
First, you will have to create a samba or cfs share, or attach a physical drive by some other means to backup the data. Once you have a backup destination attached, you will have to run the rsync or dd command to backup the drive.
Rsync example (using Arch):
[https://wiki.archlinux.org/index.php/full_system_backup_with_rsync](https://wiki.archlinux.org/index.php/full_system_backup_with_rsync)
DD example:
[http://www.thegeekstuff.com/2010/10/dd-command-examples/](http://www.thegeekstuff.com/2010/10/dd-command-examples/)
I'm pretty sure you can pipe rsync into gzip if you want to create a portable file.
Then you must install Centos in a new hyper-v machine. Then you have to go through the task of restoring the backup image (which will differ depending on the command you used to create it).
**Option 2:**
Alternatively, you could create the new CentOS VM first, and then mount the other exported VHD file to the same virtual machine under Hyper-V. Since you will have both drives mounted to the same machine, you could go through the migration process at that point. Once you have mounted the backup drive and migrated your bootloader over to it, you can unmount the replacement VM drive. You could then re-use the same drive to migrate your other machines (rinse and repeat for each VM you need to migrate). If you have many machines you could attempt to script this process, or you might be able to find a backup script already out there.
**Option 3:**
Create the new VHD/VHDX file with hyper-V, and then attach and mount it to the Xenserver guest you wish to duplicate, and do the backup directly that way.
I know there are a lot of hoops to jump through, there are three solid options that will probably work without too much fuss. I'm kind of newb with Linux, but I've moved HD images around fairly easily with DD before, and I don't see why it wouldn't work nicely here.
**ORIGINAL ANSWER:**
If you are using LVM, then the HDDs shouldn't be causing the problem and HD links should be intact after conversion, but I am no expert. I have a fair amount of experience with Linux under Hyper-V, but not converting XenServer machines to Hyper-V. That being said, the error you are seeing suggests to me that it might be an issue with the linux kernel. It would be helpful to know which Linux distribution you are using.
XenServer has two VM types:
HVM VMs - these are equal to Hyper-V VMs and need no changes. These VMs can be converted to Hyper-V machines by conventional means (copy VHD or use System Center 2012 Virtual Machine Manager (VMM) as recommended by Microsoft).
PV VMs - these are 'para virtualized' VMs and don't have a full boot kernel. They are bound to the OS of the VM and share some of the bootloader to bootstrap the machine. You need to replace the PV kernel (kernel-xen) in the VM with the pae kernel (kernel-pae).
I don't know what linux distribution you are using, and that may have some effect on the actual solution, but, assuming the VMs are PV VMs, the following link has instructions on installing the PV kernel on the Linux box, so you want to **do the reverse** of these instructions, adapting for your Linux distribution. Then the export process should work:
[http://itproctology.blogspot.ca/2009/06/pv-enabling-hvm-from-vmware-on.html](http://itproctology.blogspot.ca/2009/06/pv-enabling-hvm-from-vmware-on.html)
This answer assumes you are using PV kernel on your Xenserver vms, and assumes that is the problem causing boot failure. It also assumes you have already tried using System Center 2012 Virtual Machine Manager (VMM) to convert the vms (as per Microsoft best practices, steps shown at the following link):
[https://technet.microsoft.com/en-ca/library/gg610672.aspx](https://technet.microsoft.com/en-ca/library/gg610672.aspx)
Final Notes:
- I might try disabling secure boot and seeing if that makes a difference.
- Make sure to follow Microsoft Best Practices for Linux VMs (depending on the distribution you are using). These can be found at the following links, and you could try making those change to the VM **prior to doing the export process** (be sure to back-up your virtual machine first):
Universal Linux VM under Hyper-V best practices:
[https://technet.microsoft.com/en-ca/library/dn720239.aspx](https://technet.microsoft.com/en-ca/library/dn720239.aspx)
Distribution specific Linux VM under Hyper-V best practices:
[https://technet.microsoft.com/en-ca/library/dn531030.aspx](https://technet.microsoft.com/en-ca/library/dn531030.aspx)
Lastly, here's what my Linux kernel params look like (Ubuntu/Debian) for my virtual machines (in /etc/default/grub, make sure to run sudo update-grub afterwards):
```
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=hyperv_fb:1366x768 elevator=noop numa=off"
```
The video=hyperv_fb option will only work once hyper-v integration tools are installed on the VM (distribution specific).