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