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

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Apr 06, 2016 at 01:55:50PM +0100, Stefan Hajnoczi wrote:
> 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.

Could be an option. management has very little trouble configuring
unique CIDs and it does care about migration. Desktop users don't
migrate and they want 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.

Maybe, though I merely proposed reserving some space so we can extend
CIDs to 64 bit (or 128 bit like hyperv guys would like to?)
in the future without too much pain.
To me this doesn't look like worth starting a completely separate effort for.

> 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

I only wish the semantics were better documented somewhere :)

-- 
MST