Re: [libvirt] [RFC v2] external (pull) backup API

On 13.04.2018 12:07, Daniel P. Berrangé wrote: > On Tue, Apr 03, 2018 at 03:01:22PM +0300, Nikolay Shirokovskiy wrote: >> *Temporary snapshot API* >> >> In previous version it is called 'Fleece API' after qemu terms and I'll still >> use BlockSnapshot prefix for commands as in previous RFC instead of >> TmpSnapshots which I inclined more now. >> >> virDomainBlockSnapshotPtr >> virDomainBlockSnapshotCreateXML(virDomainPtr domain, >> const char *xmlDesc, >> unsigned int flags); >> >> virDomainBlockSnapshotDelete(virDomainBlockSnapshotPtr snapshot, >> unsigned int flags); >> >> virDomainBlockSnapshotList(virDomainPtr domain, >> virDomainBlockSnapshotPtr **snaps, >> unsigned int flags); >> >> virDomainBlockSnapshotGetXMLDesc(virDomainBlockSnapshotPtr snapshot, >> unsigned int flags); >> >> virDomainBlockSnapshotPtr >> virDomainBlockSnapshotLookupByName(virDomainPtr domain, >> const char *name, >> unsigned int flags); >> >> Here is an example of snapshot xml description: >> >> <domainblocksnapshot> >> <name>d068765e-8b50-4d74-9b72-1e55c663cbf8</name> >> <disk name='sda' type="file"> >> <fleece file="/tmp/snapshot-a.hdd"/> > > Can we just call this <source file="....."/> which is how we name > things in normal <disk> elements. 'fleece' in particular is an awful > name giving no indication of what is being talked about unless you've > already read the QEMU low levels, so I'd rather we don't use the word > "fleece" anywhere in API or XML or docs at the libvirt level. It would be easiest thing to do) Let me explain. "source" in plain external snapshots for example feels awkward to me. It is read like "make a snapshot of disk sda which source file is like that". IMHO it would be better if xml is read like "make a snapshot of disk sda and put it into dest|target file. Then for block snapshot xml would read like "make a snapshot of disk sda and put fleece there". Fleece may be a new term but it only costs one-two sentences to define it. And it is better to have this definition so that user knows what the nature of this image, so that user have correct assumptions on image size, lifetime... If fleece word itself unfortunate then we can coin another one. Looks like "source" takes root in domain xml where it reads well.

>> *Block export API* >> >> I guess it is natural to treat qemu NBD server as a domain device. So > > A domain device is normally something that is related to the guest > machine ABI. This is entirely invisible to the guest, just a backend > concept, so this isn't really a natural fit as a domain device. I have VNC in mind as a precedent.

>> And this is how this NBD server will be exposed in domain xml: >> >> <devices> >> ... >> <blockexport type="nbd"> >> <address type="ip" host="0.0.0.0" port="8000"/> >> <disk name="sda" snapshot="0044757e-1a2d-4c2c-b92f-bb403309bb17" >> checkpoint="d068765e-8b50-4d74-9b72-1e55c663cbf8" >> exportname="sda-0044757e-1a2d-4c2c-b92f-bb403309bb17"/> >> <disk name="sdb" snapshot="0044757e-1a2d-4c2c-b92f-bb403309bb17" >> checkpoint="d068765e-8b50-4d74-9b72-1e55c663cbf8 >> exportname="sdb-0044757e-1a2d-4c2c-b92f-bb403309bb17"/> >> </blockexport> > > This feels pretty awkward to me - as mentioned above this is not really > guest ABI related to having it under <devices> is not a good fit. > > I question whether the NBD server address should be exposed in the XML > at all. This is a transient thing that is started/stopped on demand via Such xml resembles VNC/serial ports to me. These two are not guest ABI. On the other hand they connected to guest devices and nbd server is not ... > the APIs you show above. So I'd suggest we just have an API to query > the listening address of the NBD server. Such API looks like having very little function to have it... > > At most in the XML we could have a element under each respective > existing <disk/> element to say whether it is exported or not, instead > of adding new <disk/> elements in a separate place. > Just as in case of graphical framebuffer I thought we can have multiple NBD servers (qemu limited to just one now). So if we put export info under disks we need to refer to NBD server which is basically specifying its address. So having xml with NBD servers each providing info on what it exports looks more simple.