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.
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.
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)
- seems to me a more standard encrypted TCP/IP connection would be
more likely to be able to reuse crypto hardware if/when they get
available.
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.
any though ?
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
