Vboxmount is public, says Christian Kellner.
It is a tool using VirtualBox APIs to bring virtual disks (not sure if it is limited to VirtualBox format or works for any format VirtualBox knows) as block devices under linux, using the network block device driver (nbd).
I have to say there are 2 things I don’t like about nbd.
First, it adds useless overhead, since it has to go through the network stack, even when the whole thing is local.
Second, I have had bad experience with nbd stability, though I must say I only tested on old stuff. A while ago, VMware ESX 2.5 had a tool, named vmware-mount, that would basically do what Vboxmount does, for ESX vmdk files, on the ESX service console (a 2.4.something kernel). The fact is, the whole thing would bring the whole server down (kernel panic or deadlock, I can’t remember) more often than not. Which is why the tool has not been provided since ESX 3.0. This tool was using nbd.
There are IMHO better ways to implement something like this, though the nicest doesn’t exist yet.
- dm-userspace allows for something similar, but requires the image file to be backed by a loopback device, and the data on the image needn’t be compressed.
- Fuse would allow to present a flattened image as a file, that you could turn into a block device with the loopback device driver. I happen to have written something like that, except its legal status is unsure.
- As for the nicest solution I can see, that doesn’t exist yet, as said above, it would be some kind of “Buse” (Block device in USEr space), or process-backed loopback device, call it like you want, that would allow a process to answer to random reads in a (virtual) block device, in a similar way a Fuse file system process would answer to random reads in a (virtual) file. This has been discussed several times on several mailing lists, but has not yet been implemented, as far as I know.
Both comments and pings are currently closed.