Re: PATCH: Enable QEMU booting of blktap disks

["Daniel P. Berrange" <berrange@redhat.com>]

On Thu, Jul 19, 2007 at 03:45:26PM -0700, Andrew Warfield wrote:
> >> In the other thread that's currently going on this topic, it sounds
> >> like others are quite successfully using the phantom code.  Why is it
> >> broken for you?
> >
> >I really can't see how it works for anybody in 3.1.0 since the code which
> >sets up phantom devices simply doesn't work
> 
> Well let's fix it then. ;)

Ok, I'll try and figure out what's broken. We still need a patch to make
QEMU watch out for disks named 'xvd*' though, since upstream paravirt
drivers only support  xvd* naming.

> >With the benefit of hindsight, I would suggest that it would
> >be better to have QEMU able to speak the native blktap protocol straight
> >to the blktap kernel driver. Keep HVM using QEMU for all file backed
> >disks, since it already handles all the formats just fine, and have a
> >new machine type in QEMU for paravirt VMs which provided the tap daemon
> >replacement and also a PVFB daemon replacement. The you could kill the
> >entire blktap userspace codebase & most of the PVFB userspace codebase
> >and the libvncserver requirement.
> 
> I think a patch that pulled a lot of the tapdisk processing into qemu
> would be a very interesting thing to compare overheads for against the
> current model.
> 
> >So there'd only be 1 single daemon in Dom0 per VM, it would be the same
> >daemon for PV and HVM, and all the open source virt platforms (Xen, KVM,
> >QEMU, VirtualBox) would all be reaping the benefit of each other's code
> >improvements to QEMU driver model, in particular for disk format code &
> >VNC server code, rather than forking & reimplementing private copies.
> >
> >Of course this isn't a quick job, but if the motiviation is reducing
> >code duplication & alternative I/O paths, the focusing on QEMU for
> >everything seems like a much more viable idea than more Xen specific
> >code.
> 
> Absolutely.  Dan, I completely agree that it would be very good to
> have a unified way to implement virtual block devices -- image
> formats, interposition, and otherwise.  I think that the qemu and
> blktap disk interfaces both shared this as an initial design goal.  I
> agree it's a lot of work and I agree that it would be a very nice
> thing -- in the same spirit as Rusty's virtio efforts -- to be able to
> share these implementations across hypervisors/emulators/etc.  I also
> know of some grad students who would be very happy to see virtual
> block devices that they are building for blktap apply against
> everything else.

Thinking about it a bit more broadly - considering differences between
paravirt & fullyvirt. With paravirt ops we're nearly able to have a 
single kernel image. VirtIO work will hopefully make a single set of
paravirt drivers for disk/network/etc. With this HVM ought to be getting
pretty near parity with paravirt in terms of performance. The primary 
compelling thing left in favour of paravirt is no reliance of hardware
support. At the same time paravirt has some really bad downsides, in
particular the terrible bootloader process with hacks of pygrub & pypxeboot.
The PV framebuffer is severely limited compared to Cirrus, and requires a
almost completely duplicated VNC server impl. Blktap is a little more 
complicated, but there's general codeduplication wrt to QEMU we've discussed
above. Then there are things like lack of emulated USB bus, an emulated
CDROM device, and other misc hardware devices that QEMU provides. 

I think it would be an interesting project to see if one could make a QEMU 
machine which allows Xen paravirt guests to be booted using QEMU (and thus 
the regular grub, viewable through the regulard graphical VNC server), and 
provide the QEMU emulated device model to the guest to enable USB, etc, 
though still primarily using paravirt drivers where available for speed of 
course. Basically I'd like to have complete parity in device models & boot 
process between paravirt & HVM guests, so I stop having to tell users "well
you  can do X in HVM, but not with paravirt" & vica-verca.

Regards,
Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|