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

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

}On 28/11/12 20:40, Toby Karyadi wrote:
}> 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.
}>>
}>> Thor
}> 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.
}
}I'm not a fan of Qemu either, but I don't know an easy way to detect if
}an image is in a NFS share, or if an image is in qcow, qcow2 or raw. I'm
}open to a solution that only launches Qemu if image format is different
}than raw or if the image file is in a NFS share.
        I admit that I don't know a lot about this particular problem and I'm
joining the discussion late, but isn't there a relatively easy set of steps
to follow to determinne if qemu needs to be called?

1. Look at the filesystem type of the filesystem in which the target
resides.  If it's an NFS filesystem, call qemu.  Otherwise, go to step 2.

2.  Examine the file and see if it has a signature for QCOW or QCOW2 format.
(How does qemu figure out which it is?  Is it a simple bit of code that
could be snagged for re-use?)  Alternatively, check to see if it's a raw
image, and, if it is not, call qemu, otherwise, call vnd and use the
existing backend  block driver.  

        I seem to remember that under xen3.3, there is a python script that 
does 
essentially step 2, except that it's tuned to detecte linux images or X86
partition tables and knows nothing about NetBSD partitions or FreeBSD
slices.

-Brian