Changes between Version 1 and Version 2 of xen_to_kvm_transfer


Ignore:
Timestamp:
Jun 4, 2011, 1:21:56 AM (10 years ago)
Author:
Daniel Kahn Gillmor
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • xen_to_kvm_transfer

    v1 v2  
    88== Shorthand ==
    99
    10  * `$guest` -- this is the name of the guest being transferred
    1110 * `$xenhost` -- this is the dom0 running the xen setup we are transferring from
    1211 * `$kvmhost` -- this is the machine we are transferring to (note that this is not the same machine as `$xenhost`, though such a transfer might be possible for some people; that's not what we're working with, so some choices here might be different)
     12 * `$guest` -- this is the name of the guest being transferred
     13 * `$xenguest` -- this refers to the copy of `$guest` when it's still running on `$xenhost`
     14 * `$kvmguest` -- this refers to the copy of `$guest` that will be running on `$kvmhost`
    1315
    14 == disk differences ==
     16== Differences ==
     17
     18Here are the main ways that the two virtualization schemes differ for us:
     19
     20=== Disk differences ===
    1521
    1622Our Xen setup (via [DebianPackage:xen-tools xen-tools]) has `$xenhost` serving `$guest` its partitions as individual volumes.  So `$xenhost` has them broken out in LVM directly, and `$guest` doesn't use LVM at all, or even see a parent `/dev/sda` -- it only sees `/dev/sda1`,`/dev/sda2`, etc.
     
    1824Our KVM setup typically has `$kvmhost` serving a single volume to `$guest`, and `$guest` carves it up however it sees fit.
    1925
    20 == booting differences ==
     26=== Booting differences ===
    2127
    2228Our Xen setup has `$xenhost` hold a kernel and initrd outside of `$guest`, and boots `$guest` into those systems directly (no bootloader, no "BIOS"-level disk access at boot).
     
    2430Our KVM setup has `$kvmhost` pass the virtual disk to `$guest`, which uses an emulated BIOS to pull a bootloader off the disk, and start from there.
    2531
    26 == architecture differences ==
     32=== Architecture differences ===
    2733
    2834All our KVM hosts are amd64.  Most of our remaining Xen hosts (and guests) are 32-bit (686).  We'd like all the guests to end up 64-bit clean eventually, but a non-invasive transfer that is relatively opaque to the guest might be preferable, even if it means the guest doesn't move to 64-bits immediately.
     35
     36== Strategies ==
     37
     38There are two main strategies we can use for transfer, which are rather different from one another:
     39
     40=== Data synchronization ===
     41
     42In this approach, we'd set up `$kvmguest` initially with a new IP address, as a clean minimal install. 
     43
     44 * synchronize packages (at the same versions) by copying the dpkg selections from `$xenguest`
     45 * synchronize user data via rsync
     46 * synchronize system configuration (except networking, maybe?)
     47 * halt public-facing services on `$xenguest`
     48 * touch up synchronization with another rsync run
     49 * dump databases on `$xenguest`, restore them on `$kvmguest`
     50 * halt `$xenguest`
     51 * modify networking on `$kvmguest` to match the old `$xenguest` networking config
     52 * restart services on `$kvmguest` (or just restart `$kvmguest` entirely)
     53
     54==== Data synchronization advantages ====
     55
     56 * `$kvmguest` will be fully 64-bit from the start
     57 * `$kvmguest` will be configured/arranged pretty closely to how we have all the other guests
     58
     59=== Block device mirroring ===
     60
     61In this approach, we'd approximate a direct transfer of disks from `$xenhost` to `$kvmhost` and try to disturb `$guest` as little as possible.
     62
     63 * get a list of block devices for `$xenguest`, and construct a parent LV on `$kvmhost` large enough to fit them all.
     64 * Use `parted` to carve up the device to match the filesystems currently exported to `$xenguest`  Use `kpartx` to expose them to `$kvmhost` directly
     65 * on `$xenguest`:
     66  * go ahead and install packages for a normal kernel and a bootloader (`linux-image-2.6-amd64` and `grub`, presumably); configure the bootloader to use the serial console.
     67  * ensure that `/etc/fstab` (and other config) refer to filesystems by UUID where possible
     68 * rsync the virtual devices from `$xenhost` to `$kvmhost`
     69 * shutdown `$xenguest`
     70 * touch up rsync
     71 * on `$kvmhost`, extract kernel and initrd from the filesystem
     72 * boot `$kvmguest` with kernel + initrd directly into single user mode (using `-kernel`, `-append`, and `-initrd` arguments to `kvm`) in order to:
     73{{{
     74rm -f /boot/grub/device.map
     75grub-install /dev/vda
     76update-grub
     77}}}
     78 * restart `$kvmguest` "normally" (from emulated BIOS)
     79
     80==== Block device mirroring advantages ====
     81
     82 * guest seems to change relatively little -- main changes (installation of kernel + bootloader packages and reconfiguration of `/etc/fstab`) can be tested while still running on `$xenhost`
     83 * user data goes through fewer transformations
     84 * no finicky network config shuffling, only one host active at once.