[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 0/3] Add support for NetBSD gntdev



On 11/30/12 5:50 AM, Manuel Bouyer wrote:
On Fri, Nov 30, 2012 at 10:43:21AM +0000, Ian Campbell wrote:
On Fri, 2012-11-30 at 10:38 +0000, Manuel Bouyer wrote:
On Fri, Nov 30, 2012 at 10:32:32AM +0000, Ian Campbell wrote:
libxl only selects the backend itself if the caller doesn't provide one.
If the caller sets the backend field !=  UNKNOWN then libxl will (try)
and use it. This field is exposed by xl via the backendtype= key in the
disk configuration
http://xenbits.xen.org/docs/unstable/misc/xl-disk-configuration.txt
thanks for pointing this out.
I guess qdisk is the qemu backend, and tap would be the in-kernel backend ?
qdisk == qemu, tap == blktap, phy == in kernel.
OK; but then, how does the script called by xenbackendd know what setup
is should do ? With xm, it would get a string in the form
phy:/dev/wd0e
or
file:/domains/foo.img

but from what I've understant, this syntax is deprecated now ?

Hi Manuel, thanks for all of your work on xen.

So, the short answer is that the /usr/pkg/etc/xen/scripts/block executable (which is just a shell script) needs to fish the type of the backend and other extra info out of xenstore. In the case of netbsd's block script, it uses the xenstore-read utility. When the block script is called, $1 ($xpath) will be an entry like so /local/domain/0/backend/vbd/2/768; so this is vbd for domU instance #2 with disk instance id 768. $2 ($xstatus) is the reason the block script is called, 2 for startup, and 6 for tear down.

If you look at the block script you can also see that the block script needs to fish out the type of the backend that is located at $xpath/type in xenstore. The block script utilizes the xenstore-read and xenstore-write to read/modify xenstore, if you notice.

So, under $xpath here are the pertinent entries:
- $xpath/type
- $xpath/params
- $xpath/physical-disk

With xm+xend, for disk config file:/var/xen/domu/server001/disk.img, prior to the block script getting called:
$xpath/type = 'file'
$xpath/params = '/var/xen/domu/server001/disk.img'
$xpath/physical-disk = <unspecified>

Then when the block script is called, it detects that the type is 'file' and so it would call vnconfig using the value $xpath/params as the actual file using an unused vnd device, say vnd2. Then it would modify $xpath/physical-disk using the xenstore-write utility and set the value of $xpath/physical-disk to /dev/vnd2. After that, the handling, everything else is handled as if the backend is an actual physical device, which is true.

If the value of $xpath/type is 'phy', nothing needs to be done, since $xpath/physical-disk has been setup properly.

Now, the above behavior is how xm+xend+xenbackendd works. There was a bug in libxl/xl that I fixed as described here http://mail-index.netbsd.org/port-xen/2012/05/29/msg007252.html so that libxl/xl would behave the same way. You might also notice, I made small changes to allow custom backend type. I don't mean to keep tooting my own horn, but I just don't want the fix to get lost, although I just learned that I probably should do a bug report with the patch, but I don't have much time right now.

Hopefully I don't bore you to death if you read this far, but the way the libxl/xl is going seems somewhat ridiculous, where they are trying to insert more and more policy vs functionality, as evidenced by Roger's effort to outrightly to just decide (hence a policy) that 'well, vnd can't work with file on NFS, so be damn with it and just route everything via qemu-dm'. Additionally, they are planning to retire xenbackendd and again this is a trend that I don't like where they clump everything into one giant ball called the libxl/xl, as opposed to a bunch of little executables doing specific things. Another illustration: you might ask who's managing the domU in the absence of xend; well what happens is that when you do 'xl create ...' xl would then daemonize itself to watch xenstore for that specific domU that it just created. I guess that's cool, but to me it's got the feel to put everything into one giant, monolithic, unflexible entity (shudder).

So, I'm just writing to give you some more information about this whole libxl/xl stuff, and hopefully it'll give you some arsenal so that some of the xen folks don't try to force policies that is claimed to protect 'end-user' or very linux specific.

Cheers,
Toby


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.