On Wed, Sep 13, 2017 at 03:24:42PM +0200, Peter Krempa wrote:
On Wed, Sep 13, 2017 at 09:05:43 -0400, John Ferlan wrote:
I was thinking more about virstoragefile.c and virstoragetest.c. It's easy enough to fetch the user/password-secret in virStorageSourceParseBackingJSONiSCSI:
+ const char *user = virJSONValueObjectGetString(json, "user"); + const char *secret = virJSONValueObjectGetString(json, "password-secret");
But there's not much one can do with it as you get (for example):
user = "myname" secret = "virtio-disk1-secret0"
but an <auth> would look like:
<auth username='myname'> <secret type='iscsi' usage='mycluster_myname'/> </auth>
So to a degree it's not testable to build the XML as virstoragetest does. Sine the secret can be built up using the disk alias, it's perhaps not even worth storing away.
Yes, the field is rather useless. I'm even surprised that it's recorded into the backing file string. It may be used as a notification that authentication is required, but without actually adding the secret with correct name, the thing won't work anyways.
That is a bug in QEMU - we should not be recording the 'password-secret" field in the backing store that is embedded in the qcow2 file. The IDs of the secret objects are only meaningful for the current invokation of QEMU / qemu-img / etc. So if a backing store needs a password, then libvirt needs to explicitly set the password-secret for the backing store, recursively Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|