[ovirt-devel] Libvirt secrets management - take 2

[Nir Soffer]

----- Original Message -----
> From: "Michal Skrivanek" <mskrivan at redhat.com>
> To: "Francesco Romani" <fromani at redhat.com>, "Nir Soffer" <nsoffer at redhat.com>
> Cc: "devel" <devel at ovirt.org>, "Adam Litke" <alitke at redhat.com>, "Federico Simoncelli" <fsimonce at redhat.com>, "Dan
> Kenigsberg" <danken at redhat.com>, "Allon Mureinik" <amureini at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Eric
> Blake" <eblake at redhat.com>
> Sent: Monday, June 15, 2015 6:30:00 PM
> Subject: Re: Libvirt secrets management - take 2
> 
> 
> On 15 Jun 2015, at 17:16, Francesco Romani wrote:
> 
> > ----- Original Message -----
> >> From: "Nir Soffer" <nsoffer at redhat.com>
> >> To: "Francesco Romani" <fromani at redhat.com>
> >> Cc: "devel" <devel at ovirt.org>, "Adam Litke" <alitke at redhat.com>, "Federico
> >> Simoncelli" <fsimonce at redhat.com>, "Dan
> >> Kenigsberg" <danken at redhat.com>, "Allon Mureinik" <amureini at redhat.com>,
> >> "Daniel Erez" <derez at redhat.com>, "Michal
> >> Skrivanek" <mskrivan at redhat.com>, "Eric Blake" <eblake at redhat.com>
> >> Sent: Monday, June 15, 2015 5:06:09 PM
> >> Subject: Re: Libvirt secrets management - take 2
> > 
> >>> - source VDSM receives VM.migrate(destination_uri)
> >>> - source VDSM sends migrationCreate to destination VDSM
> >>> - once destination VDSM created special-purpose VM, source VDSM instructs
> >>> libvirt to start the migration
> >>> - source VDSM monitors the migration, report progress, updates the
> >>> downtime
> >>> - migration fails: source VDSM automatically send VM.destroy to
> >>> destination
> >>> VDSM
> >>> - migration succeeds: source VDSM destroy source VM, execution now
> >>> continues
> >>> on destination VM
> >> 
> >> Ok, when we create the special purpose vm, do we include all the devices?
> > 
> > Sure. It has to be (actually: is) a clone of he source VM. Actually the
> > only "special" thing here
> > (to partially amend my own wording) is the reported status of the VM
> > itself.
> > 
> >> If this special vm (waiting for migration) is connected to all the disks,
> >> then we only need to register the secrets sent from the source in
> >> migrationCreate,
> >> start the special vm, and one it is running, delete the secrets.
> > 
> > Indeed. I just wonder, since we're still talking about design, if there is
> > a cleaner
> > approach.
> > 
> > To have source VM act like a passthrough feels a little funny, but probably
> > this is
> > the only thing we can do give the architecture.
> > 
> > So, changes needed on virt flows:
> > 
> > - in VM.migrate (public API, Engine->VDSM) support secrets passing. These
> > secrets
> > must not be stored, but passed verbatim to VM.migrationCreate and forgotten
> > afterwards
> > - in VM.migrationCreate (private API, VDSM->VDSM): as above. here we reuse
> > most
> > of the infrastructure we have to create VM. It is little different from
> > just create
> > a VM from Engine.
> > - in 'migration destination' flow, it doesn't look different from simple VM
> > creation.
> > we should just drop all the secrets once the disks are attached (or failed
> > to attach).
> > 
> > At glance looks simple, should be quick and easy, unless I'm missing some
> > pitfalls :)
> 
> Could it not be handled by lower layer? I suppose it has some kind of token
> or something?

What do you mean?