Update the component from qemu-kvm to qemu-kvm-rhev since I see "Layered Product: OpenStack". Free to update it if any mistakes.

Any qemu-kvm-rhev based on QEMU 2.8 has -device vhost-virtio-pci support, starting from qemu-kvm-rhev-2.8.0-1.el7.

Stefan,

I am trying to verify this bug and prepare for test plan for this new feature.

steps:
1. Boot RHEL7.4 guest with qemu-kvm-rhev-2.8.0-5.el7.x86_64 & 3.10.0-581.el7.x86_64.

2. Boot guest with vhost-vsock-pci device.
 
/usr/libexec/qemu-kvm -name vsock -enable-kvm -m 3G -smp 4 -uuid aefb55e3-91fd-46ee-a0f1-abe92345d37b -rtc base=localtime,driftfix=slew -boot order=cd,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 \

-drive file=/home/rhel7.4.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,serial=fuxc,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 \

-netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=00:52:47:58:dd:d2,bus=pci.0,addr=0x3 -device usb-tablet,id=input0 -vnc :2 -vga cirrus -monitor stdio \

-device vhost-vsock-pci,id=vhost-vsock-pci0,guest-cid=3

3.check related model in host & guest.

host:
# lsmod|grep vsock
vhost_vsock            17927  1 
vmw_vsock_virtio_transport_common    31907  1 vhost_vsock
vhost                  33734  1 vhost_vsock
vsock                  35327  2 vmw_vsock_virtio_transport_common,vhost_vsock

guest:
# lsmod|grep vsock
vmw_vsock_virtio_transport    17822  0 
vmw_vsock_virtio_transport_common    32062  1 vmw_vsock_virtio_transport
vsock                  35376  2 vmw_vsock_virtio_transport_common,vmw_vsock_virtio_transport

4. Try to transfer data with xpra between host and guest.

on host:
# xpra start :100 --start-child="xterm" --bind-vsock=auto:2000
xpra initialization error: no such option: --bind-vsock

I have 2 questions about this feature.

Q1, how should I transfer data between host and guest?(not sure if should use xpra)

Q2, About this new feature. I should mainly consider what aspects of test?(I am preparing for test plan)

(In reply to FuXiangChun from comment #8)
> I have 2 questions about this feature.
> 
> Q1, how should I transfer data between host and guest?(not sure if should
> use xpra)

xpra is currently not a use case for RHEL although it's an early vsock adopter.

I have written a netcat-like tool that can be used for tests:
https://github.com/stefanha/nc-vsock/blob/master/nc-vsock.c

This program can be used on both guest and host.  For example:

  (guest)$ nc-vsock -l 1234  # listen on port 1234

  (host)$ nc-vsock 3 1234  # connect to guest on CID 3, port 1234

> Q2, About this new feature. I should mainly consider what aspects of test?(I
> am preparing for test plan)

There is currently no automated test suite.  In the longer term an automated test suite covering both functionality and performance is needed.

AF_VSOCK supports guest<->host communication (but not guest<->guest communication).  virtio-vsock only offers SOCK_STREAM socket semantics (connection-oriented, reliable, in-order delivery).  The basic scenarios are:
1. A connects to B's listen socket
2. A gets ECONNREFUSED if B is not listening on socket
3. A sends data to B, B echoes data back to A
4. A wakes up from select(2) when B closes the connection
5. A returns from read(2) with 0 bytes when B closes the connection
6. A wakes up from select(2) when B sends data on one of several open connections

These cases should succeed for both A=host,B=guest and A=guest,B=host.

There are additional low-level cases that we should test eventually but they are harder to trigger.  For example, communication should resume if the socket sndbuf or rcvbuf (see man 7 socket) were full and the peer begins processing them again.

These are things that would be valuable in an automated test suite.  For now the simplest manual test is to use nc-vsock to send "Hello world" from host->guest and from guest->host.

Thanks for Stefan's detailed replies. 

According to comment9.  I tested several scenarios.

S1)transfer data on guest<->host with single port

1.load model in host
#modprobe vsock
#modprobe vhost_vsock


2.Boot guest with vhost-vsock-pci

/usr/libexec/qemu-kvm -name vsock -enable-kvm -m 3G -smp 4 -uuid aefb55e3-91fd-46ee-a0f1-abe92345d37b -rtc base=localtime,driftfix=slew -boot order=cd,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=/home/rhel7.4.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,serial=fuxc,cache=none -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=00:52:47:58:dd:d2,bus=pci.0,addr=0x3 -device usb-tablet,id=input0 -vnc :2 -vga cirrus -monitor stdio -device vhost-vsock-pci,id=vhost-vsock-pci0,guest-cid=3

3.load model inside guest
#modprobe vsock
#modprobe vhost_vsock

4.boot listening inside guest
#./nc-vsock -l 1234

5. connect guest CID
# ./nc-vsock 3 1234

6. input character
e.g Hello world

result:
character are displayed both guest and host simultaneously.

# ./nc-vsock -l 1234
Connection from cid 2 port 1031...
Hello world

# ./nc-vsock 3 1234
Hello world

S2)transfer data on guest<->host with multiple ports

inside guest:
#./nc-vsock -l 1234
#./nc-vsock -l 12345

on host:
# ./nc-vsock 3 1234
# ./nc-vsock 3 12345

I can get the same result as S1.


S3)negative testing

1.
inside guest:
without nc-vsock process.
on host:
#./nc-vsock 3 1234

# ./nc-vsock 3 1234
connect: Connection reset by peer

2. interrupt nc-vsock process during transfering data in guest or host.
 
#ctrl+c inside guest or on host
result
guest and host work well.


Summary.

1.According to this test result. I will update virtio-vsock test plan.

2.Can I transfer bigger file on guest<->host via nc-vsock tool?(currently, To my understanding, It only can send or receive data to "socket buffer". and It can not save data to a disk file.)

3. Does virtio-vsock device supports transfer data on windows guest<-->host?
   If supports, Do we need use qemu-guest-agent inside guest?

(In reply to FuXiangChun from comment #10)
> Thanks for Stefan's detailed replies. 
> 
> According to comment9.  I tested several scenarios.
> 
> S1)transfer data on guest<->host with single port
> 
> 1.load model in host
> #modprobe vsock
> #modprobe vhost_vsock
> 
> 
> 2.Boot guest with vhost-vsock-pci
> 
> /usr/libexec/qemu-kvm -name vsock -enable-kvm -m 3G -smp 4 -uuid
> aefb55e3-91fd-46ee-a0f1-abe92345d37b -rtc base=localtime,driftfix=slew -boot
> order=cd,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
> file=/home/rhel7.4.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,serial=fuxc,
> cache=none -device
> ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev
> tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device
> e1000,netdev=hostnet0,id=net0,mac=00:52:47:58:dd:d2,bus=pci.0,addr=0x3
> -device usb-tablet,id=input0 -vnc :2 -vga cirrus -monitor stdio -device
> vhost-vsock-pci,id=vhost-vsock-pci0,guest-cid=3
> 
> 3.load model inside guest
> #modprobe vsock
> #modprobe vhost_vsock
> 
> 4.boot listening inside guest
> #./nc-vsock -l 1234
> 
> 5. connect guest CID
> # ./nc-vsock 3 1234
> 
> 6. input character
> e.g Hello world
> 
> result:
> character are displayed both guest and host simultaneously.
> 
> # ./nc-vsock -l 1234
> Connection from cid 2 port 1031...
> Hello world
> 
> # ./nc-vsock 3 1234
> Hello world
> 
> S2)transfer data on guest<->host with multiple ports
> 
> inside guest:
> #./nc-vsock -l 1234
> #./nc-vsock -l 12345
> 
> on host:
> # ./nc-vsock 3 1234
> # ./nc-vsock 3 12345
> 
> I can get the same result as S1.
> 
> 
> S3)negative testing
> 
> 1.
> inside guest:
> without nc-vsock process.
> on host:
> #./nc-vsock 3 1234
> 
> # ./nc-vsock 3 1234
> connect: Connection reset by peer
> 
> 2. interrupt nc-vsock process during transfering data in guest or host.
>  
> #ctrl+c inside guest or on host
> result
> guest and host work well.
> 
> 
> Summary.
> 
> 1.According to this test result. I will update virtio-vsock test plan.

Sounds good.

> 2.Can I transfer bigger file on guest<->host via nc-vsock tool?(currently,
> To my understanding, It only can send or receive data to "socket buffer".
> and It can not save data to a disk file.)

Just like with netcat and other command-line tools, you can redirect files using the shell:

  (host)$ nc-vsock -l 1234 >path/to/my-file
  (host)$ sha256sum path/to/my-file
  ...checksum for comparison...

And redirect stdin from the file on the other side:

  (guest)$ sha256sum path/to/my-file
  ...checksum for comparison...
  (guest)$ nc-vsock 2 1234 <path/to/my-file

> 3. Does virtio-vsock device supports transfer data on windows guest<-->host?

There is currently no virtio-win driver for vsock.

>    If supports, Do we need use qemu-guest-agent inside guest?

qemu-guest-agent-2.8.0-1.el7 has vsock support but this is currently not supported by libvirt.  Therefore I don't expect users to enable qemu-guest-agent AF_VSOCK support yet.

The syntax is qemu-ga -m vsock-listen -p 1234.

(In reply to Stefan Hajnoczi from comment #11)
> (In reply to FuXiangChun from comment #10)
> > Thanks for Stefan's detailed replies. 
> > 
> > According to comment9.  I tested several scenarios.
> > 
> > S1)transfer data on guest<->host with single port
> > 
> > 1.load model in host
> > #modprobe vsock
> > #modprobe vhost_vsock
> > 
> > 
> > 2.Boot guest with vhost-vsock-pci
> > 
> > /usr/libexec/qemu-kvm -name vsock -enable-kvm -m 3G -smp 4 -uuid
> > aefb55e3-91fd-46ee-a0f1-abe92345d37b -rtc base=localtime,driftfix=slew -boot
> > order=cd,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
> > file=/home/rhel7.4.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,serial=fuxc,
> > cache=none -device
> > ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -netdev
> > tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device
> > e1000,netdev=hostnet0,id=net0,mac=00:52:47:58:dd:d2,bus=pci.0,addr=0x3
> > -device usb-tablet,id=input0 -vnc :2 -vga cirrus -monitor stdio -device
> > vhost-vsock-pci,id=vhost-vsock-pci0,guest-cid=3
> > 
> > 3.load model inside guest
> > #modprobe vsock
> > #modprobe vhost_vsock
> > 
> > 4.boot listening inside guest
> > #./nc-vsock -l 1234
> > 
> > 5. connect guest CID
> > # ./nc-vsock 3 1234
> > 
> > 6. input character
> > e.g Hello world
> > 
> > result:
> > character are displayed both guest and host simultaneously.
> > 
> > # ./nc-vsock -l 1234
> > Connection from cid 2 port 1031...
> > Hello world
> > 
> > # ./nc-vsock 3 1234
> > Hello world
> > 
> > S2)transfer data on guest<->host with multiple ports
> > 
> > inside guest:
> > #./nc-vsock -l 1234
> > #./nc-vsock -l 12345
> > 
> > on host:
> > # ./nc-vsock 3 1234
> > # ./nc-vsock 3 12345
> > 
> > I can get the same result as S1.
> > 
> > 
> > S3)negative testing
> > 
> > 1.
> > inside guest:
> > without nc-vsock process.
> > on host:
> > #./nc-vsock 3 1234
> > 
> > # ./nc-vsock 3 1234
> > connect: Connection reset by peer
> > 
> > 2. interrupt nc-vsock process during transfering data in guest or host.
> >  
> > #ctrl+c inside guest or on host
> > result
> > guest and host work well.
> > 
> > 
> > Summary.
> > 
> > 1.According to this test result. I will update virtio-vsock test plan.
> 
> Sounds good.
> 
> > 2.Can I transfer bigger file on guest<->host via nc-vsock tool?(currently,
> > To my understanding, It only can send or receive data to "socket buffer".
> > and It can not save data to a disk file.)
> 
> Just like with netcat and other command-line tools, you can redirect files
> using the shell:
> 
>   (host)$ nc-vsock -l 1234 >path/to/my-file
>   (host)$ sha256sum path/to/my-file
>   ...checksum for comparison...
> 
> And redirect stdin from the file on the other side:
> 
>   (guest)$ sha256sum path/to/my-file
>   ...checksum for comparison...
>   (guest)$ nc-vsock 2 1234 <path/to/my-file

Got it

> 
> > 3. Does virtio-vsock device supports transfer data on windows guest<-->host?
> 
> There is currently no virtio-win driver for vsock.
> 
> >    If supports, Do we need use qemu-guest-agent inside guest?
> 
> qemu-guest-agent-2.8.0-1.el7 has vsock support but this is currently not
> supported by libvirt.  Therefore I don't expect users to enable
> qemu-guest-agent AF_VSOCK support yet.
> 
> The syntax is qemu-ga -m vsock-listen -p 1234.

Thanks Stefan, If so, I won't add windows guest related testing to 7.4 test plan. once libvirt supports or you want user to enable this function via qemu-guest-agent. QE will cover this testing as once.  Meanwhile, If you think these test scenarios can cover this function. please signoff this test plan in bug 1432418.

(In reply to FuXiangChun from comment #12)
> (In reply to Stefan Hajnoczi from comment #11)
> > (In reply to FuXiangChun from comment #10)
> Meanwhile, If you
> think these test scenarios can cover this function. please signoff this test
> plan in bug 1432418.

Okay.  I'll post comments on that BZ.

According to comment12, set this bug as verified.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2392