Thanks Anatoly for the patch, and Chen for the cleanup help.
Supporting type=network disks breaks quite a few assumptions we carry
internally unfortunately, like ensuring So does the gluster volume path syntax
being a URI and not an actual FS path. That explains the various 'if type ==
gluster' bits sprinkled in the patch. I'd like to avoid those where possible.
So, a few thoughts:
- The testdriver addition for the gluster pool/volume is handy. However I'd
also like an example rbd volume (there's already a pool), and sheepdog
pool/volume, so we can try and generalize this support. Hopefully libvirt's
test suite has examples of all those so no one needs to set up a server just
to confirm it. I'd ACK that patch now
- testdriver test-many-devices extended to have a few example network disks:
one gluster, one http, maybe one with type=volume pointing to a
gluster/rbd/sheepdog volume. I'd ACK that patch now
- I don't like the addition that has VirtualDisk.path accept a virStorageVol
. Instead I'd just teach diskbackend how to handle a gluster:// URI. That will
also allow virt-install --disk gluster://... to automagically work.
- diskbackend.py:StorageBackend is going to need to be extended to understand
that the passed 'path' is a network disk, and every function will have to add
a case for 'elif self._is_network' or similar.
- We need to add clitest cases, at least one for gluster backed by a storage
volume, gluster _not_ backed by a storage volume, and something like
protocol=http which will never be backed by a storage volume.
I'll take a look at this stuff either this week or next, but any help in the
interim is appreciated. The first two suggestions are hopefully straightforward.
Thanks,
Cole
_______________________________________________
virt-tools-list mailing list
virt-tools-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/virt-tools-list
