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

[Roger Pau Monné <roger.pau%citrix.com@localhost>]

On 28/11/12 18:42, Jeff Rizzo wrote:
> On 11/28/12 7:48 AM, Roger Pau Monné wrote:
>> On 28/11/12 16:29, Thor Lancelot Simon wrote:
>>
>>> 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.
>> Quite a lot of people use disk images on NFS, because it's probably the
>> easiest shared storage that allows migration of guests.
> 
> I agree that this is a case we should be supporting well.  We don't 
> support migration yet, but I'd like to see this change in the nearish 
> future.
> 
>>
>> Even if disks on NFS was a remote possibility not used by much people I
>> don't think it's acceptable to have a Dom0 crash when you try to create
>> a guest with a disk on NFS, that is by far much more worse than
>> performance degradation in my opinion.
> 
> And, of course, a crash is suboptimal.  :)
> 
>>
>> If this is not accepted, I will have to detect image format somewhere
>> and use qemu when the format is different than raw.
> 
> I would definitely like to see some middle-ground compromise that allows 
> us to keep decent performance for local files while still allowing them 
> for NFS.

Well, I think the performance is not that bad, given that we are using
qemu-traditional and the Dom0 is not MP. We can archive better
performance by fixing qemu-upstream to work with NetBSD and of course
getting a MP Dom0.