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
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
