Wed, 30 May 2007

More Virtual I/O: Block devices

I now have two drivers on top of my "generic" Virtual I/O layer: a network driver and a block driver. To get the bugs out I enhanced lguest's launcher to use 8 clone()s to serve the block device asynchronously, which gives a great speedup even in a simple virtbench read.

The question of barriers/flushes and virtual block devices remains problematic: what guarantees should the host give the guest about data consistency? Consistency in the case of guest death is rather easy: the host can just service all outstanding requests. But if you want your data intact in the case of host cash, it means barriers have to be passed through to the physical underlying device. This affects performance.

Virtualization tends to do really well on naive disk benchmarks, because the server acts as an external cache (this is why lguest opens the block device it's serving with O_DIRECT, to make things a little fairer). Since virtualization loses to native on every other benchmark, I guess noone wants to give this up. But it's cheating; unless the underlying device is non-persistent (eg. copy-on-write and discarded when the guest dies), you should be honoring those barriers.

[/tech] permanent link