Greetings systemd, I hope I'm in the right place-- Can anyone sketch out an outline for how, hypothetically, the following service might be possible:
1. Systemd understands that it needs to open a socket / socket activation kicks in. 2. When the socket is asked for, systemd launches a qemu instance and pipes data into the running VM, which handles the request. 3. Further requests are fed into the same VM. 4. After an extended period of time with no activity, systemd asks the VM to shut down. Partial credit answers are awarded points too! My naive idea; 1. Systemd hosts a wrapper service, the wrapper service claims the port. 3. Inside the executable wrapper are two things, `systemd start my-qemu-guest`, `nc my-qemu-guest 33333`. Err, wait, there's got to be a long arsed `sleep` in between those two! :( 4. I have no idea how unloading is dealt with. It'd be nice to make qemu do it, but what I would know how to script is making the guest shut itself down. This seems workable and do-able, but not nearly as clean as I'd desire. Surely someone can come up with something nicer? If this idea for implementation has holes, please illuminate me. The major cruft seems to be the idea of having a wrapper script manage the QEMU system, although I've already stated that wrapper is just poking another QEMU systemd service. If multiple services rely on the same VM, who can determine when the VM needs to be shut down? Keep kicking ass guys, systemd is the best process 1 ever. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
