Changes between Initial Version and Version 1 of xen_to_kvm_transfer


Ignore:
Timestamp:
Jun 4, 2011, 4:21:27 AM (14 years ago)
Author:
Daniel Kahn Gillmor
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • xen_to_kvm_transfer

    v1 v1  
     1[[PageOutline]]
     2= Transforming Xen guests into KVM guests =
     3
     4We have some Xen systems.  They're configured in a certain way.  We want to transfer the Xen guests to a KVM host, which we want configured in a slightly different way.
     5
     6This page documents that process.  it's a work in progress. 
     7
     8== Shorthand ==
     9
     10 * `$guest` -- this is the name of the guest being transferred
     11 * `$xenhost` -- this is the dom0 running the xen setup we are transferring from
     12 * `$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)
     13
     14== disk differences ==
     15
     16Our 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.
     17
     18Our KVM setup typically has `$kvmhost` serving a single volume to `$guest`, and `$guest` carves it up however it sees fit.
     19
     20== booting differences ==
     21
     22Our 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).
     23
     24Our 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.
     25
     26== architecture differences ==
     27
     28All 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.