Host/Guest Communication (solved; patch included)

[jchatham]

I'm trying to port some virtual machines from vmware to virtualbox, and have run into a problem: I need a reasonably high speed data connection between the host and the VM, that does not go over a standard network interface. I've tried a couple of things using existing mechanisms (see this thread), but it's become clear that I'm going to have to dig into the virtualbox programming API if I want something that matches my requirements.

However, there are several different options for how I could try to implement this; what I'm looking for is suggestions on what route to pursue first - I don't have enough experience working with virtualbox to know where (or if) there are hidden gotchas. So, here are the things I've been looking at:

1: Have the host start a process in the guest, and use IProcess.read and IProcess.write methods. Advantage: most of the code for this is already written in vboxmanage; the only thing I'd have to implement is writing to the guest process' stdin. Disadvantage: I have to start this process from the host, which makes it tricky to deal with things like guest reboots.
2: There's a method to get a guest process by pid; see if I can use that to read/write stdout/stdin on a pre-existing process. Advantage: This would be basically perfect... if it works. Disadvantage: I've no idea if virtualbox guest additions can actually tie itself to the stdout/stdin of an existing process; the methods are all there, but I wouldn't be at all surprised if they don't actually work this way.
3: IMachineDebugger has some readmemory / writememory methods - though they come with "this may not be implemented" warnings... If these have been implemented (nothing I can find says if they have been or not), then they could be used to implement the communication I need.
4: Write my own HGCM service - from this thread, I know that this isn't the best place to ask for advice on implementing such a thing - but I'm hoping someone can at least comment on how much effort it's likely to be relative to the other options.

Other possibly relevant information: I need this to work with, at a minimum, windows guest machines (windows XP / server 2003 and later) and windows (win7), ubuntu, and macintosh host machines.

Any advice would be appreciated. Thanks!

[noteirak]

Oh my, you got yourself a nice challenge here must say I like it. Let's go through your approaches :

1 and 2 : These sounds like very ugly aweful hacks that would kill someone along the way, and let's not talk about perf. I would guess you want to transfer binary data aswell, god knows what will happen to it during this kind of hack. I'm pretty sure you'll get data corruption along the way.

3 : I would definitly not rely on a debugger class that is pretty much only used by the devs and could change anytime.
Hell, that would typically be the class I would see change the most and in the most impredicatable ways - it is a dev utility first or foremost.

4 : the HGCM service seems to be the best option given your requirements I must say, but also the hardest to put in place... There isn't (any?) documentation about this, you can only use what has been implemented so far as a reference guide. Looking at the dev mailing list, there isn't more info on there too about HGCM but I didn't look into the archives of it, only recent posts (there has been a few).
Effort required... I don't think anyone but the devs can give you an answer on this one.

Overall, given your requirement to not go over networking, you're very limitating your possiblities.
The only other thing I can think of is shared folders - I don't know what kind of data you want to transfer but you could write them to a specific file from the guest (for a specific amount of data maybe?) and get them back on the host. You could use guest properties as a sync mechanism.
No idea of the speed you could achieve or the impact on perf, worth a try maybe.

Other than that... don't know on top of my head.

[mpack]

Shared folders was already suggested and rejected in the earlier thread. The OP points out that shared folders are only available when the user has logged in.

[noteirak]

Ah well there goes that... I'll review the API methods tonight, might stumble on something, but don't hold your breath

[Martin]

How fast is the virtual serial port when it is not connected to a physical port on the host?

[rousseauhk]

>>I need a reasonably high speed data connection between the host and the VM, that does not go over a standard network interface

Can I ask what's wrong with a standard network interface?

[jchatham]

How fast is the virtual serial port when it is not connected to a physical port on the host?

Abysmal. That was the first thing I tried - it worked decently well when I was using vmware instead of virtualbox, but under virtualbox it is (for reasons that aren't at all clear) about an order of magnitude slower. A forum search turned up one person who had similar problems - something, somewhere, was apparently setting their virtual serial ports to 1500 baud - but they never got back with any sort of solution. (Or even anything tracking down where the problem came from...) And given that we'd eventually abandoned serial ports even in vmware as being too slow... I'd rather implement something else.

Can I ask what's wrong with a standard network interface?

Certainly. We're working with a setup where part of the point is testing if networks are functioning - and when they're not, we still need to be able to see what's going on in the virtual machine. In other words, we can't use the normal network interfaces, because what we're doing involves occasionally breaking them.

1 and 2 : These sounds like very ugly aweful hacks that would kill someone along the way, and let's not talk about perf. I would guess you want to transfer binary data aswell, god knows what will happen to it during this kind of hack. I'm pretty sure you'll get data corruption along the way.

Sounds like this may be the way to go, then - I can get by just fine with a character stream rather than binary data; the communication protocol in question uses xml. Performance looks to be pretty good - vboxmanage can get data out of a VM at a rate measured in megabytes per second using this mechanism; if I can get the other direction working in even kilobytes per second I should be fine.

Also, apologies for delayed response... I thought I'd set it to notify me when replies were posted, but apparently failed to do so. Fixed now. >.<

[noteirak]

Let us know how you manage with the XML, I am personally interested.

[Magnus Madsen]

Hi jchatham,

2: There's a method to get a guest process by pid; see if I can use that to read/write stdout/stdin on a pre-existing process. Advantage: This would be basically perfect... if it works. Disadvantage: I've no idea if virtualbox guest additions can actually tie itself to the stdout/stdin of an existing process; the methods are all there, but I wouldn't be at all surprised if they don't actually work this way.

When I was testing the same a few versions ago (around 4.2.10 I believe) it didn't work for processes that hadn't been started by the Guest Additions. I would not expect it to have changed since then, but of course it is possible it has been implemented.

I don't know if you have been working with any code to communicate with processes in the guest yet, but if you haven't then I also discovered a problem that is related to this ticket: https://www.virtualbox.org/ticket/11189#comment:3

Specifically, you need to be careful - at least in the environment I'm using - not to attempt to read too quickly in succession from a guest process, as this can cause the VirtualBox hosting process itself to crash!
And for now, it is not possible to use the IProcess->WaitFor flag ProcessWaitForFlag.StdOut, which would otherwise be suited for this. With a delay inserted between each attempt to read from the guest process, say 20ms, I haven't been experiencing any crashes so far - but that doesn't mean it is entirely stable and there does seem to be some underlying issue somewhere.

[jchatham]

A status update: It turns out to be relatively simple to hack the VBoxManage code to pipe its stdin to the process it starts (for VBoxManage guestcontrol exec --wait-stdout), although I also had to hack in a fix to https://www.virtualbox.org/ticket/12593 (essentially, the ctrlExecPrintOutput function was chopping off the last character in each buffer's worth of stdout / stderr). The hardest part, oddly, was figuring out what the actual C function signature for IProcess.Write was. So, that much I'll include in case anyone else needs to hack something together. (The rest, I'm not bothering with - in large part because my code is still very much a hack, and really not suitable for general use.)

Code: Select all

PRUint32 numcharswritten;
BYTE *inputchars;
int errorstatus = pProcess->Write( 0/* 0 is stdin */, 0 /* flags - use ProcessInputFlag_EndOfFile to specify eof */, numinputchars, inputchars, 0 /* no timeout */, &numcharswritten );

I haven't encountered the bug Magnus mentioned yet, even when testing with a windows VM, but... I've tossed an extra 50ms delay into my code anyway, because I'd rather not run into that issue somewhere farther down the line. (Edit: Turns out that due to a mistake in the units, the delay I put in was significantly less than 50ms, resulting in further issues as detailed here. If you use the patch I present later, you may wish to correct this.)

In the meantime, though, I'm getting roughly 6 megabytes per second throughput between a linux host & linux guest, and about 2-3 for a windows guest, which is far more than I actually need (and, interestingly, also much better throughput than I was ever able to get with vmware).

[noteirak]

Very interesting achievement I think. You should definitly post a diff on the vbox mailing list.
I would really want to see this included in the code personally, and can already see some use case for it.

[jchatham]

Well... I'm not on the mailing list, and - as noted - the code I'm using is still very much more "hacked to the point where it works for me" than something appropriate for a real release... Still, it'd certainly be neat to see this capability end up included.

I'll attach what I've got here; maybe someone with a bit more understanding of virtualbox's SafeArray and string formatting functionality can de-hackify it some? (Or, if you think it's worth posting to the mailing list as-is, I could go ahead and do that...)

[noteirak]

Well, the devs do read the forums, so they will see this. In case you don't see any message from them, you can always start a discussion on the mailing list. It's also there for that

[VmSpace]

Thanks