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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
