Via my experience OSOL 134 (133) PV DomU may obtain IP address just once during the first boot up after install when SMF is activated . Been shutdown and loaded again PV DomU fails to obtain IP address via DHCP and requires every time :- $ pfexec su - # svcadm restart svc:/network/physical:nwam to get IP from DHCP Server located on the LAN. Re enabling service mentioned above helps as well . Build 132 is not affected -- This message posted from opensolaris.org
Boris Derzhavets
2010-Apr-12  16:19 UTC
Re: Service svc:/network/physical:nwam on OSOL 134, 133
Oops ! 132 was tested OK  Xen 3.4.3 Dom0 & pvops 2.6.31.6.
Via  xml-profile for 132 DomU :-
<domain type=''xen''>
<name>OSOL132</name>
<memory>2097152</memory>
<currentMemory>2097152</currentMemory>
<vcpu>2</vcpu>
<bootloader>/usr/local/bin/pygrub</bootloader>
<os>
<type>linux</type>
</os>
<clock offset=''utc''/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<disk type=''block''
device=''disk''>
<driver name=''phy''/>
<source dev=''/dev/sda7''/>
<target dev=''xvda'' bus=''xen''/>
</disk>
<interface type=''bridge''>
<mac address=''00:16:3e:10:93:61''/>
<source bridge=''eth0''/>
<script path=''/etc/xen/scripts/vif-bridge''/>
<target dev=''vif7.0''/>
</interface>
<console type=''pty''
tty=''/dev/pts/2''>
<source path=''/dev/pts/2''/>
<target port=''0''/>
</console>
</devices>
</domain>
Now 132 gives the same issue as 134 (133) at Xen 4.0 Dom0 & pvops 2.6.32.11.
Via xml profile :
<domain type=''xen''>
  <name>OSOL132</name>
  <memory>1048576</memory>
  <currentMemory>1048576</currentMemory>
  <vcpu>2</vcpu>
  <bootloader></bootloader>
  <os>
    <type>linux</type>
    <kernel>/home/boris/osol132/unix</kernel>
   
<initrd>/home/boris/osol132/boot_archive</initrd>
    <cmdline>/platform/i86xpv/kernel/amd64/unix -B
zfs-bootfs=rpool/ROOT/opensolaris,bootpath=/xpvd/xdf@51712:a</cmdline>
  </os>
  <clock offset=''utc''/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>destroy</on_reboot>
  <on_crash>destroy</on_crash>
  <devices>
    <disk type=''block''
device=''disk''>
      <driver name=''phy''/>
      <source dev=''/dev/sda7''/>
      <target dev=''xvda''
bus=''xen''/>
    </disk>
    <interface type=''bridge''>
      <mac address=''00:16:3e:4d:60:e3''/>
      <source bridge=''eth0''/>
      <script
path=''/etc/xen/scripts/vif-bridge''/>
      <target dev=''vif8.0''/>
    </interface>
    <console type=''pty''
tty=''/dev/pts/1''>
      <source path=''/dev/pts/1''/>
      <target port=''0''/>
    </console>
  </devices>
</domain>
Most probably the last XML definition causes the issue.
Pygrub at Xen 4.0 Linux Dom0 cannot define OSOL 132 PV DomU at all.
Backward compatibility is broken.
-- 
This message posted from opensolaris.org
Boris Derzhavets
2010-Apr-12  21:46 UTC
Re: Service svc:/network/physical:nwam on OSOL 134, 133
At Xen 3.4.3-rc4 Dom0 (pvops 2.6.32.10)  pygrub works fine with OSOL 134 DomU
root@ServerKoala:/home/boris/osol134# cat osol134py-def.xml
<domain type=''xen''>
<name>OSOL134</name>
<memory>2097152</memory>
<currentMemory>2097152</currentMemory>
<vcpu>2</vcpu>
<bootloader>/usr/local/bin/pygrub</bootloader>
<os>
<type>linux</type>
</os>
<clock offset=''utc''/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<disk type=''block'' device=''disk''>
<driver name=''phy''/>
<source dev=''/dev/sdb6''/>
<target dev=''xvda'' bus=''xen''/>
</disk>
<interface type=''bridge''>
<mac address=''00:16:3e:10:93:61''/>
<source bridge=''eth0''/>
<script path=''/etc/xen/scripts/vif-bridge''/>
<target dev=''vif7.0''/>
</interface>
<console type=''pty'' tty=''/dev/pts/2''>
<source path=''/dev/pts/2''/>
<target port=''0''/>
</console>
</devices>
</domain>
# virsh define osol134py-def.xml
root@ServerKoala:/home/boris/osol134# virsh start OSOL134
Connecting to uri: xen:///
Domain OSOL134 started
root@ServerKoala:/home/boris/osol134# virsh console OSOL134
Connecting to uri: xen:///
Connected to domain OSOL134
Escape character is ^]
v3.4.3-rc4 chgset ''Fri Apr 09 08:48:59 2010 +0100
19941:64d80f868951''
SunOS Release 5.11 Version snv_134 64-bit
Copyright 1983-2010 Sun Microsystems, Inc.  All rights reserved.
Use is subject to license terms.
Hostname: opensolaris
Reading ZFS config: done.
Mounting ZFS filesystems: (6/6)
opensolaris console login: boris
Password: 
Last login: Mon Apr 12 21:27:55 on console
Sun Microsystems Inc.   SunOS 5.11      snv_134 February 2010
boris@opensolaris:~$ pwd
/home/boris
boris@opensolaris:~$ pfexec ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232
index 1
        inet 127.0.0.1 netmask ff000000 
xnf0: flags=1004843<UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4> mtu 1500
index 2
        inet 192.168.1.38 netmask ffffff00 broadcast 192.168.1.255
        ether 0:16:3e:10:93:61 
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252
index 1
        inet6 ::1/128 
xnf0: flags=2004841<UP,RUNNING,MULTICAST,DHCP,IPv6> mtu 1500 index 2
        inet6 fe80::216:3eff:fe10:9361/10 
        ether 0:16:3e:10:93:61 
boris@opensolaris:~$ pfexec shutdown -y -i0 -g0
Shutdown started.    Monday, April 12, 2010 09:30:43 PM MSD
Changing to init state 0 - please wait
Broadcast Message from root (console) on opensolaris Mon Apr 12 21:30:43...
THE SYSTEM opensolaris IS BEING SHUT DOWN NOW ! ! !
Log off now or risk your files being damaged
boris@opensolaris:~$ svc.startd: The system is coming down.  Please wait.
svc.startd: 93 system services are now being stopped.
Apr 12 21:30:44 opensolaris syslogd: going down on signal 15
svc.startd: Killing user processes.
Apr 12 21:30:49 The system is down.  Shutdown took 6 seconds.
syncing file systems... done
Pygrub ( & libfsimage.so)  properly working with Xen 4.0 is required. 
<cmdline>/platform/i86xpv/kernel/amd64/unix -B
zfs-bootfs=rpool/ROOT/opensolaris,bootpath=/xpvd/xdf@51712:a</cmdline>
doesn''t work even at Xen 3.4.3-rc4 Dom0.
-- 
This message posted from opensolaris.org
Boris Derzhavets
2010-Apr-12  22:02 UTC
Re: Service svc:/network/physical:nwam on OSOL 134, 133
Is a proper <cmdline> secret (just for now) ? -- This message posted from opensolaris.org
Boris Derzhavets
2010-Apr-17  16:20 UTC
Re: Service svc:/network/physical:nwam on OSOL 134, 133
I believe that OSOL 134 frontend network driver has a bug. It is able to interact with Xen 4.0 Dom0 on top of Ubuntu 9.10 Server Dom0 only supported by pvops kernel 2.6.32.10 (11). In case same Dom0 is loaded with xenified aka Suse kernel 2.6.31.12 same OSOL PV guest fails to start at all. It''s written with no connection to recent MRJ''s patch. Profiles been used may be viewed here :- http://bderzhavets.wordpress.com/2010/04/11/set-up-osol-2010-03-build-134-at-xen-4-0-2-6-32-10-pvops-kernel-on-of-ubuntu-karmic-koala-server/ -- This message posted from opensolaris.org