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

[David Hopper <dhop%nwlink.com@localhost>]

On Mar 20, 2011, at 6:32 AM, Manuel Bouyer wrote:

> On Sun, Mar 20, 2011 at 01:57:00AM -0700, David Hopper wrote:
>> Hi all, I have a very odd condition with this NetBSD-current dom0 / Xen 
>> 3.3.2nb1 in trying to start up Red Hat 6 domU instances.  I may need help 
>> understanding if I'm missing some virtual block devices in the domU based on 
>> the symptoms below, or if this could be a dom0 or script issue-- but the tap 
>> device will not connect.
>> 
>> I cannot start a VM when attaching raw images larger than 16K, and I cannot 
>> boot any method other than file: (any size qcow fails to boot as well).  It 
>> took some trial-and-error to find the 16K threshold-- needless to say the 
>> working images aren't very useful to me.
>> 
>> The disk definition in vm.install:  'file:/vnod/vm/vm.img,xvda,w'  (also 
>> tried tap:qcow).
>> 
>> # qemu-img create -f raw ./vm.img 16K  <== 16 kilobyte image works
>> Formatting './vm.img', fmt=raw size=16384 
>> # xm create -c vm.install
>> [ boots normally ]
> 
> 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"), 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?

Thanks,
David

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