On Fri, Mar 20, 2009 at 02:43:40PM +0100, Chris Lalancette wrote: > Daniel Veillard wrote: > > On Mon, Mar 16, 2009 at 04:26:58PM +0100, Chris Lalancette wrote: > >> All, > >> Attached is a *very* rough first draft of the secure migration code I'm > >> working on. This is in no way ready for merge. That being said, this > >> demonstrates the basic idea that I'm pursuing, and I've actually been able to > >> perform a KVM secure live migrate using this. Before I go and finish polishing > >> it up, though, I wanted to make sure there wasn't anything fundamentally wrong > >> with the approach. So, in that vein, comments are appreciated. > > > >> diff --git a/qemud/remote_protocol.h b/qemud/remote_protocol.h > >> index 75def5e..d97a18b 100644 > >> --- a/qemud/remote_protocol.h > >> +++ b/qemud/remote_protocol.h > >> @@ -41,6 +41,8 @@ typedef remote_nonnull_string *remote_string; > >> #define REMOTE_SECURITY_MODEL_MAX VIR_SECURITY_MODEL_BUFLEN > >> #define REMOTE_SECURITY_LABEL_MAX VIR_SECURITY_LABEL_BUFLEN > >> #define REMOTE_SECURITY_DOI_MAX VIR_SECURITY_DOI_BUFLEN > >> +#define REMOTE_CONNECT_SECURE_MIGRATION_DATA_MAX 65536 > >> +#define REMOTE_CONNECT_SECURE_MIGRATION_COOKIE_MAX 65536 > >> > >> typedef char remote_uuid[VIR_UUID_BUFLEN]; > >> > > > > Okay I have tried to think again about this, from the code fragment > > before and discussions on IRC while performances are tolerable, there > > is a lot of costs related to the 64KB chunking imposed by the XML-RPC. > > Just so others are clear on what this means: > > After doing a little bugfixing on the version of the code I posted, I did some > performance measurements with a guest using 3.4GB of memory. A standard > migration, direct qemu->qemu, took somewhere between 30 seconds and a minute to > complete this. The encrypted version took anywhere between 1 minute and 3 > minutes to complete the migration, a slowdown of between 1.5 and 3 times. I'll > have to do some more testing to get more solid numbers. > > > It is probably acceptable for a class of users who really want > > encryption of their data but I would like to make sure we don't close > > the door for a possibly more performant implementation. > > Yes, that's a good point. > > > Trying to reopen a bit the discussion we had before on opening a > > separate encrypted connection, this would have a number of potential > > improvements over the XML-RPC: > > - no chunking, far less context-switching (it would be good to know > > how much of excess time spent in the secure migration is data > > encoding, how much is overall system burden) > > Well, as DanB points out later, there is still chunking, but we get rid of the > RPC overhead of a reply to every packet. > > > My main concern is keeping a port open in the firewall for the > > incoming connection of the encrypted data, and I wonder if it's really > > necessary, basically since the receiver and the sender can both > > communicate already via the XML-RPC maybe something like STUN (for UDP) > > where both end open simultaneously a new connection to the other side > > might work, and that can be coordinated via the XML-RPC (passing the new > > port opened etc). The point being that usually firewall block only > > incoming connections to non-registered port but outcoming connections > > are allowed to go, I have no idea if this can be made to work though. > > In general I would like to make sure we have room in the initial phase > > to add such a negociation where an optimal solution may be attempted, > > possibly falling back to a normal XML-RPC solution like this. > > Basically, make sure we can try to be as efficient as possible, and > > allow the protocol to evolve, but fallback to XML-RPC encapsulation > > if that initial round fails. > > I'm not so sure I agree with this. If we have a reasonably generic solution, I > think the admin would prefer to know up-front that the most performant solution > is misconfigured somehow, rather than libvirt silently falling back to a less > optimal solution. I think we should work on finding a solution that provides > the encryption and has reasonably good performance, and just stick with one > solution. > > What I'm going to do early next week is do some additional work to try to get > DanB's suggestion of the STREAM_DATA RPC working. Then I'll try benchmarking > (both for duration, and CPU usage): > > 1) Original, unencrypted migration as a baseline > 2) Direct TLS->TLS stream migration; this requires a new port in the firewall, > but will be another good data point, and I already have the code for this > sitting around > 3) The solution I posted here > 4) The STREAM_DATA solution FWIW, I'd consider it a bug in libvirtd impl if option 4) could not match the performance of option 2).... Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list