How to signal an event from guest to host?

[calind]

I need to have some very simple event signalling from a (Windows) guest to the (Windows) host. Our app running within the guest will need to tell the host somehow "event X has occurred" so that an app running on the host can trigger some processing. Performance is not an issue. I would like to avoid using the network as I won't have control over the way networking will be set-up in the environments where this will be used. Multiple hosts and guest will be used so minimal or no configuration (except where possible programmatically) is preferable. I browsed through the documentation but couldn't find any sort of event signalling mechanism.

[socratis]

The general idea is "isolation", for a variety of reasons, but mainly security. I don't know if there's an API to cover this (have you tried the SDK documentation?), but there are a couple of ways that I can think of, but by using polling:

1. Create a "flag" of a file in a shared folder location.
2. Use the vboxcontrol within the guest to set a property(ies), which you monitor from the host as well.

[calind]

I tested the second option and it works fine, and it's not dependent on Guest Additions. I think it's just what I need.

[socratis]

and it's not dependent on Guest Additions

There's no VBoxControl without Guest Additions (GAs), so, yeah, it depends on the GAs. Ch. 4.7 of the User Manual:

To accomplish this, VirtualBox establishes a private communication channel between the VirtualBox Guest Additions and the host, and software on both sides can use this channel to exchange string data for arbitrary purposes. Guest properties are simply string keys to which a value is attached. They can be set (written to) by either the host and the guest, and they can also be read from both sides.

[calind]

I figured that on my way home, VBox installing something on the guest on its own would be weird. What made me think it works w/o GAs was that uninstalling GAs leaves the virtual box service installed and running even after guest restart.

There's still some work to do as I can retrieve any pre-created property (e.g. host IP) programmatically with the API (C++) but for some reason I get empty strings for custom properties, while VBoxManage retrieves the values fine.

[Martin]

Another way would be using the virtual serial port and connect a listening app to the serial pipe on the host.

[socratis]

Both of the way that I mentioned require GAs. A DOS VM wouldn't be able to do that for example. What 'Martin' suggested could work cross-platform, as long as you figure out how to setup a serial port on a DOS guest!

Great idea Martin!

[calind]

Yes, using a serial port is a good idea as it won't necessitate GAs. I'll look into it as I seem to be unable to read custom (not predefined) properties in my C++ test app. I can enumerate and read any predefined property (guest IP for instance) but custom properties seem to be inaccessible (the get function returns OK but the value is an empty string). Enumeration behaves similarly: it only lists predefined properties. I've inspected the VBoxManage source code but I can't figure out what is it that I'm doing wrong. Maybe this issue is deverves its own thread.

[socratis]

I think (don't quote me) that I've seen some recent changes in the source code (timeline), which restrict access(?) to the properties. Something to do with security and who has access to what... As I said, do not quote me on that.

[calind]

I managed to get it to work but unfortunately I made multiple changes at once so I don't know what the problem was. I recreated the VM by cloning it (there was a mess caused by attached disks so I wanted to start clean), maybe that was it?

And concerning the serial port, unfortunately it still presents a problem: the machine needs to be not in use in order to configure the port, which adds an extra step that complicates things. I (we, actually) need to have as little human intervention as possible. The number of VMs we'll use this for is not fixed (maybe 3, maybe 10, maybe 100+) so a method that doesn't require each to be configured separately is much preferred. OTOH now that I think about it I could use the same pipe name for all VMs and identify them from the data they send to it.