mount: cannot read /etc/fstab: No such file or directory
That's a pretty clear sign that your initramfs is borked. Probably because your install is borked.
How did you get past partitioning in debian-installer? Last time I did it (ummm... yesterday) I had to export something that I could partition, so your disk being hda1 is rather weird. Mine looks like:
disk = ['phy:/dev/GLaDOS/xen-portaltest,xvda,w']
its on a logical volume, not a file, but that shouldn't matter. Giving it xvda1 or whatever didn't work; it wanted to partition that, which is fairly silly.
With xvda, I went ahead and partitioned that (into a xvda1 for /boot and an xvda2 for a LVM physical volume, but you could certainly just use that for root). The installer then completed normally, and it works after dealing with the bootloader not executable error documented on the Debian Wiki's Xen entry.
rsync is a very good tool. If you use it, take the options "-aSH --delete" so you will get an amlost identical target (ctime-stamps of soft-links will have the current time).
From your writing I understand that the time needed for the rsync seems to be your main problem, while shutdown/startup of the DomUs is pretty fast (including their applications, I assume).
I see another problem in your snapshot of your big LV holding all your running DomUs. If you have many write-requests your snapshot will fill up pretty fast - and the snapshot will slow down the DomUs during writes.
In this situation I would chosse a different approach:
Use a software raid 1 to mirror from your images to your new LVs.
If you want you could combine that with snapshot/rsync to reduce the amount of data that needs to be moved. But IMHO the time neede to get that one sorted out and scripted is not worth the effort.
So here is the plan - in both cases you need block-devices (loopback-mount your images):
A) Using md (set up via mdadm)
Write a script to:
- Shut down DomU
- Loopback-Mount the DomUs image
- Create a degraded md-raid-1-device with that image
- Boot up your DomU with "phy:mdN" as new disk device
- Raise number of raid1-members from 1 to 2
- add your target LV
- Change the setup of your DomU so it will use the phy:vgX/lvY in the future
- If the mirror is complete, restart your DomU with the new setup
Whith plan A you have two downtimes lasting one restart of the DomU. The mirroring will take place in the background as fast as possible.
Drawback: All data will by synced (RAW mirror, not based on file-system)
You could get around that by creating the md-raid1 with (--assume clean) without degradation. But this will be tricky (you will need rsync to get your data to the LV then mirror the delta using md-bitmap).
B) Using drbd (set up via /etc/drbd.conf)
If you plan to switch to drbd in the future you should go this way. I did not test this, but can't see a reason why drbd should not mirror between 127.0.0.1 and 127.0.0.2 ;-)
I did not test this, but it should work - and is more complicated than plan A.
Drawback: Complicated, not tested.
But: If you want to switch to drbd anyway your can prepare your DomU this way. Run in disconnected mode until your cluster is ready, then connect, sync via IP and start live-migrating...
Best Answer
The virtual machine image is more like a full harddrive than a single file system that you can mount, which mean it has a partition table. You can use the
kpartxtool to make all of the partitions available to be mounted like so:When you're done and have unmounted all the partitions, you can remove them from the device mapper with this:
(Note, example cribbed from http://ppadala.net/blog/2010/09/kpartx-to-mount-vm-disk-images/)
For more extensive modification, you may wish to take a look at the guestfish tool.