Re: Concepts in storage management

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]