Re: NetBSD DomU (PV) hangs on Xen 4.13.1 / NetBSD 9.1

[Brad Spencer <brad%anduin.eldar.org@localhost>]

Matthias Petermann <mp%petermann-it.de@localhost> writes:

>     'phy:/dev/zvol/rdsk/tank0/volumes/builder91,hda,rw',


I have always had to use the block device when presenting devices to any
sort of PV type guest.  Try /dev/zvol/dsk/...  When I attempted to use
character devices I think I had the same problem that you have.

Here is a part of a line I use:

disk = [ 'phy:/dev/mapper/spacevg-pvhostlv0,0x01,w'

% ls -l /dev/mapper/spacevg-pvhostlv0
brw-r-----  1 root  operator  169, 11 Nov 14 18:27 /dev/mapper/spacevg-pvhostlv0

This is, of couse, using LVM, but I have done the same with raw physical
partitions and dk* devices.  I also tend to just start counting disks at
hex 1 rather than using the symbolic names for PV guests.  Just
something I started doing, and never changed.  I have used xvd* and that
works too.


Another example, the following is a disk line for a guest that was
converted from PV to PVHVM with -current.  The bootfloopy disk is
actually just a shim to get the normal boot blocks running, it will end
up as xvda in the guest.  The root filesystem is presented as hdb or
xvdb in the guest and I use ROOT.a in /etc/fstab so it doesn't matter
just too much what the device is.  The third disk is presented directly
as a Xen device, no ioemu need apply.

disk = [ 'phy:/dev/mapper/rustvg0-testcurrentlv0,ioemu:hdb,w','phy:/dev/mapper/ssdvg0-bootfloppy,ioemu:hda,r','phy:/dev/mapper/rustvg0-testcurrentlv2,xvdc,w' ]

I ended up having to do it this way because the original root disk
started at block 0 and had no space for the boot blocks.  Also, real
floopy device support seems to be missing from NetBSD Xen now, I know it
worked in the past for HVM, but I could not get it to work with recent
Xen kernels.





-- 
Brad Spencer - brad%anduin.eldar.org@localhost - KC8VKS - http://anduin.eldar.org