<div dir="ltr">Hi,<br><br>Some days ago, a bunch of Nova specs were approved for Kilo.  Among them was <a href="https://blueprints.launchpad.net/nova/+spec/use-libvirt-storage-pools">https://blueprints.launchpad.net/nova/+spec/use-libvirt-storage-pools</a><br><br>Now, while I do recognize the wisdom of using storage pools, I do see a couple of possible problems with this, especially in the light of my upcoming spec proposal for using StorPool distributed storage for the VM images.<br><div><br></div><div>My main concern is with the explicit specification that the libvirt pools should be of the "directory" type, meaning that all the images should be visible as files in a single directory.  Would it be possible to extend the specification to allow other libvirt pool types, or to allow other ways of pointing Nova at the filesystem path of the VM image?</div><div><br></div><div>Where this is coming from is that StorPool volumes (which we intend to write a DiskImage subclass for) appear in the host filesystem as /dev/storpool/volumename special files (block devices).  Thus, it would be... interesting... to find ways to make them show up under a specific directory (yes, we could do lots and lots of symlink magic, but we've been down that road before and it doesn't necessarily lead to Good Things(tm)).  I see that the spec has several mentions of "yeah, we should special-case Ceph/RBD here, since they do things in a different way" - well, StorPool does things in a slightly different way, too :)</div><div><br></div><div>And yes, we do have work in progress to expose the StorPool cluster's volumes as a libvirt pool, but this might take a bit of time to complete and then it will most probably take much more time to get into the libvirt upstream *and* into the downstream distributions, so IMHO "okay, let's use different libvirt pool types" might not be entirely enough for us, although it would be a possible workaround.</div><div><br></div><div>Of course, it's entirely possible that I have not completely understood the proposed mechanism; I do see some RBD patches in the previous incarnations of this blueprint, and if I read them right, it *might* be trivial to subclass the new libvirt storage pool support thing and provide the /dev/storpool/volumename paths to the upper layers.  If this is so, feel free to let me know I've wasted your time in reading this e-mail, in strong terms if necessary :)</div><div><br></div><div>G'luck,</div><div>Peter</div><div><br></div></div>