[Libvir] Concepts in storage management

[Chris Lalancette]

Daniel P. Berrange wrote:
> It is already nested, even if you don't see usually see it visible in the
> Dom0 host. eg, in the host I assign a LVM volume to a guest. A guest then
> puts this into its own nested LVM VG & allocates volumes. This nesting isn't
> normally visible by default, but tools like kpartx make it visible. 
> 
> Making this nesting visible in the host isn't neccessarily something we need
> to expose in the APIs, but we should consider it when thinking about the
> storage concepts. Depending on how we end up modelling storage APIs, we may
> end up with getting the capability 'for free', so artifically restricting it
> upfron is premature.

That's true.  I've always viewed the storage allocated to a guest, 
whether it be a partition, a file, etc., as an opaque object that the 
guest can do anything it wants with, even if the host doesn't understand 
it.  There is an argument to be made for the host being able to do 
maintenance on guest disks (if, for some reason, you can't boot the 
guest); but I honestly think this sort of maintenance is best done 
inside the guest container (via the "normal" guest rescue modes - 
LiveCD, Knoppix, Windows Rescue, etc).

> It is a good question. My thought is that if we went for a 'libstorage' the
> scope would be dramatically broader, than if we focused on the concepts we
> we need for managing virtual machines. Or we provide it in libvirt and as
> it evolves we can factor our into a standalone library. My inclination is
> to get a working implementation for libvirt before trying to over generalize
> to service non-virt related applications.

Agreed that the scope for a libstorage could get out of hand.  But I 
think if we keep the initial scope targetted enough for what we want 
(i.e. integration with libvirt/virt matters), we can get away with 
having a separate library, and the rest can grow organically from that. 
  Really, the only part that needs to be generic is the XML; if we can 
get that down, the implementation doesn't matter.  Basically with this 
model we wouldn't be dependent on libvirt internal data 
structures/functions, so we wouldn't have the pain of extracting it 
later.  Of course, that is more work too :).

Chris Lalancette