XEN -> KVM

[Abnorm]

Hello everyone,

 

I've just upgraded from Unraid 6b3 and was wondering if there is any easy method as to converting a Xen image to a KVM image? or is it possible to still run my old image in Xen with beta 12 ?

I was under the impression this should work, when I try starting my VM directly from the webgui nothing happens, and when I start the image with the old method "xl create win.cfg" I get the following;

 

Parsing config from win.cfg
libxl: error: libxl_dom.c:281:libxl__build_post: Failed to set event channel limit to 1023 (-1)
libxl: error: libxl_create.c:1022:domcreate_rebuild_done: cannot (re-)build domain: -3
libxl: error: libxl_dm.c:1467:kill_device_model: unable to find device model pid in /local/domain/7/image/device-model-pid
libxl: error: libxl.c:1421:libxl__destroy_domid: libxl__destroy_device_model failed for 7

 

what am I missing ?

[Abnorm]

NVM, decided to start over.

Holy crapballs Docker and the new KVM-management is freakin' awesome 

Fantastic work devs! <3

[jonp]

NVM, decided to start over.

Holy crapballs Docker and the new KVM-management is freakin' awesome 

Fantastic work devs! <3

 

Major appreciation goes out to gfjardim for his MAJOR MAJOR MAJOR (can't say it enough) contributions to Docker Manager and to dmacias for his KVM Management plugin.  These guys are ROCKSTARS!

[jumperalex]

Still though, I'm feeling lazy (after HOUUURRSSS or RFS to XFS conversion time) is there a decent way to convert xen to kvm? I have an Arch image. I recall previous discussions, but i also recall there not being a final solution.

 

[jonp]

"Decent" is a key word from your post. The truth is that for Linux based guests, this should be way easier than for windows. The problem is that you still have to convert your Xen cfg file into libvirt domXML format which as of now would be a manual rewrite for you.  It is doable, but not as simple as "point, click, done".  If you post your cfg file for your arch VM, I can have a crack at doing this for you.

[jumperalex]

Well damn that would be very nice of you. Here is my config file:

 

name = "arch"
memory = '4096'
vcpus = '8'
vif = [ 'bridge=xenbr0,mac=00:16:3E:1E:66:1F' ]
disk = ['file:/mnt/disk/appdisk/vm/arch/arch.img,xvda,w','file:/mnt/disk/appdisk/vm/arch/data.img,xvdb,w']
bootloader = "pygrub"

 

Really very simple actually.

[jonp]

Well damn that would be very nice of you. Here is my config file:

 

name = "arch"
memory = '4096'
vcpus = '8'
vif = [ 'bridge=xenbr0,mac=00:16:3E:1E:66:1F' ]
disk = ['file:/mnt/disk/appdisk/vm/arch/arch.img,xvda,w','file:/mnt/disk/appdisk/vm/arch/data.img,xvdb,w']
bootloader = "pygrub"

 

Really very simple actually.

OK can you make a backup of that image file while I work on this?  Yah know, in case the   hits the fan ;-)

[jonp]

Ok, after you backup your VM, give this XML a try:

 

<domain type='kvm'>
  <name>arch</name>
  <uuid>4deba3e7-e24e-4962-9b23-a6649b7a2879</uuid>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>8</vcpu>
  <bootloader>pygrub</bootloader>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
  </os>
  <clock offset='utc' adjustment='reset'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/mnt/disk/appdisk/vm/arch/arch.img'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/mnt/disk/appdisk/vm/arch/data.img'/>
      <target dev='vdb' bus='virtio'/>
    </disk>
    <interface type='bridge'>
      <mac address='00:16:3e:1e:66:1f'/>
      <source bridge='xenbr0'/>
    </interface>
    <console type='pty'>
      <target type='virtio' port='0'/>
    </console>
  </devices>
</domain>

[jonp]

Ok, after you backup your VM, give this XML a try:

 

<domain type='kvm'>
  <name>arch</name>
  <uuid>4deba3e7-e24e-4962-9b23-a6649b7a2879</uuid>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>8</vcpu>
  <bootloader>pygrub</bootloader>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
  </os>
  <clock offset='utc' adjustment='reset'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/mnt/disk/appdisk/vm/arch/arch.img'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/mnt/disk/appdisk/vm/arch/data.img'/>
      <target dev='vdb' bus='virtio'/>
    </disk>
    <interface type='bridge'>
      <mac address='00:16:3e:1e:66:1f'/>
      <source bridge='xenbr0'/>
    </interface>
    <console type='pty'>
      <target type='virtio' port='0'/>
    </console>
  </devices>
</domain>

I think I need to change the boot loader parameter having looked at this again this morning. Still give it a shot but I will take a look and post updated XML if it doesn't work as is.

[jumperalex]

Ok, after you backup your VM, give this XML a try:

 

<domain type='kvm'>
  <name>arch</name>
  <uuid>4deba3e7-e24e-4962-9b23-a6649b7a2879</uuid>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>8</vcpu>
  <bootloader>pygrub</bootloader>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
  </os>
  <clock offset='utc' adjustment='reset'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/mnt/disk/appdisk/vm/arch/arch.img'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/mnt/disk/appdisk/vm/arch/data.img'/>
      <target dev='vdb' bus='virtio'/>
    </disk>
    <interface type='bridge'>
      <mac address='00:16:3e:1e:66:1f'/>
      <source bridge='xenbr0'/>
    </interface>
    <console type='pty'>
      <target type='virtio' port='0'/>
    </console>
  </devices>
</domain>

I think I need to change the boot loader parameter having looked at this again this morning. Still give it a shot but I will take a look and post updated XML if it doesn't work as is.

 

Not only can *I* back it up, but my script backs it up every week. Same with data.img

 

OK I will try it tonight after I swap in my new flash SSD. I'll put the copies there and see if I can get everything to run from that. Sort of a double conversion; Xen to KVM and dedicated appdrive to cache-only app share.

 

Thanks for your time. Really probably there are better things for you to dedicate your time. I appreciate it.

[jonp]

Ok, after you backup your VM, give this XML a try:

 

<domain type='kvm'>
  <name>arch</name>
  <uuid>4deba3e7-e24e-4962-9b23-a6649b7a2879</uuid>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>8</vcpu>
  <bootloader>pygrub</bootloader>
  <os>
    <type arch='x86_64' machine='pc'>hvm</type>
  </os>
  <clock offset='utc' adjustment='reset'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/mnt/disk/appdisk/vm/arch/arch.img'/>
      <target dev='vda' bus='virtio'/>
    </disk>
    <disk type='file' device='disk'>
      <driver name='file'/>
      <source file='/mnt/disk/appdisk/vm/arch/data.img'/>
      <target dev='vdb' bus='virtio'/>
    </disk>
    <interface type='bridge'>
      <mac address='00:16:3e:1e:66:1f'/>
      <source bridge='xenbr0'/>
    </interface>
    <console type='pty'>
      <target type='virtio' port='0'/>
    </console>
  </devices>
</domain>

I think I need to change the boot loader parameter having looked at this again this morning. Still give it a shot but I will take a look and post updated XML if it doesn't work as is.

 

Not only can *I* back it up, but my script backs it up every week. Same with data.img

 

OK I will try it tonight after I swap in my new flash SSD. I'll put the copies there and see if I can get everything to run from that. Sort of a double conversion; Xen to KVM and dedicated appdrive to cache-only app share.

 

Thanks for your time. Really probably there are better things for you to dedicate your time. I appreciate it.

 

Well, I kinda cheated.  There is a tool in libvirt called domxml-from-native that takes xen.cfg and converts it to XML.  The problem is that it's still Xen / paravirtualization and needs to be converted to KVM/QEMU w/ HVM mode, which is where the additional modifications come into play.  Also, this tool has been pretty unreliable for us in testing, but does give you a good "base" to work off of for the new XML (better than just writing from scratch).  I think I need to change or just drop the <bootloader> parameter from the XML and it might work.

 

In addition, switching from Xen to KVM requires you to have Intel VT-x support on your hardware (VT-d isn't required unless you're doing PCI pass through, but VT-x is required to use KVM, even with Linux guests).  In theory, this should "just work" so long as the guest VM you are working with has kernel drivers in it for virtio.  With your Arch VM, chances are it has the drivers.  It obviously has them for Xen, so it would make sense for Arch to have them for KVM as well.

 

A few issues you may run into:

 

A)  Getting console access to the VM may not be as easy as Xen.  You may need to telnet into the VM directly or use a VNC connection for access.

B)  The XML I have given you may not be complete.

 

As far as spending time on this, this topic has come up enough now that it warrants further effort.  If you're able/willing to be the guinea pig, maybe you can be the model for migrations to come!  I figure most that are using VMs on Xen have either Arch or another linux variant.  Windows is tougher because the VirtIO drivers are not already present in their OS, and therefore you'd have to go through some extra effort to strip out the GPL drivers from Xen, inject generic NON-virtio drivers temporarily, then boot windows with a secondary vdisk passed through using VirtIO, then install VirtIO drivers for it, then pull a "bait and switch" on windows where you shutdown, remove the secondary vdisk from the config, then change the OS vdisk to use virtio and it *SHOULD* work.  But even then, chances are you will end up having to go through a reactivation of your Windows license because the underlying virtual hardware will have changed enough to trigger that response.  Bottom line:  probably easier to just reinstall windows than trying to convert it from Xen to KVM manually.

[jumperalex]

Hmmm you almost scared me off until you issues the challenge for me to be a guinea pig. Now I'm intrigued.  I probably won't get to it tonight because I'm still hashing through my XFS conversion, but I'll have the next few days to play.

 

Question: what do you mean getting console access will be harder? Right now I just hit up the VM via SSH at its ip address using PuTTY from my desktop. Will that not work with KVM?

[jonp]

Hmmm you almost scared me off until you issues the challenge for me to be a guinea pig. Now I'm intrigued.  I probably won't get to it tonight because I'm still hashing through my XFS conversion, but I'll have the next few days to play.

 

Question: what do you mean getting console access will be harder? Right now I just hit up the VM via SSH at its ip address using PuTTY from my desktop. Will that not work with KVM?

 

That will work fine.  With Xen, you could actually gain console access to VMs from an ssh session on unRAID at the host level.  E.g., you SSH into the host, then type xl console vmname and you're in (no IP address required).  That feature doesn't work in KVM (at least not that I've been able to get to work).

[jumperalex]

oh yeah that. i found that annoying so i never did it 

[m4f1050]

I need some help with "passthrough" coming from XEN...

 

What would be the XML for this .cfg portion?

 

boot = 'dc'
acpi = '1'
apic = '1'
viridian = '1'
xen_platform_pci='1'
sdl = '0'
vnc = '0'
vnclisten = '192.168.1.2'
vncdisplay = '1'
vncpasswd = 'password'
stdvga = '0'
#usb = '1'
#usbdevice = 'tablet'
gfx_passthru = '1'
pci = ['00:14.2','01:00.0','01:00.1','06:06.0','06:06.1','06:06.2','08:00.0']

 

pci has USB controllers, audio and GTS450 -> Quadro2000

 

Thanks!

 

 

 

EDIT:  I tried a sample xml with a disk and nic and I get this error:

 

The Page at 192.168.1.2 says:

Error creating VM: invalid argument: could not find
capabilities for arch=x86_64 domaintype=(null)

[jonp]

I need some help with "passthrough" coming from XEN...

 

What would be the XML for this .cfg portion?

 

boot = 'dc'
acpi = '1'
apic = '1'
viridian = '1'
xen_platform_pci='1'
sdl = '0'
vnc = '0'
vnclisten = '192.168.1.2'
vncdisplay = '1'
vncpasswd = 'password'
stdvga = '0'
#usb = '1'
#usbdevice = 'tablet'
gfx_passthru = '1'
pci = ['00:14.2','01:00.0','01:00.1','06:06.0','06:06.1','06:06.2','08:00.0']

 

pci has USB controllers, audio and GTS450 -> Quadro2000

 

Thanks!

 

 

 

EDIT:  I tried a sample xml with a disk and nic and I get this error:

 

The Page at 192.168.1.2 says:

Error creating VM: invalid argument: could not find
capabilities for arch=x86_64 domaintype=(null)

Please see documentation in my signature. No need for xml edits to accomplish this.