Hi all, a 'fun quick question'. This relates to migration of a linux host to KVM VM (on proxmox). In my specific case I'm working with a CentOS 5.X VM running on VMware as the 'starting point' but this is equally relevant for migration from a physical host I believe.
- I used a clonezilla LiveCD to create image files of partitions from the source linux host; then restoring partitions to the new destination KVM based VM (ultimately the method of transfer is not my concern with this question though - direct copy of the VMDK and conversion with qemu-img would have worked also just a bit slower I believe - more empty blocks to scp out of the vmware host)
- I was able to boot my KVM based VM so long as I used IDE as the bus type for the virtual HDD. But using paravirt / virtio_blk - it was unable to boot, throwing a panic early in the boot process. I believe the issue is simply that the initrd boot image doesn't have driver support for virtio_blk in the source system.
- I tried to finesse this, as follows (a) boot new VM system in IDE attached disk mode; (b) edit /etc/modprobe.conf and add a line to reference virtio_blk (c) yum update to get a new kernel and in the process build a new initrd which ?should? in theory have support for virtio_blk (d) power down, flip HDD from IDE to paravirt (e) reboot the VM.
- alas, no joy. I can see during the boot process that the initrd appears to be loading modules for virtio_blk (ie, output on console suggests this) but it still tanks in the same manner as before - as if it doesn't have virtio support.
Checking in the proxmox wiki, there are plenty of hints on migrating Windows hosts to KVM, and various steps that can be taken to make this sort of process work (ie, run mergeide.reg before migrating; first boot of VM in IDE mode virt disk; attach a paravirt HDD; get drivers installed inside windows; power down; flip all HDDs to Virtio; bingo- good; works fine). I'm just not finding any similar cribsheets or discussion for migration of Linux VMs. I suspect it will also vary somewhat based on distro being used (although conceptually it will likely be same general process?). (Last night doing my testing I noted for example, when booted from clonezilla that the virtual HDD slices of the 'new VM' were identified as sda1,sda2,sda3 -- whereas when booted 'natively' from centos the slices were hda1,2,3 -- I presume because debian vs redhat have different ways of calling local disks sda vs hda - small added bit of fun in the mix but again a side detail).
Anyhow. If anyone has a good concise reliable summary of steps to take to simplify this, it would be lovely.
Ideally, something that requires as little fiddling:booting from liveCDs; mounting root slice and editing fstab; chroot and other fun - would be nice. In theory I wonder if it is possible,
- while original host is still online, adjust config to force virtio drivers to be supported, both in initrd and in the actual boot OS instance
- update initrd as required
- image the system to the new KVM host with whatever means desired (clonezilla, direct copy and covert, etc)
- spin up the new VM with virtio disks, and happy days are here ?
Many thanks,
Tim
---------------------------------------------
Fortech I.T. Solutions
http://FortechITSolutions.ca
- I used a clonezilla LiveCD to create image files of partitions from the source linux host; then restoring partitions to the new destination KVM based VM (ultimately the method of transfer is not my concern with this question though - direct copy of the VMDK and conversion with qemu-img would have worked also just a bit slower I believe - more empty blocks to scp out of the vmware host)
- I was able to boot my KVM based VM so long as I used IDE as the bus type for the virtual HDD. But using paravirt / virtio_blk - it was unable to boot, throwing a panic early in the boot process. I believe the issue is simply that the initrd boot image doesn't have driver support for virtio_blk in the source system.
- I tried to finesse this, as follows (a) boot new VM system in IDE attached disk mode; (b) edit /etc/modprobe.conf and add a line to reference virtio_blk (c) yum update to get a new kernel and in the process build a new initrd which ?should? in theory have support for virtio_blk (d) power down, flip HDD from IDE to paravirt (e) reboot the VM.
- alas, no joy. I can see during the boot process that the initrd appears to be loading modules for virtio_blk (ie, output on console suggests this) but it still tanks in the same manner as before - as if it doesn't have virtio support.
Checking in the proxmox wiki, there are plenty of hints on migrating Windows hosts to KVM, and various steps that can be taken to make this sort of process work (ie, run mergeide.reg before migrating; first boot of VM in IDE mode virt disk; attach a paravirt HDD; get drivers installed inside windows; power down; flip all HDDs to Virtio; bingo- good; works fine). I'm just not finding any similar cribsheets or discussion for migration of Linux VMs. I suspect it will also vary somewhat based on distro being used (although conceptually it will likely be same general process?). (Last night doing my testing I noted for example, when booted from clonezilla that the virtual HDD slices of the 'new VM' were identified as sda1,sda2,sda3 -- whereas when booted 'natively' from centos the slices were hda1,2,3 -- I presume because debian vs redhat have different ways of calling local disks sda vs hda - small added bit of fun in the mix but again a side detail).
Anyhow. If anyone has a good concise reliable summary of steps to take to simplify this, it would be lovely.
Ideally, something that requires as little fiddling:booting from liveCDs; mounting root slice and editing fstab; chroot and other fun - would be nice. In theory I wonder if it is possible,
- while original host is still online, adjust config to force virtio drivers to be supported, both in initrd and in the actual boot OS instance
- update initrd as required
- image the system to the new KVM host with whatever means desired (clonezilla, direct copy and covert, etc)
- spin up the new VM with virtio disks, and happy days are here ?
Many thanks,
Tim
---------------------------------------------
Fortech I.T. Solutions
http://FortechITSolutions.ca
