On 4/24/14 4:58 , "Daniel P. Berrange" <berrange@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list