----- Original Message ----- > From: "Michal Skrivanek" <mskri...@redhat.com> > To: "Francesco Romani" <from...@redhat.com>, "Nir Soffer" <nsof...@redhat.com> > Cc: "devel" <devel@ovirt.org>, "Adam Litke" <ali...@redhat.com>, "Federico > Simoncelli" <fsimo...@redhat.com>, "Dan > Kenigsberg" <dan...@redhat.com>, "Allon Mureinik" <amure...@redhat.com>, > "Daniel Erez" <de...@redhat.com>, "Eric > Blake" <ebl...@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" <nsof...@redhat.com> > >> To: "Francesco Romani" <from...@redhat.com> > >> Cc: "devel" <devel@ovirt.org>, "Adam Litke" <ali...@redhat.com>, "Federico > >> Simoncelli" <fsimo...@redhat.com>, "Dan > >> Kenigsberg" <dan...@redhat.com>, "Allon Mureinik" <amure...@redhat.com>, > >> "Daniel Erez" <de...@redhat.com>, "Michal > >> Skrivanek" <mskri...@redhat.com>, "Eric Blake" <ebl...@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? _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
