Here's the problem. We perform full tar backups of our CentOS 4/5 machines in real-time at regular intervals. And when a disaster happens, we are able to restore those backups onto virgin filesystems, make the /dev/null, /dev/zero and /dev/console devices .. and boot the machine.
This has worked well on standalone systems, and also on Xen 3.0.3 guests on CentOS 4.4 machines, where each guest filesystem resides on regular (Xen-host) real filesystem.
But there's no way we've been able to make it work for CentOS 5 Beta guests on CentOS 5 Beta Xen hosts, where each guest disk resides in a file.
The strategy goes something like:
* losetup -o 32256 /dev/loop0 /XenGuests/Guest1 * mkfs -t ext3 /dev/loop0 * mount -t ext3 /dev/loop0 /mnt * cd /mnt && tar xjpf /tmp/Guest1.tbz * for i in console null zero; do /sbin/MAKEDEV -d /mnt -x $i; done * cd /tmp; umount /srv/vm1; losetup -d /dev/loop0 * xm create -c Guest1
And it always gets most of the way through .. then the guest dies.
Ideas anyone .. please?
Graham Jenkins wrote:
Here's the problem. We perform full tar backups of our CentOS 4/5 machines in real-time at regular intervals. And when a disaster happens, we are able to restore those backups onto virgin filesystems, make the /dev/null, /dev/zero and /dev/console devices .. and boot the machine.
This has worked well on standalone systems, and also on Xen 3.0.3 guests on CentOS 4.4 machines, where each guest filesystem resides on regular (Xen-host) real filesystem.
But there's no way we've been able to make it work for CentOS 5 Beta guests on CentOS 5 Beta Xen hosts, where each guest disk resides in a file.
The strategy goes something like:
* losetup -o 32256 /dev/loop0 /XenGuests/Guest1 * mkfs -t ext3 /dev/loop0 * mount -t ext3 /dev/loop0 /mnt * cd /mnt && tar xjpf /tmp/Guest1.tbz * for i in console null zero; do /sbin/MAKEDEV -d /mnt -x $i; done * cd /tmp; umount /srv/vm1; losetup -d /dev/loop0 * xm create -c Guest1And it always gets most of the way through .. then the guest dies.
What does "most of the way through" mean?
Do those files have partition tables?
Why not attach those volumes ro to another guest?
On Tue, 2007-03-27 at 08:48 +0800, John Summerfield wrote:
Graham Jenkins wrote:
.. The strategy goes something like:
* losetup -o 32256 /dev/loop0 /XenGuests/Guest1 * mkfs -t ext3 /dev/loop0 * mount -t ext3 /dev/loop0 /mnt * cd /mnt && tar xjpf /tmp/Guest1.tbz * for i in console null zero; do /sbin/MAKEDEV -d /mnt -x $i; done * cd /tmp; umount /srv/vm1; losetup -d /dev/loop0 * xm create -c Guest1And it always gets most of the way through .. then the guest dies.
What does "most of the way through" mean?
Here's the last bit of what you see: -- Loading ext3.ko module Loading xenblk.ko module Registering block device major 202 xvda: xvda1 xvda2 Creating root device. Mounting root filesystem. mount: could not find filesystem '/dev/root' Setting up other filesystems. Setting up new root fs setuproot: moving /dev failed: No such file or directory no fstab.sys, mounting internal defaults setuproot: error mounting /proc: No such file or directory setuproot: error mounting /sys: No such file or directory Switching to new root and running init. unmounting old /dev unmounting old /proc unmounting old /sys switchroot: mount failed: No such file or directory Kernel panic - not syncing: Attempted to kill init! --
Do those files have partition tables?
Yes, you can do: fdisk /XenGuests/Guest1 .. just like a real disk. It was created by using virt-install to build a dummy guest before making the new filesystem. Just two partitions .. / on ext3, and swap.
Why not attach those volumes ro to another guest?
The theory here is that we should be able to recover an entire guest to a new Xen host from a live tar backup done the previous night on another night. Or would could recover to a larger container file if we needed more room, etc. So recovering just part of a filesystem is useful, but doesn't really achieve what we want.
I'm guessing that what we need to do is a 'chroot /mnt' then 'grub --batch' somehow .. but grub doesn't want to know about disks with names like /dev/xvda and partitions with names like /dev/xvda1 ?
-
Graham Jenkins -
John Summerfield