xen discuss - Jul 2007 - fyi: my experiences installing nv66 as a xen guest under linux dom0/Xen 3.1

hi,

what follows is my experience setting up the nv66 bits as a xen guest in my xen
3.1 / Fedora F7 dom0 test environment, using Gavin''s hints for a
solaris domU under a linux dom0 from the xen::discuss discussion group (thanks,
Gavin).

it''s clear that much good work has been done since the nv44 drop last
year.

what''s really cool
=================

1) the solaris 11 nv66 guest installs / runs under a dom0/xen 3.1 with *and*
without PAE enabled. as far as i know, solaris is the only OS that can do this.
all others are either / or (Fedora), or non-PAE, like *BSD, plan9, other linux
distributions.

what''s cool
==========

1) the xnf front end driver''s interrupt routine race condition bug is
fixed.

2) you have solaris install working for installing guests.

what''s not so cool
=================

1) my x86 box''s clock is set to UTC. there is no option in the solaris
install to "check a box" so that install gets it right. thus, i had to
run "rtc -z GMT" after the install completed to get the time/date
correctly displayed. linux and *BSD installs have this check box.

2) ypinit -c seems broken - it doesn''t enable the
svc:/network/nis/client:default smf service. instead, it spits out these
messages:
Is this correct? [y/n: y] y
svcadm: Pattern ''network/nis/server:default'' doesn''t
match any instances
svcadm: Pattern ''network/nis/xfr:default'' doesn''t
match any instances
svcadm: Pattern ''network/nis/passwd:default'' doesn''t
match any instances
svcadm: Pattern ''network/nis/update:default'' doesn''t
match any instances

i used svcadm to enable svc:/network/nis/client:default by hand, and nis worked
just fine after that. looks like ypinit needs to be updated for the
''-c'' case.

3) why is the 64 bit boot_archive updated when the machine is 32 bit? (i would
imagine that 64 bit machine folks have the same question about the 32 bit
boot_archive):
updating /platform/i86pc/boot_archive...this may take a minute
updating /platform/i86pc/amd64/boot_archive...this may take a minute

4) on the first boot, loading the smf(5) service descriptions takes a *long*
time. perhaps some of that work can happen during install, when the services are
selected for installation.

5) why does the install try to do rarp and bootparams by default? i would expect
that the typical case would be manual configuration, followed by dhcp if that is
possible, then rarp and bootparams, overridden by solaris'' equivalent
of the linux kickstart feature.

6) sometimes during shutdown, the boot_archives are updated more than once:

updating /platform/i86pc/boot_archive...this may take a minute
updating /platform/i86pc/amd64/boot_archive...this may take a minute
# svc.startd: The system is coming down. Please wait.
svc.startd: 59 system services are now being stopped.
updating /platform/i86pc/boot_archive...this may take a minute
updating /platform/i86pc/amd64/boot_archive...this may take a minute

7) because i installed the "core system" cluster, i installed a few
packages after rebooting to get sshd and man pages. sshd did not work after
installing the package and enabling the sshd service using svcadm. I had to do
the following by hand to create the necessary keys:

# pwd
/lib/svc/method
# ./sshd -c
Creating new rsa public/private host key pair
Creating new dsa public/private host key pair

perhaps after enabling the service with svcadm for the first time, the keys can
be created automatically, rather than by hand.


what''s really not cool
=====================
1) the solaris installer lies about how much space it needs for the root slice.
i configured about 340MB for root, which install says was ample. however, when
the boot_archive is updated, a directory called /create_ramdisk.???.tmp is
created, and the root slice promptly overfills. bootadm blissfully drives on,
even while tons of "No space left on device" messages are being
displayed. i ended up configuring 1GB of space for the root slice, after which
this problem went away. solaris install should be aware of the need for this
temporary space in the root slice, and bootadm should check if its writes are
failing:

Creating ram disk for /a
updating /a/platform/i86pc/boot_archive...this may take a minute
updating /a/platform/i86pc/amd64/boot_archive...this may take a minute
cat: write error: No space left on device
cat: write error: No space left on device

the result is a useless boot_archive, which causes solaris to crash immediately
during booting, with a "read beyond end of ramdisk" error.

2) wow, solaris install needs a *lot* of ram to run for a text-only install.
512MB was not enough. i had to configure the guest with 768MB in order for it to
complete. the failure mode is hanging during the package install process. linux
and *BSD installs detect low ram configurations during  the install process, and
enable the user configured swap partitions as soon as they are specified.
perhaps the solaris install could do the same. at the very least, giving the
user some hint as to the amount of ram needed for a successful install would be
helpful. i only installed the "core system", since installing the
developer''s system always seemed to hang during install. solaris 11
nv66 will run (after install) in around 192MB, with a 256MB swap partition. i
haven''t tried to run X in this configuration.

i hope this info is helpful,
Sherry
 
 
This message posted from opensolaris.org

Sherry L. Frasier wrote:
> hi,
> 
> what follows is my experience setting up the nv66 bits as a xen guest in my
xen 3.1 / Fedora F7 dom0 test environment, using Gavin''s hints for a
solaris domU under a linux dom0 from the xen::discuss discussion group (thanks,
Gavin).
> 
> it''s clear that much good work has been done since the nv44 drop
last year.
> 
> what''s really cool
> =================> 
> 
> 1) the solaris 11 nv66 guest installs / runs under a dom0/xen 3.1 with
*and* without PAE enabled. as far as i know, solaris is the only OS that can do
this. all others are either / or (Fedora), or non-PAE, like *BSD, plan9, other
linux distributions.
> 
It works that way on bare hardware, so having Xen be the same was a no brainer.

...
> what''s not so cool
> =================> 
> 
...
> 3) why is the 64 bit boot_archive updated when the machine is 32 bit? (i
would imagine that 64 bit machine folks have the same question about the 32 bit
boot_archive):
> updating /platform/i86pc/boot_archive...this may take a minute
> updating /platform/i86pc/amd64/boot_archive...this may take a minute
We always keep both archives up to date. Solaris supports both 32 and
64 bit mode in every installation, so you can always reboot your machine/domain
into
64 bit or 32 bit mode. You only have to change menu.lst (for h/w or dom0) or
mess with the .py file for domU
>...
> 6) sometimes during shutdown, the boot_archives are updated more than once:
> 
> updating /platform/i86pc/boot_archive...this may take a minute
> updating /platform/i86pc/amd64/boot_archive...this may take a minute
> # svc.startd: The system is coming down. Please wait.
> svc.startd: 59 system services are now being stopped.
> updating /platform/i86pc/boot_archive...this may take a minute
> updating /platform/i86pc/amd64/boot_archive...this may take a minute
> 
That''s one I''ve never seen before. Does this only happen on
the first reboot after
install?

>

Hi Sherry,

   Thanks for the comments.

Sherry L. Frasier wrote:
> 3) why is the 64 bit boot_archive updated when the machine is 32 bit? (i
would imagine that 64 bit machine folks have the same question about the 32 bit
boot_archive):
> updating /platform/i86pc/boot_archive...this may take a minute
> updating /platform/i86pc/amd64/boot_archive...this may take a minute
You should be able to take a hard drive out of a 32-bit system, plug it into 
  a 64-bit system, and get it to boot (after playing around with the 
bootpath a bit).  So, both boot archives are always updated.

If this don''t care about that, and the extra time spent building the
64-bit
archives bothers you, open up /boot/solaris/bin/create_ramdisk and comment 
out this line:

*** usr/src/cmd/boot/scripts/create_ramdisk.ksh Thu Jun 28 01:26:42 2007
--- ./create_ramdisk.ksh        Wed Jul 25 14:29:19 2007
***************
*** 447,453 ****
                 lofidev64=`lofiadm -a "$rdfile64"`
         fi
         create_archive "32-bit" "$ALT_ROOT/$BOOT_ARCHIVE"
$lofidev32 &
!       create_archive "64-bit" "$ALT_ROOT/$BOOT_ARCHIVE_64"
$lofidev64
         wait
         if [ "$format" = "ufs" ]; then
                 lofiadm -d "$rdfile32"
--- 447,453 ----
                 lofidev64=`lofiadm -a "$rdfile64"`
         fi
         create_archive "32-bit" "$ALT_ROOT/$BOOT_ARCHIVE"
$lofidev32 &
!       # create_archive "64-bit"
"$ALT_ROOT/$BOOT_ARCHIVE_64" $lofidev64
         wait
         if [ "$format" = "ufs" ]; then
                 lofiadm -d "$rdfile32"

> 6) sometimes during shutdown, the boot_archives are updated more than once:
> 
> updating /platform/i86pc/boot_archive...this may take a minute
> updating /platform/i86pc/amd64/boot_archive...this may take a minute
> # svc.startd: The system is coming down. Please wait.
> svc.startd: 59 system services are now being stopped.
> updating /platform/i86pc/boot_archive...this may take a minute
> updating /platform/i86pc/amd64/boot_archive...this may take a minute
I''ve noticed this in onnv.  It''s on my list to investigate.
> what''s really not cool
> =====================> 
> 1) the solaris installer lies about how much space it needs for the root
slice. i configured about 340MB for root, which install says was ample. however,
when the boot_archive is updated, a directory called /create_ramdisk.???.tmp is
created, and the root slice promptly overfills. bootadm blissfully drives on,
even while tons of "No space left on device" messages are being
displayed. i ended up configuring 1GB of space for the root slice, after which
this problem went away. solaris install should be aware of the need for this
temporary space in the root slice, and bootadm should check if its writes are
failing:
The script building the archives needs a complete rewrite.  Its theory of 
operation seems to be "Ignore errors and carry on".  Again, this is 
something I''ll do when I get enough spare cycles...

In this case, it tries to use /tmp, but if there isn''t enough room
there, it
just assumes there is enough room on /.

-Ryan
> 
> Creating ram disk for /a
> updating /a/platform/i86pc/boot_archive...this may take a minute
> updating /a/platform/i86pc/amd64/boot_archive...this may take a minute
> cat: write error: No space left on device
> cat: write error: No space left on device
> 
> the result is a useless boot_archive, which causes solaris to crash
immediately during booting, with a "read beyond end of ramdisk" error.

I believe all the bugs below are generic Solaris ones, rather than induced by
our changes.

On Wed, Jul 25, 2007 at 01:30:48PM -0700, Sherry L. Frasier wrote:
> 1) my x86 box''s clock is set to UTC. there is no option in the
solaris
> install to "check a box" so that install gets it right. thus, i
had to run
> "rtc -z GMT" after the install completed to get the time/date
correctly
> displayed. linux and *BSD installs have this check box.
This seems like a reasonable RFE. Could you file a bug?
> 2) ypinit -c seems broken - it doesn''t enable the
svc:/network/nis/client:default smf service.
ypinit -c disables nis/client
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6427036

(I filed this bug but nobody else seems to have looked at it.)
> instead, it spits out these messages:
> Is this correct? [y/n: y] y
> svcadm: Pattern ''network/nis/server:default''
doesn''t match any instances
> svcadm: Pattern ''network/nis/xfr:default''
doesn''t match any instances
> svcadm: Pattern ''network/nis/passwd:default''
doesn''t match any instances
> svcadm: Pattern ''network/nis/update:default''
doesn''t match any instances
This is a bug: you have the minimal cluster installed, but the ypinit script
isn''t prepared for this. Can you file a bug please?
> 4) on the first boot, loading the smf(5) service descriptions takes a
*long*
> time. perhaps some of that work can happen during install, when the
services
> are selected for installation.
6534306 SMF manifests import slow on Tyan 2885 with 4gig of memory
6351623 Initial manifest-import is slow

Work is under way to make this better, I believe.
> 5) why does the install try to do rarp and bootparams by default? i would
> expect that the typical case would be manual configuration, followed by
dhcp
> if that is possible, then rarp and bootparams, overridden by
solaris''
> equivalent of the linux kickstart feature.
Dave?
> 7) because i installed the "core system" cluster, i installed a
few packages
> after rebooting to get sshd and man pages. sshd did not work after
installing
> the package and enabling the sshd service using svcadm. I had to do the
> following by hand to create the necessary keys:
> 
> # pwd
> /lib/svc/method
> # ./sshd -c
> Creating new rsa public/private host key pair
> Creating new dsa public/private host key pair
> 
> perhaps after enabling the service with svcadm for the first time, the keys
> can be created automatically, rather than by hand.
Seems a reasonable request, perhaps you could file a bug?
> 1) the solaris installer lies
> 2) wow, solaris install needs a *lot* of ram
You''ll be pleased to learn that we''re completely reworking the
installer. In
particular I believe we''ll have much more sensible defaults, and
we''re cutting
out Java to avoid the RAM requirement. You can read more here:

http://www.opensolaris.org/os/project/caiman/

Thanks for testing,
john

>> 5) why does the install try to do rarp and bootparams by default? i
would
>> expect that the typical case would be manual configuration, followed by
dhcp
>> if that is possible, then rarp and bootparams, overridden by
solaris''
>> equivalent of the linux kickstart feature.
That''s simply the default behaviour of the installer, relating back to 
Jumpstart. If you choose the ''Developer Express'' option to
install then
the rarp/bootparams doesn''t happen (a relatively new feature).

dme.

I received a friendly reminder that we should have bugIDs for these issues. 
  Sherry, if you want to be on the interest lists for these bugs, let me 
know and I''ll add you.

Ryan Scott wrote:
>> 6) sometimes during shutdown, the boot_archives are updated more than
once:
>>
>> updating /platform/i86pc/boot_archive...this may take a minute
>> updating /platform/i86pc/amd64/boot_archive...this may take a minute
>> # svc.startd: The system is coming down. Please wait.
>> svc.startd: 59 system services are now being stopped.
>> updating /platform/i86pc/boot_archive...this may take a minute
>> updating /platform/i86pc/amd64/boot_archive...this may take a minute
> 
> I''ve noticed this in onnv.  It''s on my list to
investigate.
I''ve filed 6585852 boot archive updated twice on reboot
> 
>> what''s really not cool
>> =====================>>
>> 1) the solaris installer lies about how much space it needs for the
root slice. i configured about 340MB for root, which install says was ample.
however, when the boot_archive is updated, a directory called
/create_ramdisk.???.tmp is created, and the root slice promptly overfills.
bootadm blissfully drives on, even while tons of "No space left on
device" messages are being displayed. i ended up configuring 1GB of space
for the root slice, after which this problem went away. solaris install should
be aware of the need for this temporary space in the root slice, and bootadm
should check if its writes are failing:
> 
> The script building the archives needs a complete rewrite.  Its theory of 
> operation seems to be "Ignore errors and carry on".  Again, this
is
> something I''ll do when I get enough spare cycles...
This is a symptom of

6523195 create_ramdisk needs to check everything it runs for failure

which is owned by Jan, but I promised him I''d help him out at some
point...

-Ryan

Just try to install Solaris domU on Linux Dom0 (RHEL 5 x86_64). It
doesn''t work on my Linux box.

The python configuration file looks like this:
[root@localhost xen]# cat /etc/xen/opensol.cfg 
name = "solaris"
memory = "512"
vcpus = "1"
disk = [
''file:/home/export/images/ISO/66-0624-nd.iso,6:cdrom,r'',
''file:/var/lib/xen/images/osol.img,0 ,w'' ]
vif = [ '''' ]
on_shutdown = ''destroy''
on_reboot = ''restart''
on_crash = ''destroy''
kernel = "/etc/xen/kernel/osol_xpv_b66.kernel"
ramdisk = "/etc/xen/kernel/osol_xpv_b66.miniroot"
rootdisk = "/dev/dsk/c0d0s0"
extra = ''/platform/i86xpv/kernel/unix -B install_media=cdrom''

[root@localhost xen]# xm creat -c opensol.cfg 
Using config file "./opensol.cfg".
Error: (22, ''Invalid argument'')

The log looks like:


[2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
(XendDomainInfo:190) XendDomainInfo.create([''vm'',
[''name'', ''solaris''],
[''memory'', ''512''],
[''on_reboot'', ''restart''],
[''on_crash'', ''destroy''],
[''vcpus'', ''1''], [''image'',
[''linux'', [''kernel'',
''/etc/xen/kernel/osol_xpv_b66.kernel''],
[''ramdisk'',
''/etc/xen/kernel/osol_xpv_b66.miniroot''],
[''args'',
''/platform/i86xpv/kernel/unix -B install_media=cdrom'']]],
[''device'',
[''vbd'', [''uname'',
''file:/home/export/images/ISO/66-0624-nd.iso''],
[''dev'', ''6:cdrom''],
[''mode'', ''r'']]],
[''device'', [''vbd'',
[''uname'',
''file:/var/lib/xen/images/osol.img''],
[''dev'', ''0 ''], [''mode'',
''w'']]],
[''device'', [''vif'']]])
[2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
(XendDomainInfo:296) parseConfig: config is [''vm'',
[''name'', ''solaris''],
[''memory'', ''512''],
[''on_reboot'', ''restart''],
[''on_crash'', ''destroy''],
[''vcpus'', ''1''], [''image'',
[''linux'', [''kernel'',
''/etc/xen/kernel/osol_xpv_b66.kernel''],
[''ramdisk'',
''/etc/xen/kernel/osol_xpv_b66.miniroot''],
[''args'',
''/platform/i86xpv/kernel/unix -B install_media=cdrom'']]],
[''device'',
[''vbd'', [''uname'',
''file:/home/export/images/ISO/66-0624-nd.iso''],
[''dev'', ''6:cdrom''],
[''mode'', ''r'']]],
[''device'', [''vbd'',
[''uname'',
''file:/var/lib/xen/images/osol.img''],
[''dev'', ''0 ''], [''mode'',
''w'']]],
[''device'', [''vif'']]]
[2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
(XendDomainInfo:397) parseConfig: result is {''shadow_memory'':
None,
''start_time'': None, ''uuid'': None,
''on_crash'': ''destroy'',
''on_reboot'':
''restart'', ''localtime'': None,
''image'': [''linux'',
[''kernel'',
''/etc/xen/kernel/osol_xpv_b66.kernel''],
[''ramdisk'',
''/etc/xen/kernel/osol_xpv_b66.miniroot''],
[''args'',
''/platform/i86xpv/kernel/unix -B install_media=cdrom'']],
''on_poweroff'':
None, ''bootloader_args'': None, ''cpus'': None,
''name'': ''solaris'',
''backend'': [], ''vcpus'': 1,
''cpu_weight'': None, ''features'': None,
''vcpu_avail'': None, ''memory'': 512,
''device'': [(''vbd'', [''vbd'',
[''uname'',
''file:/home/export/images/ISO/66-0624-nd.iso''],
[''dev'', ''6:cdrom''],
[''mode'', ''r'']]), (''vbd'',
[''vbd'', [''uname'',
''file:/var/lib/xen/images/osol.img''],
[''dev'', ''0 ''], [''mode'',
''w'']]),
(''vif'', [''vif''])],
''bootloader'': None, ''cpu'': None,
''maxmem'': None}
[2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
(XendDomainInfo:1264) XendDomainInfo.construct: None
[2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
(XendDomainInfo:1296) XendDomainInfo.initDomain: 18 1.0
[2007-07-27 21:07:23 xend 3764] DEBUG (balloon:127) Balloon: 542788 KiB
free; need 524288; done.
[2007-07-27 21:07:23 xend 3764] INFO (image:136) buildDomain os=linux
dom=18 vcpus=1
[2007-07-27 21:07:23 xend 3764] DEBUG (image:199) dom            = 18
[2007-07-27 21:07:23 xend 3764] DEBUG (image:200) image         
/etc/xen/kernel/osol_xpv_b66.kernel
[2007-07-27 21:07:23 xend 3764] DEBUG (image:201) store_evtchn   = 1
[2007-07-27 21:07:23 xend 3764] DEBUG (image:202) console_evtchn = 2
[2007-07-27 21:07:23 xend 3764] DEBUG (image:203) cmdline       
/platform/i86xpv/kernel/unix -B install_media=cdrom
[2007-07-27 21:07:23 xend 3764] DEBUG (image:204) ramdisk       
/etc/xen/kernel/osol_xpv_b66.miniroot
[2007-07-27 21:07:23 xend 3764] DEBUG (image:205) vcpus          = 1
[2007-07-27 21:07:23 xend 3764] DEBUG (image:206) features       = 
[2007-07-27 21:07:23 xend.XendDomainInfo 3764] ERROR
(XendDomainInfo:202) Domain construction failed
Traceback (most recent call last):
  File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 195, in create
    vm.initDomain()
  File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
line 1374, in initDomain
    raise VmError(str(exn))
VmError: (22, ''Invalid argument'')
[2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
(XendDomainInfo:1460) XendDomainInfo.destroy: domid=18
[2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
(XendDomainInfo:1468) XendDomainInfo.destroyDomain(18)


Any comments or suggestions?


On Friday, July 27, 2007 1:03 AM, xen-discuss-bounces@opensolaris.org
wrote:
> I received a friendly reminder that we should have bugIDs for
> these issues.
>  Sherry, if you want to be on the interest lists for these
> bugs, let me
> know and I''ll add you.
> 
> Ryan Scott wrote:
> 
>>> 6) sometimes during shutdown, the boot_archives are updated more
>>> than once: 
>>> 
>>> updating /platform/i86pc/boot_archive...this may take a minute
>>> updating /platform/i86pc/amd64/boot_archive...this may take a
minute
>>> # svc.startd: The system is coming down. Please wait.
>>> svc.startd: 59 system services are now being stopped.
>>> updating /platform/i86pc/boot_archive...this may take a minute
>>> updating /platform/i86pc/amd64/boot_archive...this may take a
minute
>> 
>> I''ve noticed this in onnv.  It''s on my list to
investigate.
> 
> I''ve filed 6585852 boot archive updated twice on reboot
> 
>> 
>>> what''s really not cool
>>> =====================>>> 
>>> 1) the solaris installer lies about how much space it needs
> for the root slice. i configured about 340MB for root, which
> install says was ample. however, when the boot_archive is
> updated, a directory called /create_ramdisk.???.tmp is
> created, and the root slice promptly overfills. bootadm
> blissfully drives on, even while tons of "No space left on
> device" messages are being displayed. i ended up configuring
> 1GB of space for the root slice, after which this problem went
> away. solaris install should be aware of the need for this
> temporary space in the root slice, and bootadm should check if
> its writes are failing:
>> 
>> The script building the archives needs a complete rewrite. Its
>> theory of operation seems to be "Ignore errors and carry on".
>> Again, this is something I''ll do when I get enough spare
cycles...
> 
> This is a symptom of
> 
> 6523195 create_ramdisk needs to check everything it runs for failure
> 
> which is owned by Jan, but I promised him I''d help him out at
> some point...
> 
> -Ryan
> _______________________________________________
> xen-discuss mailing list
> xen-discuss@opensolaris.org


-Allen
Intel OpenSolaris Team

Lu, Baolu wrote:
> [root@localhost xen]# xm creat -c opensol.cfg 
> Using config file "./opensol.cfg".
> Error: (22, ''Invalid argument'')
I''ve seen this a couple of times when the dom0 didn''t balloon
down fast
enough, though I''m sure that there must be other causes.

Reducing the dom0 memory in advance of the ''xm create'' would
address the
balloon problem (use ''xm mem-set'').

dme.

On , David Edmondson wrote:
 
> Lu, Baolu wrote:
>> [root@localhost xen]# xm creat -c opensol.cfg
>> Using config file "./opensol.cfg".
>> Error: (22, ''Invalid argument'')
> 
> I''ve seen this a couple of times when the dom0 didn''t
balloon down
> fast enough, though I''m sure that there must be other causes.
> 
> Reducing the dom0 memory in advance of the ''xm create''
would address
> the balloon problem (use ''xm mem-set'').
> 
> dme.
 
 It doesn''t work on my system. My system has 2G memory size, and set
 the dom0 memory to 512, 
 
 # xm mem-set 0 512
 
 The failure still exists on my system.
 
 
 -Allen
 Intel OpenSolaris Team

Lu, Baolu wrote:
> Just try to install Solaris domU on Linux Dom0 (RHEL 5 x86_64). It
> doesn''t work on my Linux box.
> 
> The python configuration file looks like this:
> [root@localhost xen]# cat /etc/xen/opensol.cfg 
> name = "solaris"
> memory = "512"
> vcpus = "1"
> disk = [
''file:/home/export/images/ISO/66-0624-nd.iso,6:cdrom,r'',
> ''file:/var/lib/xen/images/osol.img,0 ,w'' ]
> vif = [ '''' ]
> on_shutdown = ''destroy''
> on_reboot = ''restart''
> on_crash = ''destroy''
> kernel = "/etc/xen/kernel/osol_xpv_b66.kernel"
> ramdisk = "/etc/xen/kernel/osol_xpv_b66.miniroot"
> rootdisk = "/dev/dsk/c0d0s0"
> extra = ''/platform/i86xpv/kernel/unix -B
install_media=cdrom''
> 
> [root@localhost xen]# xm creat -c opensol.cfg 
> Using config file "./opensol.cfg".
> Error: (22, ''Invalid argument'')
This looks like the error Xen gives you when you try to
boot a 32-bit domU on 64-bit dom0 (which is supported in
3.1, but not in 3.0.4-1 which our current bits are based
off of).


 > kernel = "/etc/xen/kernel/osol_xpv_b66.kernel"
 > ramdisk = "/etc/xen/kernel/osol_xpv_b66.miniroot"

for a 64-bit domU:

make sure kernel is the one from
  /cdrom/boot/platform/i86xpv/kernel/amd64/unix

and bootadm is the one from:
  /cdrom//boot/amd64/x86.miniroot

also, extra should have the 64-bit kernel:
   extra = ''/platform/i86xpv/kernel/amd64/unix -B
install_media=cdrom''


That should get you past this error.




Thanks,


MRJ



> The log looks like:
> 
> 
> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
> (XendDomainInfo:190) XendDomainInfo.create([''vm'',
[''name'', ''solaris''],
> [''memory'', ''512''],
[''on_reboot'', ''restart''],
[''on_crash'', ''destroy''],
> [''vcpus'', ''1''],
[''image'', [''linux'',
[''kernel'',
> ''/etc/xen/kernel/osol_xpv_b66.kernel''],
[''ramdisk'',
> ''/etc/xen/kernel/osol_xpv_b66.miniroot''],
[''args'',
> ''/platform/i86xpv/kernel/unix -B install_media=cdrom'']]],
[''device'',
> [''vbd'', [''uname'',
''file:/home/export/images/ISO/66-0624-nd.iso''],
> [''dev'', ''6:cdrom''],
[''mode'', ''r'']]],
[''device'', [''vbd'',
[''uname'',
> ''file:/var/lib/xen/images/osol.img''],
[''dev'', ''0 ''], [''mode'',
''w'']]],
> [''device'', [''vif'']]])
> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
> (XendDomainInfo:296) parseConfig: config is [''vm'',
[''name'', ''solaris''],
> [''memory'', ''512''],
[''on_reboot'', ''restart''],
[''on_crash'', ''destroy''],
> [''vcpus'', ''1''],
[''image'', [''linux'',
[''kernel'',
> ''/etc/xen/kernel/osol_xpv_b66.kernel''],
[''ramdisk'',
> ''/etc/xen/kernel/osol_xpv_b66.miniroot''],
[''args'',
> ''/platform/i86xpv/kernel/unix -B install_media=cdrom'']]],
[''device'',
> [''vbd'', [''uname'',
''file:/home/export/images/ISO/66-0624-nd.iso''],
> [''dev'', ''6:cdrom''],
[''mode'', ''r'']]],
[''device'', [''vbd'',
[''uname'',
> ''file:/var/lib/xen/images/osol.img''],
[''dev'', ''0 ''], [''mode'',
''w'']]],
> [''device'', [''vif'']]]
> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
> (XendDomainInfo:397) parseConfig: result is
{''shadow_memory'': None,
> ''start_time'': None, ''uuid'': None,
''on_crash'': ''destroy'',
''on_reboot'':
> ''restart'', ''localtime'': None,
''image'': [''linux'',
[''kernel'',
> ''/etc/xen/kernel/osol_xpv_b66.kernel''],
[''ramdisk'',
> ''/etc/xen/kernel/osol_xpv_b66.miniroot''],
[''args'',
> ''/platform/i86xpv/kernel/unix -B install_media=cdrom'']],
''on_poweroff'':
> None, ''bootloader_args'': None, ''cpus'':
None, ''name'': ''solaris'',
> ''backend'': [], ''vcpus'': 1,
''cpu_weight'': None, ''features'': None,
> ''vcpu_avail'': None, ''memory'': 512,
''device'': [(''vbd'', [''vbd'',
[''uname'',
> ''file:/home/export/images/ISO/66-0624-nd.iso''],
[''dev'', ''6:cdrom''],
> [''mode'', ''r'']]),
(''vbd'', [''vbd'', [''uname'',
> ''file:/var/lib/xen/images/osol.img''],
[''dev'', ''0 ''], [''mode'',
''w'']]),
> (''vif'', [''vif''])],
''bootloader'': None, ''cpu'': None,
''maxmem'': None}
> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
> (XendDomainInfo:1264) XendDomainInfo.construct: None
> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
> (XendDomainInfo:1296) XendDomainInfo.initDomain: 18 1.0
> [2007-07-27 21:07:23 xend 3764] DEBUG (balloon:127) Balloon: 542788 KiB
> free; need 524288; done.
> [2007-07-27 21:07:23 xend 3764] INFO (image:136) buildDomain os=linux
> dom=18 vcpus=1
> [2007-07-27 21:07:23 xend 3764] DEBUG (image:199) dom            = 18
> [2007-07-27 21:07:23 xend 3764] DEBUG (image:200) image          >
/etc/xen/kernel/osol_xpv_b66.kernel
> [2007-07-27 21:07:23 xend 3764] DEBUG (image:201) store_evtchn   = 1
> [2007-07-27 21:07:23 xend 3764] DEBUG (image:202) console_evtchn = 2
> [2007-07-27 21:07:23 xend 3764] DEBUG (image:203) cmdline        >
/platform/i86xpv/kernel/unix -B install_media=cdrom
> [2007-07-27 21:07:23 xend 3764] DEBUG (image:204) ramdisk        >
/etc/xen/kernel/osol_xpv_b66.miniroot
> [2007-07-27 21:07:23 xend 3764] DEBUG (image:205) vcpus          = 1
> [2007-07-27 21:07:23 xend 3764] DEBUG (image:206) features       = 
> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] ERROR
> (XendDomainInfo:202) Domain construction failed
> Traceback (most recent call last):
>   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
> line 195, in create
>     vm.initDomain()
>   File
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
> line 1374, in initDomain
>     raise VmError(str(exn))
> VmError: (22, ''Invalid argument'')
> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
> (XendDomainInfo:1460) XendDomainInfo.destroy: domid=18
> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
> (XendDomainInfo:1468) XendDomainInfo.destroyDomain(18)
> 
> 
> Any comments or suggestions?
> 
> 
> On Friday, July 27, 2007 1:03 AM, xen-discuss-bounces@opensolaris.org
> wrote:
> 
>> I received a friendly reminder that we should have bugIDs for
>> these issues.
>>  Sherry, if you want to be on the interest lists for these
>> bugs, let me
>> know and I''ll add you.
>>
>> Ryan Scott wrote:
>>
>>>> 6) sometimes during shutdown, the boot_archives are updated
more
>>>> than once: 
>>>>
>>>> updating /platform/i86pc/boot_archive...this may take a minute
>>>> updating /platform/i86pc/amd64/boot_archive...this may take a
minute
>>>> # svc.startd: The system is coming down. Please wait.
>>>> svc.startd: 59 system services are now being stopped.
>>>> updating /platform/i86pc/boot_archive...this may take a minute
>>>> updating /platform/i86pc/amd64/boot_archive...this may take a
minute
>>> I''ve noticed this in onnv.  It''s on my list to
investigate.
>> I''ve filed 6585852 boot archive updated twice on reboot
>>
>>>> what''s really not cool
>>>> =====================>>>>
>>>> 1) the solaris installer lies about how much space it needs
>> for the root slice. i configured about 340MB for root, which
>> install says was ample. however, when the boot_archive is
>> updated, a directory called /create_ramdisk.???.tmp is
>> created, and the root slice promptly overfills. bootadm
>> blissfully drives on, even while tons of "No space left on
>> device" messages are being displayed. i ended up configuring
>> 1GB of space for the root slice, after which this problem went
>> away. solaris install should be aware of the need for this
>> temporary space in the root slice, and bootadm should check if
>> its writes are failing:
>>> The script building the archives needs a complete rewrite. Its
>>> theory of operation seems to be "Ignore errors and carry
on".
>>> Again, this is something I''ll do when I get enough spare
cycles...
>> This is a symptom of
>>
>> 6523195 create_ramdisk needs to check everything it runs for failure
>>
>> which is owned by Jan, but I promised him I''d help him out at
>> some point...
>>
>> -Ryan
>> _______________________________________________
>> xen-discuss mailing list
>> xen-discuss@opensolaris.org
> 
> 
> 
> -Allen
> Intel OpenSolaris Team
> _______________________________________________
> xen-discuss mailing list
> xen-discuss@opensolaris.org
-- 
Mark Johnson <mark.johnson@sun.com>
Sun Microsystems, Inc.
(781) 442-0869

On 7/27/07, Lu, Baolu <baolu.lu@intel.com> wrote:
> [root@localhost xen]# xm creat -c opensol.cfg
> Using config file "./opensol.cfg".
> Error: (22, ''Invalid argument'')
This is what I got when I had a non-PAE kernel and tried to start the
opensolaris domU (which requires PAE).  I realize you indicated you
are on a x86_64 platform, but I just wanted to mention this ;)  It
seems to me xen is not liking the kernel for whatever reason.

On Fri, Jul 27, 2007 at 11:03:24AM -0400, Gavin Hurlbut wrote:
> On 7/27/07, Lu, Baolu <baolu.lu@intel.com> wrote:
> > [root@localhost xen]# xm creat -c opensol.cfg
> > Using config file "./opensol.cfg".
> > Error: (22, ''Invalid argument'')
> 
> This is what I got when I had a non-PAE kernel and tried to start the
> opensolaris domU (which requires PAE).  I realize you indicated you
> are on a x86_64 platform, but I just wanted to mention this ;)  It
> seems to me xen is not liking the kernel for whatever reason.
This is odd though. This part of the code was changed quite some time ago
to report error messages back for things like PAE and 32-bitness not matching.
Is there nothing in xend.log?

john

On Fri, Jul 27, 2007 at 04:09:05PM +0100, John Levon wrote:
> On Fri, Jul 27, 2007 at 11:03:24AM -0400, Gavin Hurlbut wrote:
> 
> > On 7/27/07, Lu, Baolu <baolu.lu@intel.com> wrote:
> > > [root@localhost xen]# xm creat -c opensol.cfg
> > > Using config file "./opensol.cfg".
> > > Error: (22, ''Invalid argument'')
> > 
> > This is what I got when I had a non-PAE kernel and tried to start the
> > opensolaris domU (which requires PAE).  I realize you indicated you
> > are on a x86_64 platform, but I just wanted to mention this ;)  It
> > seems to me xen is not liking the kernel for whatever reason.
> 
> This is odd though. This part of the code was changed quite some time ago
> to report error messages back for things like PAE and 32-bitness not
matching.
> Is there nothing in xend.log?
Sorry, the broken threading confused me. In RHEL5 you won''t get the
better
message indeed, since it''s 3.0.3 based

regards
john

By changing the kernel and miniroot to the 64-bit versions under amd64, 

the original failure is really gone. :)

But the new issue comes:

The installation process blocks at the point of 

"Setting up Java. Please wait ..."

I''ve waited for about half a hour. It still blocks there.

Here is my config file:

name = "solaris"
memory = "512"
vcpus = "1"
disk = [
''file:/home/export/images/ISO/66-0624-nd.iso,6:cdrom,r'',''file:/etc/xen/v
disks/solaris.raw,hda,w'' ]
vif = [ '''' ]
on_shutdown = ''destroy''
on_reboot = ''restart''
on_crash = ''destroy''
kernel = "/etc/xen/kernel/osol_xpv_b66.kernel"
ramdisk = "/etc/xen/kernel/osol_xpv_b66.miniroot"
rootdisk = "/dev/dsk/c0d0s0"
extra = ''/platform/i86xpv/kernel/amd64/unix -B
install_media=cdrom''


On Friday, July 27, 2007 9:25 PM, Mark.Johnson@Sun.COM
wrote:
> Lu, Baolu wrote:
>> Just try to install Solaris domU on Linux Dom0 (RHEL 5 x86_64). It
>> doesn''t work on my Linux box. 
>> 
>> The python configuration file looks like this:
>> [root@localhost xen]# cat /etc/xen/opensol.cfg
>> name = "solaris"
>> memory = "512"
>> vcpus = "1"
>> disk = [
''file:/home/export/images/ISO/66-0624-nd.iso,6:cdrom,r'',
>> ''file:/var/lib/xen/images/osol.img,0 ,w'' ]
>> vif = [ '''' ]
>> on_shutdown = ''destroy''
>> on_reboot = ''restart''
>> on_crash = ''destroy''
>> kernel = "/etc/xen/kernel/osol_xpv_b66.kernel"
>> ramdisk = "/etc/xen/kernel/osol_xpv_b66.miniroot"
>> rootdisk = "/dev/dsk/c0d0s0"
>> extra = ''/platform/i86xpv/kernel/unix -B
install_media=cdrom''
>> 
>> [root@localhost xen]# xm creat -c opensol.cfg
>> Using config file "./opensol.cfg".
>> Error: (22, ''Invalid argument'')
> 
> This looks like the error Xen gives you when you try to
> boot a 32-bit domU on 64-bit dom0 (which is supported in
> 3.1, but not in 3.0.4-1 which our current bits are based
> off of).
> 
> 
>> kernel = "/etc/xen/kernel/osol_xpv_b66.kernel"
>> ramdisk = "/etc/xen/kernel/osol_xpv_b66.miniroot"
> 
> for a 64-bit domU:
> 
> make sure kernel is the one from
>  /cdrom/boot/platform/i86xpv/kernel/amd64/unix
> 
> and bootadm is the one from:
>  /cdrom//boot/amd64/x86.miniroot
> 
> also, extra should have the 64-bit kernel:
>   extra = ''/platform/i86xpv/kernel/amd64/unix -B
install_media=cdrom''
> 
> 
> That should get you past this error.
> 
> 
> 
> 
> Thanks,
> 
> 
> MRJ
> 
> 
> 
> 
>> The log looks like:
>> 
>> 
>> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
>> (XendDomainInfo:190) XendDomainInfo.create([''vm'',
[''name'',
>> ''solaris''], [''memory'',
''512''], [''on_reboot'',
''restart''],
>> [''on_crash'', ''destroy''],
[''vcpus'', ''1''], [''image'',
[''linux'',
>> [''kernel'',
''/etc/xen/kernel/osol_xpv_b66.kernel''],
[''ramdisk'',
>> ''/etc/xen/kernel/osol_xpv_b66.miniroot''],
[''args'',
>> ''/platform/i86xpv/kernel/unix -B
install_media=cdrom'']]], [''device'',
>> [''vbd'', [''uname'',
''file:/home/export/images/ISO/66-0624-nd.iso''],
>> [''dev'', ''6:cdrom''],
[''mode'', ''r'']]],
[''device'', [''vbd'',
[''uname'',
>> ''file:/var/lib/xen/images/osol.img''],
[''dev'', ''0 ''], [''mode'',
>> ''w'']]], [''device'',
[''vif'']]]) [2007-07-27 21:07:23
>> xend.XendDomainInfo 3764] DEBUG (XendDomainInfo:296) parseConfig:
>> config is [''vm'', [''name'',
''solaris''], [''memory'',
''512''],
>> [''on_reboot'', ''restart''],
[''on_crash'', ''destroy''],
[''vcpus'', ''1''],
>> [''image'', [''linux'',
[''kernel'',
>> ''/etc/xen/kernel/osol_xpv_b66.kernel''],
[''ramdisk'',
>> ''/etc/xen/kernel/osol_xpv_b66.miniroot''],
[''args'',
>> ''/platform/i86xpv/kernel/unix -B
install_media=cdrom'']]], [''device'',
>> [''vbd'', [''uname'',
''file:/home/export/images/ISO/66-0624-nd.iso''],
>> [''dev'', ''6:cdrom''],
[''mode'', ''r'']]],
[''device'', [''vbd'',
[''uname'',
>> ''file:/var/lib/xen/images/osol.img''],
[''dev'', ''0 ''], [''mode'',
>> ''w'']]], [''device'',
[''vif'']]] [2007-07-27 21:07:23
>> xend.XendDomainInfo 3764] DEBUG (XendDomainInfo:397) parseConfig:
>> result is {''shadow_memory'': None,
''start_time'': None, ''uuid'': None,
>> ''on_crash'': ''destroy'',
''on_reboot'': ''restart'',
''localtime'': None,
>> ''image'': [''linux'',
[''kernel'',
>> ''/etc/xen/kernel/osol_xpv_b66.kernel''],
[''ramdisk'',
>> ''/etc/xen/kernel/osol_xpv_b66.miniroot''],
[''args'',
>> ''/platform/i86xpv/kernel/unix -B
install_media=cdrom'']],
>> ''on_poweroff'': None,
''bootloader_args'': None, ''cpus'': None,
''name'':
>> ''solaris'', ''backend'': [],
''vcpus'': 1, ''cpu_weight'': None,
>> ''features'': None, ''vcpu_avail'':
None, ''memory'': 512, ''device'':
>> [(''vbd'', [''vbd'',
[''uname'',
>> ''file:/home/export/images/ISO/66-0624-nd.iso''],
[''dev'', ''6:cdrom''],
>> [''mode'', ''r'']]),
(''vbd'', [''vbd'', [''uname'',
>> ''file:/var/lib/xen/images/osol.img''],
[''dev'', ''0 ''], [''mode'',
>> ''w'']]), (''vif'',
[''vif''])], ''bootloader'': None,
''cpu'': None,
>> ''maxmem'': None} [2007-07-27 21:07:23
xend.XendDomainInfo 3764] DEBUG
>> (XendDomainInfo:1264) XendDomainInfo.construct: None [2007-07-27
>> 21:07:23 xend.XendDomainInfo 3764] DEBUG (XendDomainInfo:1296)
>> XendDomainInfo.initDomain: 18 1.0 [2007-07-27 21:07:23 xend 3764]
>> DEBUG (balloon:127) Balloon: 542788 KiB free; need 524288; done.
>> [2007-07-27 21:07:23 xend 3764] INFO (image:136) buildDomain
>> os=linux dom=18 vcpus=1 [2007-07-27 21:07:23 xend 3764] DEBUG
>> (image:199) dom            = 18 [2007-07-27 21:07:23 xend 3764]
>> DEBUG (image:200) image          >>
/etc/xen/kernel/osol_xpv_b66.kernel [2007-07-27 21:07:23 xend 3764]
>> DEBUG (image:201) store_evtchn   = 1 [2007-07-27 21:07:23 xend 3764]
>> DEBUG (image:202) console_evtchn = 2 [2007-07-27 21:07:23 xend 3764]
>> DEBUG (image:203) cmdline        = /platform/i86xpv/kernel/unix -B
>> install_media=cdrom [2007-07-27 21:07:23 xend 3764] DEBUG
>> (image:204) ramdisk        = /etc/xen/kernel/osol_xpv_b66.miniroot
>> [2007-07-27 21:07:23 xend 3764] DEBUG (image:205) vcpus          = 1
>> [2007-07-27 21:07:23 xend 3764] DEBUG (image:206) features      
>> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] ERROR
>> (XendDomainInfo:202) Domain construction failed   
>> Traceback (most recent call last):
>>   File
> "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
>> line 195, in create
>>     vm.initDomain()
>>   File
> "/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
>> line 1374, in initDomain
>>     raise VmError(str(exn))
>> VmError: (22, ''Invalid argument'')
>> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
>> (XendDomainInfo:1460) XendDomainInfo.destroy: domid=18
>> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
>> (XendDomainInfo:1468) XendDomainInfo.destroyDomain(18)
>> 
>> 
>> Any comments or suggestions?
>> 
>> 
>> On Friday, July 27, 2007 1:03 AM,
>> xen-discuss-bounces@opensolaris.org wrote: 
>> 
>>> I received a friendly reminder that we should have bugIDs for
>>> these issues.
>>>  Sherry, if you want to be on the interest lists for these
>>> bugs, let me
>>> know and I''ll add you.
>>> 
>>> Ryan Scott wrote:
>>> 
>>>>> 6) sometimes during shutdown, the boot_archives are updated
more
>>>>> than once: 
>>>>> 
>>>>> updating /platform/i86pc/boot_archive...this may take a
minute
>>>>> updating /platform/i86pc/amd64/boot_archive...this may take
a
>>>>> minute # svc.startd: The system is coming down. Please
wait.
>>>>> svc.startd: 59 system services are now being stopped.
>>>>> updating /platform/i86pc/boot_archive...this may take a
minute
>>>>> updating /platform/i86pc/amd64/boot_archive...this may
> take a minute
>>>> I''ve noticed this in onnv.  It''s on my list
to investigate.
>>> I''ve filed 6585852 boot archive updated twice on reboot
>>> 
>>>>> what''s really not cool
>>>>> =====================>>>>> 
>>>>> 1) the solaris installer lies about how much space it needs
>>> for the root slice. i configured about 340MB for root, which
>>> install says was ample. however, when the boot_archive is
>>> updated, a directory called /create_ramdisk.???.tmp is
>>> created, and the root slice promptly overfills. bootadm
>>> blissfully drives on, even while tons of "No space left on
>>> device" messages are being displayed. i ended up configuring
>>> 1GB of space for the root slice, after which this problem went
>>> away. solaris install should be aware of the need for this
>>> temporary space in the root slice, and bootadm should check if
>>> its writes are failing:
>>>> The script building the archives needs a complete rewrite. Its
>>>> theory of operation seems to be "Ignore errors and carry
on".
>>>> Again, this is something I''ll do when I get enough
spare cycles...
>>>> This is a symptom of 
>>> 
>>> 6523195 create_ramdisk needs to check everything it runs for
failure
>>> 
>>> which is owned by Jan, but I promised him I''d help him out
at
>>> some point...
>>> 
>>> -Ryan
>>> _______________________________________________
>>> xen-discuss mailing list
>>> xen-discuss@opensolaris.org
>> 
>> 
>> 
>> -Allen
>> Intel OpenSolaris Team
>> _______________________________________________
>> xen-discuss mailing list
>> xen-discuss@opensolaris.org
> 
> --
> Mark Johnson <mark.johnson@sun.com>
> Sun Microsystems, Inc.
> (781) 442-0869


-Allen
Intel OpenSolaris Team

Lu, Baolu wrote:
> By changing the kernel and miniroot to the 64-bit versions under amd64, 
> 
> the original failure is really gone. :)
> 
> But the new issue comes:
> 
> The installation process blocks at the point of 
> 
> "Setting up Java. Please wait ..."
> 
> I''ve waited for about half a hour. It still blocks there.
> 
> Here is my config file:
> 
> name = "solaris"
> memory = "512"
You need at least 768M for the install bits
included with that iso..  I expect that to
go down in time.


Once the install is complete, you can lower
the memory back down.



MRJ



> vcpus = "1"
> disk = [
>
''file:/home/export/images/ISO/66-0624-nd.iso,6:cdrom,r'',''file:/etc/xen/v
> disks/solaris.raw,hda,w'' ]
> vif = [ '''' ]
> on_shutdown = ''destroy''
> on_reboot = ''restart''
> on_crash = ''destroy''
> kernel = "/etc/xen/kernel/osol_xpv_b66.kernel"
> ramdisk = "/etc/xen/kernel/osol_xpv_b66.miniroot"
> rootdisk = "/dev/dsk/c0d0s0"
> extra = ''/platform/i86xpv/kernel/amd64/unix -B
install_media=cdrom''
> 
> 
> On Friday, July 27, 2007 9:25 PM, Mark.Johnson@Sun.COM wrote:
>> Lu, Baolu wrote:
>>> Just try to install Solaris domU on Linux Dom0 (RHEL 5 x86_64). It
>>> doesn''t work on my Linux box. 
>>>
>>> The python configuration file looks like this:
>>> [root@localhost xen]# cat /etc/xen/opensol.cfg
>>> name = "solaris"
>>> memory = "512"
>>> vcpus = "1"
>>> disk = [
''file:/home/export/images/ISO/66-0624-nd.iso,6:cdrom,r'',
>>> ''file:/var/lib/xen/images/osol.img,0 ,w'' ]
>>> vif = [ '''' ]
>>> on_shutdown = ''destroy''
>>> on_reboot = ''restart''
>>> on_crash = ''destroy''
>>> kernel = "/etc/xen/kernel/osol_xpv_b66.kernel"
>>> ramdisk = "/etc/xen/kernel/osol_xpv_b66.miniroot"
>>> rootdisk = "/dev/dsk/c0d0s0"
>>> extra = ''/platform/i86xpv/kernel/unix -B
install_media=cdrom''
>>>
>>> [root@localhost xen]# xm creat -c opensol.cfg
>>> Using config file "./opensol.cfg".
>>> Error: (22, ''Invalid argument'')
>> This looks like the error Xen gives you when you try to
>> boot a 32-bit domU on 64-bit dom0 (which is supported in
>> 3.1, but not in 3.0.4-1 which our current bits are based
>> off of).
>>
>>
>>> kernel = "/etc/xen/kernel/osol_xpv_b66.kernel"
>>> ramdisk = "/etc/xen/kernel/osol_xpv_b66.miniroot"
>> for a 64-bit domU:
>>
>> make sure kernel is the one from
>>  /cdrom/boot/platform/i86xpv/kernel/amd64/unix
>>
>> and bootadm is the one from:
>>  /cdrom//boot/amd64/x86.miniroot
>>
>> also, extra should have the 64-bit kernel:
>>   extra = ''/platform/i86xpv/kernel/amd64/unix -B
install_media=cdrom''
>>
>>
>> That should get you past this error.
>>
>>
>>
>>
>> Thanks,
>>
>>
>> MRJ
>>
>>
>>
>>
>>> The log looks like:
>>>
>>>
>>> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
>>> (XendDomainInfo:190) XendDomainInfo.create([''vm'',
[''name'',
>>> ''solaris''], [''memory'',
''512''], [''on_reboot'',
''restart''],
>>> [''on_crash'', ''destroy''],
[''vcpus'', ''1''], [''image'',
[''linux'',
>>> [''kernel'',
''/etc/xen/kernel/osol_xpv_b66.kernel''],
[''ramdisk'',
>>> ''/etc/xen/kernel/osol_xpv_b66.miniroot''],
[''args'',
>>> ''/platform/i86xpv/kernel/unix -B
install_media=cdrom'']]], [''device'',
>>> [''vbd'', [''uname'',
''file:/home/export/images/ISO/66-0624-nd.iso''],
>>> [''dev'', ''6:cdrom''],
[''mode'', ''r'']]],
[''device'', [''vbd'',
[''uname'',
>>> ''file:/var/lib/xen/images/osol.img''],
[''dev'', ''0 ''], [''mode'',
>>> ''w'']]], [''device'',
[''vif'']]]) [2007-07-27 21:07:23
>>> xend.XendDomainInfo 3764] DEBUG (XendDomainInfo:296) parseConfig:
>>> config is [''vm'', [''name'',
''solaris''], [''memory'',
''512''],
>>> [''on_reboot'', ''restart''],
[''on_crash'', ''destroy''],
[''vcpus'', ''1''],
>>> [''image'', [''linux'',
[''kernel'',
>>> ''/etc/xen/kernel/osol_xpv_b66.kernel''],
[''ramdisk'',
>>> ''/etc/xen/kernel/osol_xpv_b66.miniroot''],
[''args'',
>>> ''/platform/i86xpv/kernel/unix -B
install_media=cdrom'']]], [''device'',
>>> [''vbd'', [''uname'',
''file:/home/export/images/ISO/66-0624-nd.iso''],
>>> [''dev'', ''6:cdrom''],
[''mode'', ''r'']]],
[''device'', [''vbd'',
[''uname'',
>>> ''file:/var/lib/xen/images/osol.img''],
[''dev'', ''0 ''], [''mode'',
>>> ''w'']]], [''device'',
[''vif'']]] [2007-07-27 21:07:23
>>> xend.XendDomainInfo 3764] DEBUG (XendDomainInfo:397) parseConfig:
>>> result is {''shadow_memory'': None,
''start_time'': None, ''uuid'': None,
>>> ''on_crash'': ''destroy'',
''on_reboot'': ''restart'',
''localtime'': None,
>>> ''image'': [''linux'',
[''kernel'',
>>> ''/etc/xen/kernel/osol_xpv_b66.kernel''],
[''ramdisk'',
>>> ''/etc/xen/kernel/osol_xpv_b66.miniroot''],
[''args'',
>>> ''/platform/i86xpv/kernel/unix -B
install_media=cdrom'']],
>>> ''on_poweroff'': None,
''bootloader_args'': None, ''cpus'': None,
''name'':
>>> ''solaris'', ''backend'': [],
''vcpus'': 1, ''cpu_weight'': None,
>>> ''features'': None, ''vcpu_avail'':
None, ''memory'': 512, ''device'':
>>> [(''vbd'', [''vbd'',
[''uname'',
>>> ''file:/home/export/images/ISO/66-0624-nd.iso''],
[''dev'', ''6:cdrom''],
>>> [''mode'', ''r'']]),
(''vbd'', [''vbd'', [''uname'',
>>> ''file:/var/lib/xen/images/osol.img''],
[''dev'', ''0 ''], [''mode'',
>>> ''w'']]), (''vif'',
[''vif''])], ''bootloader'': None,
''cpu'': None,
>>> ''maxmem'': None} [2007-07-27 21:07:23
xend.XendDomainInfo 3764] DEBUG
>>> (XendDomainInfo:1264) XendDomainInfo.construct: None [2007-07-27
>>> 21:07:23 xend.XendDomainInfo 3764] DEBUG (XendDomainInfo:1296)
>>> XendDomainInfo.initDomain: 18 1.0 [2007-07-27 21:07:23 xend 3764]
>>> DEBUG (balloon:127) Balloon: 542788 KiB free; need 524288; done.
>>> [2007-07-27 21:07:23 xend 3764] INFO (image:136) buildDomain
>>> os=linux dom=18 vcpus=1 [2007-07-27 21:07:23 xend 3764] DEBUG
>>> (image:199) dom            = 18 [2007-07-27 21:07:23 xend 3764]
>>> DEBUG (image:200) image          >>>
/etc/xen/kernel/osol_xpv_b66.kernel [2007-07-27 21:07:23 xend 3764]
>>> DEBUG (image:201) store_evtchn   = 1 [2007-07-27 21:07:23 xend
3764]
>>> DEBUG (image:202) console_evtchn = 2 [2007-07-27 21:07:23 xend
3764]
>>> DEBUG (image:203) cmdline        = /platform/i86xpv/kernel/unix -B
>>> install_media=cdrom [2007-07-27 21:07:23 xend 3764] DEBUG
>>> (image:204) ramdisk        = /etc/xen/kernel/osol_xpv_b66.miniroot
>>> [2007-07-27 21:07:23 xend 3764] DEBUG (image:205) vcpus          =
1
>>> [2007-07-27 21:07:23 xend 3764] DEBUG (image:206) features      
>>> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] ERROR
>>> (XendDomainInfo:202) Domain construction failed   
>>> Traceback (most recent call last):
>>>   File
>>
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
>>> line 195, in create
>>>     vm.initDomain()
>>>   File
>>
"/usr/lib64/python2.4/site-packages/xen/xend/XendDomainInfo.py",
>>> line 1374, in initDomain
>>>     raise VmError(str(exn))
>>> VmError: (22, ''Invalid argument'')
>>> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
>>> (XendDomainInfo:1460) XendDomainInfo.destroy: domid=18
>>> [2007-07-27 21:07:23 xend.XendDomainInfo 3764] DEBUG
>>> (XendDomainInfo:1468) XendDomainInfo.destroyDomain(18)
>>>
>>>
>>> Any comments or suggestions?
>>>
>>>
>>> On Friday, July 27, 2007 1:03 AM,
>>> xen-discuss-bounces@opensolaris.org wrote: 
>>>
>>>> I received a friendly reminder that we should have bugIDs for
>>>> these issues.
>>>>  Sherry, if you want to be on the interest lists for these
>>>> bugs, let me
>>>> know and I''ll add you.
>>>>
>>>> Ryan Scott wrote:
>>>>
>>>>>> 6) sometimes during shutdown, the boot_archives are
updated more
>>>>>> than once: 
>>>>>>
>>>>>> updating /platform/i86pc/boot_archive...this may take a
minute
>>>>>> updating /platform/i86pc/amd64/boot_archive...this may
take a
>>>>>> minute # svc.startd: The system is coming down. Please
wait.
>>>>>> svc.startd: 59 system services are now being stopped.
>>>>>> updating /platform/i86pc/boot_archive...this may take a
minute
>>>>>> updating /platform/i86pc/amd64/boot_archive...this may
>> take a minute
>>>>> I''ve noticed this in onnv.  It''s on my
list to investigate.
>>>> I''ve filed 6585852 boot archive updated twice on
reboot
>>>>
>>>>>> what''s really not cool
>>>>>> =====================>>>>>>
>>>>>> 1) the solaris installer lies about how much space it
needs
>>>> for the root slice. i configured about 340MB for root, which
>>>> install says was ample. however, when the boot_archive is
>>>> updated, a directory called /create_ramdisk.???.tmp is
>>>> created, and the root slice promptly overfills. bootadm
>>>> blissfully drives on, even while tons of "No space left on
>>>> device" messages are being displayed. i ended up
configuring
>>>> 1GB of space for the root slice, after which this problem went
>>>> away. solaris install should be aware of the need for this
>>>> temporary space in the root slice, and bootadm should check if
>>>> its writes are failing:
>>>>> The script building the archives needs a complete rewrite.
Its
>>>>> theory of operation seems to be "Ignore errors and
carry on".
>>>>> Again, this is something I''ll do when I get enough
spare cycles...
>>>>> This is a symptom of 
>>>> 6523195 create_ramdisk needs to check everything it runs for
failure
>>>>
>>>> which is owned by Jan, but I promised him I''d help him
out at
>>>> some point...
>>>>
>>>> -Ryan
>>>> _______________________________________________
>>>> xen-discuss mailing list
>>>> xen-discuss@opensolaris.org
>>>
>>>
>>> -Allen
>>> Intel OpenSolaris Team
>>> _______________________________________________
>>> xen-discuss mailing list
>>> xen-discuss@opensolaris.org
>> --
>> Mark Johnson <mark.johnson@sun.com>
>> Sun Microsystems, Inc.
>> (781) 442-0869
> 
> 
> 
> -Allen
> Intel OpenSolaris Team
-- 
Mark Johnson <mark.johnson@sun.com>
Sun Microsystems, Inc.
(781) 442-0869

On Monday, July 30, 2007 1:20 PM, Mark.Johnson@Sun.COM wrote:
> Lu, Baolu wrote:
>> By changing the kernel and miniroot to the 64-bit versions under
>> amd64, 
>> 
>> the original failure is really gone. :)
>> 
>> But the new issue comes:
>> 
>> The installation process blocks at the point of
>> 
>> "Setting up Java. Please wait ..."
>> 
>> I''ve waited for about half a hour. It still blocks there.
>> 
>> Here is my config file:
>> 
>> name = "solaris"
>> memory = "512"
> 
> You need at least 768M for the install bits
> included with that iso..  I expect that to
> go down in time.
> 
> 
> Once the install is complete, you can lower
> the memory back down.
Yes, it passes if I increase the virtual memory to 1024.

Thanks. However, it still comes into another failure on the way of
installation.

I used the file-backed virtual disk and made the file with:

# dd if=/dev/zero of=/etc/xen/vdisk/solaris.raw bs=1k seek=8192k count=1

and pass this file-backed v-disk to Solaris domU with:

disk = [
''file:/home/export/images/ISO/66-0624-nd.iso,6:cdrom,r'',''file:/etc/xen/v
disks/solaris.raw,hda,w'' ]

During installation after typing ''xm create -c
opensolaris.cfg'', I
allocated the entire disk to SOLARIS and made it auto-layouted. 

After this, it comes to an error:


        The following disk configuration condition(s) have been
        detected. Errors must be fixed to ensure a successful
        installation. Warnings can be ignored without causing the
        installation to fail.

        ERROR: The ''/'' slice extends beyond HBA cylinder 1023 

I tried to layout the partition manually, but not helpful.

Thanks.
> 
> 
> 
> MRJ
>

Lu, Baolu wrote:
> On Monday, July 30, 2007 1:20 PM, Mark.Johnson@Sun.COM wrote:
> 
>> Lu, Baolu wrote:
>>> By changing the kernel and miniroot to the 64-bit versions under
>>> amd64, 
>>>
>>> the original failure is really gone. :)
>>>
>>> But the new issue comes:
>>>
>>> The installation process blocks at the point of
>>>
>>> "Setting up Java. Please wait ..."
>>>
>>> I''ve waited for about half a hour. It still blocks there.
>>>
>>> Here is my config file:
>>>
>>> name = "solaris"
>>> memory = "512"
>> You need at least 768M for the install bits
>> included with that iso..  I expect that to
>> go down in time.
>>
>>
>> Once the install is complete, you can lower
>> the memory back down.
> 
> Yes, it passes if I increase the virtual memory to 1024.
> 
> Thanks. However, it still comes into another failure on the way of
> installation.
> 
> I used the file-backed virtual disk and made the file with:
> 
> # dd if=/dev/zero of=/etc/xen/vdisk/solaris.raw bs=1k seek=8192k count=1
> 
> and pass this file-backed v-disk to Solaris domU with:
> 
> disk = [
>
''file:/home/export/images/ISO/66-0624-nd.iso,6:cdrom,r'',''file:/etc/xen/v
> disks/solaris.raw,hda,w'' ]
> 
> During installation after typing ''xm create -c
opensolaris.cfg'', I
> allocated the entire disk to SOLARIS and made it auto-layouted. 
> 
> After this, it comes to an error:
> 
> 
>         The following disk configuration condition(s) have been
>         detected. Errors must be fixed to ensure a successful
>         installation. Warnings can be ignored without causing the
>         installation to fail.
> 
>         ERROR: The ''/'' slice extends beyond HBA cylinder
1023
> 
> I tried to layout the partition manually, but not helpful.
Hmm, very strange..  Try removing the /etc/xen/vdisk/solaris.raw
file and re-creating.


MRJ


-- 
Mark Johnson <mark.johnson@sun.com>
Sun Microsystems, Inc.
(781) 442-0869

> 
> I received a friendly reminder that we should have
> bugIDs for these issues. 
> Sherry, if you want to be on the interest lists for
>  these bugs, let me 
> now and I''ll add you.
hi ryan,

sure, please do.

Sherry
 
 
This message posted from opensolaris.org

> 
> I believe all the bugs below are generic Solaris
> ones, rather than induced by
> our changes.
> 
> On Wed, Jul 25, 2007 at 01:30:48PM -0700, Sherry L.
> Frasier wrote:
> 
> > 1) my x86 box''s clock is set to UTC. there is no
> option in the solaris
> > install to "check a box" so that install gets it
> right. thus, i had to run
> > "rtc -z GMT" after the install completed to get the
> time/date correctly
> > displayed. linux and *BSD installs have this check
> box.
> 
> This seems like a reasonable RFE. Could you file a
> bug?
hi john,

are you asking me to file a bug, or some one else? if it''s me, then how
would i go about doing this?

thanks,
Sherry
 
 
This message posted from opensolaris.org

On Fri, Aug 10, 2007 at 10:30:06AM -0700, Sherry L. Frasier wrote:
> are you asking me to file a bug, or some one else? if it''s me,
then how would i go about doing this?
I''m asking you. You can file bugs here:

http://bugs.opensolaris.org/

thanks
john