[libvirt] question about syntax of storage volume <target> element
I've attempted to use virt-manager to create a new VM that uses a volume from an rbd-based network pool, but have not been able to progress past step 4/5 where VM storage is selected. It appears virt-manager has problems properly detecting the volume as network-based storage, but before investigating those further I have a question about the syntax of the <target> element of a storage volume. The storage management page [0] of the website describing rbd volumes claims that the <path> subelement contains an 'rbd:rbd/' prefix in the volume path. But the page describing pool and volume format [1] syntax does not contain any info wrt specifying network URLs in the <path> subelement. What is the expectation wrt the <path> subelement of the <target> element within rbd volume config? In general, should the <path> subelement encode the scheme (e.g. rbd://) of a network-based volume? And if so, should it be formatted in the traditional 'rbd://' vs 'rbd:rbd/' syntax? Regards, Jim [0] https://libvirt.org/storage.html#StorageBackendRBD [1] https://libvirt.org/formatstorage.html#StorageVolTarget
On 09/28/2018 12:54 AM, Jim Fehlig wrote:
I've attempted to use virt-manager to create a new VM that uses a volume from an rbd-based network pool, but have not been able to progress past step 4/5 where VM storage is selected. It appears virt-manager has problems properly detecting the volume as network-based storage, but before investigating those further I have a question about the syntax of the <target> element of a storage volume.
Yeah virt-manager is known to be lacking WRT rbd. I did some work a few years back but didn't finish it. At least it doesn't know how to correctly use a volume with any auth data in the XML. I need to get another rbd setup to test with and fix it all The storage management page
[0] of the website describing rbd volumes claims that the <path> subelement contains an 'rbd:rbd/' prefix in the volume path. But the page describing pool and volume format [1] syntax does not contain any info wrt specifying network URLs in the <path> subelement.
What is the expectation wrt the <path> subelement of the <target> element within rbd volume config? In general, should the <path> subelement encode the scheme (e.g. rbd://) of a network-based volume? And if so, should it be formatted in the traditional 'rbd://' vs 'rbd:rbd/' syntax?
I noticed this too. sheepdog is weird as well. Gluster has full URIs in the volume <path> though I certainly think full URIs is the way it should be... even if nothing natively handles the URI format we output, I think a <path> field should be fully descriptive/unique, like how file volumes in directory pools show absolute paths. I guess the question though is if we can change it at this point, it's been like that for years, apps may be depending on the weird format in someway - Cole
On Mon, Oct 01, 2018 at 02:28:09PM -0400, Cole Robinson wrote:
On 09/28/2018 12:54 AM, Jim Fehlig wrote:
I've attempted to use virt-manager to create a new VM that uses a volume from an rbd-based network pool, but have not been able to progress past step 4/5 where VM storage is selected. It appears virt-manager has problems properly detecting the volume as network-based storage, but before investigating those further I have a question about the syntax of the <target> element of a storage volume.
Yeah virt-manager is known to be lacking WRT rbd. I did some work a few years back but didn't finish it. At least it doesn't know how to correctly use a volume with any auth data in the XML. I need to get another rbd setup to test with and fix it all
I was investigating the RBD support as well and in order to add proper support for it into virt-manager we need to add support for secrets. With secrets the issue is that they don't have any name, only UUID or usage can be sensible ID from virt-manager POV and our current object caching code expects name for objects and that's where I've stopped. Pavel
On 10/2/18 5:13 AM, Pavel Hrdina wrote:
On Mon, Oct 01, 2018 at 02:28:09PM -0400, Cole Robinson wrote:
On 09/28/2018 12:54 AM, Jim Fehlig wrote:
I've attempted to use virt-manager to create a new VM that uses a volume from an rbd-based network pool, but have not been able to progress past step 4/5 where VM storage is selected. It appears virt-manager has problems properly detecting the volume as network-based storage, but before investigating those further I have a question about the syntax of the <target> element of a storage volume.
Yeah virt-manager is known to be lacking WRT rbd. I did some work a few years back but didn't finish it. At least it doesn't know how to correctly use a volume with any auth data in the XML. I need to get another rbd setup to test with and fix it all
I was investigating the RBD support as well and in order to add proper support for it into virt-manager we need to add support for secrets.
Right. But I was starting with the assumption that a "storage admin" setup an rbd-based pool, necessary secrets, etc. Then user creating a new VM could select existing volumes in the pool or create new ones at step 4/5 of the VM creation wizard. Currently a user can select an existing volume or create a new one, but can't progress beyond that point. I have a hack (attached, based against 1.5.1) to workaround the problem in virt-manager. Commit 582c1d3d fixed virt-install to copy auth data from the pool to the device config in domXML and as a first step I'm trying to do the same with virt-manager. Regards, Jim
On 9/28/18 12:54 AM, Jim Fehlig wrote:
I've attempted to use virt-manager to create a new VM that uses a volume from an rbd-based network pool, but have not been able to progress past step 4/5 where VM storage is selected. It appears virt-manager has problems properly detecting the volume as network-based storage, but before investigating those further I have a question about the syntax of the <target> element of a storage volume. The storage management page [0] of the website describing rbd volumes claims that the <path> subelement contains an 'rbd:rbd/' prefix in the volume path. But the page describing pool and volume format [1] syntax does not contain any info wrt specifying network URLs in the <path> subelement.
The [1] pool/vol page is meant to be a bit more "generic" with respect to the general format of the <target>...<path>... field because some fields can have different formats/expectations. The [0] storage page should represent more details for each storage backend's expectations over the format to be used. Although my recollection is that it's modified/patched far less frequently than the [1] page. When in doubt though, I usually search "tests/*/*.{xml|args} and then of course looking at the source code. If I must, I'll look at the RNG files. In this case storagevol.rng says @path could be "anyURI" or "absFilePath", nothing specific for RBD. My git history search shows [0] seems to have been originally written and intended as is seen now (commit 74951eade). In the long run it doesn't matter if the <path> has the "rbd:" prefix because virStorageSourceParseRBDColonString will strip it before duplicating and then later qemuBuildNetworkDriveStr will slap it back onto the command line. How's that for a round-about way of saying - it doesn't seem to matter.
What is the expectation wrt the <path> subelement of the <target> element within rbd volume config? In general, should the <path> subelement encode the scheme (e.g. rbd://) of a network-based volume? And if so, should it be formatted in the traditional 'rbd://' vs 'rbd:rbd/' syntax?
I don't think "rbd:rbd/" is the prefix, just the "rbd:". It just so happens the example shows the RBD pool "source" name as "rbd" and the "volume" as "myvol". If you look at the <key> that's more indicative of path to the volume. The example when paired with the pool of source name "rbdpool" probably should have shown "rbd:rbdpool/myvol" and the key "rbdpool/myvol" (to be less confusing). As for "expected" format - well being consistent would be "nice" - probably depends on when the code was originally added though. Adding new or consistent formats ends up being a coding and documenting exercise and we never seem to be able to "lose" old formats and aren't supposed to "rewrite" someone's files - so we're stuck. John
Regards, Jim
[0] https://libvirt.org/storage.html#StorageBackendRBD [1] https://libvirt.org/formatstorage.html#StorageVolTarget
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
participants (4)
-
Cole Robinson -
Jim Fehlig -
John Ferlan -
Pavel Hrdina