11:33 a.m.
----- Original Message -----
From: "Michal Skrivanek" <mskrivan(a)redhat.com>
To: "Francesco Romani" <fromani(a)redhat.com>, "Nir Soffer"
<nsoffer(a)redhat.com>
Cc: "devel" <devel(a)ovirt.org>, "Adam Litke"
<alitke(a)redhat.com>, "Federico Simoncelli" <fsimonce(a)redhat.com>,
"Dan
Kenigsberg" <danken(a)redhat.com>, "Allon Mureinik"
<amureini(a)redhat.com>, "Daniel Erez" <derez(a)redhat.com>, "Eric
Blake" <eblake(a)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(a)redhat.com>
>> To: "Francesco Romani" <fromani(a)redhat.com>
>> Cc: "devel" <devel(a)ovirt.org>, "Adam Litke"
<alitke(a)redhat.com>, "Federico
>> Simoncelli" <fsimonce(a)redhat.com>, "Dan
>> Kenigsberg" <danken(a)redhat.com>, "Allon Mureinik"
<amureini(a)redhat.com>,
>> "Daniel Erez" <derez(a)redhat.com>, "Michal
>> Skrivanek" <mskrivan(a)redhat.com>, "Eric Blake"
<eblake(a)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?