1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

VMware Still Trying To Push VMCI, VSOCK For Linux

Virtualization

Published on 09 January 2013 05:56 PM EST
Written by Michael Larabel in Virtualization
Comment On This Article

VMware is still trying to push VMCI (the Virtual Machine Communication Interface) and VSOCK (VMCI Sockets) into the mainline Linux kernel. Fortunately, it looks like this virtualization code from the proprietary software vendor will make it into the Linux 3.9 kernel.

Going back to May of last year, VMCI for the mainline Linux kernel was talked about by VMware as one of their interests. VMware has published the patches multiple times, but to date the code hasn't landed in the kernel nor its staging area.

In July of 2012 it looked like VMCI might be ready to enter the mainline tree. It turned out that the code wasn't ready to be merged due to comments by other kernel developers. In October was another mainline attempt for VMCI/VSOCK, but that too didn't bear any fruit.

With a new year now comes a new attempt by VMware to mainline the Virtual Machine Communication Interface and VMCI Sockets. While VMCI/VSOCK is designed around VMware's needs of their commercial virtualization software, the code they are trying to push is obviously all open-source and they're trying to push this code in order to improve the "out of the box" Linux experience for VMware customers -- similar to Microsoft pushing Hyper-V Linux drivers.

For those that don't remember what VMware VMCI is all about:
VMCI allows virtual machines to communicate with host kernel modules and the VMware hypervisors. User level applications both in a virtual machine and on the host can use vmw_vmci through VMCI Sockets, a socket address family designed to be compatible with UDP and TCP at the interface level. Today, VMCI and VMCI Sockets are used by the VMware shared folders (HGFS) and various VMware Tools components inside the guest for zero-config, network-less access to VMware host services. In addition to this, VMware's users are using VMCI Sockets for various applications, where network access of the virtual machine is restricted or non-existent. Examples of this are VMs communicating with device proxies for proprietary hardware running as host applications and automated testing of applications running within virtual machines.

In a virtual machine, VMCI is exposed as a regular PCI device. The primary communication mechanisms supported are a point-to-point bidirectional transport based on a pair of memory-mapped queues, and asynchronous notifications in the form of datagrams and doorbells. These features are available to kernel level components such as HGFS and VMCI Sockets through the VMCI kernel API. In addition to this, the VMCI kernel API provides support for receiving events related to the state of the VMCI communication channels, and the virtual machine itself.
Fortunately, this time around with the latest revisions to the VMware patches, it looks like they will make it into the mainline tree. Greg Kroah-Hartman has already responded to the VMCI patch-set, "Nice work, thanks for the changes you've made over time, and for your persistence. I can't see anything else to complain about, so I've applied this to my tree and it will show up in linux-next tomorrow or so."

However, when it comes to the VSOCK patches, David Miller has not acknowledged them. "...what I remember doing was deferring to the feedback these folks received, stating that ideas that the virtio people had mentioned should be considered instead. So definitely NACK this code and any infrastructure you've merged which essentialy depends upon it." After VMware attempted to clarify the infrastructure situation that VSOCK is just built atop VMCI, Miller added, "I'd much rather see a hypervisor neutral solution than a hypervisor specific one which this certainly is."

The VMware answer there is that nothing is really hypervisor neutral. "Objectively speaking neither solution is hypervisor neutral as there are hypervisors that implement either VMCI or virtio or something else entirely. Our position is that VSOCK feature set is more complete and that it should be possible to use transports other than VMCI for VSOCK traffic, should interested parties implement them, and on this basis we ask to include VSOCK."

Those wanting to look at this VMware kernel code for upstreaming can find the six patches and comments on VSOCK in this thread while the twelve patches and comments for VMCI can be found in this thread.

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. Intel Xeon E5-1680 v3 & E5-2687W v3 Compared To The Core i7 5960X On Linux
  2. Intel 120GB 530 Series SSD Linux Performance
  3. Btrfs/EXT4/XFS/F2FS RAID 0/1/5/6/10 Linux Benchmarks On Four SSDs
  4. AMD's Windows Catalyst Driver Remains Largely Faster Than Linux Drivers
Latest Linux Articles
  1. Mesa Git Yields Performance Improvements For Newer AMD GPUs
  2. Apple OS X 10.10 vs. Ubuntu 14.10 Performance
  3. Mesa 10.5-devel Brings Some Intel Haswell HD Graphics Changes Over Mesa 10.3
  4. NVIDIA vs. Nouveau Drivers With Linux 3.18 + Mesa 10.4-devel
Latest Linux News
  1. Quantum OS Aims For A Linux Desktop With QML, Wayland & Material Design
  2. New Open-Source, Linux Benchmarks To Feast On
  3. FreeBSD Plans For The Next Ten Years
  4. Qt 5.4 Planned For Release On 9 December
  5. Meizu's Ubuntu Phone Not Expected Until Early Next Year
  6. DragonFlyBSD 4.0 Drops i386 Support, Improves Graphics
  7. Expensive "Free/Libre Software Laptop" Uses A NVIDIA GPU
  8. QEMU 2.2-rc3 Released, Final Release Pushed Back By Couple Days
  9. 64-bit ARM FreeBSD Support Is Taking Shape
  10. GCW Zero Starts Seeing New Game Releases
Latest Forum Discussions
  1. Updated and Optimized Ubuntu Free Graphics Drivers
  2. Hurrican SDL Port
  3. Roadmap to Catalyst 14.10 ?
  4. how to configure module phoromatic ?
  5. PulseAudio 6.0 Is Coming & Other Linux Audio Plans For The Future
  6. Debian Developer Resigns From The Systemd Maintainership Team
  7. Cant get working Kaveri APU - A10-7850k
  8. Script for Fan Speed Control