similar to: virtio-vsock live migration

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

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

On Tue, Mar 15, 2016 at 06:12:55PM +0200, Michael S. Tsirkin wrote: > On Tue, Mar 15, 2016 at 03:15:29PM +0000, Stefan Hajnoczi wrote: > > 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 > >

On Tue, Mar 15, 2016 at 06:12:55PM +0200, Michael S. Tsirkin wrote: > On Tue, Mar 15, 2016 at 03:15:29PM +0000, Stefan Hajnoczi wrote: > > 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 > >

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? > >

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? > >

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 > >

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 > >

The vsock_diag.ko module already has a test suite but the core AF_VSOCK functionality has no tests. This patch series adds several test cases that exercise AF_VSOCK SOCK_STREAM socket semantics (send/recv, connect/accept, half-closed connections, simultaneous connections). Stefan: Do you think we should have a single application or is better to split it in single tests (e.g.

This series is based on v4.7. This RFC is the implementation for the new VIRTIO Socket device. It is developed in parallel with the VIRTIO device specification and proves the design. Once the specification has been accepted I will send a non-RFC version of this patch series. v6: * Add VHOST_VSOCK_SET_RUNNING ioctl to start/stop vhost cleanly * Add graceful shutdown to avoid port reuse while

This series is based on v4.7. This RFC is the implementation for the new VIRTIO Socket device. It is developed in parallel with the VIRTIO device specification and proves the design. Once the specification has been accepted I will send a non-RFC version of this patch series. v6: * Add VHOST_VSOCK_SET_RUNNING ioctl to start/stop vhost cleanly * Add graceful shutdown to avoid port reuse while

v2: - style fixes [Dave] - removed RCU sync and changed 'the_vsock_loopback' in a global static variable [Stefan] - use G2H transport when local transport is not loaded and remote cid is VMADDR_CID_LOCAL [Stefan] - rebased on net-next v1: https://patchwork.kernel.org/cover/11251735/ This series introduces a new transport (vsock_loopback) to handle local communication. This

The vsock_diag.ko module already has a test suite but the core AF_VSOCK functionality has no tests. This patch series adds several test cases that exercise AF_VSOCK SOCK_STREAM socket semantics (send/recv, connect/accept, half-closed connections, simultaneous connections). The v1 of this series was originally sent by Stefan. v3: - Patch 6: * check the byte received in the recv_byte() * use

This series is based on v4.4-rc2 and the "virtio: make find_vqs() checkpatch.pl-friendly" patch I recently submitted. v4: * Addressed code review comments from Alex Bennee * MAINTAINERS file entries for new files * Trace events instead of pr_debug() * RST packet is sent when there is no listen socket * Allow guest->host connections again (began discussing netfilter support with

This series is based on v4.4-rc2 and the "virtio: make find_vqs() checkpatch.pl-friendly" patch I recently submitted. v4: * Addressed code review comments from Alex Bennee * MAINTAINERS file entries for new files * Trace events instead of pr_debug() * RST packet is sent when there is no listen socket * Allow guest->host connections again (began discussing netfilter support with

This series is based on Michael Tsirkin's vhost branch (v4.5-rc6). I'm about to process Claudio Imbrenda's locking fixes for virtio-vsock but first I want to share the latest version of the code. Several people are playing with vsock now so sharing the latest code should avoid duplicate work. v5: * Transport reset event for live migration support * Reorder virtqueues, drop unused

This series is based on Michael Tsirkin's vhost branch (v4.5-rc6). I'm about to process Claudio Imbrenda's locking fixes for virtio-vsock but first I want to share the latest version of the code. Several people are playing with vsock now so sharing the latest code should avoid duplicate work. v5: * Transport reset event for live migration support * Reorder virtqueues, drop unused

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use VSOCK with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using VMware

This series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use VSOCK with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using VMware

Hi all, this series adds the multi-transports support to vsock, following this proposal: https://www.spinics.net/lists/netdev/msg575792.html With the multi-transports support, we can use vsock with nested VMs (using also different hypervisors) loading both guest->host and host->guest transports at the same time. Before this series, vmci-transport supported this behavior but only using