David Becker wrote:
" So it's either something different with the xen bits
" you have or with the solaris domU bits that you have.
It was the the domU bits. Recreating boot_archive resulted in a larger
file that worked fine. The new size:
-rw-r--r-- 1 root root 33145701 Aug 22 09:10 boot_archive
That file was recreated with
solaris# touch /platform/i86xen/kernel/unix
solaris# bootadm update-archive
With the new boot_archive, the solaris domU solaris kernel boots up.
Great.
Next hurdle is the root device. The linux xend throws an exception
trying to create a vbd disk named 0.
[2006-08-22 09:13:08 xend] DEBUG (blkif:24) exception looking up device
number for 0: [Errno 2] No such file or directory: '/dev/0'
The disk spec was
disk = ['file:/vol/local/solaris/root.file,0,w']
Yep, it does for us too, but keeps on going.. It's something that
needs to be cleaned up.
[2006-08-18 13:52:44 xend] DEBUG (blkif:24) exception looking up device number f
or 0: [Errno 2] No such file or directory: '/dev/0'
[2006-08-18 13:52:44 xend] DEBUG (DevController:103) DevController: writing {'vi
rtual-device': '0', 'backend-id': '0', 'state': '1', 'backend': '/local/domain/0
/backend/vbd/4/0'} to /local/domain/4/device/vbd/0.
...
What are you seeing when you do a xm create with it set to 0?
If I change the disk specification to
disk = ['file:/vol/local/solaris/root.file,sda,w']
the exception goes away, but domU solaris gives the same panic message
for both disk specs:
linuxdom0# xm create -c mydomU.py
Using config file "mydomU.py".
Started domain mydomU
SunOS Release 5.11 Version matrix-build-2006-07-14 32-bit
Copyright 1983-2006 Sun Microsystems, Inc. All rights reserved.
Use is subject to license terms.
DEBUG enabled
WARNING: Found xen v3.0.2-3 but need xen v3.0.2-sun
WARNING: The kernel may not function correctly
panic[cpu0]/thread=fb828380: cannot mount root path
/pci@0,0/pci1022,7450@2/pci1000,3060@3/sd@0,0:a
fb83f77c genunix:rootconf+fa (0, 1, fb827b10, 0, )
fb83f7a0 genunix:vfs_mountroot+54 (fb400010, fb83d638,)
fb83f7c0 genunix:main+e4 ()
skipping system dump - no dump device configured
rebooting...
When renaming the vbd disk to sda instead of 0, booting domU results in the
same panic message:
panic[cpu0]/thread=fb828380: cannot mount root path
/pci@0,0/pci1022,7450@2/pci1000,3060@3/sd@0,0:a
fb83f77c genunix:rootconf+fa (0, 1, fb827b10, 0, )
fb83f7a0 genunix:vfs_mountroot+54 (fb400010, fb83d638,)
fb83f7c0 genunix:main+e4 ()
skipping system dump - no dump device configured
# cat mydomU.py
name = "mydomU"
memory = "400"
kernel = "/vol/local/solaris/unix"
extra = "/platform/i86xen/kernel/unix"
ramdisk = "/vol/local/solaris/boot_archive"
on_shutdown = "destroy"
on_reboot = "restart"
on_crash = "destroy"
root = "/dev/dsk/c0d0s0"
# disk = ['file:/vol/local/solaris/root.file,0,w']
disk = ['file:/vol/local/solaris/root.file,sda,w']
vif = ['mac=aa:00:ac:10:0c:09, bridge=xenbr0']
yep, definitely can't do that. The number after the disk
file specifies the disk # for us. The root disk has to be
/dev/dsk/c0d#s0 for most cases. If your really advanced, you
can change the controller and slice number easy enough..
But that's not going to help you here.
Currently, the xen code is linux specific here (we need to
clean it up and get it back), but it still works for us even
with the exception.
Are you sure the exception is the problem?
MRJ
|
