[ovirt-devel] Libvirt secrets management - take 2

[Francesco Romani]

----- 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 :)

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