I need to communicate between Guest and Host OS. The development environment is C#. With Workstation 6.0, I had a sample done in C# with Dlls in C++ using VMCI Shared memory API and could communicate. After a while, I came across the synchronization problem and found the Socket API that comes with 6.5 Beta 2. Now, the documentation states that for communication between Host and Guest only UDP is avalaible and TCP can be used for communication between two Guest OS. UDP, is not a reliable protocol. Now, since this is a virtalisation concept, will the UDP be reliable in this case ? Can I pass UDP packets with length 8k - 12K byets without packet loss ? The communication between Guest and Host is very important in my application and I cannot to afford to loose even a single packet.
If I use Shared Memory, Will future version of Workstation support it? What it is best and reliable way to share these kind of packets between Guest and Host, I am unable to come to a conclusion. Can anyone please help.
Thanks and Regards
Unfortunately the shared memory interface has been deprecated, so that approach will no longer work on 6.5 and later.
We cannot guarantee that SOCK_DGRAM (UDP equivalent) VMCI Sockets will be reliable between host and guest. The likelihood of losing a message is very low, but it can occur if either one of your endpoints are not able to drain their datagram queue fast enough. You could increase each socket's receive buffer size (set the SO_RCVBUF option via setsockopt(2)) to decrease the likelihood further.
We are working on SOCK_STREAM support for hosts and expect it to come in a future Workstation release.
Your best bet might be to use SOCK_DGRAM for now and switch to SOCK_STREAM once we release our support for that.
I also have been using the VMCI shared memory interface of workstation 6.0.
Unfortunately Socket interface is not suitable for my communications.
Can I use the VMCI socket interface to just create and destroy the underlying shared memory, but directly read and write the shared memory.
Or is there any other way that I can create shared memory blocks between host and guest, using any vmware product, prefer workstation 6.5, server 2 or player.
I do not have an issue with synchronization between the read/writing from different processes, I am using appropiate Locked Read/Modify/Write instructions, such as CMPXCHG.
I have started using the 6.5 and so socket APIs rather than the shared memory. Please note that that later versions will not have the support for shared memory interface.
Thanks and Regards
Unfortunately sockets is not suitable for my application and I require shared memory bewteen Linux host, and windows guest.
I have both windows with wine or windows guest in VMware workstation 6.0 (using VMCI) working with shared memory.
But am unable to use VMCI sockets from server 2 or workstation 6.5.
Obviously VMCI sockets is implemented using shared memory blocks.
What I would like to know, is there a way of using VMCI to create the shared memory block and then directly use that shared memory. Obviously would not be able to use Send/Recv etc on that socket, after "corrupting" the shared memory block.
VMCI sockets are not implemented on top of the old (deprecated) shared memory mechanism. Instead it uses a pair of shared queues between the peers - each queue is a unidirectional transfer channel, where one end enqueues data and the other end dequeues data. So even at the VMCI device level (upon which VMCI sockets is built) there is no longer a shared memory API.
Thanks for your reply.
So each socket has two blocks of shared memory (two queues), One peer reads from one block and writes to the other block. Underlying this must be a way of creating and mapping blocks of shared memory.
From what I have been able to discover, by looking a vmci_sockets.h, there is only 3 non socket functions implemented in the header file and the interface is via ioctr calls to /dev/vmci.
What I am looking for is any way of getting shared memory between host and guest os.
If need be I am prepared to, and able, to write Linux and/or windows device drivers, but would rather use VMware supported interface.
It is correct that the queues may be backed by shared memory but this is not necessarily the case. The hypervisor may adopt a copy based approach to the queues, where updates to queue head and tail pointers cause data to be copied in and out of a VM. Also, the hypervisor assumes queue semantics for the areas mapped into the guests to increase efficiency of certain operations. So I'm sorry to say that even at the low level, there is no general shared memory mechanism available.
Furthermore, in WS6.5 the queues are not even available on the host - only in the VMs.
Thank you, you are of cause correct, re shared memory is not the only option.
I believe WS6.5 (and server 2) has datagram support between host and a VM, or between two VMs. But Socket Streams is only supported bewteen two VMs. Is this correct?
Do you have any idea how fast are the datagrams? How many short messages, say 32 bytes, can be ping pong between host and VM per second?
I dont expect you to know this, but may be able to guess. Is it likely to be 10K, 100K, 1M or 10M message per second. Assuming quad core 2.5GHzmachine.
You are correct in that datagrams are the only VMCI socket mechanisme available for communication between host and guest in WS 6.5, but that both streams and datagrams are supported between VMs.
The latency of VMCI socket datagrams are comparable to regular networking but slightly lower - I don't have exact numbers for Windows host/guest on WS 6.5 but it is in the area of 7K - 10K roundtrips per second.
Thanks again. I was hoping for a much higher number. Currently I am getting greater then 1M roundtrips per sec, using WS6.0 shared memory.
At 10K VMCI sockets is unsable for my application, hence my desire to find a shared memory solution.
I will write a test case and post results.
I am also using the old VMCI implementation and have a functional socket implementation in Java wrapped around that API. If I understand this discussion correct Vmware has decided to only provide the new VMCI-socket API in the future. In 6.5 the old API is marked as deprecated but for how long is it going to be available?