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

[Tomoki Sekiyama]

On 4/24/14 4:58 , "Daniel P. Berrange" <berrange at redhat.com> wrote:

>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/6d26115e769a7fe6aba7be52d2180453
>>ac
>> 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.

OK, then, APIs will look like

  int virDomainFSFreeze(virDomainPtr dom, const char *mountPoints,
                        unsigned int nMountPoints, unsigned int flags);

  int virDomainFSThaw(virDomainPtr dom, unsigned int flags);

As we drop nesting, FSThaw will not take mountPoints argument.



>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.

This sounds reasonable to me.

Thanks for your suggestions.

>Regards,
>Daniel

Regards,
Tomoki Sekiyama