Re: [Libguestfs] Suggestions on building VM disks from scratch

On Wed, Apr 04, 2012 at 09:45:18AM +0100, Richard W.M. Jones wrote: ===================================================================== I upgraded and installed a few more things and my error at least changed, at least so I thought: # virt-rescue -a recovery2.immortaldata.net.raw mke2fs: Attempt to write block to filesystem resulted in short write while zeroing block 1048560 at end of filesystem Could not write 6 blocks in inode table starting at 917506: Attempt to write block to filesystem resulted in short write febootstrap-supermin-helper: /sbin/mke2fs -t ext2 -Fq '/var/tmp/guestfs.cZge1g/root': failed But guestfish apparently finds my small root disk to be a tasty morsel of fish food and impolitely swallows it whole: 4.1G /var/tmp/guestfs.1PFF68 3.5G /var/tmp/guestfs.cZge1g 4.1G /var/tmp/guestfs.FYAm8O 4.1G /var/tmp/guestfs.JP2LNO 4.1G /var/tmp/guestfs.qsLaNA 4.1G /var/tmp/guestfs.wwKT58 4.1G /var/tmp/guestfs.ZueM9V This maxed out the root partition. Once I found this was happening I cleared this out and added: TMPDIR=/home/tmp This got me back to the original error message: # virt-rescue -a recovery2.immortaldata.net.raw febootstrap-supermin-helper: ext2: parent directory not found: /lib: File not found by ext2_lookup ===================================================================== # libguestfs-test-tool ===== Test starts here ===== LIBGUESTFS_DEBUG=1 TMPDIR=(not set) libguestfs: new guestfs handle 0x23dc190 library version: 1.14.8 guestfs_get_append: (null) guestfs_get_attach_method: appliance guestfs_get_autosync: 1 guestfs_get_direct: 0 guestfs_get_memsize: 500 guestfs_get_network: 0 guestfs_get_path: /usr/lib/guestfs guestfs_get_pgroup: 0 guestfs_get_qemu: /usr/bin/kvm guestfs_get_recovery_proc: 1 guestfs_get_selinux: 0 guestfs_get_smp: 1 guestfs_get_trace: 0 guestfs_get_verbose: 1 host_cpu: x86_64 Launching appliance, timeout set to 600 seconds. libguestfs: [00000ms] febootstrap-supermin-helper --verbose -f checksum '/usr/lib/guestfs/supermin.d' x86_64 supermin helper [00000ms] whitelist = (not specified), host_cpu = x86_64, kernel = (null), initrd = (null), appliance = (null) supermin helper [00000ms] inputs[0] = /usr/lib/guestfs/supermin.d checking modpath /lib/modules/3.2.0-16-generic is a directory picked vmlinuz-3.2.0-16-generic because modpath /lib/modules/3.2.0-16-generic exists checking modpath /lib/modules/3.2.0-21-generic is a directory picked vmlinuz-3.2.0-21-generic because modpath /lib/modules/3.2.0-21-generic exists checking modpath /lib/modules/2.6.32-38-server is a directory picked vmlinuz-2.6.32-38-server because modpath /lib/modules/2.6.32-38-server exists supermin helper [00000ms] finished creating kernel supermin helper [00098ms] visiting /usr/lib/guestfs/supermin.d supermin helper [00098ms] visiting /usr/lib/guestfs/supermin.d/daemon.img supermin helper [00098ms] visiting /usr/lib/guestfs/supermin.d/init.img supermin helper [00098ms] adding kernel modules supermin helper [00259ms] finished creating appliance libguestfs: [00353ms] begin building supermin appliance libguestfs: [00353ms] run febootstrap-supermin-helper libguestfs: [00353ms] febootstrap-supermin-helper --verbose -f ext2 /usr/lib/guestfs/supermin.d x86_64 /var/tmp/guestfs.xtl6Jb/kernel /var/tmp/guestfs.xtl6Jb/initrd /var/tmp/guestfs.xtl6Jb/root supermin helper [00000ms] whitelist = (not specified), host_cpu = x86_64, kernel = /var/tmp/guestfs.xtl6Jb/kernel, initrd = /var/tmp/guestfs.xtl6Jb/initrd, appliance = /var/tmp/guestfs.xtl6Jb/root supermin helper [00000ms] inputs[0] = /usr/lib/guestfs/supermin.d checking modpath /lib/modules/3.2.0-16-generic is a directory picked vmlinuz-3.2.0-16-generic because modpath /lib/modules/3.2.0-16-generic exists checking modpath /lib/modules/3.2.0-21-generic is a directory picked vmlinuz-3.2.0-21-generic because modpath /lib/modules/3.2.0-21-generic exists checking modpath /lib/modules/2.6.32-38-server is a directory picked vmlinuz-2.6.32-38-server because modpath /lib/modules/2.6.32-38-server exists supermin helper [00000ms] finished creating kernel supermin helper [02595ms] finished mke2fs supermin helper [02596ms] visiting /usr/lib/guestfs/supermin.d supermin helper [02596ms] visiting /usr/lib/guestfs/supermin.d/daemon.img supermin helper [02601ms] visiting /usr/lib/guestfs/supermin.d/init.img febootstrap-supermin-helper: ext2: parent directory not found: /lib: File not found by ext2_lookup libguestfs: error: external command failed, see earlier error messages libguestfs-test-tool: failed to launch appliance libguestfs: closing guestfs handle 0x23dc190 (state 0) ===================================================================== Updated from official Ubuntu Precise Pangolin server last night. Package: libguestfs0 Architecture: amd64 Source: libguestfs Version: 1:1.14.8-1 Package: febootstrap Architecture: amd64 Version: 3.12-1 If I can get the grub installed it should, since the original are in most cases virtual servers built on vmdk disks on a licensed VMware ESX server. The other way I found to get to this particular point was: $ dd if=/dev/zero of=/recover2.us.net.raw count=20M $ losetup /dev/loop0 recover2.us.net.raw $ cfdisk /dev/loop0 create a 9G bootable linux partition and a 1G swap $ kpartx -a -v /dev/loop0 $ mkfs.ext4 /dev/mapper/loop0p1 -m 0.01 -L "RecoverTest" $ mkdir tmp $ mount /dev/mapper/loop0p1 tmp From the backup server: $ cd <to the lastest dirvish backup set> $ rsync -av tree/ root@rebuild.server.net:/srv/idcpool/tmp/ But I could not figure out a safe way to install grub that would not put the boot disk of a critical server at risk of getting its MBR clobbered. Grub is very good at doing such things and very difficult to convince to do what *you* want rather than what *it* wants. I much prefer the technique of just using a guestfish script to do it all as you showed, but I still need to load up the backup set and install grub properly. Actually, what the situation is that for our restoration of *last resort*, we have a server that does incremental daily and for some key infrastructure 4 times daily backups via dirvish. So what we need dirvish for is so that we can connect to the backup server and copy the most recent copy of the failed device. So yes, we do have a good reason to use rsync as it gives us a very simple secure data transfer of the files from one server to the new image. The alternative is to do the rsync over to the rebuild server, being careful not to get links messed up, tar.gz the result and then pray the result will actually recreate things, links, dev files, uid.gid's, modes, etc on when unpacked. I have an inherent distrust of adding extra steps into things if I can avoid them, particularly when discussing a mission critical last resort failsafe. Oh, and yes, we do separately back up database files via the appropriate snapshotting and those would have to be overloaded seperately after the main restoration. That's one problem, the big one I am working on. The other I can talk to you about after I get this one sorted, and that is using virt-rescuse/guestfish in the virtualization of an old SuSE server on end of life hardware. It of course has lots of LVM's on the system disk just to make things interesting...