[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [PATCH 2/2] libxl: switch NetBSD image file handling to Qemu
On 11/28/12 10:29 AM, Thor Lancelot Simon wrote:
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
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.
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:
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.
Main Index |
Thread Index |