Solaris Logical Domains (LDoms)

List domains	ldm ls -l
List domain information	ldm ls-bindings {domain}
ldm ls-constraints {domain}
Start domain	ldm start {domain}
Stop domain	ldm stop {domain}
Connect to console (port from ldm ls)	telnet localhost {port}
Disconnect from console	Ctrl+{}

ldm list

Following are definitions of the flags in the list subcommand output:

Column	Flag	Definition
any	-	placeholder
1	s	starting or stopping
2	n	normal
t	transition
3	d	delayed reconfiguration
4	c	control domain
5	v	virtual I/O service domain
6	e	error
s	source domain
t	target domain

Create Domain Quickstart

Add domain	ldm add-domain {domain}
Add CPU	ldm add-vcpu {num} {domain}
Add Memory	ldm add-memory {N}G {domain}
Add virtual network	ldm add-vnet vnet{N} primary-vsw{N} {domain}
Export virtual disk	ldm add-vdsdev {backend} vol{N}@primary-vds{N}
Add virtual disk	ldm add-vdisk vdisk{N} vol{N}@primary-vds{N} {domain}
Set auto-boot variable	ldm set-var auto-boot\?=true {domain}
Set boot device variable	ldm set-var boot-device=vdisk {domain}
Bind domain	ldm bind-domain {domain}

LDom configuration persistence across various power events

Poweron reset events are system-wide events that result in the host processor performing a poweron reset system boot.

Soft reset events are domain-wide events that result in the hypervisor performing a domain reboot.

LDom configuration persistence is tightly related to the two power events. The main two points to remember are:

After a poweron reset event, either an LDom configuration previously saved on the service processor (SP) (also known as Service Controller (SC)) or the factory default configuration is used to boot the system.

The configuration changes done by LDom manager are saved only to memory. One needs to explicitly save current in-memory configuration to the service processor with the LDom manager “add-spconfig” subcommand. See LDom Administration Guide for more details on how to use the LDom manager.

Keeping in mind the above four points, its easy to understand that an LDom configuration which has not been saved to the SP will be lost after a poweron reset event but not after a soft reset event.

The more difficult part is keeping track of which commands cause which reset events. These commands may be invoked from different environments (SP, Openboot, Solaris) and the behavior is known to have been tweaked with certain firmware and OS versions. I suggest avoiding any dependencies on these differences and adopting a policy of always saving your current LDom configuration before *any* power or reset related command, just as you would always save your document before restarting your word processor.

If you still want to know which commands cause which power events keep in mind these rules of thumb:

Power commands executed from non-control domain guests do not cause host-wide poweron reset events, they only cause soft reset events. Examples include the Solaris “reboot” and OBP “reset-all, “power-off” commands.

Commands executed on the SP are usually host-wide poweron reset events. Examples include the ALOM shell “reset” and “powercycle” commands. An exception is the ALOM shell “reset” command with the ”-d” option, which only resets the control domain.

Commands executed on the control domain may result in either power cycle or soft reset power events. Table 9-1 of LDoms 1.1 Administration Guide describes the effects of Solaris “halt”, “reboot”, and “shutdown -i 5” commands. Open Boot “reset-all” and “power-off” commands act the same as Solaris “reboot” and “halt” commands respectively.