qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/6] spice: client migration.


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH 2/6] spice: client migration.
Date: Mon, 10 Jan 2011 19:39:36 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Jan 10, 2011 at 09:26:12PM +0200, Alon Levy wrote:
> On Mon, Jan 10, 2011 at 05:37:18PM +0100, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > >>I like client_migrate_info and it fits both spice+vnc naming too.
> > >>
> > >>Given that vnc just needs hostname and port (which are present
> > >>already) and the arguments not used by vnc are optional all we need
> > >>to do is rename the command and add a "protocol" argument similar to
> > >>"set_password", correct?
> > >
> > >Yeah, that sounds sufficient to me.
> > 
> > Quick incremental patch attached.  Became a bit larger than
> > initially expected due to some code reorganization (move out of
> > ui/spice-core.c) needed.
> > 
> > comments?
> 
> Couldn't we just apply the migration info to all connected clients?
> I mean, it doesn't make sense to have a connection open that you don't
> want to migrate, and if we do want that we could always add that as
> an optional last argument. i.e.
> 
> client_migrate_info <host> <port> <sport> <cert-subject> [<connection>]
> 
> (unrelated: are we assuming the same ca for both hosts? that isn't totally
> obvious)

That shouldn't matter either way. Whether there is the same CA or
different CAs, the key factor is that the client must have the CA
used in each host in its trusted set. Only once it has decided it
trusts the CA, does it go on to use the cert-subject data for the
next step of validation.

> If you omit connection, we connect to all.
> 
> This way the user doesn't have to say spice/vnc again after already having
> set it once at command line.

If you have both spice and VNC displays active, then you need to
specify different ports for each. You might also have them listening
on different IP addresses, and potentially using different certs
(though the latter is unlikely). So I think we do need to specify
this data separately for each network service that needs migration
support

Regards,
Daniel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]