[Ovirt-devel] Modeling LVM storage
Daniel P. Berrange
berrange at redhat.com
Tue Sep 16 17:38:17 UTC 2008
On Tue, Sep 16, 2008 at 07:31:36PM +0200, Chris Lalancette wrote:
> Steve Ofsthun wrote:
> > Chris Lalancette wrote:
> >> sseago and I (and variously, other folks) had a somewhat longish
> >> conversation on IRC today about carving up storage with LVM. This is the
> >> second time we've beaten this horse, so hopefully we are somewhat OK now.
> >> The basic idea is that, given an iSCSI LUN (and SCSI and FC LUNs in the
> >> future), we want to either:
> >>
> >> 1) Assign the entire LUN to a guest (this is the way that ovirt works
> >> right now) 2) Carve up the LUN using LVM, and then hand out individual
> >> logical volumes to guests.
> >
> > How do you plan to distinguish between LVM PVs/LVs created by ovirt/libvirt
> > on iscsi LUNs from LVM PVs/LVs created by guest OSes on directly connected
> > iscsi LUNs? Just blindly running pvscan will run into all sorts of trouble.
>
> This actually shouldn't be a problem, I don't think. When we assign a whole LUN
> to a guest, the guest will in all likelihood lay down a partition table. Since
> the partition table isn't a valid LVM partition, scanning that LUN won't have
> any LVM metadata on it. Now, if you have the case where a guest *doesn't* lie
> down a partition table, and directly uses the whole disk as LVM, I guess we
> could run into a problem. I don't know how common a case that is, but at least
> in Fedora/RHEL land, we never do that by default.
That's basically saying that correct operation of the host would be relying
on a specific configuration by the guest admin. I wouldn't assume that guest
admin's are nice in that way - we have to assume hostile/badly-configured
guests will appear every now & then and make oVirt robust against them.
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 :|
More information about the ovirt-devel
mailing list