logoalt Hacker News

How to use Linux vsock for fast VM communication

77 pointsby mfrwtoday at 5:19 AM17 commentsview on HN

Comments

dymktoday at 4:27 PM

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.

Veservtoday at 9:08 AM

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.

show 2 replies
tostitoday at 4:32 PM

My standard solution for doing stuff in a VM is to prepare some kind of storage with downloads, batch jobs, etc. Control it over serial and have the last step be a shutdown. Artifacts can then be found in one of the storage units.

nlytoday at 10:09 AM

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 advantages highlighted at the end of the article about using many different OS's and language environments on a single host. Seems like enabling and micro-optimising chaos instead of trying to tame it.

Particularly in the ops demo: Statically linking a C++ grpc binary, and standardising on host OS and gcc-toolset, doesn't seem that hard. On the other hand, if you're using e.g. a python rpc server are you even going to be able to feel the impact of switching to vsock?

show 1 reply
imirictoday at 10:43 AM

This is interesting. I wasn't familiar with vsock.

I think the use of Bazel and gRPC in the article distracts from understanding how vsock works. I found this article[1] much more approachable.

[1]: https://medium.com/@F.DL/understanding-vsock-684016cf0eb0

webdevvertoday at 3:56 PM

disappointed to find out "nbd" doesn't mean "No Big Deal"