On Mon, Mar 14, 2016 at 01:13:24PM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 03, 2016 at 03:37:37PM +0000, Stefan Hajnoczi wrote:
> > Michael pointed out that the virtio-vsock draft specification does not
> > address live migration and in fact currently precludes migration.
> >
> > Migration is fundamental so the device specification at least mustn't
> > preclude it. Having brainstormed migration with Matthew Benjamin and
> > Michael Tsirkin, I am now summarizing the approach that I want to
> > include in the next draft specification.
> >
> > Feedback and comments welcome! In the meantime I will implement this in
> > code and update the draft specification.
>
> Most of the issue seems to be a consequence of using a 4 byte CID.
>
> I think the right thing to do is just to teach guests
> about 64 bit CIDs.
>
> For now, can we drop guest CID from guest to host communication completely,
> making CID only host-visible? Maybe leave the space
> in the packet so we can add CID there later.
> It seems that in theory this will allow changing CID
> during migration, transparently to the guest.
>
> Guest visible CID is required for guest to guest communication -
> but IIUC that is not currently supported.
> Maybe that can be made conditional on 64 bit addressing.
> Alternatively, it seems much easier to accept that these channels get broken
> across migration.
I reached the conclusion that channels break across migration because:
1. 32-bit CIDs are in sockaddr_vm and we'd break AF_VSOCK ABI by
changing it to 64-bit. Application code would be specific
virtio-vsock and wouldn't work with other AF_VSOCK transports that
use the 32-bit sockaddr_vm struct.
2. Dropping guest CIDs from the protocol breaks network protocols that
send addresses. NFS and netperf are the first two protocols I looked
at and both transmit address information across the connection...
