For the last few months I've been designing a bare-metal implementation of VirtualBox. It works reasonably well. By bare metal, I mean that a very small host is installed onto the system in as uncomplicated a manner as possible. Currently I've got it down to three files (and any images of course). A vmlinuz, an initrd, and a root squashfs system, as well as grub in the mbr. When the host boots up, the initrd will mount the root squashfs system and aufs (think unionfs) it with a tmpfs system.
The squashfs system basically boots a stripped down version of linux that has enough to get X running and VirtualBox. It then starts my own service that automatically scans for images in the original root, automagically creates bridges and network interfaces as required, and starts them up, optionally full screen. The host is entirely anonymous. That is, all its bridges and interfaces have no IP's. As far as the user is concerned, they don't even know there is a host os and that there was just a different starting splash screen (briefly) which actually just displays my company logo using usplash.
Currently I'm at the point where if there are three images, and they are all set to start full screen, the client will start each one on a separate X display. My client has a 'kvm-like' app where if you hit scroll lock a couple of times, it pops up a menu on the active screen and you can choose a display to change to. I of course disable the host key, the X zap key and the X vt change keys.
Ok, now for the mulling time. I would like to be able to control my service that sitting on the host FROM one of the VM's. That is, I'd like to write an app that allows me to start/stop VM's, update the hostos squashfs file, configure VM's such as change memory allocation, and upload new VM's to it. You could think of it as similar to the VirtualBox GUI, but with a few hostos specific options as well and it would also require a password to get into (which would be stored on the hostos itself). It would be communicating from the Virtual World into the Real World.
However, I can't think of HOW I can get the client to connect to a service on the hostos. Oh, I can easily write the app, and I can easily write a server component that it could connect to, but the hostos is anonymous and has no IP.
Things I've thought of so far: -
- I could give the hostOS a specific IP, but what IP would I give it? It has no idea what IP addresses the VM's are going to use, and its supposed to be extremely generic. If I change my VM's IP, I don't want to have to go and change my hosts IP as well. A
- I could give ALL hosts a generic ip of something like 169.254.2.3 and intercept traffic to that IP. However if the host is multihomed, and different VM's are bridged onto different network cards, you can't have the same ip address on separate bridges.
- Perhaps send via a multicast. That is, maybe the client communicates over 255.0.0.124 (or whatever, I've never dealt with multicast addresses before). No idea of the implications, but probably similar to broadcast (see below)
- Perhaps send via broadcasts. That is, 255.255.255.255. Not sure how this affects if there is more than one host on the real network (ie, a broadcast leaking off one host and getting replied back from several others)
- Is there someway to communicate via the VirtualBox Guest Additions? This would probably be the best way.
The only way I can think of that is more a work-around is to run full screen on one of the displays the configuration client FROM the hostos. That is, you hit scroll-lock twice, and choose the 'Configuration' screen which displays the configuration which is acutally running ON the hostos. Unfortuantely it means a lot of the stuff I want to do (update hostos, uload images, move images from one host to another, remote access admin host) can't easily be done.
- Brendan
Congrats to you and your partner, BTW. You might be interested in this topic as a point of comparison: 