11:54 p.m.
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
1:28 p.m.
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
6:13 a.m.
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
9:53 a.m.
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
5:57 p.m.
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(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
2274
days inactive
2278
days old
4 comments
4 participants
participants (4)
-
Cole Robinson -
Jim Fehlig -
John Ferlan -
Pavel Hrdina