| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [4 Patches] New blktap implementation, 2nd try
Hi,
> I agree that integrating the backend into qemu is the right thing. You
> don't want to have numerous tools running. It's not a complete solution,
> though. A nice thing about blktap is that you can attach a qcow2 image
> to Dom0, e.g. to copy the kernel out of the image.
There is qemu-nbd ...
> I think this is the point where your approach and the new blktap (which
> according to Andraw in fact isn't blktap anymore) are complementary.
> blkfront talks to qemu which uses its drivers to access the image.
I've read the thread down meanwhile, although I've seen the text
describing the blktap design only quoted in your reply, looks like
Andrew's mail didn't made it to the list for some reason.
It is very different from old blktap indeed.
> Alternatively (maybe for the more complicated stuff blktap seems to
> provide) it can use the now Xen agnostic blktap to access the blktap
> device nodes through its raw block driver.
Would work, yes. But what is the point? qemu will certainly not rip
out the disk format drivers, so there is zero need to go that route.
> For accessing images in Dom0,
> blktap without qemu is used. And of course, the blktap drivers are
> compiled out of qemu source if qemu has the respective driver.
See qemu-nbd.
cheers,
Gerd
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home