On Wed, Jun 01, 2016 at 09:04:00AM -0400, John Ferlan wrote: > My quandary is less about the qemu-img infrastructure than the storage > driver code. > > That is, it's "less clear" in my mind how the storage_backend.c code > would need to handle a ",file=" for its short lived master key. Where to > create the file? What issues around permissions will there be? > Basically anything that virSecurityManagerDomainSetPathLabel handles for > the domain master key. I've been working under the assumption that it'll > need to be done, but hadn't quite got that far yet. I see three possible options 1 Have storage driver create a random master key when libvirtd starts up and use that with all qemu-img invokations 2 Have storage driver create a random master key per pool and use that with all qemu-img invokations against that pool 3 Ignore master keys entirely and just put the encryption key for the luks volume in a file directly. ie just one secret object using file= instead of two secret objects I think any of these are valid approachs really, so pick whatever you think fits best > FWIW: The current "working" plan is a command such as: > > qemu-img create -f luks \ > --object secret,id=m0,file=$FILE \ > --object secret,id=s0,data=$SECRET,keyid=m0,iv=$IV,format=base64 \ > -o key-secret=s0 $LUKSFILE $SIZE That's certainly a valid cli arg set if you pick my options 1/2 above > > Thanks for the feedback so far... trying to make sure I don't get too > far off into the weeds and the dog just keeps looking at me like I'm > crazy when I ask her. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list