Re: [virtio-dev] virtio-vsock live migration

[Stefan Hajnoczi <stefanha@redhat.com>]

On Wed, Mar 16, 2016 at 05:05:19PM +0200, Michael S. Tsirkin wrote:
> > > >  NFS and netperf are the first two protocols I looked
> > > >    at and both transmit address information across the connection...
> > > 
> > > 
> > > Does netperf really attempt to get local IP
> > > and then send that inline within the connection?
> > 
> > Yes, netperf has separate control and data sockets.  I think part of the
> > reason for this split is that the control connection can communicate the
> > address details for the data connection over a different protocol (TCP +
> > RDMA?), but I'm not sure.
> > 
> > Stefan
> 
> Thinking about it, netperf does not survive disconnects.
> So the current protocol would be useless for it.
> I am not sure about NFS but from (long past) experience it did not
> attempt to re-resolve the name to address, so changing an
> address would break it as well.
> 
> So I think these applications would have to use a 64 bit CID.
> 
> Why, then, do we care about one aspect of these applications
> (creating connections) and not another (not breaking them)?

I care about mapping the semantics of AF_VSOCK to virtio-vsock.
AF_VSOCK was implemented with the ability to plug in additional
transports (like virtio).  This allows guest agents and other
applications to compile once and run on any transport.

If we change virtio-vsock to rely on unique addresses across migration
then we lose zero-configuration.  AF_VSOCK applications use the
VMADDR_CID_HOST (2) constant to communicate with the host.  After live
migration this well-known CID refers to the new host.  Applications
would need to know a unique host CID in order to work correctly across
live migration.

Although I appreciate your drive to make the device as flexible as
possible, if we want to do this we are totally beyond AF_VSOCK semantics
and would be better served by a separate effort that avoids confusion
between class AF_VSOCK semantics and virtio socket semantics.

Can we please treat AF_VSOCK semantics as the requirements we're trying
to implement?  It supports qemu-guest-agent and as I described in a
previous mail could also support transparent connection migration a la
CRIU sockets.

Stefan

Attachment: signature.asc
Description: PGP signature