* Eric Blake (ebl...@redhat.com) wrote: > On 02/04/2015 07:02 AM, Daniel P. Berrange wrote: > > >> > >> I think fixing this for migration might simplify stuff for users a lot as > >> well; > >> the choice of whether libvirt does tunneling or not and what it means > >> for how block migration happens etc can get very confusing. > > > > Yes, and not helped by the fact that no single current impl offers all > > desired features - they are all partially overlapping sets :-( > > >> Some things to keep in mind: > >> 1) The current patch from Liang Li doing multi threaded compression > >> It just strikes me as an exmaple of another type of filter in the > >> migration > >> stream. > > > > Yes, that does make sense in that way, > > > >> 2) Postcopy and fault tolerance need a bidirectional channel; and that > >> back > >> channel tends to be small messages. > > > > TLS will require bidirectional channels too in order to perform the > > handshake. SASL will require bidirectional channels too. So this > > seems rather inevitable. > > > >> 3) I'd considered making a separate socket/fd for passing page data > >> in the hope of maybe making that page take data via splice; but am not > >> sure yet. > > Another thing to think about - should migration to file be something > that can be encrypted? There, you don't have the luxury of a > bidirectional channel, but securing the machine state so that only an > authenticated user can decrypt to reload the state later sounds like > another benefit that might be possible.
That's something that's pretty easy to do via exec-migration; so I'm not sure it's worth doing anything particularly special for it. Dave > > -- > Eric Blake eblake redhat com +1-919-301-3266 > Libvirt virtualization library http://libvirt.org > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
