Re: Xen boot failures with disks >16K (tap device issues)

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Sun, Mar 20, 2011 at 07:51:16AM -0700, David Hopper wrote:
> > [...]
> > Are you using a HVM domU, or a PV one ?
> > The disk definition looks like a PV one, but you're also talking about
> > tap(4) which is used only by HVM guests.
> 
> Well, I thought there were two kinds of "tap" devices when working with Xen, 
> at least on NetBSD-- the Xen tap device which is used to define block access 
> methods in a "disk" definition ("tap:aio", "tap:qcow"),

This is a linux thing, it's not used for NetBSD.

> and the NetBSD tap(4) device, which kicks in with the ioemu flag for the vif 
> device (HVM network driver).  I'm talking about the former.  If they refer to 
> the same thing (HVM drivers) then that clears some things up, but the hangs 
> are happening with the file: disk access method as well.
> 
> > I suspect qemu-img creates a sparse file, which is not supported
> > by NetBSD's PV backend. qcow is also not supported.
> 
> But the "-f raw" format files created qemu-img are not sparse, they are 
> bit-for-bit image files-- at least, I thought that was the case (raw are 
> full-sized images, while qcow are sparse).  But thank you, that helps-- I 
> couldn't find the status of qcow on NetBSD/xen.
> 
> I should add that if I provision a disk file using VMware, and convert the 
> image file from .vmdk to raw using 'qemu-img convert', then it works for any 
> size.  So that points to 'qemu-img create' as the culprit.
> 
> What is the method for creating empty disk images for NetBSD/xen, if qemu-img 
> isn't supported?  Just straight-up dd?

Yes, this is how I do it:
dd if=/dev/zero of=disk.img bs=1m count=<size in mb>

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--