Display Default LDOM services
|Check ldom manager (ldmd)||# svcs ldmd|
|Check vntsd is running||# svcs vntsd|
|Check Default Services are running||# ldm list-services primary|
|Check ldm software||# ldm -V|
|check ldoms manager package in Solaris 11||# pkg info ldomsmanager|
Creating Default LDOM services
|add virtual console concentrator (vcc)||# ldm add-vcc port-range=5000-5100 primary-vcc0 primary|
|add virtual network switch (vsw)||# ldm add-vsw net-dev=net0 primary-vsw0 primary|
|add virtual disk server (vds)||#ldm add-vds primary-vds0 primary|
|add virtual storage device to virtual disk service (Add zfs filesystem to existing Guest domain)||# zfs create -V 5G rpool/ldom01_disk01|
# ldm add-vdsdev /dev/zvol/dsk/rpool/ldom01_disk01 [email protected]
Removing Default LDOM services
|remove virtual console concentrator (vcc)||# ldm remove-vcc primary-vcc0|
|remove virtual network switch (vsw)||# ldm remove-vsw primary-vsw0|
|remove virtual disk server (vds)||# ldm remove-vds primary-vds0|
|remove virtual storage device to virtual disk service||# ldm [email protected]|
Start Default Services
|start ldom manager||# svcadm [enable|restart] ldmd|
|start vntsd||# svcadm [enable|restrat] vntsd|
Basic Guest LDOM Administration
|list resources binded to a Guest Domain||#ldm list-bindings ldom01|
|how to identify if the current domain role ? [Control,Guest,Service or Root]||# virtinfo -a|
|how to check status of I/O device||# ldm list-io|
|how to check logical domain (ldom) status||# ldm list-domain -o domain ldom01|
|list the status of all the guest domains on the system||# ldm list|
|how to manually list the LDOM config on a system||# ldm list-bindings [ldom_name]|
|list current LDOM configuration in Solaris||# ldm list-spconfig|
|Check CPU activation||# ldm list-permits|
|Check Autoreplacement policy for CPU||# svccfg -s ldmd listprop ldmd/autoreplacement_policy_cpu|
|issue send break||# telnet localhost 5000|
telnet> send brk
|stop Guest Domain||# ldm stop ldom01|
|start Guest Domain||# ldm start ldom01|
|unbind Guest Domain||# ldm unbind ldom01|
|bind Guest Domain||# ldm bind ldom01|
|Add Guest Domain||# ldm add-domain ldom01|
|assign cpu threads to Guest Domain||# ldm add-vcpu 6 ldom01|
|assign vcpu units of cores||# ldm add-core, ldm set-core [number] [ldom]|
|assign memory to Guest Domain||# ldm add-memory 4G ldom01|
|add vnet device to Guest Domain||# ldm add-vnet vnet1 primary-vsw0 ldom01|
|assign disk resource to Guest Domain||# ldm add-vdisk ldom01-disk01 [email protected] ldom01|
|Remove a Guest Domain||# ldm remove-domain ldom01|
|Remove disk resource from Guest Domain||# ldm remove-vdisk vdisk01 ldom01|
|Remove virtual network device from a Guest Domain||# ldm remove-vnet vnet1 ldom01|
|Remove CPU threads from a Guest Domain||# ldm remove-vcpu 8 ldom01|
|Remove virtual cpu units in cores from a Guest Domain||# ldm remove-core 2 ldom01|
|Remove memory from a Guest Domain||# ldm remove-memory 8G ldom01|
Save LDOM Config
|save ldom configuration to the SP||# ldm add-spconfig newconfig|
|backup of existing configuration from the control domain||# ldm list-constraints -x > /var/tmp/guest-domain-name.xml|
# ldm list-bindings > /var/tmp/full-bindings
# ldm ls -l > /var/tmp/guest-domain-list.xml”
|identify physical resources bindings||# ldm list-constraints|
|login to the console of a Guest Domain||# telnet localhost 5001|
|Enable/Disable console loggging function for a Guest Domain||# ldm set-vcons log=[off|on] [dom-name]|
|Display current console settings of a Guest Domain||# ldm list -o console ldom01|
|list all LDOM config from SP with timestamp||-> show /HOST/domain/configs date_created -t|
|list current LDOM config from SP||-> show /HOST/bootmode config -t|
|Generate crashdump from SP||-> set /HOST/send_break_action=dumpcore|
|Crash a guest domain from the control domain||# ldm panic-domain ldom01|
|to check failed cpu or memory components from Control Domain||# ldm list-domain -l -S|
In my opinion one of the hardest thing to do by any system admin is to pin point the exact cause of performance bottleneck. Many of us struggle to do this. This post will help to get started with some basic performance monitoring and troubleshooting. The post contains some of the excellent videos by Brenden Gregg. Gregg is one of the leading experts on DTrace and creator of the DTraceToolkit.
1. uptime : Load averages
The uptime command gives us the load averages along with the system uptime information. The uptime command gives the 1 minute, 5 minute and 15 minute load averages which signifies how much is the overall CPU utilization.
# uptime 11:57pm up 44 mins(s), 2 users, load average: 0.08, 0.13, 0.14
2. mpstat : Key fields
The mpstat command is used to check how the load is balanced across CPUs and what is the load on each CPU. The video explains about the key fields in the output of mpstat and how to interpret them to analyze a performance issue.
3. mpstat : All the fields
The 2nd video in the mpstat series goes through the remaining fields in the mpstat command output.
4. mpstat : Digging deeper
The 3rd part in the mpstat series goes deeper in the analysis of the mpstat command output and how to use it with dtrace to dig deeper into a performance issue.
5. vmstat : Key fields
The vmstat command is used to report virtual memory statistics and getting information about CPU load, paging and system interrupts. The video discusses the key fields in the about of vmstat command and how to interpret them.
6. vmstat : All the fields
The 2nd part in the vmstat series goes through all the fields in the vmstat command output and how to analyze them to troubleshoot a performance bottleneck.
7. vmstat : Scope
The 3rd part in the vmstat series diggs deeper into the virtual memory statistics and troubleshooting virtual memory bottlenecks along with some other tools like prstat.
8. sar and prstat
Unfortunately, Brenden does not have a video explicitly on the usage of sar and prstat for performance monitoring and troubleshooting. But he has well explained it, how to use them along with the other tools discussed above.
Here is an another video by Gabriel Smith that I would like to share on how to do basic performance troubleshooting in Solaris.
I hope the post will help you guys with getting started with performance troubleshooting on a solaris machine. Do comment me back if you have any other good references which I can include in the post.
Solaris Live Upgrade enables system administrators to create and upgrade a boot environment that is initially inactive, without affecting the running system. A simple Solaris live upgrade procedure involves below 4 steps :
1. Creating new Boot environment.
2. Applying patches to the new boot environment or upgrading the OS version in new BE.
3. Activating the new boot environment.
4. Rebooting the system with new boot environment in effect.
1. Disk space
– You should either have an extra disk or one disk large enough to house both the boot environments. The safest and recommended approach is to have an extra disk all together.
– In case of a ZFS root, we need not have a separate partition. ZFS uses the snapshot feature to copy only the files that are changed and thus saves the disk space.
2. Live upgrade packages
– Make sure you have the latest live upgrade packages installed.
Creating and Configuring the new boot environment
– The lucreate command is used to create the new, inactive boot environment.
– It has the single mandatory command line option -n, to name the boot environment. There are several other command line options that can be used with lucreate.
– In the following example, the lucreate command is used to create the new boot environment named new_be from the currently active boot :
# lucreate -n new_be
– When the lucreate command is invoked for the first time, the currently active boot environment is given a default name. Alternatively -c command line option can be used to assign a user-defined name for the current boot environment.
Applying patches to new environment
– The luupgrade command is used to install the software/patches on the inactive boot environment.
– The luupgrade command performs the following functions :
- Upgrade the OS image on the inactive boot environment
- Add or remove packages/patches to or from the inactive boot.
– The following example demonstrates the use of luupgrade to install patch 139503-01 on an inactive boot environment called new_be, without disrupting the existing environment. The luupgrade command validates and then installs the patch on the new BE. The -s option identifies the path to the media.
# luupgrade -t -n new_be -s /var/tmp/139503-01
Activating the new boot environment
– The luactivate command is used to activate new_be :
# luactivate new_be
– The luactivate command activates new_be, by making its root partition bootable.
– Before activating the new BE make sure :
1. new_be can not have mounted partitions.
2. The lustatus command must report new_be as complete.
– After activating and rebooting the system, you will have the new active boot environment with the installed patch.
There are several other things involved when doing a live upgrade. The post touch bases upon the concepts of live upgrade. In the upcoming posts, I will be writing on some live upgrade example. Stay tuned !