You are right of course, /etc/fstab on the guest contains "/dev/sdXY" entries. These get generated by /usr/share/pyshared/VMBuilder/plugins/ubuntu/feisty.py as you mentioned. After changing all "/dev/sdXY" to "/dev/vdXY" I can indeed boot happily :)
What threw me off was that QEMU did not (and does not) see these virtio- based drives when booting (see screenshots) and that changing the target device name in the domain definition (<target dev='vda' bus='virtio'/> to <target dev='sda' bus='virtio'/> and vice versa) does nothing. I suppose this has to do with the snippet of documentation I quoted previously and probably with the fact that the virtio driver is paravirtualized so QEMU doesn't do any of the emulation it would do with IDE- or SCSI-based buses. Should have thought of that earlier. So creating guests in the manner I described in my original post using vmbuilder works after applying your one-line fix to /usr/share/pyshared/VMBuilder/plugins/ubuntu/feisty.py. I am not sure where this bug lies since I am just getting to know the more advanced aspects of libvirt but I suppose vmbuider is to "blame". That's understandable given that it is still somewhat young and cannot consider all possible combinations and varieties of libvirt options. Too bad virt-install is mostly useless for quickly creating and deploying guests for testing purposes. I like your solution b.) but doesn't that add yet another level of indirection and complicates guest setup even more? -- Using virtio for block devices makes disks and partitions disappear in KVM/QEMU (using vmbuilder and libvirt) https://bugs.launchpad.net/bugs/517067 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs