[mig6] Listener Service (/Flight Control)

[tfc]

The task of the listener service is to listen on a fixed port and start VMMs on request which will act as migration destination end points. Currently the protocol works like the following (With LST, SRC and DST as listener service, source VMM and destination VMM):

1. SRC initially connects to LST and sends SRC’s complete command line string.
2. LST cuts off all binaries from this string and adds a retrieve_guest:<port> argument for the new Vancouver instance. Then it tries to start DST with this command line string. (port is a running number)
3. If the start of DST was successful, LST propagates DST’s listen port to SRC.
4. SRC can now connect to DST directly and start the migration procedure.

It turned out to be very handy to have a listener service because this way a running machine is always ready for migration requests. Furthermore it is easy to start VMM instances with the same configuration string like the source VMM.

Cutting off the binaries out of a configuration string

The listener service receives a string like the following:

sigma0::mem:64 sigma0::dma name::/s0/log name::/s0/timer name::/s0/fs/rom ||
rom:///nul/vancouver.nul.gz PC_PS2 ||
rom:///tools/munich ||
rom:///linux/bzImage clocksource=tsc ||
rom:///linux/initrd1.lzma

…and transforms it to the following…

sigma0::mem:64 sigma0::dma name::/s0/log name::/s0/timer name::/s0/fs/rom ||
rom:///nul/vancouver.nul.gz PC_PS2 tsc_offset rdtsc_exit retrieve_guest:40000

Obtaining the source VMM's configuration string

The source VMM has to obtain its own configuration string before being able to send it to the listener service.

Because only sigma0 knows the full configuration string of each running application, i gave MessageConsole some additional semantics: If the new read bit in a message of type MessageConsole::TYPE_START is set, sigma0 will copy the desired configuration string (of the requesting application) into the memory pointed to by cmdline.

The application provides information about the length of the given string memory area in the mem field. If this number is not sufficient for storing the whole configuration, sigma0 returns the message with the first bit of the configuration string set to '\0' and the actual configuration length in the mem field. The application can then try another request with a sufficient number of bytes allocated.

Launching the new VMM

The listener service has to start the destination VMM from a configuration string. Since only sigma0 can start applications, i added another interface for this. The same semantics like for obtaining the configuration string are used with the message type MessageConsole::TYPE_START, but this time the read bit is set to false and mem contains the value 0xdeadbeef. Sigma0 will try to launch the new application and accordingly reply into the res field of the message and return.

Launching an application this way will typically look like this:

MessageConsole msg(MessageConsole::TYPE_START, configuration_string);
unsigned res = Sigma0Base::console(msg);

[alex-ab]

The listener service has to start the destination VMM from a configuration string. Since only sigma0 can start applications, i added another interface for this.

As pointed out in issue #9 there exists one interface to start VMMs outside from sigma0, maybe you don't need an additional interface here.

[tfc]

I didn't know about this interface, yet. I will look into it and try to use it.

[tfc]

Ok, starting new VMM instances with specific configuration strings is now done with the service_config service. Should have seen that earlier. :-)

However, i also need an interface for the source VMM to obtain its own configuration string. My initial implementation emitted a MessageConsole via Sigma0Base::console(cmsg) to obtain this string. Right now i'm trying to implement this functionality into service_config to get some interface like service_config->info_config_string(...).

The problem i'm facing here is that i need to get a pointer to the right moduleinfo entry. My initial implementation using Sigma0Base::console(...) eventually enters Sigma0 via the do_request portal. Here we get a variable pid as parameter from which the moduleinfo entry is derived.

When entering Sigma0 via the portal function of service_config.cc, there is also a variable pid, but the value is not the same like in the other portal and it is of type cap_sel (instead unsigned). I don't understand how to derive the right moduleinfo entry from this. Can you help me out here?

[blitz]

Haven't had a look at that code in a while. Perhaps, @alex-ab can help out?

[alex-ab]

Ok, starting new VMM instances with specific configuration strings is now done with the service_config service. Should have seen that earlier. :-)

👍

The problem i'm facing here is that i need to get a pointer to the right moduleinfo entry. My initial implementation using Sigma0Base::console(...) eventually enters Sigma0 via the do_request portal. Here we get a variable pid as parameter from which the moduleinfo entry is derived.

When entering Sigma0 via the portal function of service_config.cc, there is also a variable pid, but the value is not the same like in the other portal and it is of type cap_sel (instead unsigned). I don't understand how to derive the right moduleinfo entry from this. Can you help me out here?

The service_config interface wasn't developed/meant to be used by the child (VMM) which got started. The pid you refer of the service_config to hasn't anything common with the internal pid you get from the do_request call, they are two different interfaces. A parent using the service_config just starts some child (VMM) and gets back the internal id (which should be actually a cap but there was no time to do it right) which it has to remember, in order to suspend and to kill the child, if wanted. So the idea here was, that the parent actually knows exactly the configuration of the child it started, no need to ask it back ...

Just out of curiosity, why should it be permitted to a VM to decide by its own (or the user inside the VM connected to) to migrate somewhere else and additionally be able to choose the place to go ? Shouldn't this be triggered/controlled by the parent who started it, whether a VM may migrate to another host and if yes, where to go?

I'm just asking, because if the design would be that the parent (using this service_config) interface is in control over all childs (VMMs) than you would have all the information you need, the configuration how you started the VM and the control whether and where to let the VM to migrate to.

[tfc]

closing this as it is a little bit outdated in the meanwhile. :)