Sun Solaris 10 Enterprise System

[VMTN_Admin]

http://www.vmware.com/vmtn/appliances/directory/420

Sun Solaris 10 Enterprise System Virtual Appliance

[rrunner]

Where should I start troubleshooting the error;

Panic: can not open kernel/amd64/unix

Thanks..

[KevinG]

What product are you using to run this Sun Solaris 10 Enterprise System VM?

[rrunner]

I am running VMware Server 1.0.1 build 29996 on Windows server 2003 Enterpise Edition.

[ZahirB]

I've tried to use VMware converter to import the 06/06 VM into ESX 3.

The host is a Dell 2950 with quad Xeon CPU

It doesn't boot and I get

panic\[cpu0]/thread=fec14fa0: cannot mount root path

...

rebooting

Is this something to do with running it on a 64bit host?

Or is it to do with the change from IDE to SCSI?

Any way of troubleshooting this?

Cheers, Zahir.

[atucker]

Zahir: this looks like a problem with the disk layout, not anything to do with 64 bit. I don't

think Solaris guests are currently supported by VMware Converter. Disk type changes are

particularly problematic, since they require updates to device configuration data within the

guest OS.

[ZahirB]

Thanks for the info.

Unfortunately, I'm inexperienced with Solaris 10, which is why I'm trying to use the Sun pre-built VM in the first place...

Is there any way to use this VM with ESX? Maybe I can configure the guest OS in VMware server before importing into ESX?

In the readme it says:

"this VM consists of Solaris 10 6/06 (aka Solaris 10 Update2) plus Kernel Update Patch 118855-19."

"This Patch includes several improvements for running Solaris 10 x64 as a guest operating system on VMware's Virtual Infrastructure 3 product including performance enhancements, recognition of Intel family 6 chips and bug fixes."

Doesn't this suggest it can work with ESX?

Cheers, Zahir.

[christoph_puppe]

Salve,

I'm stuck with the same stuff. "Cannot mount root path", Solaris 11/06 from sun on ESX on Xeon.

Snapshot of the beast ...

Booted into failsave, mounted the drive, then:

cd /a/etc/

cat device.tab | sed -e 's/c0d0s/c0t0d0s/s' > device.tab.1

cat device.tab.1 | sed -e 's/c0d0s/c0t0d0s/s' > device.tab

(dunno how to do global on solaris ... using vi in failsave is above me ....)

cat dumpadm.conf | sed -e 's/c0d0s/c0t0d0s/s' > dumpadm.conf.new

copy cumpadm.conf.new dumpadm.conf

cat vfstab | sed -e 's/c0d0s/c0t0d0s/s' > vfstab.1

cat vfstab.1 | sed -e 's/c0d0s/c0t0d0s/s' > vfstab

But now I'm stuck, I don't know what parameters to put in /boot/solaris/bootenv.rc to have this disk mounted on startup

Could someone with a working 5.10 on ESX mail / post the right bootpath?

thx

[radman]

I just posted a way to get a Solaris 10 Update 3 VM image bootable after running it through VMware Converter here:

http://www.vmware.com/community/thread.jspa?messageID=728713&#728713

[radman]

Zahir: this looks like a problem with the disk

layout, not anything to do with 64 bit. I don't

think Solaris guests are currently supported by

VMware Converter. Disk type changes are

particularly problematic, since they require updates

to device configuration data within the

guest OS.

Thinking about this some more, I think this argument is frankly specious. If you follow the link to how I resolved this problem you can see that Converter could have used the /devices path and thus not have had to deal with device reconfiguration - all that does is to create the legacy /dev path links but the /devices path relies entirely on bus topology and that's known at conversion time.

It's ugly, which is why humans don't use the /devices paths in vfstab but it's perfectly valid to do so and the user can clean that up later after reconfiguration has occurred to use the "nicer" /dev/dsk and /dev/rdsk paths. If Converter wanted to be extremely nice to Solaris users it could drop an RC script in one of the later boot phases to do the vfstab cleanup once after reconfig (and then remove itself). It seems like Converter is doing 95% of what Solaris users need, and could be made to do the remaining 5% (which many users will struggle with - those /devices paths are tough to type correctly).

Please consider enhancing Converter to deal with Solaris better. You have a great product here but it could be easier to use. While you're at it, please make Converter deliver better error messages. I usually got "unknown error, see the logs", and the real error was buried in the log (typically an absolute pathname to the vmdk file, while I was importing the directory via a Samba share so the absolute path couldn't be resolved. This wouldn't have been a problem if VMware Server had used a relative pathname rather than an absolute one when it created the VM).

In summary - my 3 enhancement requests:

1 Converter: update bootparms.rc and vfstab using the /devices pathnames

2 Converter: reflect the errors better from the logs

3 Server: use relative pathnames in the vmx file, to make future conversions easier from exported filesystems

OK - two more biggies:

Make both VI Client and Converter runnable from within the COS! That would be huge, and save having to set up a Windows host for these purposes, complete with licensing costs. I wound up creating an XP guest VM (and enabled Remote Terminal Services so I could access it via RDP) just for this purpose, and I'm sure I'm in good company.

Thanks!

Message was edited by:

radman

[atucker]

rrunner: The VM was built on a 32-bit host, and thus only includes 32-bit kernel modules

in the ramdisk archive used by GRUB to boot. Your host is capable of booting 64-bit,

so it tries to boot the 64-bit kernel and fails. You need to follow the instructions here:

http://docs.sun.com/app/docs/doc/817-1985/6mhm8o5pq?a=view

to force the VM to boot 32-bit, then run "bootadm update-archive -f" to add 64-bit

modules to the ramdisk. This is fixed in Solaris 10 update 3 (11/06 I think) - 64-bit

kernel modules are now always included in the ramdisk if booted as a VM (even on

32-bit hosts).

We should have a KB article on this - I'll get the ball rolling.

[rrunner]

That was it! Thanks a ton!

[rrunner]

Hi, I have the vm up and running but when i tried to configure the network interface to have a static ip it originally took the setting but after reboot the interface has vanished. I'm not able to do a plumb on the interface either. Does the interface name change to something else depending on the vmhost? Originally it was " pcn0 " . I've tried "ifconfig pcn0 plumb" but that fails any thoughts?

#ifconfig pcn0 plumb

ifconfig: plumb: pcn0: No such file or directory.

[atucker]

Did you install VMware tools? That changes the interface name to vmxnet0 (since the kernel driver has changed names). Try "ifconfig vmxnet0 plumb". If that works, rename /etc/hostname.pcn0 to /etc/hostname.vmxnet0 to allow the interface to be configured automatically at boot time.

[atucker]

Whoops, I forgot this was a 64-bit host. If you changed the VM type to "Solaris 10 64-bit", that also changes the interface to e1000, and the interface name will be e1000g0. If this is the case, then your .vmx file will contain a line like:

ethernet0.virtualDev = "e1000"

In this case, "ifconfig e1000g0 plumb" will bring up the interface, and you should rename /etc/hostname.pcn0 to /etc/hostname.e1000g0 (and /etc/dhcp.pcn0 to /etc/dhcp.e1000g0 if using DHCP).

[atucker]

There's now a KB article on the 64-bit kernel issue:

http://kb.vmware.com/kb/5336780

[peterwatt]

The appliance description says that the appliance will contain "Solaris 10, Java Enterprise System, developer tools, desktop infrastructure and N1 management software."

I can't find all of these components. Are they actually a separate download?

[cabbiebatman]

My problem with the booting into the 64 bit kernel on a 32 bit host was solved by "eeprom boot-file=kernel/unix" at root prompt and reboot" I found it on http://forum.java.sun.com/thread.jspa?threadID=5167562&messageID=9642403