[ovirt-devel] Libvirt secrets management - take 2

[Michal Skrivanek]

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?

> 
> -- 
> Francesco Romani
> RedHat Engineering Virtualization R & D
> Phone: 8261328
> IRC: fromani