| Deletions are marked like this. | Additions are marked like this. |
| Line 107: | Line 107: |
| = When the DomU is running squeeze and the destination DomU is running wheezy = | = When the DomU is running squeeze and the destination Dom0 is running wheezy = |
This really isn't rocket science.
When the DomU and both Dom0s are all running the same Debian version:
- Identify the DomU's block devices. Examine its configuration file in /etc/xen/«name». Usually it will simply be LVM LVs in the general pattern /dev/dom0.root/«name»-«whatever». But sometimes it can be more complicated (e.g., www-nodes have an extra disk dedicated for caching; hence to move a www-node, you will also need to physically move that disk, or setup a new dedicated disk at the destination Dom0).
- Shutdown the DomU.
- Create new block devices at the destination Dom0 with appropriate sizes.
I usually use lvscan to help figure this out, E.g.,:
root@radium:~# lvscan ACTIVE '/dev/dom0.root/dom0.swap' [1.00 GiB] inherit ACTIVE '/dev/dom0.root/dom0.root' [2.00 GiB] inherit ACTIVE '/dev/dom0.root/bt2-swap' [1.00 GiB] inherit ACTIVE '/dev/dom0.root/bt2-disk' [4.00 GiB] inherit ACTIVE '/dev/dom0.root/bt2-afscache' [1.00 GiB] inherit ACTIVE '/dev/dom0.root/bt2-tmp' [2.00 GiB] inherit ACTIVE '/dev/dom0.root/svn-swap' [1.00 GiB] inherit ACTIVE '/dev/dom0.root/svn-disk' [4.00 GiB] inherit ACTIVE '/dev/dom0.root/svn-afscache' [1.00 GiB] inherit ACTIVE '/dev/dom0.root/www-node-2-swap' [1.00 GiB] inherit ACTIVE '/dev/dom0.root/www-node-2-root' [4.00 GiB] inherit ACTIVE '/dev/dom0.root/www-node-2-afscache' [2.00 GiB] inherit ACTIVE '/dev/dom0.root/www-node-2-userlogs' [2.00 GiB] inherit
Then use lvcreate -n «lvname» -L «lvsize» «vgname»; the VG will almost always be dom0.root, unless the Dom0 was set up in a non-standard fashion. E.g.,
root@cesium:~# lvcreate -n svn-swap -L 1G dom0.root Logical volume "svn-swap" created root@cesium:~# lvcreate -n svn-disk -L 4G dom0.root Logical volume "svn-disk" created root@cesium:~# lvcreate -n svn-afscache -L 1G dom0.root Logical volume "svn-afscache" created
To verify you've created the desired LVs, you can run lvscan on the destination Dom0. E.g.,
root@cesium:~# lvscan ACTIVE '/dev/dom0.root/dom0.root' [3.81 GiB] inherit ACTIVE '/dev/dom0.root/dom0.swap' [1.00 GiB] inherit ACTIVE '/dev/dom0.root/snail-root' [10.00 GiB] inherit ACTIVE '/dev/dom0.root/snail-swap' [1.00 GiB] inherit ACTIVE '/dev/dom0.root/svn-swap' [1.00 GiB] inherit ACTIVE '/dev/dom0.root/svn-disk' [4.00 GiB] inherit ACTIVE '/dev/dom0.root/svn-afscache' [1.00 GiB] inherit
If you are paranoid, you can double-check that the destination devices are large enough by comparing blockdev --getsz «dev» at the source and destination Dom0s.
- Copy the data from each source block device to the corresponding destination block device as needed. (I say as needed, because some do not contain any data that's truly persistent. The most common case is for -swap and -afscache devices.)
You can use the dd and ssh commands to do the copying. E.g.,
root@radium:~# dd if=/dev/dom0.root/svn-disk bs=4M | ssh -e none cesium dd bs=4M of=/dev/dom0.root/svn-disk 1024+0 records in 1024+0 records out 4294967296 bytes (4.3 GB) copied, 153.976 s, 27.9 MB/s 0+261858 records in 0+261858 records out 4294967296 bytes (4.3 GB) copied, 154.738 s, 27.8 MB/s
Using "-e none" is important! Otherwise, if the ssh escape sequence (<CR>~) exists in the block device, it will screw up the copy.
- Properly initialize any devices that did not need to be copied. E.g.,
root@cesium:~# mkswap /dev/dom0.root/svn-swap mkswap: /dev/dom0.root/svn-swap: warning: don't erase bootbits sectors on whole disk. Use -f to force. Setting up swapspace version 1, size = 1048572 KiB no label, UUID=83760789-8312-4c4f-bbc3-660a5babe810 root@cesium:~# mkfs.ext2 /dev/dom0.root/svn-afscache mke2fs 1.42.5 (29-Jul-2012) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) Stride=0 blocks, Stripe width=0 blocks 65536 inodes, 262144 blocks 13107 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=268435456 8 block groups 32768 blocks per group, 32768 fragments per group 8192 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Allocating group tables: done Writing inode tables: done Writing superblocks and filesystem accounting information: done
- Copy /etc/xen/«name» from the source Dom0 to the destination Dom0.
- Remove /etc/xen/auto/«name» from the source Dom0.
- Usually this is not necessary, but sometimes you may need to edit the block device paths in the configuration (at the destination Dom0). This would needed if, for example, either the source or destination used a non-standard VG name (i.e., NOT dom0.root). Just make sure the block device paths are correct for the destination Dom0.
Try to start the DomU on the destination Dom0. I.e., xm create -c «name». Verify it boots successfully. If everything looks good, you can exit the DomU console with ^].
- On the source Dom0, rename /etc/xen/«name» to something like /etc/xen/«name».moved-to-«destdom0».«date». This is to make it less likely for the DomU to get started in two places.
- Make it so the DomU will automatically start on the destination Dom0. E.g.,
snail login: root@cesium:~# cd /etc/xen/auto root@cesium:/etc/xen/auto# ln -s ../svn root@cesium:/etc/xen/auto# ls -hl total 0 lrwxrwxrwx 1 root root 14 Oct 12 20:05 snail -> /etc/xen/snail lrwxrwxrwx 1 root root 6 Oct 25 18:36 svn -> ../svn
- Remove old volumes on the source DomU (lvscan is helpful here). e.g.,
root@thallium:~# lvremove dom0.root/rgh-swap Do you really want to remove active logical volume rgh-swap? [y/n]: y Logical volume "rgh-swap" successfully removed
When the DomU is running squeeze and the destination Dom0 is running wheezy
This is slightly complicated by the fact you need the squeeze kernel installed on the wheezy Dom0. (Though you will still be running the wheezy kernel!) That just requires a little bit of apt ninjary.
Put the following in /etc/apt/preferences.d/squeeze-kernel:
Package: * Pin: release n=squeeze Pin-Priority: -1 Package: linux-image-2.6.32-5-xen-amd64 Pin: release n=squeeze Pin-Priority: 500 Package: linux-image-2.6.32-5-xen-686 Pin: release n=squeeze Pin-Priority: 500
It's basically saying that squeeze packages should be uninstallable, except for the Xen kernel needed to boot squeeze DomUs.
Then add the following to /etc/apt/sources.list:
# pull from the squeeze repos as well (for older domU kernels) deb http://mirrors.mit.edu/debian/ squeeze main deb-src http://mirrors.mit.edu/debian/ squeeze main deb http://security.debian.org/ squeeze/updates main deb-src http://security.debian.org/ squeeze/updates main
So it will look in the squeeze repo for packages (and find the kernel). (Tick... tick... tick... eventually the regular Debian mirrors are going to stop hosting squeeze. When that happens, the URLs will need to be adjusted to go to some mirror of archive.debian.org.)
Then:
aptitude update aptitude install linux-image-2.6.32-5-xen-amd64 # or, for i386: aptitude install linux-image-2.6.32-5-xen-686
After that, moving the DomU is no different than the like-versions case detailed above.
When the DomU is running something really old... (lenny, etch, ... sarge‽)
At this point, the apt_preferences trick above doesn't work so well, since Debian's made changes in the way initrds work.
What I've been doing is installing the kernel within the DomU, setting up a /boot/grub directory, and using pygrub.
The tricky part is getting a happy grub configuration in the DomU. How to do this varied depending on the Debian version.
One caveat I do remember quite well, is that a lot of the etch DomUs will fail to boot (some sort of memory fault in the initrd) if libc6-xen is installed. Be sure to uninstall it before moving the DomU.
Another is that pygrub doesn't understand jfs. You'll need to recreate the DomU's filesystem as ext3.
Perhaps I'll provide more useful information in the future.
One piece of good news though: in the case that I've already set up pygrub for an old domU, you should be able to move it as in the like-versions case without issue.