Live data from Hacker News

How to use Linux vsock for fast VM communication

popovicu.com

11–20 of 22 posts

Re: How to use Linux vsock for fast VM communication

#11
post #3
post #2

Says it is fast, but presents zero benchmarks to demonstrate it is actually fast or even “faster”. It is shameful to make up adjectives just to sound cool.

vsock is pretty widely used, and if you're using virtio-vsock it should be reasonably fast. Anyway if you want to do some quick benchmarks and have an existing Linux VM on a libvirt host: (1) 'virsh edit' the guest and check it has ' ' in the section of the XML. (2) On the host: $ nbdkit memory 1G --vsock -f (3) Inside the guest: $ nbdinfo 'nbd+vsock://2' (You should see the size being 1G) And then you can try using…

Thank you for benchmarking.

2.5x slower than what they were replacing. Demanding evidence for claims strikes again.

Re: How to use Linux vsock for fast VM communication

#12
post #4

Given how slow protobufs and grpc is, I wonder if the socket transport would ever be the bottleneck to throughput here. Changing transports means if you want to move your grpc server process to a different box you now have new runtime configuration to implement/support and new performance characteristics to test. I can see some of the security benefits if you are running on one host, but I also don't buy the advantag…

> Given how slow protobufs and grpc is, I wonder if the socket transport would ever be the bottleneck to throughput here.

I think this is supposed to be option for when you want to pass stuff to host quickly without writing another device driver or using other interface rather than replacement for any rpc between VMs. "Being fast" is just a bonus.

For example at our job we use serial port for the communication with VM agent (it's just passing some host info about where VM is running, so our automation system can pick it up), this would be ideal replacement for that.

And as it is "just a socket", stuff like this is pretty easy to setup https://libvirt.org/ssh-proxy.html

Re: How to use Linux vsock for fast VM communication

#13
post #11
post #3

Earlier quoted context omitted.

vsock is pretty widely used, and if you're using virtio-vsock it should be reasonably fast. Anyway if you want to do some quick benchmarks and have an existing Linux VM on a libvirt host: (1) 'virsh edit' the guest and check it has ' ' in the section of the XML. (2) On the host: $ nbdkit memory 1G --vsock -f (3) Inside the guest: $ nbdinfo 'nbd+vsock://2' (You should see the size being 1G) And then you can try using…

Thank you for benchmarking. 2.5x slower than what they were replacing. Demanding evidence for claims strikes again.

vsock isn't a replacement for TCP, because you can't assume that IP exists or is routable / not firewalled between the guest and the host.

Having said that, yes it also really ought to be faster. It's a decent, modern protocol so there's no particular reason for it, so with a bit of tuning somewhere it should be possible.

Re: How to use Linux vsock for fast VM communication

#14
post #3
post #2

Says it is fast, but presents zero benchmarks to demonstrate it is actually fast or even “faster”. It is shameful to make up adjectives just to sound cool.

vsock is pretty widely used, and if you're using virtio-vsock it should be reasonably fast. Anyway if you want to do some quick benchmarks and have an existing Linux VM on a libvirt host: (1) 'virsh edit' the guest and check it has ' ' in the section of the XML. (2) On the host: $ nbdkit memory 1G --vsock -f (3) Inside the guest: $ nbdinfo 'nbd+vsock://2' (You should see the size being 1G) And then you can try using…

> It's therefore convenient for things like guest agents where you want them to "just work" without reconfiguration hassle.

This. The point of vsock is not performance, it's the zero-configuration aspect of them. No IP address plan. No firewall. No DHCP. No nothing. Just a network-like API for guest-host communication for guest agents and configuration agents. Especially useful to fetch a configuration without having a configuration.

IMHO the "fast" in the original article should be read as "quick to setup", not as "high bandwidth".

Re: How to use Linux vsock for fast VM communication

#16
post #2

Says it is fast, but presents zero benchmarks to demonstrate it is actually fast or even “faster”. It is shameful to make up adjectives just to sound cool.

It's probably faster than, say, an emulated UART port.

But likely no faster than a TCP socket across a virtio-net device.

Re: How to use Linux vsock for fast VM communication

#17
This is a weird article. It’s titled “how to use vsock” but 95% is how to set up Bazel, gRPC, and building a C++ project. And then 5% is a link to an off-site Twitter thread of screenshots for setting up a Linux VM image and running that in qemu.

This should have been a VM with a basic server and socat’ing the vsocket. I don’t know why so much space was dedicated to unrelated topics. Also zero qualifications or benchmarks for “fast” compared to tcp/virtio.

Author says “no ssh keys” when ssh is an orthogonal concept. sshd can listen on a vsock interface, it’s not specific to tcp/ip.

From the “Under the hood” section, which should be the part actually about vsock:

> I haven’t delved into the low-level system API for vsocks, as frameworks typically abstract this away.

Re: How to use Linux vsock for fast VM communication

#19
post #13
post #11

Earlier quoted context omitted.

Thank you for benchmarking. 2.5x slower than what they were replacing. Demanding evidence for claims strikes again.

vsock isn't a replacement for TCP, because you can't assume that IP exists or is routable / not firewalled between the guest and the host. Having said that, yes it also really ought to be faster. It's a decent, modern protocol so there's no particular reason for it, so with a bit of tuning somewhere it should be possible.

Couldn’t you just use a broadcast address and get the same result ?

Re: How to use Linux vsock for fast VM communication

#20
post #13

Earlier quoted context omitted.

vsock isn't a replacement for TCP, because you can't assume that IP exists or is routable / not firewalled between the guest and the host. Having said that, yes it also really ought to be faster. It's a decent, modern protocol so there's no particular reason for it, so with a bit of tuning somewhere it should be possible.

Couldn’t you just use a broadcast address and get the same result ?

VMs might not have a network connection at all, or (in a more normal secure configuration) have all their network traffic trunked onto a VLAN that avoids touching the host. Vsock is designed so it can only be used for traffic between the hypervisor/host and guests (or between guests on the same host). It's more akin to virtio or hypercalls than a traditional network.
Post reply on HN