In creating a bootable virtual machine image, the user often needs to do several things that require root access. These may include:

• mounting a new filesystem
• chrooting into the filesystem
• creating device nodes
• creating setuid executables

In a securely configured system, these things are not able to be done without root access.

The goal of vvpc is to provide the user with an easy way to do these things and others, without requiring root access. vvpc uses ready-to-boot images that provide a “virtual victim pc” for the user to perform these actions in. From the user perspective, it appears that a new machine has been booted with user-supplied hard disk images connected and has been given full root access to the machine

 EXAMPLES:
  ./vvpc
    The simplest invocation.  This will create a virtual machine and
    put you inside it.  a 1G hda will be set up to play with.  on exit
    from the shell, the vm will be destroyed.
  qemu-img create -f qcow myhda.img 100M
  ./vvpc -hda myhda.img
    create an hard drive image myhda.img and then connect to it.
    # create a qemu image for hda hard drive
  qemu-img create -f qcow myhda.img 500M
    # create a vm, and save its reconnect id to var 'r'
  r=$(./vvpc --create --multi -hda hda.img)
    # partition the new /dev/hda with sfdisk
  ./vvpc -r $r "printf '0,100,L,*\n,,S\n' | sfdisk /dev/hda"
    # make a filesystem on the disk and mount it
  ./vvpc -r $r "mke2fs /dev/hda1 && mount /dev/hda1 /mnt"
    # extract a root tarball in /mnt from local file myroot.tar
  ./vvpc -r $r "cd /mnt && tar xvf -" < myroot.tar
    # unmount /mnt and poweroff the vm
  ./vvpc -r $r "umount /mnt && poweroff"
    # cleanup the pc in $r
  ./vvpc -r $r --teardown

gitweb source can be viewed at http://smoser.brickies.net/git/?p=vvpc.git;a=summary. Obtain source code with git using the following

git-clone http://smoser.brickies.net/git/vvpc.git

• probably should move to using virsh (or python-libvirt)
• use ssh multiple connection to reduce overhead on reconnect
• linux/kvm will reportedly support vix from vmware. This would provide a lighter weight transport than ssh (and also secure secure).
• vvpc is similar to libguestfs but would provide some additional benefits.
• kvm now supports hot plug of devices. This will be used to allow adding and removing devices after initial boot.
  • would like to have a '–attach-drive' and '–detach-drive' flag that took a path to a disk (disk image) and also a name for the drive. udev scripts in the guest would then be utilized to ensure that the following would work as expected:

  $ vvpc --reconnect --attach-drive my-disk:my-disk.img
  $ vvpc 'mkdir /mnt/my-disk1 && mount /dev/my-disk1 /mnt/my-disk1  && rm /mnt/my-disk1/etc/fstab && umount /mnt/my-disk1'
  $ vvpc --detach-drive my-disk

• install-grub (install grub onto a drive)
• star for copying filesystem (zeroing un-used data in the process)

• udev doc
  • udevinfo listed there is 'udevadm info' (similar with trigger)
  • my plan would be to have a single udev rule installed in the guest that would use PROGRAM to get partitions named correctly. On a '–add-device', the guest would be modified so that the next device added got the intended name.
• Issues Encountered
  • linux-virtual package does not include the required acpiphp module. CONFIG_HOTPLUG_PCI_ACPI is set to 'm', but the module is not collected. linux-virtual is a subset of linux-server. bug 364916
  • Ubuntu kernels do have pci_hotplug (CONFIG_HOTPLUG_PCI=y)
  • Ryan suggested “use virtio”, as scsi isn't stable. This is unfortunate, though, as jaunty kernels do not have a patch required to support hotplug removal of pci. 368978
  • kvm-x denotes kvm without cpu extensions required (ie really just qemu)