Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If I stick to one of the standard, well-supported VM disk images (like a raw image, or VDI, VMDK, ...), are Linux VMs typically easy to move between VM environments? E.g., between (say) VirtualBox and KVM, or VMWare and Xen? I'm talking here of fully virtualized environments, not paravirtualization requiring support within the guest OS.

It seems to me that the kernels in most Linux distributions these days are configured to...keep an open mind and detect things at boot time, so you don't have the issue that you sometimes have moving a Windows VM from one virtualization system to another (I'm thinking particularly of HAL issues that Windows has, like ACPI vs. non-ACPI; I've also just had Windows VMs generally acting strangely when moved from VMWare to VirtualBox, for instance).

I'm looking for a general answer, but if it helps, specifically I'm mostly going to be doing this with Ubuntu 8.04 LTS and 10.04 LTS guests. But that could change.

share|improve this question
up vote 2 down vote accepted

Linux is able to load modules (drivers) for it's hardware platform on demand. As long as your kernel is able to find modules for you hardware, it does not even matter on what platform you start your VM, save for a couple of caveats:

  • for all hypervisor types, use generic hardware: use IDE disks (not SCSI, KVM sucks with SCSI disks) and use e1000 network adapters. For portability, stay away from KVM's vda disks or VMware vmxnet. This is not alway possible (VMware uses SCSI by default), but it'll help.
  • make sure you use the same MAC addresses for the migrated VM on the new platform as you did on the old one
  • use LVM for your disks: the bootloader will find your kernel and feed it your initrd; if you use LVM, you don't have to worry about disks going awol (worry less, anyway).
  • leave your network configuration at DHCP if possible
  • do not install VMwareTools and similar
  • generate an initrd and try to put as many of the drivers you'll need on the other platforms in it. This will save your behind when trying to go from KVM (IDE disks) to VMware (SCSI disks) and you already have support for VMware's LSI Logic SCSCI controller in your initrd.
share|improve this answer

I was moving Linux VMs from VMWare to xen to openvz to kvm and back and had no issues that couldn't be resolved by massaging /etc/modules a bit, nothing that you really can't get out of with a bit of googling.

Windows is a diffrent story. I've managed to move Win2003 server VM from VMWare to xen but not without open heart surgery (mounting the image in linux and manually editing boot loader config). I have also managed to move from xen to kvm without any trouble, but thats to be expected since they are both running under qemu.

share|improve this answer
Thanks! That's good to hear. What sort of modules issues did you have? Just a couple of examples would be handy. – T.J. Crowder Jun 11 '10 at 18:06
How are Xen VM's running under Qemu?? – wzzrd Jun 12 '10 at 12:03
eh, i meant that xen hvm (fully virtual) is using patched qemu daemon qemu-dm for hardware emulation, so you basically get the same hardware as under qemu-kvm – Aleksandar Ivanisevic Jun 12 '10 at 16:40
T.J. there were really no issues, i just had to figure out which hardware is emulated in the VM and adjust the config files to modprobe the correct modules. No black magic, really, you can google it in 10 seconds ;) – Aleksandar Ivanisevic Jun 12 '10 at 16:42

I'm not pro but I often use the same VMDK from a VMware virtual machine into a VirtualBox one, so I suppose that there is some standards between the virtual disk. I never tried Xen or other solution.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.