[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Improved virtualbox integration

Hi all,

I've been struggling with running Debian live inside virtualbox, which works
rather nicely. I've been also playing with the virtualbox guest additions,
which improve the interaction with the virtualbox window and allow for
filesharing with the host system. This works properly, but I would like to
have a slightly better integration even. In particular:
 * Installing the virtualbox-ose-guest-utils (or virtualbox-ose-guest-x11
   package in unstable) is not enough to enable windowing integration. For
   this to work, there is a small change that needs to happen to the X
   configuration. It would be nice if this happened automatically in some way.
 * The guest additions allow files to be shared from the host system to the
   guest systems. I would like to use this sharing to make my system (and/or
   homedir) persistent, which currently does not seem to be supported.

So, the general question is, would people be interested in supporting the
virtualbox configuration more neatly? This would probably require some special
casing to get working, though.

Let's look a bit closer at the two points above. The first point, updating the
X configuration, seems to require a single change: The mouse driver should be
replaced with the "vboxmouse" driver, to get mouse integration. X is already
smart enough to choose the vbox video driver on startup, so that doesn't
require any changes.

I'm not sure what the best place to fix this is. From looking around in the
initramfs scripts, it seems there is a hook in live-bottom that generates the X
configuration by reconfiguring the xserver-xorg package (though I couldn't
actually find the configure script from the package). The easiest solution
would be to just run /usr/share/virtualbox/x11config.pl when it exists to
update the config (from initramfs). This enables one to just add the
guest-utils package to an image and make it work for virtualbox. OTOH, it will
then no longer work without virtualbox, I think.

I guess the proper solution is to make whatever generates the config in
initramfs (live scripts? xorg config scripts? The X binary itself? Anyone got
a pointer here?) also detect if the virtualbox mouse driver would be
appropriate (and available). I'm not so sure if there is any current support
for different kinds of mouses, or that just every mouse pointer is taken to
support the "mouse" driver. Even better would be to do this without
configuration, just let X detect this on startup (or perhaps let HAL do
something here?).

Using the guest additions we can mount folders shared from the host system.
This works using a separate kernel module that exposes a filesystem type.
E.g., you can run "mount -t vboxsf foo /mnt/foo", which mounts the share named
"foo" on /mnt/foo. This means you don't mount actual block devices (the driver
exports none), but special named shares. This also means that there is no
block device listed in /sys/block.

Since the live-initramfs scripts look for block devices in /sys/block to find
filesystems with the "live-rw" or "home-rw" labels, these vbox shares won't be
used currently. Considering that these vbox shares are quite special and don't
expose a block device, we would need some special casing to get this to work.

My idea would be the following. After (or before?) looking for block devices
or files with the right label or name (e.g., live-rw or home-rw), we could try
to mount the vbox share with that name. If it works, we can use it for

Unfortunately, there does not seem to be a way to get a list of available
shares. So the only way to see if a share is available, is by trying to mount
it. Not very pretty, but it would probably work. This would perhaps need some
refactoring of the code, but that's another matter :-)

Another issue is the including of the proper utilities en kernel modules in
the initramfs, which should probably also be done by the live-initramfs
scripts, since this is really live specific.

Any comments on all this? If this approach looks reasonable, I could have look
at implementing something.



Attachment: signature.asc
Description: Digital signature

Reply to: