[libvirt] [PATCH v5 1/5] Introduce virDomainFSFreeze() and virDomainFSThaw() public API

[Daniel P. Berrange]

On Thu, Apr 24, 2014 at 12:16:00AM +0000, Tomoki Sekiyama wrote:
> Hi Daniel,
> 
> 
> On 4/23/14 5:55 , "Daniel P. Berrange" <berrange at redhat.com> wrote:
> >On Tue, Apr 22, 2014 at 06:22:18PM +0000, Tomoki Sekiyama wrote:
> >> Hi Daniel,
> >> thanks for your comment.
> >> 
> >> On 4/22/14 11:39 , "Daniel P. Berrange" <berrange at redhat.com> wrote:
> >> >On Thu, Apr 03, 2014 at 11:39:29AM -0400, Tomoki Sekiyama wrote:
> >> >> +
> >> >> +/**
> >> >> + * virDomainFSFreeze:
> >> >> + * @dom: a domain object
> >> >> + * @disks: list of disk names to be frozen
> >> >> + * @ndisks: the number of disks specified in @disks
> >> >
> >> >I realize this current patch series doesn't use the @disks parameter
> >> >at all, but what exactly are we expecting to be passed here ? Is
> >> >this a list of filesystem paths from the guest OS pov, or is it a
> >> >list of disks targets from libvirt's POV ? I'm guessing the former
> >> >since this is expected to be passed to the guest agent.
> >> 
> >> My intention for 'disks' is latter, a list of disks targets from
> >> libvirt's POV.
> >> Currently it is just a placeholder of API. It would be passed to the
> >> agent after it is converted into a list of device addresses (e.g. a pair
> >> of drive address and controller's PCI address) so that the agent can
> >> look up filesystems on the specified disks.
> >
> >Hmm, I wonder how practical such a conversion will be.
> >
> >eg libvirt has a block device "sda", but the guest OS may have added
> >a partition table (sda1, sda2, sda3, etc) and then put some of those
> >partitions into LVM (volgroup00) and then created logical volume
> >(vol1, vol2, etc). The guest agent can freeze individual filesystems
> >on each logical volume, so if the API is just taking libvirt block
> >device names, we can't express any way to freeze the filesystems the
> >guest has.
> 
> Specifying libvirt disk alias name is coming from applications'
> requirement. For example, OpenStack cinder driver only knows provide
> libvirt device names.
> It is also nice if virDomainSnapshotCreateXML can specify 'disks' to be
> frozen when only a subset of the disks is specified in snapshot XML.
> 
> I'm now prototyping qemu-guest-agent code to resolve filesystems from
> disk addresses, and it is working with virtio/SATA/IDE/SCSI drives on
> x86 Linux guests. It can also handle LVM logical volumes that lies on
> multiple partitions on multiple disks.
> 
> https://github.com/tsekiyama/qemu/commit/6d26115e769a7fe6aba7be52d2180453ac
> a5fee5
> 
> 
> This gathers disk device information from sysfs in the guest.
> On windows, I hope Virtual Disk Service can provide this kind of
> informations too.

All of this assumes that you're only interested in freezing filesystems
that are backed by virtual devices exposes from the hypervisor. A guest
OS could be directly accessing iSCSI/RBD/Gluster volumes. IMHO, it is
within scope of this API to be able to freeze/thaw such volumes, but
if you make the API take libvirt disk names, this is impossible, since
these volumes are invisible to libvirt.

What you propose is also fairly coarse because you are forcing all
filesystems on a specified block device to be suspended at the
same time. That is indeed probably the common case need, but it is
desirable not to lock ourselves into that as the only option.

Finally, if the guest is doing filesystem passthrough (eg virtio-9p)
then we ought to allow for freeze/thaw of such filesystems, which
again don't have any block device associated with libvirt XML.

> >So I think we have no choice but to actually have the API take a
> >list of guest "volumes" (eg mount points in Linux, or drive letters
> >in Windows).
> >
> >Ideally the guest agent would also provide a way to list all
> >currently known guest "volumes" so we could expose that in the
> >API too later.
> 
> Possibly. If the volumes information from the API contains the
> dependent hardware addresses, libvirt clients might be able to map
> the volumes and libvirt disks from domain XML.
> In this case, specifying subset volumes in virDomainSnapshotCreateXML
> would be difficult. Maybe libvirt should provide the mapping function.
> 
> Which way do you prefer?

IMHO the more I look at this, the more I think we need to provide a way
for apps to enumerate mount points in the guest, so that we can cover
freeze/thaw of individual filesystems, not merely block device.

When listing filesystems, we'd need a way to express what storage a
filesystem is hosted on. So we'd likely be talking about an API
which returned an array of (mount point, storage XML), where storage
XML is some concise XML description of the storage beneath the FS.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|