2011/7/20 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
> On Wed, 2011-07-20 at 12:37 +0100, Stefano Stabellini wrote:
>> On Wed, 20 Jul 2011, Roger Pau Monné wrote:
>> > Hello,
>> >
>> > I'm trying to run PV machines using the new libxenlight toolstack on
>> > NetBSD. So far, I've been able to connect to the domu using the
>> > console (I was unable to do so before). I'm attaching a little patch
>> > that removes setting the consback to IOEMU when detecting a qdisk
>> > (that was preventing the domu from even booting). With the
>> > introduction of libxenlight, Xen doesn't use vbd for disk backend
>> > anymore, it uses qdisk, which I assume Qemu automatically attaches to
>> > running guests. It works fine with HVM guests, but it seems to fail
>> > with PV guests. The config file I'm using is:
>> >
>>
>> Xen uses qdisk only when blktap is not available.
>> I suggest you install blktap if you can because it is significantly
>> faster than qdisk at the moment.
>
> This is a NetBSD host so I don't think blktap is an option.
NetBSD has the vnd driver, which provides a disk interface to a file
(it's basically a loop device):
http://netbsd.gw.com/cgi-bin/man-cgi?vnd+4+NetBSD-current
It is used with xend and xenbackendd to mount raw disks. It is not the
fancy blktap2, altough something similar to blktap2 *could* be
implemented *easily* using the RUMP Anykernel I think:
http://www.netbsd.org/docs/rump/index.html
Don't know for sure, but I think it should be possible to port the
blktap2 driver or something very similar using this.
>
>> Otherwise if you use a physical partition and specify phy: in the config
>> file you should get the kernel based blkback that is the fastest option
>> available.
>
> phy: would be worth a go since it should tie into NetBSD's equivalent of
> blkback, whereas file: presumably goes to qdisk in the absence of
> blktap.
Haven't tried phy:/ with unstable, but I supose it works, since it
worked in previous versions.
>
> [...]
>> > >From what I see, the guest is unable to find the disk, which is
>> > strange, because HVM guests work fine, and the disk is attached
>> > correctly. Does this also happen when using file:/ backend (qdisk)
>> > under Linux also? Is it a problem with Qemu or is it related to libxl?
>>
>> It doesn't happen under Linux; it is probably a problem with Qemu. Qemu
>> uses the gntdev device (/dev/xen/gntdev) to open the grant table
>> (necessary to implement xen backends in userspace).
>> There doesn't seem anything equivalent on NetBSD, hence it fails...
>
> That makes some sense. libxl should really detect that qdisk isn't an
> option under NetBSD (like it does for blktap) and abort if that is the
> case. This could be a case of a simple check in
> tools/libxl/libxl_device.c:disk_try_backend. (could be as simple as an
> #ifdef __NetBSD__ or we could e.g. add -DHAVE_QEMU_BACKENDS to the build
> infrastructure where appropriate).
>
> Presumably if libxl isn't trying to start a qdisk it won't try and use a
> qemu based console either (which also won't work under NetBSD) and the
> original patch from this thread becomes unnecessary.
What I don't get is why qdisk work with HVM machines but not with PV
machines, shouldn't it be the same?
>
> Ian.
>
>
Also, I saw that on Linux the loop device was used to mount images in
the past, but with libxl the loop device isn't used anymore right? I
think that using the vnd device is the only way to get file images to
work under NetBSD.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home