[ovirt-devel] Libvirt secrets management - take 2

[Michal Skrivanek]

On 15 Jun 2015, at 17:33, Nir Soffer wrote:

> 
> 
> ----- 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?

do we have to manage the connection? If qemu lose the connection we can't re-establish?
I understood that libvirt keeps the secret in memory - is that correct? If so then it can send it to the destination, right?
And what do we do about libvirt restarts?

I missed the initial discussions so please ignore me if i'm completely off....