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

Re: [Xen-devel] [PATCH 2/2] libxl: switch NetBSD image file handling to Qemu

On 11/28/12 10:29 AM, Thor Lancelot Simon wrote:
On Wed, Nov 28, 2012 at 03:41:56PM +0100, Roger Pau Monn? wrote:
On 28/11/12 14:26, Thor Lancelot Simon wrote:
I am assuming there's some reason we want this, rather than handling
such requests in-kernel.  But what is it?
I should have marked this as "experimental", or something like this. I'm
not sure if switching to Qdisk for all image file backends is needed.
>From the Xen wiki (http://wiki.xen.org/wiki/Blktap) I've found that:

"loop device had problems with flushing dirty pages (specifically, doing
a large number of writes to an NFS-backed image don't result in the OOM
killer going berserk)."

I'm not sure if NetBSD is in the same situation, but if I remember
correctly (haven't tried that in a long time), trying to use a disk file
on a NFS share caused the NetBSD Dom0 kernel to crash. The PR for this
issue is: http://gnats.netbsd.org/40726.
It seems highly unlikely to me that a problem with the loop device driver
on Linux is tremendously relevant to NetBSD.

But, even if there is some problem with vnd backed by NFS, that hardly
seems like it would be a good reason to make a change that reduces I/O
throughput for the *non* NFS-backed case by at least 20%.  Why would one
keep disk images for guests, as a general rule, on NFS, rather than simply
doing the NFS mounts on the guests themselves, or using a more sensible
protocol like iSCSI?  I have to assume most folks using files as disks are
storing them on local filesystems on the dom0, and wrecking performance
for that case to solve a problem with NFS that may or may not be hypothetical
seems like a very, very bad trade-off.

Yeah, I usually don't pipe up, but I strongly dislike being forced to use qemu to read raw disk file instead of being able to use vnd on netbsd dom0.

There was/is? a bug in xentools 4.1 in libxl that prevents using vnd for raw disk file. The problem boils down to libxl not notifying xenbackendd (via xenstored) to call /usr/pkg/etc/xen/scripts/block at the right time such that vnconfig doesn't get called when it's time to shutdown the domU, and hence you end up with a bunch of vnd devices even after the corresponding domU's have been shutdown. I created a patch to fix that: http://mail-index.netbsd.org/port-xen/2012/05/29/msg007252.html Additionally I put in an experimental feature that allows specifying other types of backend aside from phy: or file:, and as long as the /usr/pkg/etc/xen/scripts/block sh script is modified accordingly, the domU will just get the appropriate device in dom0. Then we can use, for example, vnd:, or iscsi: and from the POV of the domU, it's just another 'physical' device that the dom0 manages. I think the way xenbackendd works, in conjunction with xenstored, is pretty flexible and decoupled, at least with xen 3.3 and 4.1; I don't know what the story is for xen 4.2. Was there a rumor of retiring xenbackendd?

I'm also concerned about the trend, which to me is more of putting more and more policy in libxl, as opposed to functionality. I saw this back when I was trying to fix the bug above, hopefully this trend is no longer true. For example, I had the impression (I don't remember the details) that the code that parses the disk configuration to a certain degree decides whether the disk is a block device or a regular file based on the prefix (phy: vs file:), which is not true in netbsd dom0, because the file path is then used to setup a vnd device, which is from libxl's POV is just a block device. Most probably it's born out of the fact that libxl is developed in a mostly linux environment. I do appreciate Roger's effort in improving xen support in netbsd, but hopefully some BSDism would travel back to xen as well.

Xen-devel mailing list



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