On Thu, Aug 07, 2008 at 09:57:17AM -0500, Javier Guerra wrote: > On Thu, Aug 7, 2008 at 9:51 AM, Dietmar Maurer <[EMAIL PROTECTED]> wrote: > > I thought about using 1 lvm volume, but splitting that into slices > > somehow, which can then be used as kvm disks - maybe by implementing a > > very simple filesystem (block mapper). The problem with this approach is > > that adding/deleting a new disk would mean to grow/shrink an lvm > > partition, which is slow. > > you could run LVM in the VM. be careful about block scanning tools on > Dom0, could mistake the LVM structure inside a LV for the 'outer' one. > (reiserfsck has this problem with image files)
This is an example of why you should use nested partition tables and not export a whole block device to the guest - always partition the block device on your host into at least one partition, and expose this as the virtual disk to the guest. The guest then partitions this and puts the partition in as the physical volume. No dom0 tool will accidentally see the guest LVM volumes now. In the few occassions when you do need to, you can access this nested partition table in the dom0 using kpartx. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
