Hi,
with my recent work into snapshots with native libgfapi support I've run
into an issue with libvirt APIs used to delete snapshots by management apps.
The management apps use the APIs to do the job:
int
virDomainBlockCommit(virDomainPtr dom, const char *disk,
const char *base, const char *top,
unsigned long bandwidth, unsigned int flags)
int
virDomainBlockPull(virDomainPtr dom, const char *disk,
unsigned long bandwidth, unsigned int flags)
int
virDomainBlockRebase(virDomainPtr dom, const char *disk,
const char *base, unsigned long bandwidth,
unsigned int flags)
As you can see in the prototypes of these functions (and from the docs
for them which I'm not going to copy here) the user can provide the disk
specification in two possible options:
1) a full path if it's unambiguous - this is file centric and requires
the file to be in the local filesystem
2) a disk name "vda" - this is selected automatically by libvirt but
allows to specify only the top image.
For systems that want to use remote storage without local representation
such as gluster+libgfapi, this doesn't allow to use the APIs to start
block jobs.
To solve this issue we need a way to specify paths on remote storage in
some way. Below are two options we've discussed on IRC.
1) Use URIs along with the file path to specify disk images.
This option would add a new, possibly well documented URIs to specify
paths for disk images. These would be libvirt defined URIs (but
surprisingly "similar" to qemu URIS) so that hypervisors with different
storage specification would need a conversion.
This would allow to specify the targets as:
vda - disk name
/path/to/file - legacy way, path
file:///path/to/file - new way of file paths
block:///dev/blah - new way, block devs
gluster://server/vol/img - new way, remote images
...
Possible caveats: RBD for example allows to use multiple hosts and we'd
need to introduce a possibility to specify it if we'd add support for
this on rbd.
2) Export the image chain in the XML and allow to use indexed disk names
This option would require to export the backing chain in the XML in some
way, either the existing disk source specification in multiple elements
(which I don't like as it is a bit convoluted), or possibly again via URIs.
Then the user would be allowed to specify vda[2] for the second backing
image of the vda disk.
With this the internal representations of the backing chain would be
used without the need for the user to specify path.
A possible caveat here is that if backing chains for some reason will be
converted to backing trees, this approach will be invalid.
3) ? anyone suggesting something better? :)
Thanks in advance for suggestions and/or new ideas.
Peter
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list