Student Guide - SA-345 Sun Virtualization - Solaris 10 Logical Domains Administration

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.
COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
D66810
April 2010
Edition 2.0
D61784GC20
SA-345-S10 B
Student Guide
Administration
Sun Virtualization:
Solaris 10 Logical Domains
Oracle University and BOS-it GmbH & Co.KG use only

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY. COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED
Copyright © 2010, Oracle and/or its affiliates. All rights reserved.
Disclaimer
This document contains proprietary information, is provided under a license agreement containing restrictions on use and
disclosure, and is protected by copyright and other intellectual property laws. You may copy and print this document solely for
your own use in an Oracle training course. The document may not be modified or altered in any way. Except as expressly
permitted in your license agreement or allowed by law, you may not use, share, download, upload, copy, print, display,
perform, reproduce, publish, license, post, transmit, or distribute this document in whole or in part without the express
authorization of Oracle.
The information contained in this document is subject to change without notice. If you find any problems in the document,
please report them in writing to: Oracle University, 500 Oracle Parkway, Redwood Shores, California 94065 USA. This
document is not warranted to be error-free.
Sun Microsystems, Inc. Disclaimer
This training manual may include references to materials, offerings, or products that were previously offered by Sun

Microsystems, Inc. Certain materials, offerings, services, or products may no longer be offered or provided.Oracle and its
affiliates cannot be held responsible for any such references should they appear in the text provided.
Restricted Rights Notice

If this documentation is delivered to the U.S. Government or anyone using the documentation on behalf of the U.S.
Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS

The U.S. Government’s rights to use, modify, reproduce, release, perform, display, or disclose these training materials are
restricted by the terms of the applicable Oracle license agreement and/or the applicable U.S. Government contract.
Trademark Notice
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective
owners.
AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro
Devices. Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used
under license and are trademarks or registered trademarks of SPARC International, Inc. UNIX is a registered trademark
licensed through X/Open Company, Ltd.
This page intentionally left blank.

This page intentionally left blank.


Table of Contents
About This Course .................................................................Preface-i
Course Map.............................................................................. Preface-ii
Topics Not Covered...............................................................Preface-iii
How Prepared Are You?.......................................................Preface-iv
Introductions ........................................................................... Preface-v
How to Use Course Materials ..............................................Preface-vi
Conventions ...........................................................................Preface-vii
Typographical Conventions ..................................... Preface-viii
Logical Domains Fundamentals .....................................................1-1
Additional Resources ........................................................................ 1-2
Introduction to Logical Domains..................................................... 1-3
What Are Logical Domains?.................................................... 1-3
How Is Logical Domains Positioned in Sun Microsystems
Virtualization Technologies?................................................ 1-3
Logical Domains Virtual Machines Overview ..................... 1-5
Logical Domains Architecture ......................................................... 1-9
The Hypervisor ....................................................................... 1-10
Logical Domains Manager..................................................... 1-11
Logical Domain Channel ....................................................... 1-12
The OpenBoot™ PROM Environment................................. 1-13
The Operating System ............................................................ 1-14
Physical and Virtual Devices................................................. 1-15
Logical Domains Planning.............................................................. 1-16
Identifying Design Goals ....................................................... 1-16
Gather System Hardware and Software Configuration
Information ........................................................................... 1-18
Additional Configuration Planning Considerations ......... 1-26
Identify Installation Tasks ..................................................... 1-27
Identify Configuration Tasks ................................................ 1-28
Identify Administrative and Maintenance Tasks............... 1-29
Identify Implementation Resources ..................................... 1-29
1
Copyright 2010 Sun Microsystems, Inc. All Rights Reserved. Sun Learning Services, Revision B
Installing Logical Domains Software ............................................. 2-1

Introduction ........................................................................................ 2-3
Verifying the Correct Build of the Solaris OS ................................ 2-5
Checking the System Firmware ....................................................... 2-6
Installing the Logical Domains Manager Software Packages ... 2-10
Downloading the Logical Domains Manager Software
Package .................................................................................. 2-10
Installing the Logical Domains Manager Software
Packages ................................................................................ 2-11

Ensuring the Logical Domains Manager Daemon is
Enabled .................................................................................. 2-13
Ensuring Security on a Logical Domains System is
Enabled .................................................................................. 2-14
The Logical Domains Manager ldm Command........................... 2-15
Applying What You Have Learned – Lab Exercise .................... 2-20
Preparation............................................................................... 2-21
Task 1 – Gather System Hardware and Software
Configuration Information ................................................. 2-24
Task 2 – Upgrade the System Controller Firmware........... 2-29
Task 3 – Install the Logical Domains Management
Software................................................................................. 2-35
Lab Exercise Summary ........................................................... 2-38
Configuring the Control and Service Domain ............................... 3-1
Introduction ........................................................................................ 3-3
Configuring the Control Domain’s Resources............................... 3-4
Determining How Many Resources are Available .............. 3-5
Setting Virtual CPUs for the Control Domain ...................... 3-5
Setting Cryptographic Resources for the Control Domain. 3-6
Setting Memory for the Control Domain .............................. 3-6
Verifying the Resources Assigned to the Control Domain. 3-7
Adding Virtual Services.................................................................... 3-8
Adding a Virtual Disk Server.................................................. 3-9
Adding a Virtual Switch Service........................................... 3-10
Adding a Virtual Console Concentrator Service ................ 3-11
Verifying the Virtual Services Have Been Created ............ 3-12
Saving the Configuration to the System Controller.................... 3-13
Verifying the Configuration is Ready to be Used at the Next
Reboot ............................................................................................. 3-14
Rebooting the Control Domain...................................................... 3-15
Enabling Networking Between the Control/Service Domain and
Other Domains .............................................................................. 3-16
Enabling the Virtual Network Terminal Server Daemon .......... 3-18
2 Sun Virtualization: Solaris™ 10 Logical Domains Administration

Preparation............................................................................... 3-19
Task 1 – Set Up the Control Domain.................................... 3-20
Task 2 – Create Virtual Services............................................ 3-28
Task 3 – Configure the Virtual Switch as a Primary
Network Interface ................................................................ 3-31
Task 4 – Enable the Virtual Network Terminal Server...... 3-33
Creating a Guest Domain.................................................................4-1

Introduction ........................................................................................ 4-3
Creating and Starting a Guest Domain........................................... 4-4
Determining Available Resources .......................................... 4-4
Creating the Guest Domain ..................................................... 4-5
Installing the Solaris OS on a Guest Domain Using JumpStart .. 4-9
Verifying a Guest Domain Configuration .................................... 4-11
Preparation............................................................................... 4-13
Task 1 – Create a Guest Domain........................................... 4-14
Task 2 – Switch Between Control and Guest Domains ..... 4-21
Task 3 – JumpStart the Guest Domain ................................. 4-22
Task 4 – Explore the Guest Domain ..................................... 4-26
Performing Logical Domains Administration ................................5-1
Introduction ........................................................................................ 5-3
Reconfiguring Logical Domain Resources ..................................... 5-4
Overview of Dynamic and Delayed Reconfiguration
Operations............................................................................... 5-4
Reconfiguring Virtual CPU and Memory ............................. 5-5
Using Virtual Disks............................................................................ 5-8
Introduction to Virtual Disks .................................................. 5-8
Virtual Disk Appearance ......................................................... 5-9
Virtual Disk Backend Options .............................................. 5-10
Virtual Disk Backend.............................................................. 5-10
Exporting CD, DVD and ISO Images................................... 5-16
Using ZFS to Create Virtual Disks for Guest Domains ..... 5-17
Using Virtual Networks .................................................................. 5-22
Configuring a Virtual Switch and the Service Domain for
NAT and Routing................................................................. 5-23
Configuring Virtual Local Area Networks ......................... 5-24
Managing Logical Domains Configurations................................ 5-27
Saving, Removing, and Restoring a Guest Domain
Configuration ....................................................................... 5-27
Resetting the Logical Domains Configuration ................... 5-30
3
Managing Advanced Logical Domains Configurations................ 6-1

Introduction ........................................................................................ 6-3
Migrating a Logical Domain from One Server to Another.......... 6-4
Migration Process Overview ................................................... 6-4
Migrating an Active Domain (Warm Migration) ................. 6-6
Migrating a Bound or Inactive Domain (Cold Migration) 6-10
Performing the Migration ...................................................... 6-11
Performing Automated Migrations...................................... 6-13
Using Multiple I/O Domains......................................................... 6-14

Creating an Additional I/O Domain ................................... 6-14
Configuring Virtual Network Multipathing With Multiple
I/O Domains......................................................................... 6-17
Configuring Virtual Disk Multipathing With Multiple I/O
Domains................................................................................. 6-20
Preparation............................................................................... 6-23
Task 1– Remove and Restore a Guest Domain ................... 6-24
Task 2 – Reconfigure Guest Virtual CPUs........................... 6-27
Task 3 – Reconfigure Guest Domain Memory.................... 6-30
Task 4 – Split the PCI Configuration to Create I/O
Domains................................................................................. 6-33
Task 5 – Use a File as a Virtual Disk..................................... 6-41
Task 6 – Export a ZFS Volume as a Virtual Disk................ 6-47
Task 7 – Migrate an Active Guest Domain.......................... 6-53
Task 8 – Reset the System to the Factory Default
Configuration ....................................................................... 6-63
4 Sun Virtualization: Solaris™ 10 Logical Domains Administration

Preface
About This Course

Course Goals
Upon completion of this course, you should be able to administer
Logical Domains. This includes administrative tasks such as:
● Planning a Logical Domains installation
● Installing the Logical Domains software
● Configuring the control and service domain
● Creating a guest domain
● Reconfiguring logical domains resources
● Using virtual disks
● Using virtual networks
● Managing logical domains configurations
● Migrating an active guest domain (warm migration)
● Migrating a bound or inactive guest domain (cold migration)
● Creating an additional I/O domain
● Configuring virtual network multipathing with multiple I/O
domains
● Configuring virtual disk multipathing with multiple I/O domains
Preface-i
Course Map
Course Map
The following course map enables you to see what you have
accomplished and where you are going in reference to the course goals.
System Management

Logical
Changes in Domains
Solaris 10 Installing Logical
Fundamentals Domains Software
System Management
Configuring the Control Creating
ChangesainGuest Domain
Solaris 10
and Service Domain
System Management
Managing Advanced
Performing Logical Changes in Solaris
Logical Domains 10
Domains Administration Configurations
Preface-ii Sun Virtualization: Solaris™ 10 Logical Domains Administration

Topics Not Covered
Topics Not Covered

This course does not cover the following topics. Many of these topics are
covered in other courses offered by Sun Learning Services:
● Concepts involving IP packet forwarding and routing
● Concepts relating to Sun™ Enterprise Volume Manager software
Refer to the Sun Learning Services catalog for specific information and

registration.
About This Course Preface-iii

How Prepared Are You?
How Prepared Are You?

To be sure you are prepared to take this course, can you answer yes to the
following questions?
● Can you administer the Solaris 10 Operating System?
● Do you have experience with logical domain capable systems?
● Can you configure remote installation methods such as JumpStart?

● Do you understand security protection methods commonly
employed in computer environments?
Preface-iv Sun Virtualization: Solaris™ 10 Logical Domains Administration

Introductions
Introductions
Now that you have been introduced to the course, introduce yourself to
the other students and the instructor, addressing the following items:
● Name
● Company affiliation
● Title, function, and job responsibility

● Experience related to topics presented in this course
● Reasons for enrolling in this course
● Expectations for this course
About This Course Preface-v

How to Use Course Materials
How to Use Course Materials

To enable you to succeed in this course, these course materials contain a
learning module that is composed of the following components:
● Goals – You should be able to accomplish the goals after finishing
this course and meeting all of its objectives.
● Objectives – You should be able to accomplish the objectives after
completing a portion of instructional content. Objectives support

goals and can support other higher-level objectives.
● Lecture – The instructor presents information specific to the objective
of the module. This information helps you learn the knowledge and
skills necessary to succeed with the activities.
● Activities – The activities take various forms, such as an exercise,
self-check, discussion, and demonstration. Activities help you
facilitate the mastery of an objective.
● Visual aids – The instructor might use several visual aids to convey a
concept, such as a process, in a visual form. Visual aids commonly
contain graphics, animation, and video.
Preface-vi Sun Virtualization: Solaris™ 10 Logical Domains Administration

Conventions
Conventions
The following conventions are used in this course to represent various
training elements and alternative learning resources.
Icons

Additional resources – Indicates other references that provide additional
information on the topics described in the module.
Discussion – Indicates a small-group or class discussion on the current

topic is recommended at this time.
!
?
Note – Indicates additional information that can help students but is not
crucial to their understanding of the concept being described. Students
should be able to understand the concept or complete the task without
this information. Examples of notational information include keyword
shortcuts and minor system adjustments.
Caution – Indicates that there is a risk of personal injury from a

nonelectrical hazard, or risk of irreversible damage to data, software, or
the operating system. A caution indicates that the possibility of a hazard
(as opposed to certainty) might happen, depending on the action of the
user.
About This Course Preface-vii

Conventions
Typographical Conventions
Courier is used for the names of commands, files, directories,
programming code, and on-screen computer output; for example:
Use ls -al to list all files.
system% You have mail.
Courier is also used to indicate programming constructs, such as class

names, methods, and keywords; for example:
The getServletInfo method is used to get author information.
The java.awt.Dialog class contains Dialog constructor.
Courier bold is used for characters and numbers that you type; for
example:
To list the files in this directory, type:
# ls
Courier bold is also used for each line of programming code that is
referenced in a textual description; for example:
1 import java.io.*;
2 import javax.servlet.*;
3 import javax.servlet.http.*;
Notice the javax.servlet interface is imported to allow access to its
life cycle methods (Line 2).
Courier italics is used for variables and command-line placeholders

that are replaced with a real name or value; for example:
To delete a file, use the rm filename command.
Courier italic bold is used to represent variables whose values are to

be entered by the student as part of an activity; for example:
Type chmod a+rwx filename to grant read, write, and execute
rights for filename to world, group, and users.
Palatino italics is used for book titles, new words or terms, or words that
you want to emphasize; for example:
Read Chapter 6 in the User’s Guide.
These are called class options.
Preface-viii Sun Virtualization: Solaris™ 10 Logical Domains Administration

Module 1
Logical Domains Fundamentals

Objectives
This module introduces you to Logical Domains concepts, architecture,
and planning considerations.
Upon completion of this module, you should be able to:

● Describe Logical Domains virtualization.
● Describe the Logical Domains architecture.
● Plan your Logical Domains installation.
1-1
Additional Resources
The following references provide additional information about the topics

described in this module:
● Logical Domains 1.3 Administration Guide, Part No: 821-0406-10
● Logical Domains 1.3 Reference Manual, Part No: 821-0405-10
1-2 Sun Virtualization: Solaris™ 10 Logical Domains Administration

Introduction to Logical Domains
What Are Logical Domains?

The Logical Domains, or LDoms, technology is part of a suite of
methodologies for consolidation and resource management that includes
Sun Fire Dynamic System Domains (dynamic hardware domains) and
Solaris OS Zones, of which resource control and operating system

virtualization are a subset.
How Is Logical Domains Positioned in Sun

Microsystems Virtualization Technologies?
Sun provides a wide spectrum of virtualization technologies designed to
meet the needs of the most demanding dynamic datacenter. Each
virtualization technology provides varying degrees of flexibility,
availability, and security. In some cases, organizations benefit by utilizing
multiple virtual technologies within a single server deployment. By
harnessing commodity software, delivering Sun's own advanced products
and technologies, and leveraging Sun's global expertise in providing
systems and software, Sun offers a full portfolio of virtualization
solutions. Sun Microsystems' comprehensive approach addresses strategic
virtualization categories, including hard partitioning with Dynamic
System Domains, virtual machines with Logical Domains, operating
system virtualization with Solaris Zones, and resource management (see
Figure 1-1).
Hard Partitions Virtual Machines OS Virtualization Resource Management
App App App App App App App App App App App App App
A B C A B C D A B A B C
OS
Hypervisor
Server
Dynamic System Solaris Zones Solaris Resource

Logical Domains (LDoms) Manager
Domains
Trend to Flexability Trend to Isolation and Security
Figure 1-1 Sun Virtualization Technologies for SPARC
Logical Domains Fundamentals 1-3

● Dynamic System Domains (DSD) are engineered to remain isolated

from each other within the system, providing a highly secure and
reliable environment for running multiple functions simultaneously.
Each domain is a self-contained server of one or multiple system
boards, containing CPU, memory, I/O, boot-disk and network
resources, running Sun's highly robust Solaris Operating System
software in each domain instance. This solution provides the greatest
isolation and security.
● Logical Domains, or LDoms, allows you to share a system's various

resources, such as memory, CPUs, and devices, into logical
groupings and create multiple, discrete systems, each with their own
operating system, resources, and identity within a single computer
system. These discrete systems are known as logical domains. At the
heart of the LDoms architecture is the hypervisor. The hypervisor
provides a set of support functions to the operating system, so that
the OS does not need to know intimate details of how to perform
functions with the hardware. A Logical Domains environment helps
you achieve greater resource usage.
● Solaris Zones, also known as Solaris Containers, provide a complete
execution environment for a set of software services. They are a
separate, virtual Solaris environment sharing a common kernel. A
zone provides a virtual mapping from software services to platform
resources, and allows application components to be isolated from
each other even though they share a single kernel. It establishes
boundaries for resource consumption and provides isolation from
other zones on the same system. The boundaries can be changed
dynamically to adapt to changing processing requirements of the
applications running in the zone.
● Solaris resource management software, formerly referred to as
Solaris Resource Manager, enables increased resource availability for
users, groups, and applications. It provides the ability to allocate and
control major system resources such as CPU, memory, and number
of processes. After a resource policy is set, the system administrator
can walk away, confident that mission-critical applications will get
the resources they demand.
Two other virtualization technologies you should be aware of are Sun

VirtualBox, which falls between Virtual Machines and OS Virtualization
as an application that runs within an OS instances, and Oracle VM Server,
which is functionally the equivalent of Logical Domains (SPARC) for
x86/x64 but supports Linux as a guest OS.

● Sun VirtualBox is a multi-operating environment virtualization

application that runs on x86 platforms only. It extends the
capabilities of the user's existing computer so that it can run multiple
operating systems (inside multiple virtual machines) at the same
time. So, for example, a user can run Windows and Linux on a Mac,
run Windows Server 2008 on a Linux server, run Linux on a
Windows PC, and so on, all alongside existing applications. The user
can install and run as many virtual machines as he or she likes. The
only practical limits are disk space and memory.

● Oracle VM Server is a free, next-generation server virtualization and
management solution from Oracle that makes enterprise applications
easier to deploy, manage, and support. Users can create and manage
virtual machines that exist on the same physical server but behave
like independent physical servers. Each virtual machine created with
Oracle VM Server has its own virtual CPUs, network interfaces,
storage, and operating system. With Oracle VM Server, users have an
easy-to-use browser-based tool for creating, cloning, sharing,
configuring, booting, and migrating virtual machines.
Logical Domains complements Sun’s existing virtualization technologies

and brings additional value to enterprises. For example, Logical Domains
enables partitioning of entry level servers. This capability was previously
only available to mid-range and high-end systems with Dynamic System
Domains. Logical Domains can also enhance computer resource
management on systems using Solaris Zones technology for
virtualization.
Logical Domains Virtual Machines Overview

Logical Domains, which are available on SPARC Chip Multithreaded
servers, uses server virtualization technology to transform one physical
server into a host for many virtual machines. Each virtual machine can
run a separate, independent operating system and applications. The
server virtualization technology partitions the hardware so that it can
function as if it were several separate independent pools. As a result the
underlying server resources, such as memory, CPUs, network interfaces,
and storage devices, can be shared among the virtual machines.

A Logical Domains virtual machine is known as a logical domain. A

logical domain is comprised of a discrete logical grouping of resources
and has its own operating system and identity within a single computer
system. Each logical domain can be created, destroyed, reconfigured, and
rebooted independently, without requiring you to powercycle the physical
server.
You can run a variety of applications software in different logical domains

and keep them independent for performance and security purposes. Each
logical domain is only permitted to observe and interact with those

physical server resources that are made available to it by the hypervisor.
There are multiple roles that logical domains can perform (see Figure 1-2),
such as a:
● Control domain – The control domain controls the Logical Domains
environment. It is used to configure machine resources and guest
domains, and provides services necessary for domain operation,
such as virtual console service. The control domain also normally
acts as a service domain. The Logical Domains Manager software is
located within the control domain. A system has exactly one control
domain. It is the first domain configured on the system and is also
known as the primary domain.
● I/O domain – An I/O domain has direct ownership of and direct
access to physical I/O devices connected to the PCI bus, such as
local network interfaces and disk drives, and devices connected to
PCI adapters. It is normally a prerequisite role for a service domain.
● Service domain – A service domain provides virtual services, such as
virtual disk drives, virtual network switches, and virtual console
services to guest domains. The service and I/O roles are typically
configured on the same domain.

● Guest domain – A guest domain runs an operating system instance

without performing any of the above roles, but leverages the services
provided by a service domain in order to run applications and user
services.
Workload

Control I/O Service Guest
Domain Domain Domain Domain
System
Controller Logical Device Device
Domains Client
Driver Server
Manager
Hypervisor
Physical Resourses
(CPUs, LANs, Storage, Network)
Figure 1-2 Logical Domains With Individual Roles
Here is a summary of the logical domain roles:

● If a domain runs the Logical Domains Manager, then it is the control
domain.
● If a domain has access to a physical device, then it is an I/O domain.
● If a domain provides virtual device services, then it is a service
domain.
● If a domain uses only virtual devices, then it is a guest domain.

A domain can also have multiple roles. For example, the initial domain
(the “primary” domain) usually has the role of control, I/O, and service
domains (see Figure 1-3).
Workload

Control I/O Service Guest
Domain Domain Domain Domain
System
Controller Logical Device Device
Domains Client
Driver Server
Manager
Hypervisor
Physical Resourses
(CPUs, LANs, Storage, Network)
Figure 1-3 Logical Domains With Multiple Roles
Although control, I/O, and service functions can be combined within a

domain, it is recommended that additional user applications not run
within the control or service domain in order to protect domain stability
and performance. This is also recommended for security reasons to
prevent other domains from being compromised.
Now that you have a better understanding of what the Logical Domains
product is, how it is positioned in Sun Microsystems virtualization
technologies, and how it utilizes server virtualization technology, let’s
look at the key architectural components that enable you to create and
configure a Logical Domains environment.

Logical Domains Architecture

The key architectural components that make up Logical Domains include:
● Hypervisor
● Logical Domains Manager
● Logical domain channels
● OpenBoot environment

● Operating system
● Physical and virtual devices
In the sections that follow, you are introduced to each of these

components and the functions they serve within the Logical Domains
architecture.

The Hypervisor
The hypervisor is a firmware layer on the Flash PROM of the server
motherboard, which partitions a physical system into one or more virtual
machines (see Figure 1-4). The SPARC sun4v architecture contains a new
hyper-privileged mode that enables the hypervisor to access and control
all platform devices. In this role, the hypervisor abstracts underlying
hardware and exposes a subset of system resources to each logical
domain. In fact, logical domains can only access platform resources

explicitly made available by the hypervisor.
Control Guest
Domain Domain
User/Services Logical Application

Domains Application
Manager
Application
Kernel Solaris 10 8/07 or later Solaris 10 8/07 or later
Firmware Hypervisor
CPU, Memory,
Hardware
& I/O
Figure 1-4 The Hypervisor

Logical Domains Manager

The Logical Domains Manager software communicates with the
hypervisor and logical domains to sequence changes, such as the removal
of resources or creation of a logical domain (see Figure 1-5). The Logical
Domains Manager, which resides on the control domain, provides an
administrative interface and keeps track of the mapping between the
physical and virtual devices in a system. Only one Logical Domains
Manager can run on a server.

Control Domain Guest Domain
Solaris 10 Solaris 10
CLI
App App
LDoms Manager App App
LDOM LDOM
Controller Sequencer
Nexus Virtual Virtual

Driver Device Service Device Driver
DB
Hypervisor Virtual Nexus I/F Logical Domain Channel
Hardware
Resources
Figure 1-5 Logical Domains Manager

Logical Domain Channel

A logical domain channel (LDC) is a point-to-point, full-duplex link
created by the hypervisor. Within the Logical Domains architecture, an
LDC provides a data path between virtual device services and guest
domains and establishes virtual networks between logical domains (see
Figure 1-6). A unique LDC is explicitly created for each link, ensuring
data transfer isolation. Each logical domain, virtual I/O device, and
network device needs an LDC. With assistance from the hypervisor, data

is transferred across an LDC as a simple 64-byte datagram or by using
shared memory. With the shared memory approach the data is stored in
memory and multiple domains have access to the same memory location.
This is done so that you do not need multiple copies of the same data in
physical memory. The hypervisor controls access.
Control Domain Guest Domain Guest Domain
Virtual Virtual Virtual

Device Device Device
Services Driver Driver
Hypervisor
Physical Resources
Figure 1-6 Logical Domain Channel
For the Sun UltraSPARC T2-based platforms, the maximum number of

LDCs available in any logical domain is 512, and for the UltraSPARC-T2
Plus-based platforms the maximum number of LDCs is 768. This limit is
more relevant on the control domain, because the control domain has at
least part, if not all, of the I/O subsystem allocated to it, and because of
the potentially large number of LDCs created for both virtual I/O data
communications and the Logical Domains Manager’s control of the other
logical domains.

The OpenBoot™ PROM Environment

The OpenBoot PROM environment forms the basis for initial program
loading and execution, typically for an operating system (see Figure 1-7).
It also provides other features, such as diagnostics and boot-time
parameters, to control operation. The OpenBoot ok prompt is the first
thing you see when connecting to the console of a newly created logical
domain, and a familiar sight for those experienced in using Sun’s SPARC
hardware.

Virtual OpenBoot
Console {0}ok
Service
Hypervisor
Physical Resources
I/O Devices
Figure 1-7 Guest Domain OpenBoot Environment
In the Logical Domains software, the OpenBoot PROM environment is

partitioned for each guest domain. The OpenBoot PROM interacts with
the hypervisor on startup. It is removed after the Solaris OS is started.
Each logical domain runs its own OpenBoot environment.
When you boot the logical domain, the OBP passes its current device tree
(both real and virtual devices) to the Solaris OS kernel. At that point the
/etc/path_to_inst file is built or updated. It contains the mapping
between how the OBP represents things and how the Solaris OS
represents them.
Note – Each domain runs the same version of the OpenBoot PROM.

The Operating System

Control, service, I/O, and guest domains must contain operating systems
that understand both the sun4v platform and the virtual devices
presented by the hypervisor. Currently, for Logical Domains 1.3 this is at
least the Solaris 10 8/07 operating system with required patches for the
supported servers (see Figure 1-8).
Control/Service/IO Guest

Domain Domain
User/Services Logical Application

Domains Application
Manager
Application
Operating System Solaris 10 8/07 or later Solaris 10 8/07 or later
Firmware Hypervisor
CPU, Memory,
Hardware
& I/O
Figure 1-8 The Operating System Physical and Virtual Devices
Note – To have all the Logical Domains 1.3 features, you need to run the
Solaris 10 10/09 OS.

Physical and Virtual Devices

With Logical Domains, I/O domains will have direct access to physical
I/O devices, such as disk drives or network interfaces. These physical
devices can then be virtualized using virtual device services and made
available as virtual devices to guest domains. This allows physical devices
to be shared among multiple domains, thereby providing additional
consolidation benefits by rationalization of storage and network (and the
reduction in the administrative burden involved) (see Figure 1-9).

Service Guest
Domain Domain
Solaris 10 Solaris 10
App
Device Driver
Virtual Virtual
Nexus Driver
Device Device
Service Driver
Hypervisor Virtual I/F Logical Domain Channel
Shared CPU, I/O MMU

Memory, I/O Bridge
& I/O PCI-Express
A B
Figure 1-9 Virtual Devices
Now that you are familiar with the Logical Domains architecture, let’s
look at the steps involved in planning for your Logical Domains
environment.

Logical Domains Planning

Before you proceed with creating a Logical Domains environment, you
must first have a plan. Your plan should include configuration details,
such as the number of logical domains you need, the types and amount of
resources each domain will have, the properties of your network setup,
and so on. You also need to consider how to boot an OS for the guest
domains, and finally, if you are virtualizing devices, how to virtualize
devices in terms of your I/O and service domain setup.

The following are key tasks that should be part of your planning
activities:
● Identify design goals (for example, plan for high availability).
● Gather system hardware and software configuration information.
● Identify installation tasks.
● Identify configuration tasks.
● Identify administrative and maintenance tasks.
● Identify implementation resources.
Planning for your Logical Domains implementation will help you

uncover and resolve potential issues before they occur, thereby reducing
your chances of encountering problems with your new Logical Domains
environment either before, during, or after implementation.
Identifying Design Goals

Knowing what end state your environment must have to support your
design goals and system requirements is a key factor in achieving a
successful implementation. You will save both time and resources by
taking time up front to document what the end state should be.

For example, let’s assume our primary design goal is to plan for high
availability. With this goal in mind, we might configure our new Logical
Domains production environment to look something like the example
shown in Figure 1-10.
Secondary Service LDom Guest LDom Primary Service LDom
Virtual Virtual Disk Virtual Disk Virtual

Switch 2 Server 2 Server 1 Switch 1

IPMP
Physical Physical Physical Physical
Network Disk Disk Network
vNet vNet
Driver Driver vDisk Driver Driver
2 1
Virtual SAN 2 Virtual SAN 1
Virtual LAN 2 Virtual LAN 1
Hypervisor
I/O Bridge (Leaf B) I/O Bridge (Leaf A)
NIC NIC
Storage
Figure 1-10 Logical Domains Production Environment Example
As you can see, we are planning for high availability by having two
service domains. Each service domain provides access to the same storage
and to the same network. The guest domain uses multipathing to access
the storage and the network through either of the service domains. That
way if a service domain is not available, the guest domain still has access
to the storage and the network through the other service domain.
The number of logical domains you create per server is based on two
factors:
● The purpose of the logical domain (what applications you intend to
run).
● Available resources in the underlying system.

Gather System Hardware and Software Configuration

Information
After you have identified your design goals and know what your end
state configuration is going to look like, the next task is to gather system
hardware and software configuration information and requirements.
Note – In this class you will be installing and configuring Logical

Domains 1.3 software on a Sun SPARC Enterprise T5140 server. Keep this
in mind as you review the system requirements and domain and memory
sizing guidelines presented in this section.
System Requirements
The purpose of the system requirements gathering task is to answer such

questions as “What are the supported platforms for the version of the
Logical Domains Manager software that you are planning to install?” and
“What software and patches are required to use all the features of the
Logical Domains software you want to run?” When you complete this
task, your plan should contain the following information:
● Supported platforms for the Logical Domains Manager software you
are running
● Required and recommended Solaris OS versions
● Required Solaris 10 patches
● Required software to enable any new Logical Domains features
● Minimum version of software required
● Required system firmware patches
● Location of the Logical Domains software
● Location of the patches
● Location of any supporting documentation
The Release Notes contain all of this information. It is a good practice to

always read the Release Notes for the latest system requirements.
Discussion – Take a moment to review the Release Notes for Logical

Domains 1.3 software provided in the files installed on your workstation
! for this class. You will need this information for the first lab activity.
?

Note – For additional information about the hardware platforms that can
run Logical Domains and their capabilities, see Section 1 - Hardware of
the LDoms Community Cookbook
(http://wikis.sun.com/display/SolarisLogicalDomains/Section+1+%28N
EW%29+-+Hardware).
During the logical domains configuration process, you map physical

system devices to virtual devices and then bind the virtual devices to the

domains. To map the devices correctly, you must have a good
understanding of how the devices are configured on the underlying
platform. Once you have identified the platform you will be using, take
the time to familiarize yourself with the device pathing requirements for
that system and include this information in your plan.
Discussion – Take a moment to study the device locations on the rear and
front panels of the Sun SPARC Enterprise T5140 server in the figures that
! follow. You will need this information for the first lab activity. Also,
?
review the device pathing information that is provided for the T5140.
Sun SPARC Enterprise T5140 Server Example
The Sun SPARC Enterprise T5140 Server begins the next wave of high-
efficiency systems based on the second generation of Sun's Chip Multi-
threaded Technology (CMT). The Sun SPARC Enterprise T5140 server
utilizes multiple UltraSPARC-T2 Plus processors. Because the system has
multiple chips, it uses cache coherency protocols via connections between
the chips to manage the sharing of data. Figure 1-11 and Figure 1-12 show
the location of devices accessed from the front and rear panels.
Locator LED/
Locator Button
Service Action
Required LED DVD Drive Disk Drive Map
Power/OK LED
Power HDD0 HDD1 HDD2 HDD3 Power Supply Service LED
Button Disk Drives Disk Drives System Overtemperature LED
Fan Module Service LED
Figure 1-11 Sun SPARC Enterprise T5140 Server Device Locations Front
Panel

Power Supply Rear

0 1 Panel LEDs
PCIe/XAUI 0 PCIe/XAUI 1 PCIe 2
Power Serial Network 0 12 3 0 1 Serial Port

Supply LEDs Mgmt Port Mgmt Port Gigabit USB Ports
Ethernet Ports

Figure 1-12 Sun SPARC Enterprise T5140 Server Device Locations Rear
Panel
Table 1-1 provides the device and slot mapping for the T5140 (1U) and
T5240 (2U) systems.
Table 1-1 T5140/T5240 PCI-E Device/Slot Map
Device Name Device Path
PCI-E to PCI-E Switches (PLX8548) /pci@400/pci@0/ (switch 0)

/pci@500/pci@0/ (switch 1)
PCI-E Gigabit Ethernet Adapter /pci@500/pci@0/pci@8/network@0 (net0)
(Neptune)
/pci@500/pci@0/pci@8/network@0,1 (net1)
10 Gigabit Ethernet Option /pci@500/pci@0/pci@8/network@0 (XAUI)
/pci@500/pci@0/pci@8/network@0,1 (XAUI)
Internal SAS Disk 0 /pci@400/pci@0/pci@8/scsi@0/sd@0,0

CD/DVD /pci@400/pci@0/pci@1/pci@0/usb@0,2/storage@
2/disk@0:f

Table 1-1 T5140/T5240 PCI-E Device/Slot Map
Device Name Device Path
PCI-E Slots PCIE Slot 0: /pci@500/pci@0/pci@9 (1U & 2U)

PCIE Slot 1: /pci@400/pci@0/pci@c (1U & 2U)
PCIE Slot 2: /pci@400/pci@0/pci@9 (1U & 2U)
PCIE Slot 3: /pci@400/pci@0/pci@d (2U only)

PCIE Slot 4: /pci@500/pci@0/pci@d (2U only)
PCIE Slot 5: /pci@500/pci@0/pci@c (2U only)
The T5140/T5240 have all Ethernet ports on pci@500 and all the hard
disks are located at pci@400. Both the T5140 and T5240 systems can be
configured with two I/O domains, with the on-board network interfaces
connected to one I/O domain and the internal disks connected to the
other.
Note – For device path information for other Sun platforms, see
Solaris[TM] Operating System: Matrix of Recognized Device Paths
(http://sunsolve.sun.com/search/document.do?assetkey=1-61-208209-1).

Domain Sizing Guidelines
Another important piece of information you will need as part of planning

is the number of virtual CPUs you can assign to each domain. With Chip
Multithreaded (CMT) systems, each of the cores of the system contain
multiple processing strands. The strands in a core work as a team to
switch through the workloads, one each cycle, so it is important to keep
the strands together. This approach is particularly effective for workloads
that have many threads and where performance is impacted to a
significant degree by memory latency. Figure 1-13 illustrates the Chip

Multithreading execution model for a single core in a Sun SPARC
Enterprise T5140 server with an UltraSPARC T2+ processor.
UltraSPARC T2-Plus Systems CMT Processor (Single core shown)
Thread 8
C M C M C M
Thread 7 C M C M C M
Time
Single Threaded Processor
Time
C Compute Time
M Cache/Memory Latency
Figure 1-13 Chip Multithreaded Execution Model
In a CMT system, the impact of memory latency can be reduced by

switching to other processing strands to perform useful work while
waiting for memory. From a Logical Domains Manager perspective, each
of the threads in a system appear to be virtual CPUs, and, as such, can be
allocated independently to any domain in the system.

Running threads from the same core in separate domains can lead to
unpredictable and poor performance. For that reason, when creating a
domain with eight virtual CPUs, ensure that the virtual CPUs come from
the same core to provide the best performance. Because the Logical
Domains Manager adds from the lowest virtual CPU and removes from
highest, in terms of the CPU ID, it is possible to create several domains in
a way that can break the core/thread affinity model.
Following are guidelines for determining the number of CPUs/cores to

assign to domains.

The number of CPUs required for each domain mostly depends on
applications and workload running on that domain. However, a best
practice is to assign entire CPU cores to domains. So the minimum
guideline is to assign a minimum of one CPU core to each domain.
Note – Depending on the CPU chip and system type, the number of CPU
threads per CPU core can be different. See the Sun SPARC Enterprise
Server table in the LDom Community Cookbook, Section 1, System
Overview for a listing of number of cores and threads by system
(http://wikis.sun.com/display/SolarisLogicalDomains/Section+1+%28N
EW%29+-+Hardware).
● A service domain will provide virtual device services to other

domains, and it will have to process any virtual I/O (such as virtual
disk or virtual network requests) for domains it is servicing. As such
it is more likely to have a more important workload, especially if
applications running in other domains are very I/O intensive. The
guideline in that case is to assign a minimum of two CPU cores to a
service domain.
● An I/O domain requires a minimum of one CPU core. However, if an
I/O domain is also used as a service domain, the CPU requirement
for a service domain has to be applied (that is, a minimum of two
CPU cores). Also, if an I/O domain has a lot of I/O devices, the
number of CPUs might have to be increased to better handle the I/O
requests (for example, an I/O domain with a lot of 10-Gbit Ethernet
interfaces can have a lot of network interrupts to process and require
more CPUs).
● The control domain is an I/O domain, and it does not have any
additional CPU requirement. So the number of CPUs required also
depends on the application and workload use, with a minimum of

one CPU core. But, similarly, if the control domain is used as a

service domain, then an additional CPU is required (that is, a
minimum of two CPU cores).
It is also recommended to have a cryptographic unit (also referred to
as a Modular Arithmetic Unit or MAU) for each CPU core assigned
to the control domain. This is useful for migration purposes.
The number of virtual CPUs assigned to a domain can be changed after

the domain has been created. Virtual CPUs can be dynamically added or

removed from a domain without having to stop, restart, or interrupt the
domain. You might want to provision additional CPUs so that you can
add more CPUs to a domain later if, for example, that domain has a more
important workload.
Memory Sizing Guidelines
As part of your planning you will also want to determine the amount of
memory required for each domain. Logical Domains software does not
impose a minimum memory size limitation when creating a domain. The
memory size requirement is a characteristic of the guest operating system.
For recommended and minimum size memory requirements, refer to the
installation guide for the operating system you are using.
You will want to keep the following information in mind when

determining the amount of memory required for each domain:
● The amount of memory the operating system requires
● Applications running in the logical domain will have their own
minimum memory size requirements.
Following are guidelines for determining the amount of memory required

for each domain.
The amount of memory required for each domain mostly depends on

applications and workload running on that domain. The Solaris
Operating System requires a minimum of 1 Gbyte of memory. So that will
be the minimum amount of memory to assign to one domain.
● A service domain will provide virtual device services to other
domains, and it will have to process any virtual I/O (such as virtual
disk or virtual network requests) for domains it is servicing. As such
it is more likely to have a more important workload, especially if

applications running in other domains are very I/O intense. The

guideline in that case is to assign a minimum of 2 Gbytes of memory
to a service domain.
● An I/O domain does not have any special memory requirement, so
the amount of memory required depends on the application and
workload use, with a minimum of 1 Gbyte of memory for running
the Solaris OS. However, if an I/O domain is also used as a service
domain, then the memory requirement for a service domain has to
be applied (that is, a minimum of 2 Gbytes of memory).

● The control domain is an I/O domain, and it does not have any
additional memory requirement. So the amount of memory required
also depends on the application and workload use, with a minimum
of 1 Gbyte of memory for running the Solaris OS. But, similarly, if
the control domain is used as a service domain, then the memory
requirement for a service domain has to be applied (that is, a
minimum of 2 Gbytes of memory).
The amount of memory assigned to a domain can be changed after the

domain has been created. However, the Logical Domains software does
not currently support dynamic reconfiguration of memory, so changing
the amount of memory assigned to an active domain requires that domain
to be restarted for the change to take effect.
Sizing Guidelines Summary
Table 1-2 presents the minimum guidelines to size a domain depending

on its role. If a domain assumes several roles (for example, a control
domain that is also an I/O domain and a service domain), then the most
restrictive guideline should be selected.
Table 1-2 Sizing Guidelines
Domain Role Memory CPUs
Control domain 1GB* 1 core*

I/O domain 1GB* 1 core*
Service domain 2GB 2 cores
Guest domain 1GB 1 core
(*) If the domain is also a service domain, the guideline for the service
domain has to be selected.

Additional Configuration Planning Considerations
Additional Applications in the Control and Service Domains
When upgrading an existing system to provide Logical Domains

functionality, pre-existing applications might be present in the newly
established control domain. Running these applications within the newly
established control domain might not be desirable for several reasons.
First, a lot of resources can be required to handle virtual I/Os, and we do

not want to have to compete with other applications for resources.
Second, extra applications create attack vectors for someone attempting to
compromise the server. Keep in mind that if someone can gain access to
the root account on the control domain, that individual has access to not
only the control domain but to all of the other domains as well.
Supported Network Adapters
In a Logical Domains environment the virtual switch service, running in a

service domain, can directly interact with network adapters that comply
with Generic LAN Driver version 3 (GLDv3).
Though non-GLDv3 compliant network adapters can be used in these

systems, the virtual switch cannot interface with them directly.
To determine if a network adapter is GLDv3-compliant:

1. Use the Solaris OS dladm(1M) command, where, for example, nxge0
is the network device name.
# dladm show-link nxge0
nxge0 type: non-vlan mtu: 1500 device: nxge0
2. Look at type: in the output.
● GLDv3-compliant drivers will have a type of non-vlan or
vlan.
● Non-GLDv3-compliant drivers will have a type of legacy.

Range of MAC Addresses Assigned to Logical Domains

Software
Logical domains have been assigned the following block of 512K MAC
addresses:
00:14:4F:F8:00:00 ~ 00:14:4F:FF:FF:FF

The lower 256K addresses are used by the Logical Domains Manager for
automatic MAC address allocation, and you cannot manually request an
address in this range:
00:14:4F:F8:00:00 - 00:14:4F:FB:FF:FF
You can use the upper half of this range for manual MAC address
allocation:
00:14:4F:FC:00:00 - 00:14:4F:FF:FF:FF
When you do not specify a MAC address when you create a logical
domain or a network device, the Logical Domains Manager automatically
allocates and assigns a MAC address to that logical domain or network
device.
Identify Installation Tasks

After you have gathered all your system hardware and software
configuration information and requirements, you will want to identify
your installation tasks. For Logical Domains these tasks would include the
following:
● Verifying the correct build of the Solaris OS
● Checking the system firmware
● Installing the Logical Domains Manager
● Ensuring security on the Logical Domains system is enabled

As part of this planning step you will want to gather as much information
as possible as to what actions are required to complete each task. A good
practice is to read through the appropriate sections of the Logical
Domains Administration Guide and make note of any considerations that
might impact your plan.
In Module 2 of this course you are given the opportunity to complete each
of the installation tasks using the Logical Domains 1.3 software and a
T5140 server.

Identify Configuration Tasks
After you have identified the installation tasks you will need to complete
as part of your Logical Domains implementation, you will need to
identify your configuration tasks. These tasks are based on the design
goals you have set. At a minimum you should plan to complete the
following tasks:
● Configure the control and service domain, which includes:
● Configuring the control domain’s resources
● Enabling virtual services
● Saving the configuration to the system controller
● Enabling networking between the control/service domain and
other domains
● Enabling the virtual network terminal server daemon
● Create guest domains, which includes:
● Creating and starting a guest domain
● Installing the Solaris OS on a guest domain using JumpStart
● Verifying the guest domain configuration
As part of this planning step you will want to ensure that your
configuration tasks are complete and fully support your design
requirements. Review the configuration sections of the Logical Domains
Administration Guide and make note of any considerations that might
impact your design or plan.
In modules 3 and 4 of this course you are given the opportunity to

complete each of the configuration tasks in the previous lists using the
Logical Domains 1.3 product and a T5140 server.

Identify Administrative and Maintenance Tasks

The on-going administrative and maintenance tasks you identify as part
of your Logical Domains planning will be based on your company’s
policies and specific needs and requirements. At a minimum your plan
should identify what the tasks are and the frequency with which they
should be performed.
In modules 5 and 6 of this course you are introduced to a number of

administrative tasks associated with Logical Domains. You are given the
opportunity to perform a number of these tasks in the lab exercise that
follows Module 6.
Identify Implementation Resources

The final step in the planning process is to identify the resources you will
need to implement your plan. Depending on the size and complexity of
the environment in which you are working, you will need to consider the
following:
● Time required to install and configure the Logical Domains system
● Resources needed to perform the installation and configuration
● Impact to applications running on the Logical Domains server
(downtime)
● Scheduled day and time to perform and test the implementation
● Communication to management on scheduled implementation
● Resources required to sustain environment (that is, resources
required to perform on-going administrative and maintenance tasks)
Once you have completed your plan and have had it approved by
management, you are ready to implement your design. You will find that
having spent the time up front in planning your approach will make the
implementation and maintenance of your new Logical Domains
environment go more smoothly.

Notes:

Module 2
Installing Logical Domains Software

Objectives
This module describes how to install the different software components
required to enable the Logical Domains (LDoms) 1.3 software on a new
system.

● Verify the correct build of the Solaris OS.
● Check the system firmware.
● Install the Logical Domains Manager software.
● Identify Logical Domains security features.
2-1
The following references provide additional information about the topics

● Logical Domains 1.3 Release Notes, Part No: 821-0404-10

● Logical Domains 1.3 Reference Manual, Part No: 821-0405-10

Introduction
Introduction
After you have completed your Logical Domains planning and have a
good idea of what you want your Logical Domains environment to look
like, the next step is to install the different software components required
to install and enable the Logical Domains (LDoms) software on your
system. In this module you will be shown how to enable the LDoms 1.3
software on a T5140 server. You will then be given the opportunity to
apply what you have learned by completing a lab exercise.

Note – Logical Domains 1.3 is not supported on T1 systems (T1 systems
have been end-of-lifed). However, older versions of the Logical Domains
product can still be run on T1 systems (up to Logical Domains 1.2).
Before we get started, there are a few things you need to know. Using the
LDoms software requires the following components:
● Supported server running an operating system at least equivalent to
the Solaris 10 10/09 OS with any patches recommended in
“Required Software and Patches” in the Logical Domains 1.3 Release
Notes.
● System firmware Version 7.2.4 at a minimum for your Sun
UltraSPARC T2 or T2 Plus platform; however, Version 7.2.7 is
recommended.
● Logical Domains 1.3 software installed and enabled on the server.
The Solaris OS and the system firmware must be installed or upgraded on

your server before you install the Logical Domains Manager software.
The UltraSPARC T2 and UltraSPARC T2 Plus come pre-installed with the

appropriate firmware and software for using LDoms. Therefore, LDoms
can be used out of the box. You only need to update the firmware or the
software when you want to update to the latest version of LDoms. For
information about how to upgrade the LDoms software components, see
the “Installing and Enabling Software” chapter in the Logical Domains 1.3
Administration Guide.
Installing Logical Domains Software 2-3

Introduction
Initially, a Sun platform that supports the Logical Domains software

appears as a single system hosting only one operating system. After the
Solaris OS, system firmware, and Logical Domains Manager software
have been installed, the original system and instance of the Solaris OS
become the control domain. That first domain on the platform is named
primary. You cannot change that name or destroy that domain. From
there, the platform can be reconfigured to have multiple domains hosting
different instances of the Solaris OS.

Verifying the Correct Build of the Solaris OS
Verifying the Correct Build of the Solaris OS

The first task associated with installing the Logical Domains software on a
new system is to verify that you have the correct version of the Solaris OS
that supports the Logical Domains Manager and advanced features like
dynamic reconfiguration. As you discovered during your software
information and requirements gathering, you must have the Solaris 10
10/09 OS (or the equivalent patch level) with any patches recommended
to run Logical Domains 1.3 on your system.

To check the release of the Solaris OS present on your system, run the
following command:
# cat /etc/release
If you need to upgrade your system to the Solaris 10 OS required for the
1.3 version of the Logical Domains software, refer to “Required Software
and Patches” in Logical Domains 1.3 Release Notes. The Release Notes will
also list any required and recommended patches.
You can use any normal process of installation for the server, including
JumpStart, network, DVD or CD, or upgrading from a previous version.
Select the Entire Distribution for a regular installation or SUNWCall for a
JumpStart installation.
Note – For complete instructions for upgrading the Solaris OS, refer to the
Solaris 10 10/09 Release and Installation Collection
(http://docs.sun.com/app/docs/coll/1236.11).

Checking the System Firmware

After you have verified that you have the correct build of the Solaris OS,
the next thing you want to do is to check that you have the right version
of the system firmware. During planning, you should have noted what
version of the firmware you needed by checking the “Required System
Firmware Patches” section in Logical Domains 1.3 Release Notes.
Once you know what version of the firmware you need, you can check to

see what version you have on your system using one of the following
approaches:
● Enter the following command on the Integrated Lights Out Manager
(ILOM):
-> show /HOST
● Enter the following command on the Advanced Lights Out Manager
(ALOM):
sc> showhost
Note – Servers now use the ILOM service processor, which has
commands different from the ALOM system controller. However, the
ILOM has an ALOM compatibility mode so you can still use the ALOM
commands which remain unchanged.
If you don’t have the right version, you will need to upgrade the system
firmware. In this section you are shown two ways to upgrade the system
firmware:
● From the operating system
● From a local TFTP server using system controller commands
Note – Another approach to checking and upgrading the system firmware

is to launch a browser and connect to the Sun Integrated Lights Out
Manager WebGUI. In the lab exercise at the end of this module you will
have the opportunity to use this approach.
You can find system firmware for your platform at the SunSolvesm site
(http://sunsolve.sun.com).

Upgrading System Firmware From the Operating System
To upgrade the system firmware from the operating system, perform the
following steps:
1. In the system console window, access the system controller.
2. From the system controller, open a console session on the system.
Using ILOM:
-> start /SP/console

Using ALOM:
sc> console -f
3. Log in to the operating system as root.
Console Window: root
Password:
...
4. Navigate to the /opt/ses/firmware directory.
# cd /opt/ses/firmware
5. Copy the firmware package 139444-07.zip to the /var/tmp
directory and unzip the file.
# cp 139444-07.zip /var/tmp
# cd /var/tmp
# unzip 139444-07.zip
6. Change to the 139444-07 directory.
# cd 139444-07
# ls
Note – The Sun_System_Firmware-7_2_7_b-

SPARC_Enterprise_T5140+T5240.pkg file contains the system controller
firmware.
7. Run the sysfwdownload -u command to download and update the

system controller firmware.
# ./sysfwdownload -u Sun_System_Firmware-7_2_7_b-
SPARC_Enterprise_T5140+T5240.pkg
WARNING: Host will be powered down for automatic
firmware update when download is completed.
Do you want to continue(yes/no)? yes

The -u option automatically performs these tasks:

● Downloads the system firmware image
● Powers down the host
● Updates the system firmware
● Resets the system controller
● Powers the host back on

Note – The system controller takes a few minutes to complete the
firmware update operation.
Upgrading System Firmware With a TFTP Server
The steps for upgrading the system firmware with a TFTP server are as
follows:
1. Shut down and power off the host server operating system.
# shutdown -i0 -g0 -y
2. Use the #. escape sequence to return to the system controller.
3. Power down the system.
Using ILOM:
-> cd /SYS
-> stop /SYS
Do you want to stop SYS (y/n)? y
Using ALOM:
sc> poweroff -fy
4. Upgrade the system firmware, depending on your server.
Refer to your platform documentation for information about how to
update your firmware.
Sample ILOM command:
-> load -source tftp://IP-address/Firmware_File
Sample ALOM command:
sc> flashupdate -s IP-address -f path/Firmware_File

Where:
● IP-address is the IP address of your TFTP server.
● path is the location in SunSolve or your own directory where
you can obtain the system firmware image.
5. Reset the service processor.
Using ILOM:
-> cd /SP
-> reset

Using ALOM:
sc> resetsc -y
6. Log back in to the system controller.
7. Power on the system.
Using ILOM:
-> cd /SYS
-> start /SYS
Using ALOM:
sc> poweron -c

Installing the Logical Domains Manager Software Packages

Packages
After you have checked the system firmware, the next task is to install the
Logical Domains Manager software packages. To complete this task, you
will need to do the following:
● Download the Logical Domains Manager software package.
● Install the Logical Domains Manager software packages.

● Ensure the Logical Domains Manager daemon is enabled.
● Ensure security on the Logical Domains system is enabled.
Let’s look at how to perform each of these procedures.
Downloading the Logical Domains Manager Software

Package
The steps for downloading the Logical Domains Manager software
package are as follows:
1. Download the zip file (LDoms_Manager-1_3.zip) from the Sun
Software Download site.
You can find the software at
http://www.sun.com/servers/coolthreads/ldoms/index.jsp.
2. Unzip the zip file.
$ unzip LDoms_Manager-1_3.zip
The Logical Domains Manager 1.3 software includes the SUNWldm
and SUNWldmp2v packages.
See “Location of LDoms 1.3 Software” in Logical Domains 1.3 Release
Notes for details about the structure of the file and what it includes.


Packages
After you have downloaded the Logical Domains Manager software
package, you can install the software. There are two methods of installing
the Logical Domains Manager software that we will focus on in this
course:
● Using the installation script to install the packages and patches. This

automatically installs the Logical Domains Manager software.
● Installing the package manually.
Let’s take a look at each method.
Installing the Logical Domains Manager Software Using the

Installation Script
If you use the install-ldm installation script, you have several choices
to specify how you want the script to run. Each choice is described in the
procedures that follow.
● Using the install-ldm script with no options does the following
automatically:
● Checks that the Solaris OS release is Solaris 10 10/09 OS at a
minimum
● Verifies that the package subdirectories SUNWldm/ and
SUNWldmp2v/ are present
● Verifies that the prerequisite Solaris Logical Domains driver
packages, SUNWldomr and SUNWldomu, are present
● Verifies that the SUNWldm and SUNWldmp2v packages have not
been installed
● Installs the Logical Domains Manager 1.3 software
● Verifies that all packages are installed
● If the Solaris Security Toolkit (SUNWjass) is already installed,
you are prompted to harden the Solaris OS on the control
domain.
● Determine whether to use the Logical Domains Configuration
Assistant (ldmconfig) to perform the installation.

Note – For information about the Logical Domains Configuration

Assistant, see the description at the end of this procedure.
● Using the install-ldm script with the -c option installs the

software by using the Logical Domains Configuration Assistant.
● Using the install-ldm script with the -s option skips the running
of the Logical Domains Configuration Assistant.

Logical Domains Configuration Assistant
The Logical Domains Configuration Assistant leads you through the

configuration of a logical domain by setting basic properties. It can be
used to configure any system where the Logical Domains software is
installed but not already configured.
After gathering the configuration data, the Configuration Assistant creates

a configuration that is suitable for booting as a logical domain. You can
also use the default values selected by the Configuration Assistant to
create a usable system configuration.
The Configuration Assistant is available as both a graphical user interface

(GUI) and terminal-based tool.
For more information, see Appendix D, “Logical Domains Configuration

Assistant,” in the Logical Domains 1.3 Administration Guide and the
ldmconfig(1M) man page.

Manually
This procedure assumes you have downloaded the Logical Domains

Manager 1.3 software, the SUNWldm and SUNWldmp2v packages, from the
Sun Software Download site.
The steps for installing the Logical Domains Manager software packages
manually are as follows:
1. Use the pkgadd command to install the SUNWldm.v and SUNWldmp2v
packages.
For more information about the pkgadd command, see the
pkgadd(1M) man page.

The -G option installs the package in the global zone only and the -d
option specifies the path to the directory that contains the SUNWldm.v
and SUNWldmp2v packages.
# pkgadd -Gd . SUNWldm.v SUNWldmp2v
Note – Installation of the SUNWldmp2v package is optional. This package is

not required for using LDoms, it is only needed to use the LDoms P2V
tool.

2. Answer y for yes to all questions in the interactive prompts.
3. Use the pkginfo command to verify that the Logical Domains
Manager 1.3 packages, SUNWldm and SUNWldmp2v, are installed.
For more information about the pkginfo command, see the
pkginfo(1) man page.
The revision (REV) information shown below is an example.
# pkginfo -l SUNWldm | grep VERSION
VERSION=1.3,REV=2009.12.03.10.20
Ensuring the Logical Domains Manager Daemon is

Enabled
The install-ldm installation script automatically enables the Logical
Domains Manager daemon (ldmd). The ldmd daemon is also
automatically enabled when the SUNWldm package is installed. When
enabled, you can create, modify, and control the logical domains.
If the ldmd daemon has been disabled, you can use the following
procedure to enable it.
1. Use the svcadm command to enable the Logical Domains Manager
daemon, ldmd.
# svcadm enable ldmd
For more information about the svcadm command, see the
svcadm(1M) man page.
2. Use the ldm list command to verify that the Logical Domains
Manager is running.
# ldm list
NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME
primary active ---c- SP 64 3264M 0.3% 19d 9m

The ldm list command should list all domains that are currently
defined on the system. In particular, the primary domain should be
listed and be in the active state. The sample output presented in step
2 shows that only the primary domain is defined on the system.
Ensuring Security on a Logical Domains System is

Enabled

The Logical Domains Manager has two levels of authorization that are
enabled during installation:
● Read – Allows you to view, but not modify the configuration.
● Read and write – Allows you to view and change the configuration.
By default, the root user has read and write authorization while all other
users have read-only authorization.
Following are the Logical Domains entries automatically added to the

Solaris OS /etc/security/auth_attr file:
● solaris.ldoms.:::LDom administration::
● solaris.ldoms.grant:::Delegate LDom configuration::
● solaris.ldoms.read:::View LDom configuration::
● solaris.ldoms.write:::Manage LDom configuration::
You can set up authorization and profiles and assign roles for user
accounts using the Solaris OS Role-Based Access Control (RBAC) adapted
for the Logical Domains Manager. For more information about RBAC,
refer to the Solaris 10 System Administrator Collection
(http://docs.sun.com/app/docs/coll/47.16)
To find out more about how to add authorization for additional users and
manage user profiles on your Logical Domains system as well as how to
enable other security features, see the “Security” chapter in the Logical
Domains 1.3 Administration Guide.

The Logical Domains Manager ldm Command

The Logical Domains Manager uses a command-line interface (CLI) to
create, configure, and manage logical domains. The CLI is a single
command, ldm, that has multiple subcommands.
The general syntax for the ldm command is:
ldm [--help] subcommand [options] [properties] operands

Where:
● --help displays command details
● subcommand specifies the action to be performed
● options are used to modify the subcommand operation
● properties are used to tailor the characteristics of the target
specified by the operand
● operands identify the target of the command.
Note – For a complete listing of the ldm command subcommands, see the
ldm(1M) man page.
The Logical Domains Manager daemon, ldmd, must be running to use the
Logical Domains Manager CLI.
Discussion – Your instructor will now take a few minutes to introduce

you to the ldm command and familiarize you with some of the more
! common subcommands using the command usage statement output that
?
follows. The instructor will also explain the use of aliases and shortcuts.
primary# ldm
Usage:
ldm [--help] command [options] [properties] operands
ldm -V
Options:
-V Display version information

Command(s) for each resource (aliases in parens):
bindings
list-bindings [-e] [-p] [<ldom>...]
services
list-services [-e] [-p] [<ldom>...]
constraints
list-constraints ([-x] | [-e] [-p]) [<ldom>...]

devices
list-devices [-a] [-p] [cpu] [crypto|mau] [memory] [io]
domain ( dom )
add-domain (-i <file> | [mac-addr=<num>] [hostid=<num>]
[failure-policy=<ignore|stop|reset|panic>]
[master=<master_ldom1,...,master_ldom4>] <ldom>...)
set-domain (-i <file> | [mac-addr=<num>] [hostid=<num>]
[failure-policy=<ignore|stop|reset|panic>]
[master=<master_ldom1,...,master_ldom4>] <ldom>)
remove-domain (-a | <ldom>...)
list-domain [-e] [-l] [-o <format>] [-p] [<ldom>...]
’format’ is one or more of:
console,cpu,crypto,disk,domain,memory,network,physio,
resmgmt,serial,status
start-domain (-a | -i <file> | <ldom>...)
stop-domain [-f] (-a | <ldom>...)
bind-domain (-i <file> | <ldom>)
unbind-domain <ldom>
panic-domain <ldom>
migrate-domain [-n] [-p <password_file>] <source_ldom>
[<user>@]<target_host>[:<target_ldom>]
io
add-io [bypass=on] <bus> <ldom>
remove-io <bus> <ldom>
crypto ( mau )
add-crypto <number> <ldom>
set-crypto <number> <ldom>
remove-crypto <number> <ldom>

memory ( mem )
add-memory <number>[GMK] <ldom>
set-memory <number>[GMK] <ldom>
remove-memory <number>[GMK] <ldom>
operation
cancel-operation (migration | reconf) <ldom>
policy
add-policy [enable=yes|no] [priority=<value>]

[attack=<value>] [decay=<value>] [elastic-margin=<value>]
[sample-rate=<value>] [tod-begin=<hh>:<mm>[:<ss>]]
[tod-end=<hh>:<mm>[:<ss>]] [util-lower=<percent>]
[util-upper=<percent>] [vcpu-min=<value>]
[vcpu-max=<value>] name=<policy-name> <ldom>...
set-policy [enable=[yes|no]] [priority=[<value>]
[attack=[<value>]] [decay=[<value>]] [elastic-
margin=[<value>]]
[sample-rate=[<value>]] [tod-begin=[<hh>:<mm>:<ss>]]
[tod-end=[<hh>:<mm>:<ss>]] [util-lower=[<percent>]]
[util-upper=[<percent>]] [vcpu-min=[<value>]]
[vcpu-max=[<value>]] name=<policy-name> <ldom>...
remove-policy [name=]<policy-name>... <ldom>
reconf
cancel-reconf <ldom>
spconfig ( config )
add-spconfig [-r <autosave>] <config_name>
set-spconfig <config_name>
remove-spconfig [-r] <config_name>
list-spconfig [-r [<autosave>]]
variable ( var )
add-variable <var_name>=<value>... <ldom>
set-variable <var_name>=<value>... <ldom>
remove-variable <var_name>... <ldom>
list-variable [<var_name>...] <ldom>
vconscon ( vcc )
add-vconscon port-range=<x>-<y> <vcc_name> <ldom>
set-vconscon port-range=<x>-<y> <vcc_name>
remove-vconscon [-f] <vcc_name>

vconsole ( vcons )
set-vconsole [port=[<port-num>]] [group=<group>]
[service=<vcc_server>] <ldom>
vcpu
add-vcpu <number> <ldom>
set-vcpu <number> <ldom>
remove-vcpu <number> <ldom>
vdisk

add-vdisk [timeout=<seconds>] [id=<diskid>]
<disk_name> <volume_name>@<service_name> <ldom>
set-vdisk [timeout=<seconds>]
[volume=<volume_name>@<service_name>] <disk_name> <ldom>
remove-vdisk [-f] <disk_name> <ldom>
vdiskserver ( vds )
add-vdiskserver <service_name> <ldom>
remove-vdiskserver [-f] <service_name>
vdpcc ( ndpsldcc )
add-vdpcc <vdpcc_name> <service_name> <ldom>
remove-vdpcc [-f] <vdpcc_name> <ldom>
vdpcs ( ndpsldcs )
add-vdpcs <vdpcs_name> <ldom>
remove-vdpcs [-f] <vdpcs_name>
vdiskserverdevice ( vdsdev )
add-vdiskserverdevice [-f] [options={ro,slice,excl}]
[mpgroup=<mpgroup>] <backend> <volume_name>@<service_name>
set-vdiskserverdevice [-f] [options=[{ro,slice,excl}]]
[mpgroup=[<mpgroup>]]
<volume_name>@<service_name>
remove-vdiskserverdevice [-f] <volume_name>@<service_name>
vnet
add-vnet [mac-addr=<num>] [mode=hybrid] [pvid=<pvid>]
[vid=<vid1,vid2,...>] [mtu=<mtu>] [linkprop=phys-state]
[id=<networkid>] <if_name> <vswitch_name> <ldom>
set-vnet [mac-addr=<num>] [mode=[hybrid]] [pvid=[<pvid>]]
[vid=[<vid1,vid2,...>]] [mtu=[<mtu>]] [linkprop=[phys-
state]]
[vswitch=<vswitch_name>] <if_name> <ldom>
remove-vnet [-f] <if_name> <ldom>

vswitch ( vsw )
add-vswitch [default-vlan-id=<vid>] [pvid=<pvid>]
[vid=<vid1,vid2,...>]
[mac-addr=<num>] [net-dev=<device>] [linkprop=phys-state]
[mode=<mode>] [mtu=<mtu>] [id=<switchid>] <vswitch_name>
<ldom>
set-vswitch [pvid=[<pvid>]] [vid=[<vid1,vid2,...>]] [mac-
addr=<num>]
[net-dev=[<device>]] [mode=[<mode>]] [mtu=[<mtu>]]
[linkprop=[phys-state]] <vswitch_name>

remove-vswitch [-f] <vswitch_name>
Verb aliases:
Alias Verb
----- -------
rm remove
ls list
Command aliases:
Alias Command
----- -------
cancel-op cancel-operation
create add-domain
modify set-domain
destroy remove-domain
remove-reconf cancel-reconf
start start-domain
stop stop-domain
bind bind-domain
unbind unbind-domain
panic panic-domain
migrate migrate-domain
#
Note – You can also find the ldm command and subcommand information
in the Logical Domains 1.3 Reference Manual located in the files installed on
your workstation for this class.

Applying What You Have Learned – Lab Exercise

Now that you know how to install the Logical Domains software and are
familiar with the ldm command, try applying what you have learned in
the lab exercise that follows.
In this exercise, you will perform the following tasks:

● Gather system hardware and software configuration information.

● Upgrade the system controller firmware.
● Install operating system patches.
● Install the Logical Domains Management software.

Preparation
During this exercise you work with lab equipment located in Sun’s
Remote Lab Data Center (RLDC). The RLDC is remote from your present
location. To successfully complete the following tasks, you should
familiarize yourself with the RLDC lab topology. Figure 2-1 shows the
major components that make up the lab topology.
Figure 2-1 Course SA-345-S10 Lab Topology

Table 2-1 shows the IP addresses assigned to the RLDC lab host machine’s
system controller (SC) network management (net mgmt) port, the SC
login credentials, and the server login credentials. Note that the IP
address subnet assignment varies based on the lab to which you are
assigned. Please contact your instructor for IP address information.
Table 2-1 Host Machine’s System Controller IP Address Assignments
Sun SPARC Server

SC Login OS Login
Enterprise SC IP Address Host
Credentials Credentials

T5140 Name
Machine1 192.168.XX.10 root/cangetin host01 root/cangetin

Before You Begin
Before you begin Task 1, complete the following lab configuration

information. See your instructor if you need help.
Your assigned host machine:

● Host machine assignment: machine # _____
● Solaris™ login credentials: root/cangetin
● System Controller (SC) IP address _______________
● SC login credentials root/cangetin
Note – Examples shown in this exercise are from lab machine 4.

Depending upon your lab configuration, the responses to the commands
in the labs might vary slightly.
Accessing the Lab Equipment
Before you perform the following tasks, here is an overview on how to

access your lab equipment.

Sun uses the Sun Secure Global Desktop (SGD) to provide you with access
to the remote lab environment. To access the SGD, open the following
path in your Web browser:
http://rldc.sun.net
Click the LOGIN button and enter the user name and password provided
by your instructor. When the Security Warning dialog box appears, click
the Accept button. Figure 2-2 shows a typical SGD session.

Figure 2-2 Sun Secure Global Desktop
The SGD places you on the lab “landing pad” from which you can access
your lab equipment.
The SGD left panel contains tools that allow you to access your lab
systems. The Gnome tools open remote desktops on the landing pad or lab
systems. The Terminal tools open terminal windows on the landing pad or
lab systems. The Console tool opens a remote console on the lab system.
The Administration Console is for shadowing your lab partner.
Caution – While performing the exercises in this course, do not change

the passwords to the system controller or the Solaris 10 operating system.
Changing the passwords will cause the labs to function incorrectly.

Task 1 – Gather System Hardware and Software

Configuration Information
In this task you explore your assigned lab equipment and determine if the
hardware and software meet the requirements necessary for creating
logical domains. Figure 2-3 shows the major components of a host server.
Operating System

System Hypervisor
Controller
Physical Resourses
(CPUs, LANs, Storage)
Figure 2-3 Host Server Major Components
Note – The sample command output shown for the following commands
are from a Sun SPARC Enterprise T5140 server. The server details and
device pathing information might differ based on the server’s system
disks and server architecture of the machine you are using.
Perform the following steps:

1. Log in to your assigned system in the classroom. From the classroom
system, open a network browser and connect to the Sun Secure
Global Desktop URL http://rldc.sun.net.
Enter your assigned SGD login credentials to access the lab.
2. From the SGD session interface, click the landing pad Gnome
application to open a desktop session on the landing pad.
3. Open a terminal window on the desktop on the landing pad.
4. Verify the following file is located in the /opt/ses/firmware
directory on the lab landing pad system:
Sun_System_Firmware-7_2_7-SPARC_Enterprise_T5140+T5240.pkg
The Sun SPARC Enterprise T5140 firmware package.

5. In the landing pad desktop session, open a Web browser and enter
the IP address of the system controller in your assigned lab server to
open the Sun Integrated Lights Out Manager WebGUI.
Log in using the appropriate credentials shown in Table 2-1.
6. Click the System Information tab to determine the following:
Product Name: T5140
System Firmware: Sun System Firmware 7.2.6

Do the server model and firmware release meet the requirements for
creating logical domains? Yes
7. Click the Remote Control tab and Remote Power Control tab. Verify
that the host is currently on. If not, select the Power On action and
click Save. Click the OK button in the confirmation dialog box.

8. Click the Redirection tab and start the remote console.

10. Display the contents of the /etc/release file.
# cat /etc/release
Solaris 10 10/09 s10s_u8wos_08a SPARC
Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 16 September 2009

Does this OS release meet the requirement for installing the Logical
Domains Manager 1.3 software? Yes
11. Run the prtdiag|more command to determine the following
configuration information:
# prtdiag|more
System Configuration: Sun Microsystems sun4v T5140
Memory size: 7968 Megabytes
========================== Virtual CPUs ==============================

CPU ID Frequency Implementation Status
------ --------- ---------------------- -------
0 1165 MHz SUNW,UltraSPARC-T2+ on-line
...
● Platform group: sun4v
● Memory size: 8 GB
● Number of available CPU strands: 64
12. Run the more /etc/path_to_inst command to determine the
system PCI configuration.
# more /etc/path_to_inst
#
# Caution! This file contains critical kernel state
#
"/iscsi" 0 "iscsi"
"/pseudo" 0 "pseudo"
"/scsi_vhci" 0 "scsi_vhci"
"/options" 0 "options"
"/ramdisk-root" 0 "ramdisk"
"/virtual-devices@100" 0 "vnex"
"/virtual-devices@100/channel-devices@200" 0 "cnex"
"/virtual-devices@100/channel-devices@200/virtual-channel@3" 0 "vldc"
"/virtual-devices@100/channel-devices@200/virtual-channel-client@2" 1 "vldc"

"/virtual-devices@100/channel-devices@200/virtual-channel@0" 2 "vldc"
"/virtual-devices@100/channel-devices@200/virtual-channel-client@1" 3 "vldc"
"/virtual-devices@100/console@1" 0 "qcn"
"/virtual-devices@100/ncp@6" 0 "ncp"
"/virtual-devices@100/random-number-generator@e" 0 "n2rng"
"/virtual-devices@100/n2cp@7" 0 "n2cp"
"/pci@400" 0 "px"
"/pci@400/pci@0" 0 "pxb_plx"
"/pci@400/pci@0/pci@1" 1 "pxb_plx"
"/pci@400/pci@0/pci@1/pci@0" 0 "px_pci"

"/pci@400/pci@0/pci@1/pci@0/usb@0,2" 0 "ehci"
"/pci@400/pci@0/pci@1/pci@0/usb@0,2/storage@2" 1 "scsa2usb"
"/pci@400/pci@0/pci@1/pci@0/usb@0,2/storage@2/disk@0,0" 2 "sd"
"/pci@400/pci@0/pci@1/pci@0/usb@0,2/hub@4" 0 "hubd"
"/pci@400/pci@0/pci@1/pci@0/usb@0" 0 "ohci"
"/pci@400/pci@0/pci@1/pci@0/usb@0,1" 1 "ohci"
"/pci@400/pci@0/pci@8/scsi@0" 0 "mpt"
"/pci@400/pci@0/pci@8/scsi@0/sd@0,0" 0 "sd"
"/pci@400/pci@0/pci@c" 4 "pxb_plx"
"/pci@400/pci@0/pci@c/network@0" 0 "e1000g"
"/pci@400/pci@0/pci@c/network@0,1" 1 "e1000g"
"/pci@400/pci@0/pci@d" 5 "pxb_plx"
"/pci@500" 1 "px"
"/pci@500/pci@0" 6 "pxb_plx"
"/pci@500/pci@0/pci@8/network@0" 0 "nxge"
"/pci@500/pci@0/pci@8/network@0,1" 1 "nxge"
"/pci@500/pci@0/pci@c" 9 "pxb_plx"
"/pci@500/pci@0/pci@d" 10 "pxb_plx"
"/ebus@c0" 0 "ebus"
"/ebus@c0/serial@0,ca0000" 0 "su"
"/pci-performance-counters@400" 0 "n2piupc"
"/pci-performance-counters@500" 1 "n2piupc"
#
How many PCI buses are configured in the system? Two PCI buses,
pci@400 and pci@500.
PCI bus 400 configuration:
How many of the disk drives reside on PCI bus 400? Three
How many network interfaces reside on PCI bus 400? Two
Which network interfaces reside on PCI bus 400? e1000g0, e1000g1

PCI bus 500 configuration:

How many of the disk drives reside on PCI bus 500? None
How many network interfaces reside on PCI bus 500? Four
Which network interfaces reside on PCI bus 500? nxge0, nxge1,
nxge2, nxge3
13. Run the format command to determine the disk drives available on
your lab system.
# format

Searching for disks...done
c1t2d0: configured with capacity of 279.38GB
AVAILABLE DISK SELECTIONS:

0. c1t0d0 <SUN300G cyl 46873 alt 2 hd 20 sec 625>
/pci@400/pci@0/pci@8/scsi@0/sd@0,0
Specify disk (enter its number):^D
14. Use the dladm show-link command to verify the network devices
are compliant with logical domain requirements.
# dladm show-link
e1000g0 type: non-vlan mtu: 1500 device: e1000g0
e1000g1 type: non-vlan mtu: 1500 device: e1000g1
If the network interface is non-vlan or vlan, the interface meets logical
domain requirements. If the network interface is legacy, the interface is
not compliant. In this example, all network interfaces are compliant.
15. Use the dladm show-dev command to determine which network
devices are currently up.
# dladm show-dev
e1000g0 link: unknown speed: 0 Mbps duplex: half
e1000g1 link: unknown speed: 0 Mbps duplex: half
nxge0 link: up speed: 100 Mbps duplex: full
nxge1 link: up speed: 100 Mbps duplex: full
nxge2 link: down speed: 0 Mbps duplex: unknown
nxge3 link: down speed: 0 Mbps duplex: unknown

Note – At this point, you have gathered the configuration information

required to complete the remaining tasks in this exercise. This information
will be required in later exercises.
Task 2 – Upgrade the System Controller Firmware

In this task you upgrade the system controller firmware on your assigned

lab equipment. Upgrading the system controller firmware can be
performed by three methods:
● Load the firmware from a remote host using the Sun Integrated
Lights Out Manager WebGUI
● Load the firmware from a local TFTP server using system controller
commands
● Load the firmware from the operating system
In this task, you can choose to either upgrade the system controller
firmware from the “landing pad” system using the Sun Integrated Lights
Out Manager WebGUI (see “Loading Firmware Using the Sun Integrated
Lights Out Manager WebGUI” on page 29) or load the firmware from the
operating system (see “Loading Firmware From the Operating System”
on page 32).
Loading Firmware Using the Sun Integrated Lights Out Manager

WebGUI
If you wish to load the system controller firmware using the Sun
Integrated Lights Out Manager WebGUI, perform the following steps:
Note – These steps are specific to the Sun SPARC Enterprise T5140 server,
which is used as an example in this exercise. To see the patch
requirements and installation instructions for other servers, please read
the README file associated with the patch file of your server and follow
the instructions given.
1. Verify that you have the landing pad Web browser open to the Sun
Integrated Lights Out Manager WebGUI. If not, open a browser
session at this time.
If the Redirection (Sun ILOM Remote Console) window is open, click
the Redirection pull down menu and select Quit.

2. In the Sun Integrated Lights Out Manager WebGUI, click the Remote
Control tab and Remote Power Control tab. Select the Graceful
Shutdown and Power Off action and click Save. Click the OK button
in the confirmation dialog box.

3. Click the Keyswitch tab and verify that the keyswitch is in the
Normal position.
4. Click the Maintenance tab and from the Firmware Upgrade tab select
Enter Upgrade Mode. Click the OK button in the confirmation dialog
box.


5. Browse to the location of the firmware package file. For this lab, the
location is /opt/ses/firmware. Select the version 7.2.7 firmware
package for T5140 systems and click Upload.
6. Verify that the Preserve Configuration option is selected and click

Start Upgrade. Click the OK button in the confirmation dialog box.
7. After the firmware upgrade is complete, click the Reconnect link.

Note – At the end of the firmware upgrade process, the system controller
is reset. It might take a few minutes before you can access Sun Integrated
Lights Out Manager WebGUI.
8. After the system has reconnected, log back in to the Sun Integrated
Lights Out Manager WebGUI.
9. Click the Remote Control tab and Remote Power Control tab. Power
the system on.

10. Verify that the system firmware is now at a version appropriate for
running LDoms 1.3 software by navigating to the System
Information tab, Overview tab.
11. Log out of the Sun Integrated Lights Out Manager WebGUI and
close the Web browser.
Loading Firmware From the Operating System
In this task you download the system controller firmware from the
operating system (on the local host) to the system controller memory and
install it. This procedure requires that you use the system controller
ALOM command set.

On systems that run ILOM, you can switch to ALOM compatibility mode
by running these commands on the system controller:
-> cd /SP/users/SC_User_Name
-> set cli_mode=alom
The next time you log in to the system controller, you will be able to run
ALOM commands.
If you wish to load the firmware from the operating system on the local

host, perform these steps:
1. In the system console window, access the system controller.
If you are at the system controller prompt, log in as alom with the
password cangetin.
If you are at the operating system or OpenBoot prompt, enter the #.
escape sequence. Run the exit command to log out of the system
controller. Log in as alom with the password cangetin.
Note that the alom account used in this lab was created for training
purposes only. This account has the ALOM compatibility mode
already set.
2. From the system controller, open a console session on the system.
sc> console -f
Console Window: root
Password: cangetin
...
4. Navigate to the /opt/ses/firmware directory.
# cd /opt/ses/firmware
5. Copy the firmware package 139444-07.zip to the /var/tmp
directory and unzip the file.
# cp 139444-07.zip /var/tmp
# cd /var/tmp
# unzip 139444-07.zip
6. Change to the 139444-07 directory.
# cd 139444-07
# ls
copyright
Install.info
Legal
LEGAL_LICENSE.TXT

README.139444-07
Sun_System_Firmware-7_2_7_b-SPARC_Enterprise_T5140+T5240.pkg
sysfw720_README_docs.css
sysfw720_README_docs.html
sysfwdownload
sysfwdownload.README
TPM-Feature-README.txt
Note that the Sun_System_Firmware-7_2_7_b-
SPARC_Enterprise_T5140+T5240.pkg file contains the system

controller firmware.
7. Run the sysfwdownload -u command to download and update the
system controller firmware.
The -u option automatically performs these tasks:
● Downloads the system firmware image
● Powers down the host
● Updates the system firmware
● Resets the system controller
Powers the host back on
●
# ./sysfwdownload -u Sun_System_Firmware-7_2_7_b-
SPARC_Enterprise_T5140+T5240.pkg
WARNING: Host will be powered down for automatic firmware update when
download is completed.
Do you want to continue(yes/no)? yes
.......... (6%).......... (12%).......... (19%).......... (25%)..........

(32%).......... (38%).......... (45%).......... (51%)..........
(58%).......... (64%).......... (71%).......... (77%)..........
(83%).......... (90%).......... (96%)..... (100%)
Download completed successfully.
# Feb 25 16:03:40 ldom01 unix: WARNING: Power-off requested, system will

now shutdown.
Shutdown started. Thursday, February 25, 2010 4:03:40 PM MST
Changing to init state 5 - please wait

Broadcast Message from root (msglog) on ldom01 Thu Feb 25 16:03:43...
THE SYSTEM ldom01 IS BEING SHUT DOWN NOW ! ! !
Log off now or risk your files being damaged

svc.startd: The system is coming down. Please wait.

svc.startd: 128 system services are now being stopped.
Feb 25 16:03:58 ldom01 syslogd: going down on signal 15
svc.startd: The system is down.
syncing file systems... done
8. Use the #. escape sequence to return to the system controller.
Note that the system controller takes a few minutes to complete the
firmware update operation.

9. When the system controller prompt is available, log back in as root
with the password cangetin.
Task 3 – Install the Logical Domains Management

Software
In this task you install the Logical Domains Manager 1.3 software on the
Sun SPARC Enterprise server. Before you begin this task, you must first
have successfully completed tasks 1 and 2 in this exercise.

1. On the SGD desktop, click the console link for your assigned server.
If you see the SC -> prompt, start the SC serial console to access the
Solaris OS. For example:
When you see the Solaris OS login prompt, log in as root.
console login: root
Password: cangetin
...
If a prompt does not appear, try entering the #. sequence to enter the
system controller. Then run the start /SP/console command to open a
console session on the system.
2. Copy the LDoms_Manager-1_3.zip archive located in the
/opt/ses/software directory to the /var/tmp directory. Unzip the
LDoms_Manager-1_3.zip file.
# pwd
/var/tmp
# cp /opt/ses/software/LDoms_Manager-1_3.zip .
# unzip LDoms_Manager-1_3.zip
Archive: LDoms_Manager-1_3.zip
creating: LDoms_Manager-1_3/

creating: LDoms_Manager-1_3/Install/
inflating: LDoms_Manager-1_3/Install/install-ldm
creating: LDoms_Manager-1_3/Legal/
inflating: LDoms_Manager-1_3/Legal/CDDL.LICENSE
inflating: LDoms_Manager-1_3/Legal/Ldoms_MIB_1.0.1_Entitlement.txt
inflating: LDoms_Manager-1_3/Legal/Ldoms_MIB_1.0.1_SLA_Entitlement.txt
...
# ls -d LDoms_Manager-1_3*
LDoms_Manager-1_3 LDoms_Manager-1_3.zip

3. Change to the LDoms_Manager-1_3/Install directory and run the
install-ldm installation script to install the Logical Domains
Manager 1.3 software.
# cd LDoms_Manager-1_3/Install
# ./install-ldm
Welcome to the LDoms installer.
You are about to install the Logical Domains Manager package that will
enable you to create, destroy and control other domains on your system.
You will also be given the option of running the LDoms Configuration
Assistant (ldmconfig) to setup the control domain and create guest
domains.
If the Sun Security Toolkit (SST) is installed, you will be prompted to

optionally harden your control domain.
Installing LDoms packages.

pkgadd -n -d "/var/tmp/LDoms_Manager-1_3/Product" -a pkg_admin SUNWldm.v
Copyright 2010 Sun Microsystems, Inc. All rights reserved.
...
Installation of <SUNWldm> was successful.

pkgadd -n -d "/var/tmp/LDoms_Manager-1_3/Product" -a pkg_admin SUNWldmp2v
Use is subject to license terms.
...
Installation of <SUNWldmp2v> was successful.
LOGICAL DOMAINS CONFIGURATION
Once installed, you may configure your system for a basic Logical
Domains deployment. If you select "y" for the following question, the
Logical Domains Configuration Assistant will be launched following a
successful installation of packages.

(You may launch the LDoms Configuration Assistant at a later time with
the command /usr/sbin/ldmconfig, or use the GUI Configuration Assistant
which is bundled in the LDoms zip file - see README.GUI for more
details)
Select an option for configuration:
y) Yes, launch the LDoms Configuration Assistant after install

n) No thanks, I will configure LDoms myself later

Enter y or n [y]: n
The Logical Domains Configuration Assistant is delivered as part of the

Logical Domains zip bundle.
In this exercise, you will not be using the Logical Domains Configuration
Assistant. You will configure logical domains using the command-line.
Note – The installation script loads the Logical Domains Manager

commands in the /usr/sbin directory.
4. Verify that the logical domains daemon (ldmd) has been

automatically started.
# svcs -l ldmd
fmri svc:/ldoms/ldmd:default
name Logical Domains Manager
enabled true
state online
next_state none
state_time January 11, 2010 2:21:01 PM MST
logfile /var/svc/log/ldoms-ldmd:default.log
restarter svc:/system/svc/restarter:default
contract_id 43
dependency require_all/none svc:/system/filesystem/local (online)
The state should be “online”.
Note that the install-ldm installation script automatically enables the
Logical Domains Manager daemon (ldmd). When enabled, you can create,
modify, and control the logical domains.

5. Verify the Logical Domains Management utility is operational by

running the ldm list-domain command. Also, verify that the ldm
man page can be viewed.
primary# ldm list-domain
primary active -n-c-- SP 64 7968M 0.1% 5m
primary# man ldm
Reformatting page. Please Wait... done
...

Lab Exercise Summary
Discussion – Take a few minutes to discuss the experiences, issues, or

discoveries you had during the lab exercise.
!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Module 3
Configuring the Control and Service Domain

Objectives
This module describes how to configure the control domain.

● Configure the control domain.
● Configure the control domain as a service domain by adding virtual
services.
● Save a configuration to the service controller.
● Enable networking between the control/service domain and other
domains.
● Enable the virtual network terminal server daemon.
3-1
The following reference provides additional information about the topics


Introduction
Introduction
After you have installed the Logical Domains software, your next task is
to create and configure the logical domains that will constitute your
Logical Domains environment.
In this module you will be shown how to configure the control domain
(specifically the control domain’s resources) and then how to configure
the control domain as a service domain. After you have been shown how

to configure the control and service domain, you will be given the
opportunity to apply what you have learned by completing a lab exercise.
Configuring the Control and Service Domain 3-3

Configuring the Control Domain’s Resources

The Logical Domains’ control or primary domain is created as part of the
Logical Domains software installation. Initially, all system resources are
allocated to the control domain. To create other logical domains, you must
release some of these resources. In this section you will be shown how to
assign the following control domain resources (see Figure 3-1):
● CPUs

● Cryptographic devices (MAUs)
● System memory
Control Domain
Hypervisor
Physical Resources
(CPUs, MAU, Memory, I/O)
Figure 3-1 Control Domain Initial Configuration
By assigning fewer resources to the control domain, you “release” (or

make available) the remaining resources to other logical domains.
The following examples show you how to assign each resource type to the
control domain. You should have determined the allocation of each
resource as part of your Logical Domains planning, so that when you
come to this task, you know exactly how many resources to allocate to the
control domain and why.

Determining How Many Resources are Available

Before you assign resources to the control domain, it is a good practice to
determine how many resources you have available.
To determine how many resources you have available on the control

domain, run the following command:
primary# ldm list-devices -a

Note – The output may differ due to varying hardware configurations.
Review and make note of how many of each resource you have,
specifically virtual CPUs, MAUs, and memory.
In the sections that follow you are shown how to set the virtual CPUs,
MAUs, and memory for the control domain.
Setting Virtual CPUs for the Control Domain

The first resources you want to set for the control domain are the virtual
CPUs. In the example that follows eight virtual CPUs are assigned to the
control domain, primary. This leaves the remainder of the virtual CPUs
available for other domains.
To set the virtual CPUs for the control domain, run the following
command:
primary# ldm set-vcpu 8 primary

Setting Cryptographic Resources for the Control

Domain
After you have set the virtual CPUs for the control domain, the next task
is to assign the cryptographic resources. The UltraSPARC T2 processor is
equipped with eight cryptographic units or Modular Arithmetic Units
(MAUs). You may recall from Module 1 that the number of MAUs bound
to a domain should not be more than the number of cores assigned to the
domain as part of virtual CPU allocation. The number of MAUs bound to

a domain can, however, be less than the number of cores assigned for that
domain. In the example that follows one cryptographic resource has been
assigned to the control domain, primary. This leaves the remainder of the
cryptographic resources available for other domains.
To assign a cryptographic resource (MAU) to the control domain, run the

following command:
primary# ldm set-mau 1 primary
Note – Adding a MAU to the control domain is useful because having this
resource can speed up warm migration by taking advantage of the
cryptographic unit when transferring data (transfer is done using
encryption). You will learn more about warm migration in Module 6.
Setting Memory for the Control Domain

After you have assigned the cryptographic resources to the control
domain, the next task is to set memory for the control domain. In the
example that follows two gigabytes of memory are assigned to the control
domain, primary. This leaves the remainder of the memory available for
other domains.
primary# ldm set-memory 2G primary

Verifying the Resources Assigned to the Control

Domain
After you have completed all your resource assignments, it is a good
practice to verify that the resources have been assigned correctly.
To verify that the resources have been assigned correctly to the control
domain, run the following command:

primary# ldm list-constraints primary

Adding Virtual Services

You may recall from Module 1 that a control domain can also serve as a
service domain. In this section you will be shown how to configure the
control domain as a service domain.
The control domain is configured as a service domain by enabling the

following virtual services:

● vdiskserver – Virtual disk server
● vswitch – Virtual switch service
● vconscon – Virtual console concentrator service
You must enable these virtual services initially to be able to use them later.
Note – You can add more than one disk or switch service if desired.
To enable a virtual service, you add it to the domain. In the sections that
follow you will be shown how to add each of the virtual services.

Adding a Virtual Disk Server

The virtual disk server (vdiskserver or vds) enables domains to access
block level storage that is not directly connected to them through a client-
server model. It consists of two components: a virtual disk client (vdc)
running in the guest domain and a virtual disk server (vds) running in the
service domain. The virtual disk server processes disk requests on behalf
of the virtual disk client and submits them to the physical storage residing
on the service / I/O domain (see Figure 3-2). Although the virtual disks

appear as regular disks on the client domain, disk operations are
forwarded to the physical disk through the virtual disk service.
Logical Domain 1 Logical Domain 2 Logical Domain 3 Service Domain

App App App V-Disk
App App App App App App Server V-Disk
App App App Server
V-Disk V-Disk V-Disk Device

Driver Driver Driver Device
Driver
Driver
Virtual SAN 2
Virtual SAN 1
Hypervisor
I/O Bridge
Storage
Devices
Figure 3-2 Virtual Disk Server
To allow configuring virtual disks into a logical domain, you must add a
virtual disk server (vds). In the example that follows a virtual disk server
(primary-vds0) is being added to the control domain (primary), which
will also serve as a service domain.
To add a virtual disk server, enter the following command:

primary# ldm add-vdiskserver primary-vds0 primary
Note – The alias for vdiskserver is vds.

Adding a Virtual Switch Service

The virtual switch service (vswitch or vsw) enables networking between
virtual network (vnet) devices in domains. This service is implemented
using two components: the virtual network (vnet) device and the virtual
network switch (vsw) device. The vnet device emulates an Ethernet
device and communicates with other virtual network devices in the
system using a point-to-point channel.

The vsw device mainly functions as a multiplexor of all the virtual
network’s incoming and outgoing packets. The vsw device can interface
directly with a physical network adapter in an I/O domain. The virtual
switch device sends and receives packets on a virtual network’s behalf
(see Figure 3-3). The vsw device also functions as a simple layer-2 switch
and switches packets between the vnet devices connected to it within the
system. Guest domains can share the same virtual switch to access the
network.
Logical Domain 1 Logical Domain 2 Logical Domain 3 Service Domain

App App App V-Ether
App App App App App App Switch V-Ether
App App App Switch
V-Ether V-Ether V-Ether

Driver Driver Driver Device
Driver
Virtual LAN 2: 192.168.100/24

Virtual LAN 1: 192.168.200/24
Hypervisor
I/O Bridge
Gb
Ether I/F
Figure 3-3 Virtual Switch Service
In the example that follows a virtual switch service (primary-vsw0)

connected to network adapter nxge0 is being added to the control domain
(primary).
Note – The virtual switch should be connected to a GLDv3-compliant

network adapter if you want the logical domains using that virtual switch
to be able to communicate with a physical network connected to the box.

To add a virtual switch service, enter the following command:

primary# ldm add-vswitch net-dev=nxge0 primary-vsw0 \
primary
Note – The alias for vswitch is vsw.
This command automatically allocates a MAC address to the virtual

switch. You can specify your own MAC address as an option to the ldm

add-vsw command. However, in that case, it is your responsibility to
ensure that the MAC address specified does not conflict with an already
existing MAC address.
Adding a Virtual Console Concentrator Service

The virtual console concentrator service (vconscon or vcc) functions as a
concentrator for all logical domains’ console traffic. It interfaces with the
virtual network terminal server daemon (vntsd) and exports access to
each console through a UNIX socket.
With a virtual console service, console I/O from all domains, except the
primary domain, is redirected to a service domain running the virtual
console concentrator (vcc) service and virtual network terminal server
daemon (vntsd), instead of to the systems controller.
In the example that follows a virtual console concentrator service

(primary-vcc0) with a port range from 5000 to 5100 is being added to the
control domain (primary).
To add a virtual console concentrator service, enter the following

command:
primary# ldm add-vconscon port-range=5000-5100 \
primary-vcc0 primary
Note – The alias for vconscon is vcc.
To provide access to the virtual console of each logical domain, you must
enable the virtual network terminal server daemon (vntsd). You are
shown how to complete this task in the “Enabling the Virtual Network
Terminal Server Daemon” section of this module.

Verifying the Virtual Services Have Been Created

After you have added each of the virtual services, you should verify the
services have been created.
To verify the services have been created, run the following command:
primary# ldm list-services primary
VCC
NAME LDOM PORT-RANGE

primary-vcc0 primary 5000-5100
VSW
NAME LDOM MAC NET-DEV ID DEVICE LINKPROP DEFAULT-VLAN-ID PVID VID MTU MODE
primary-vsw0 primary 00:14:4f:fb:79:88 nxge0 0 switch@0 1 1 1500
VDS
NAME LDOM VOLUME OPTIONS MPGROUP DEVICE
primary-vds0 primary
At this point the control domain is configured as a service domain. Before

the new configuration can take effect, you must save it to the system
controller and reboot the operating system.

Saving the Configuration to the System Controller
Saving the Configuration to the System Controller

After you have allocated the control domain resources and have
configured the control domain as a service domain by enabling the virtual
services, you need to save the configuration to the system controller.
To save the configuration, run the following command:

primary# ldm add-spconfig config_initial

This configuration contains the information used to set up the control
domain hardware. The saved configuration will be used during the next
powercycle of the system. However, if you have a single domain running
(as in our example), a reboot of that domain will trigger a powercycle. If
you have multiple domains running, a reboot of a domain will not trigger
a powercycle.

Verifying the Configuration is Ready to be Used at the Next Reboot
Verifying the Configuration is Ready to be Used at the Next

Reboot
After you have saved the configuration, take a moment to verify the
configuration is ready to be used at the next reboot.
To verify the configuration is ready to be used at the next reboot, enter the
following command:

primary# ldm list-spconfig
factory-default [current]
config_initial [next]
primary#
Note – The alias for list-spconfig is list-config.
This list command shows the initial configuration set will be used once
you powercycle.

Rebooting the Control Domain
Rebooting the Control Domain

You must reboot the control domain for the configuration changes to take
effect and for the resources to be released for other logical domains to use.
To reboot the control domain, enter the following command:

primary# shutdown -i6 -g0 -y

Enabling Networking Between the Control/Service Domain and Other Domains
Enabling Networking Between the Control/Service Domain

and Other Domains
By default, networking between the control domain and other domains in
the system is disabled. To enable inter-domain networking, the virtual
switch device (vsw) should be configured as a network device. The virtual
switch can either replace the underlying physical device (nxge0 in this
example) as the primary interface or be configured as an additional
network interface in the domain.

To configure the virtual switch as the primary interface:
1. Print out the addressing information for all interfaces.
primary# ifconfig -a
2. Unplumb the physical network device assigned to the virtual switch
(net-dev).
primary# ifconfig nxge0 unplumb
3. Plumb the virtual switch. In this example, vsw0 is the virtual switch
being configured. vsw0 has to be plumbed to enable networking
between the control domains and other domains connected to that
virtual switch.
primary# ifconfig vsw0 plumb
4. (Optional) To obtain the list of all virtual switch instances in a
domain, you can list them.
primary# dladm show-link | grep vsw
vsw0 type: non-vlan mtu: 1500 device: vsw0
5. To migrate properties of the physical network device (nxge0) to the
virtual switch (vsw0) do one of the following:
● If networking is configured using a static IP address, reuse the
IP address and netmask from nxge0 for vsw0.
primary# ifconfig vsw0 IP_of_nxge0 netmask \
netmask_of_nxge0 broadcast + up
● If networking is configured using DHCP, enable DHCP for
vsw0.
primary# ifconfig vsw0 dhcp start
6. Make the required configuration file modifications to make this
change permanent.
primary# mv /etc/hostname.nxge0 /etc/hostname.vsw0
primary# mv /etc/dhcp.nxge0 /etc/dhcp.vsw0

Enabling Networking Between the Control/Service Domain and Other Domains
Note – If a net-dev is defined, the vsw will be connected with that net-
dev, and packets can be exchanged between that net-dev and other
domains connected to that vsw. Plumbing vsw allows the domain with the
vsw to communicate with other domains connected to that vsw.

Enabling the Virtual Network Terminal Server Daemon
Enabling the Virtual Network Terminal Server Daemon

You must enable the virtual network terminal server daemon (vntsd) to
provide access to the virtual console of each logical domain. Refer to the
vntsd(1M) man page for information about how to use this daemon.
Note – Be sure that you have created the virtual console concentrator
(vcc) service on the control domain before you enable vntsd.

To enable the virtual network terminal server daemon:
1. Use the svcadm(1M) command to enable the virtual network
terminal server daemon, vntsd(1M).
primary# svcadm enable vntsd
2. Use the svcs(1) command to verify that the vntsd daemon is
enabled. The state should be online.
primary# svcs -l vntsd
fmri svc:/ldoms/vntsd:default
name virtual network terminal server
enabled true
state online
next_state none
state_time January 19, 2010 9:01:39 AM MST
logfile /var/svc/log/ldoms-vntsd:default.log
restarter svc:/system/svc/restarter:default
contract_id 121
dependency optional_all/error svc:/milestone/network
(online)
dependency optional_all/none svc:/system/system-log
(online)


Now that you know how to assign the control domain resources and
configure the control domain as a service domain by adding the virtual
services, try applying what you have learned in the lab exercise that
follows.

● Set up the control domain hardware resources.
● Create virtual services.
● Configure the virtual switch as a network interface.
● Enable the virtual network terminal server.
Preparation
To prepare for this lab exercise:
● Review the Preparation section in the previous lab.
● Review the hardware and software configuration information you
gathered in Task 1 of the previous lab.
● When performing this exercise, use the following system login
Control domain operating system:
● Login name root
● Login password cangetin
Note – Examples shown in this exercise are from lab machine 4. The
command responses shown in this lab are examples only. Depending
upon your lab configuration, the responses to the commands in the labs
might vary slightly.

Note – In the following examples, the IP subnet field is shown as XX in

the IP addresses. Replace XX with the subnet of the system you are
working on. You can use ifconfig -a to determine the subnet address.
Note – In the examples shown in this lab, commands run on the primary
domain are indicated by the primary# prompt. The primary domain is
the domain in which the Logical Domains Manager software is running.

Task 1 – Set Up the Control Domain
This task is to perform the initial setup of the control (primary) domain.
This involves assigning system resources (Figure 3-4) to be used by the
control domain. The remaining system resources can be used by other
guest domains in the system. Finally, after you configure the control
domain, you save the configuration to the system controller.
In this task you allocate the following resources to the control domain:
● vcpu – The virtual CPUs representing the processor strands of the
server to be used by the control domain.
● mau – The modular arithmetic unit to be used by the control domain.
● memory – The amount of memory to be used by the control domain.
Control Domain
Hypervisor
Physical Resources
(CPUs, MAU, Memory, I/O)
Figure 3-4 Initial Configuration Resource Set

Perform the following steps

1. List all the server resources.
VCPU
PID %FREE PM
0 0 no
1 0 no
2 0 no
3 0 no

4 0 no
5 0 no
6 0 no
7 0 no
8 0 no
9 0 no
10 0 no
11 0 no
12 0 no
13 0 no
14 0 no
15 0 no
16 0 no
17 0 no
18 0 no
19 0 no
20 0 no
21 0 no
22 0 no
23 0 no
24 0 no
25 0 no
26 0 no
27 0 no
28 0 no
29 0 no
30 0 no
31 0 no
64 0 no
65 0 no
66 0 no
67 0 no
68 0 no
69 0 no
70 0 no
71 0 no

72 0 no
73 0 no
74 0 no
75 0 no
76 0 no
77 0 no
78 0 no
79 0 no
80 0 no
81 0 no

82 0 no
83 0 no
84 0 no
85 0 no
86 0 no
87 0 no
88 0 no
89 0 no
90 0 no
91 0 no
92 0 no
93 0 no
94 0 no
95 0 no
MAU
ID CPUSET BOUND
0 (0, 1, 2, 3, 4, 5, 6, 7) primary
1 (8, 9, 10, 11, 12, 13, 14, 15) primary
2 (16, 17, 18, 19, 20, 21, 22, 23) primary
3 (24, 25, 26, 27, 28, 29, 30, 31) primary
4 (64, 65, 66, 67, 68, 69, 70, 71) primary
5 (72, 73, 74, 75, 76, 77, 78, 79) primary
6 (80, 81, 82, 83, 84, 85, 86, 87) primary
7 (88, 89, 90, 91, 92, 93, 94, 95) primary
MEMORY
PA SIZE BOUND
0x0 512K _sys_
0x80000 1536K _sys_
0x200000 94M _sys_
0x6000000 32M _sys_
0x8000000 96M _sys_
0xe000000 7968M primary
IO

DEVICE PSEUDONYM BOUND OPTIONS

pci@400 pci_0 yes
pci@500 pci_1 yes
2. List the resources that are bound to the control domain.
primary# ldm list-bindings primary
primary active -n-c-- SP 64 7968M 0.1% 17h 55m
MAC

00:14:4f:46:3e:4e
HOSTID
0x84463e4e
CONTROL
failure-policy=ignore
DEPENDENCY
master=
VCPU
VID PID UTIL STRAND
0 0 0.6% 100%
1 1 0.1% 100%
2 2 0.0% 100%
3 3 0.0% 100%
4 4 0.0% 100%
5 5 0.0% 100%
6 6 0.0% 100%
7 7 0.0% 100%
8 8 0.0% 100%
9 9 0.0% 100%
10 10 0.0% 100%
11 11 0.0% 100%
12 12 0.0% 100%
13 13 0.0% 100%
14 14 0.0% 100%
15 15 0.0% 100%
16 16 0.0% 100%
17 17 0.0% 100%
18 18 0.0% 100%
19 19 0.0% 100%
20 20 0.0% 100%
21 21 0.0% 100%
22 22 0.0% 100%

23 23 4.1% 100%
24 24 0.0% 100%
25 25 0.0% 100%
26 26 0.0% 100%
27 27 0.5% 100%
28 28 0.0% 100%
29 29 0.0% 100%
30 30 0.0% 100%
31 31 0.0% 100%
64 64 0.0% 100%

65 65 0.0% 100%
66 66 0.0% 100%
67 67 0.0% 100%
68 68 0.0% 100%
69 69 0.0% 100%
70 70 0.0% 100%
71 71 0.0% 100%
72 72 0.0% 100%
73 73 0.0% 100%
74 74 0.1% 100%
75 75 0.0% 100%
76 76 0.0% 100%
77 77 0.0% 100%
78 78 0.0% 100%
79 79 0.0% 100%
80 80 0.0% 100%
81 81 0.0% 100%
82 82 0.0% 100%
83 83 0.0% 100%
84 84 0.0% 100%
85 85 0.0% 100%
86 86 0.0% 100%
87 87 0.0% 100%
88 88 0.0% 100%
89 89 0.0% 100%
90 90 0.0% 100%
91 91 0.0% 100%
92 92 0.0% 100%
93 93 0.0% 100%
94 94 0.0% 100%
95 95 0.0% 100%
MAU
ID CPUSET
0 (0, 1, 2, 3, 4, 5, 6, 7)
1 (8, 9, 10, 11, 12, 13, 14, 15)

2 (16, 17, 18, 19, 20, 21, 22, 23)

3 (24, 25, 26, 27, 28, 29, 30, 31)
4 (64, 65, 66, 67, 68, 69, 70, 71)
5 (72, 73, 74, 75, 76, 77, 78, 79)
6 (80, 81, 82, 83, 84, 85, 86, 87)
7 (88, 89, 90, 91, 92, 93, 94, 95)
MEMORY
RA PA SIZE
0xe000000 0xe000000 7968M

IO
DEVICE PSEUDONYM OPTIONS
pci@400 pci_0
pci@500 pci_1
VCONS
NAME SERVICE PORT
SP
How many virtual CPUs are currently available for creating guest
domains? 0 vCPUs
How much memory is currently available for creating guest
domains?
0 memory
3. Assign one modular arithmetic unit to the primary domain.
primary# ldm set-mau 1 primary
4. Assign eight virtual CPUs to the primary domain.
primary# ldm set-vcpu 8 primary
5. Assign two gigabytes of memory to the primary domain.
Initiating delayed reconfigure operation on LDom primary. All
configuration changes for other LDoms are disabled until the LDom
reboots, at which time the new configuration for LDom primary will also
take effect.
6. Verify the resources assigned to the control domain by running the
ldm list-bindings command.
primary active -ndc-- SP 8 2G 0.1% 17h 57m
MAC
00:14:4f:46:3e:4e

HOSTID
0x84463e4e
CONTROL
DEPENDENCY
master=

VCPU
VID PID UTIL STRAND
0 0 0.2% 100%
1 1 0.1% 100%
2 2 0.1% 100%
3 3 0.1% 100%
4 4 0.1% 100%
5 5 0.2% 100%
6 6 0.2% 100%
7 7 0.1% 100%
MAU
ID CPUSET
0 (0, 1, 2, 3, 4, 5, 6, 7)
MEMORY
RA PA SIZE
0xe000000 0xe000000 2G
IO
pci@400 pci_0
pci@500 pci_1
VCONS
NAME SERVICE PORT
SP
Note that the status flags indicate that the primary domain is now in a
delayed configuration state. The system must be rebooted for the
configuration changes to take effect.
7. Reboot the control domain.
...
You will have to wait a few minutes until the login prompt is available.
8. After the control domain has rebooted, log in as root.
console login: root

Password: cangetin
...
9. Generate a long listing of the primary domain to verify the new
configuration was created correctly.
primary# ldm list-domain -l primary
primary active -n-c-- SP 8 2G 37% 2m
SOFTSTATE
Solaris running

MAC
00:14:4f:46:3e:4e
HOSTID
0x84463e4e
CONTROL
DEPENDENCY
master=
VCPU
VID PID UTIL STRAND
0 0 12% 100%
1 1 25% 100%
2 2 38% 100%
3 3 19% 100%
4 4 35% 100%
5 5 55% 100%
6 6 21% 100%
7 7 6.6% 100%
MAU
ID CPUSET
0 (0, 1, 2, 3, 4, 5, 6, 7)
MEMORY
RA PA SIZE
0xe000000 0xe000000 2G
IO
pci@400 pci_0
pci@500 pci_1
VCONS
NAME SERVICE PORT
SP

Additionally, you can run the psrinfo and prtconf|grep Mem

commands to view the results of your work.
Task 2 – Create Virtual Services

In this task you use the Logical Domains Management utility to create
virtual services to be used by guest domains.

You set up the following (Figure 3-5) virtual services:
● vdiskserver – The virtual disk server
● vswitch – The virtual switch service
● vconscon – The virtual console concentrator service
vswitch vdiskserver vconscon Service Domain
Hypervisor
Network Disk Hardware Resources

Interfaces Storage
Figure 3-5 Logical Domain Virtual Services

1. List the virtual services currently configured on the control domain.
primary# ldm list-services
There should be no services defined at this time.
2. Add a virtual disk service named primary-vds0 to the primary
domain.
primary# ldm add-vdiskserver primary-vds0 primary
vdiskserver is a virtual disk server that allows you to configure virtual
disks into a logical domain. Note that currently no volumes, partitions, or
image files have been bound to disk service primary-vds0.
3. Add a virtual console service named primary-vcc0 with a port
range of 5000 - 5100 to the primary domain.
primary# ldm add-vconscon port-range=5000-5100 primary-vcc0 primary

vconscon is a virtual console concentrator service with a specific range of

TCP ports to assign to each guest domain at the time it is created.
4. Add a virtual network switch service named primary-vsw0 to the
primary domain. Bind this virtual network switch to network
interface nxge0.
primary# ldm add-vswitch net-dev=nxge0 primary-vsw0 primary
vswitch is a virtual network switch that connects the virtual network
devices to the external network and also switches packets between them.

5. List the services to ensure they are configured correctly.
VCC
VSW
VDS
6. List the logical domain configurations currently stored on the system

controller.
factory-default [next poweron]
...
If configurations other than factory-default are listed, use the

ldm remove-spconfig config_name command to remove them at
this time. Do not remove the factory-default configuration.
primary# ldm remove-spconfig config_name
factory-default [next poweron]
7. Save the new configuration to the system controller. Name the
configuration config_initial.
primary# ldm add-spconfig config_initial
8. List the configurations stored on the system controller.

factory-default
config_initial [current]

9. Generate a long listing of the primary domain to verify the new

configuration was created correctly.
primary active -n-cv- SP 8 2G 0.2% 7m
SOFTSTATE
Solaris running
MAC
00:14:4f:46:3e:4e
HOSTID
0x84463e4e

CONTROL
DEPENDENCY
master=
VCPU
VID PID UTIL STRAND
0 0 0.4% 100%
1 1 0.2% 100%
2 2 0.6% 100%
3 3 0.1% 100%
4 4 0.1% 100%
5 5 0.0% 100%
6 6 0.1% 100%
7 7 0.2% 100%
MAU
ID CPUSET
0 (0, 1, 2, 3, 4, 5, 6, 7)
MEMORY
RA PA SIZE
0xe000000 0xe000000 2G
IO
pci@400 pci_0
pci@500 pci_1
VCC
NAME PORT-RANGE
primary-vcc0 5000-5100
VSW
NAME MAC NET-DEV ID DEVICE LINKPROP DEFAULT-VLAN-ID PVID VID MTU MODE
primary-vsw0 00:14:4f:f9:bf:47 nxge0 0 switch@0 1 1 1500
VDS
NAME VOLUME OPTIONS MPGROUP DEVICE
primary-vds0
VCONS
NAME SERVICE PORT
SP
Additionally, you can run the psrinfo and prtconf|grep Mem

command to view the results of your work.

Task 3 – Configure the Virtual Switch as a Primary

Network Interface
A virtual switch can serve as the primary network interface to the control
domain. This task demonstrates how the virtual switch can be configured
as the primary network interface for the control domain.
In this task you configure the virtual switch created in ‘‘Task 2 – Create
Virtual Services’’ on page 3-28 to access the subnet discovered in the

previous task. See Figure 3-6.
vsw0
Service Domain
nxge0
Hypervisor
pci@500/../network@0 Resource
Subnet 192.168.xx.0
Figure 3-6 Virtual Switch Configuration

1. Display the IP addressing information for all network interfaces.
This example uses machine # 4.
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu
8232 index 1
inet 127.0.0.1 netmask ff000000
nxge0: flags=1000803<UP,BROADCAST,MULTICAST,IPv4> mtu 1500 index 7
inet 192.168.XX.104 netmask ffffff00 broadcast 192.168.XX.255
ether 0:15:17:8f:ec:4a

2. Unplumb the current primary network interface (nxge0).

primary# ifconfig nxge0 unplumb
3. Plumb the virtual switch vsw0.
primary# ifconfig vsw0 plumb
4. Manually configure the IP addressing information for the vsw0
network interface. Use the IP address information originally
assigned to the nxge0 interface (see the results from Step 1). Be sure
to set the up flag.

The following example shows network configuration information for
machine 4.
primary# ifconfig vsw0 192.168.XX.104 netmask 255.255.255.0 \
broadcast + up
5. Use the ifconfig -a command to verify the new IP configuration.
8232 index
1
vsw0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 3
ether 0:14:4f:f9:da:3b
6. Use the ping command to verify the vsw0 interface can access the
subnet discovered in the previous step.
primary# ping -s 192.168.XX.255
You should see responses from other systems on the subnet.
7. Rename the /etc/hostname.nxge0 file to /etc/hostname.vsw0 so
that the virtual switch will automatically be configured as the
primary interface after the next OS reboot.
primary# mv /etc/hostname.nxge0 /etc/hostname.vsw0

Task 4 – Enable the Virtual Network Terminal Server

The virtual network terminal server daemon (vntsd) provides access to
the virtual console for each guest domain. By default, this daemon is
disabled.
In this task you enable the vntsd daemon.

1. Run the svcs vntsd command to determine the current state of the
vntsd daemon.
..
state: disabled
...
The state should be “disabled”.
When the vntsd daemon is disabled, you will experience telnet
failures when opening a console session on guest domains. For
example:
# telnet localhost 5000
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection
refused
2. Use the svcadm command to enable the virtual network terminal
server daemon, vntsd.
primary# svcadm enable vntsd
3. Use the svcs command to verify that the vntsd daemon is enabled.
...
state online
...
The state should be “online”.


!
?
● Experiences
● Interpretations
● Conclusions

● Applications

Module 4
Creating a Guest Domain

Objectives
This module describes how to create a guest domain.

● Determine which resources are available to assign to a guest domain.
● Create and start a guest domain.
● Install the Solaris OS on a guest domain using JumpStart.
● Verify a guest domain configuration.
4-1
The following reference provides additional information on the topics


Introduction
Introduction
After you have configured the control and service domain, your next task
is to create the appropriate number of guest domains needed to support
your Logical Domains environment requirements. You may recall from
Module 1 that each guest domain runs an operating system instance and
leverages the services provided by a service domain to run applications
and user services.

In this module you will be shown how to create and start a guest domain.
After you have been shown how to create a guest domain, you will be
given the opportunity to apply what you have learned by completing a
lab exercise.
Creating a Guest Domain 4-3

Creating and Starting a Guest Domain

A guest domain must run an operating system that understands both the
sun4v platform and the virtual devices presented by the hypervisor.
Currently, for Logical Domains 1.3 this means that you must run at least
the Solaris 10 8/07 OS. However, to have all the Logical Domains 1.3
features, you need to run the Solaris 10 10/09 OS.
In this section you are shown how to determine which resources are

available to assign to a guest domain, how to create the domain using the
available resources, and how to start the domain.
Determining Available Resources

Before you create a guest domain, you will need to determine what
resources are available to assign to the domain. To do this, you will need
to look at which domains are currently configured, what devices are being
used by those domains, what services are being used by the service
domain, and what resources are bound to which logical domains.
You can use the following commands to gather this information:

● ldm list-domain – This command shows you which logical
domains are currently configured.
● ldm list-devices – This command shows you the system devices
currently configured in the system. These devices are resources you
assign to logical domains and include CPU threads, MAUs, memory,
and PCI buses.
● ldm list-services – This command shows you the services
currently provided by the service domain.
● ldm list-bindings – This command shows you the resources
bound to the currently configured logical domains.
Once you know what resources are available and how you are going to
assign those resources, you can create the guest domain.

Creating the Guest Domain

The process for creating and starting a guest domain is as follows:
● Add the guest domain.
● Add the CPU and memory resources.
● Add cryptographic resources (optional).
● Add virtual devices.

● Set the auto-boot? and boot-device variables (optional).
● Bind the resources to the guest domain.
● Start the guest domain.
● Connect to the console of the guest domain.
In the example that follows, you are shown how to create and start guest
domain ldom1 using the process presented above.
To create a guest domain and then start it, enter the following commands:
1. Add a guest domain.
primary# ldm add-domain ldom1
Note – The subcommand shortcut for add-domain is create.
2. Add CPUs to the guest domain. For example, to add eight virtual
CPUs to guest domain ldom1, type:
primary# ldm add-vcpu 8 ldom1
3. Add memory to the guest domain. For example, to add two
gigabytes of memory to guest domain ldom1, type:
primary# ldm add-memory 2G ldom1
4. Add a virtual network device to the guest domain. For example, the
following command would add a virtual network device with these
specifics to the guest domain ldom1:
primary# ldm add-vnet vnet0 primary-vsw0 ldom1
● vnet0 is a unique interface name to the logical domain,
assigned to this virtual network device instance for reference on
subsequent set-vnet or remove-vnet subcommands.
● primary-vsw0 is the name of an existing network service
(virtual switch) to which to connect.

Note – You also have the option of setting a specific MAC address for this
virtual network device. You will have the opportunity to do this as part of
the lab exercise at the end of this module.
5. Specify the device to be exported by the virtual disk server as a

virtual disk to the guest domain.
You can export a physical disk, disk slice, volumes, or file as a block
device. The following examples show a physical disk and a file.

● Physical Disk Example. The first example adds a physical disk
with these specifics.
primary# ldm add-vdiskserverdevice \
/dev/dsk/c2t1d0s2 vol0@primary-vds0
Note – Make sure you use slice 2 and not slice 0.
● File Example. This second example is exporting a file as a block

device.
primary# ldm add-vdiskserverdevice \
/var/tmp/backend vol1@primary-vds0
Note – The alias for vdiskserverdevice is vdsdev.
6. Add a virtual disk to the guest domain.

primary# ldm add-vdisk vdisk0 vol0@primary-vds0 ldom1
7. Set the auto-boot? variable for the guest domain. For example, to
set auto-boot? to false, type:
primary# ldm set-variable auto-boot\?=false ldom1
Note – The alias for set-variable is set-var.
Note – You do not need to set a boot-device variable because a guest

domain will boot on the first virtual disk.

8. Bind the resources to the guest domain.

primary# ldm bind-domain ldom1
Note – The subcommand shortcut for bind-domain is bind.
9. Start the guest domain.

primary# ldm start-domain ldom1

Note – The subcommand shortcut for start-domain is start.
10. To find the console port of the guest domain, you can look at the
output of the list-domain subcommand.
primary# ldm list-domain ldom1
Note – The subcommand shortcut for list-domain is list.
11. Connect to the console of the guest domain. There are several ways
you can do this:
● By default, you can you can access a guest domain’s console
from the control domain by running the following command:
primary# telnet localhost 5000
● Or you can configure the vntsd service so that it can be
accessed remotely (that is, from outside of the control domain).
Once the vntsd service is properly configured for remote
access, you can access the domain’s console from a system
different from the control domain by running the command:
# telnet hostname-of-the-control-domain 5000

Figure 4-1 shows the logical interconnections for a guest domain after it
has been created. The device path information may differ on your server.
Service Domain Guest Domain

primary-vsw0
nxge0 vnet0
primary-vds0 c0d0 CPUs
vol0 vdisk0 vnet0 Memory

c1t1d0s2
Hypervisor
/pci@500/../network@0 /pci@400/../sd@1,0 CPUs Memory

Resources
Network
Internal Disk 1
Figure 4-1 Guest Domain Configuration

Installing the Solaris OS on a Guest Domain Using JumpStart
Installing the Solaris OS on a Guest Domain Using

JumpStart
After you have created and started a guest domain, you will need to
install the Solaris OS on that domain. There are several different ways you
can install the Solaris OS on a guest domain:
● From a DVD
● From a Solaris ISO file

● Using JumpStart
In this class you are shown how to install the Solaris OS on a guest
domain using JumpStart. For instructions on how to install the Solaris OS
on a guest domain from a DVD or from a Solaris ISO file, see “Installing
Solaris OS on a Guest Domain” in the Logical Domains 1.3 Administration
Guide.
To jumpstart a guest domain, you must first modify the basic Solaris
JumpStart profile as follows:
Normal JumpStart profile:

filesys c1t1d0s0 free /
filesys c1t1d0s1 2048 swap
filesys c1t1d0s5 120 /spare1
filesys c1t1d0s6 120 /spare2
Virtual disk device names in a logical domain differ from physical disk
device names in that they do not contain a target ID (tN) in the device
name. Instead of the normal cNtNdNsN format, virtual disk device names
are of the format cNdNsN, where cN is the virtual controller, dN is the
virtual disk number, and sN is the slice. Modify your JumpStart profile to
reflect this change as in the following profile example:
JumpStart profile used for a logical domain:

filesys c0d0s0 free /
filesys c0d0s1 2048 swap
filesys c0d0s5 120 /spare1
filesys c0d0s6 120 /spare2

Installing the Solaris OS on a Guest Domain Using JumpStart
In order to JumpStart the Solaris Operating System aliases must exist for
the virtual devices. Aliases are now automatically created based on the
name of the virtual device (name used with ldm add-vnet or ldm add-
vdisk).
You can directly JumpStart the Solaris operating system by using the
following command:
{1} ok boot vnet0 -v install

Note – Because the devalias net is also defined to be the first virtual
network interface, you could use boot net -v install as well.
Figure 4-2 shows an example of the logical path the operating system
installation takes through the system.

primary-vsw0
nxge0 vnet0
primary-vds0 c0d0 vnet0
vol0 vdisk0
c1t1d0s2
Hypervisor
/pci@500/../network@0 /pci@400/../sd@1,0
Resources
JumpStart Server
Internal Disk 1
Figure 4-2 JumpStart Installation Path

Verifying a Guest Domain Configuration

After you have created the guest domain, you will ensure the
configuration is correct.
You can get the information you need from the Logical Domains Manager
by running the ldm command with the appropriate subcommands and by
logging into the guest domain and running OpenBoot PROM and Solaris
operating system commands. Table 4-1 summarizes the commands you

will use to verify the guest domain configuration.
Table 4-1 Guest Domain Verification Commands
Property Command
Number of primary# ldm list-domain

domains
Domain primary# ldm list-domain
names
Operating guest# uname -a
environment and
guest# more /etc/release
CPU primary# ldm list-domain -l ldom1
resources and
{0} show-devs
and
guest# psrinfo -vp
Memory primary# ldm list-domain -l ldom1
resources and
guest# prtdiag|grep Mem
Network {0} ok show-nets
resources and
guest# ifconfig -a
Disk {0} ok show-disks
resources and
guest# format
Auto boot primary# ldm list-variable auto-boot\? ldom1
variable and
{0} ok printenv auto-boot?
and
guest# eeprom auto-boot\?

Table 4-1 Guest Domain Verification Commands (Continued)
Property Command
Boot device primary# ldm list-variable boot-device ldom1
variable and
{0} ok printenv boot-device
and
guest# eeprom boot-device

You should now have a basic understanding of how to build the
foundation for a Logical Domains environment. After you complete the
lab exercise that concludes this module, you will be shown how to
perform a series of more advanced administration tasks in modules 5 and
6.


Now that you know how to create and start a guest domain, try applying
what you have learned in the lab exercise that follows.

● Create a guest domain.
● Switch between control and guest domains.

● JumpStart the guest domain.
● Explore the guest domain.
Preparation
● Review the LDom services you configured in the previous exercise.
● Login name root
Guest domain operating system:
● Login name root
command responses shown in the lab are examples only. Depending upon
your lab configuration, the responses to the commands in the labs might
vary slightly.

Task 1 – Create a Guest Domain

In this task you use the logical domain management utility to create a
guest domain.
You add the following resources (Figure 4-3) to your new guest domain:
● Eight virtual CPUs
● Two gigabytes of memory

● One virtual network interface
● One virtual disk drive

primary-vsw0
nxge0 vnet0
primary-vds0 c0d0 CPUs
vol0 vdisk0 vnet0 Memory
c1t1d0s2
Hypervisor
/pci@500/../network@0 /pci@400/../sd@1,0 CPUs Memory

Resources
Network
Internal Disk 1
Figure 4-3 Guest Domain Configuration


1. Verify you are logged in to the host machine’s control domain as
root.
2. List the control domain services.
VCC
VSW

VDS
Are there sufficient services available to create the new guest domain
that has a boot disk and network interface? Yes
3. List all the host server devices to identify the resources available for
creating a new guest domain.
VCPU
PID %FREE PM
0 0 no
1 0 no
2 0 no
3 0 no
4 0 no
5 0 no
6 0 no
7 0 no
8 100 ---
9 100 ---
10 100 ---
11 100 ---
12 100 ---
13 100 ---
14 100 ---
15 100 ---
16 100 ---
17 100 ---
18 100 ---
19 100 ---
20 100 ---
21 100 ---
22 100 ---

23 100 ---
24 100 ---
25 100 ---
26 100 ---
27 100 ---
28 100 ---
29 100 ---
30 100 ---
31 100 ---
64 100 ---

65 100 ---
66 100 ---
67 100 ---
68 100 ---
69 100 ---
70 100 ---
71 100 ---
72 100 ---
73 100 ---
74 100 ---
75 100 ---
76 100 ---
77 100 ---
78 100 ---
79 100 ---
80 100 ---
81 100 ---
82 100 ---
83 100 ---
84 100 ---
85 100 ---
86 100 ---
87 100 ---
88 100 ---
89 100 ---
90 100 ---
91 100 ---
92 100 ---
93 100 ---
94 100 ---
95 100 ---
MAU
ID CPUSET BOUND
0 (0, 1, 2, 3, 4, 5, 6, 7) primary
1 (8, 9, 10, 11, 12, 13, 14, 15)

2 (16, 17, 18, 19, 20, 21, 22, 23)

3 (24, 25, 26, 27, 28, 29, 30, 31)
4 (64, 65, 66, 67, 68, 69, 70, 71)
5 (72, 73, 74, 75, 76, 77, 78, 79)
6 (80, 81, 82, 83, 84, 85, 86, 87)
7 (88, 89, 90, 91, 92, 93, 94, 95)
MEMORY
PA SIZE BOUND
0x0 512K _sys_

0x80000 1536K _sys_
0x200000 94M _sys_
0x6000000 32M _sys_
0x8000000 96M _sys_
0xe000000 2G primary
0x8e000000 5920M
IO
DEVICE PSEUDONYM BOUND OPTIONS
pci@400 pci_0 yes
pci@500 pci_1 yes
Are there sufficient vCPU and memory resources available to create
the new guest domain? Yes
4. Use the ldm add-domain command to create the framework for a
new guest domain named ldom1.
primary# ldm add-domain ldom1
5. Add eight virtual CPUs to the configuration of guest domain ldom1.
6. Add two gigabytes of memory to the configuration of guest domain
ldom1.
7. List the bindings for guest domain ldom1.
primary# ldm list-bindings ldom1
ldom1 inactive ------ 8 2G
CONTROL
DEPENDENCY
master=

8. Add a virtual network interface named vnet0 to the configuration of

guest domain ldom1. Bind vnet0 to the virtual switch primary-
vsw0. Use the information in Table 4-2 to assign an Ethernet address
that is associated with your lab machine to the vnet0 interface. The
valid range of MAC addresses that can be assigned for logical
domains are described in Table 4-2. Note that you must change the
fifth octet to match the subnet address of your lab environment. Use
the ifconfig -a command to determine the correct subnet address.
Table 4-2 Lab Ethernet Address Assignments

Assigned Machine Ethernet Address
machine1 00:14:4F:FC:XX:01
primary# ldm add-vnet mac-addr=00:14:4F:FC:XX:04 vnet0 primary-vsw0

ldom1
Note that you must use the appropriate Ethernet address from Table 4-2 to
JumpStart the logical domain later in this exercise. The fifth octet in the
Ethernet address could vary depending on which lab “pod” you are
assigned. See your instructor if you have any questions.
9. Add a disk named vol0 to the virtual disk service. Bind the second
disk drive on your primary PCI bus to vol0. Refer to the
configuration information you gathered earlier in the course.
For example:
primary# ldm add-vdiskserverdevice /dev/dsk/c1t1d0s2 \
vol0@primary-vds0
10. Add a virtual disk named vdisk0 to the configuration of guest
domain ldom1. Use the volume currently bound to virtual disk
service vds0.
The virtual disk (vdisk0) exported to guest domain ldom1 will be
represented in the guest domain’s OpenBoot environment as device
/virtual-devices@100/channel-devices@200/disk@0. You use
the show-disks OpenBoot command to determine this device name.

Note that the boot-device variable for guest domain ldom1 will default
to the first disk which is now vdisk0.
11. Set the auto-boot? variable for guest domain ldom1 to false.
primary# ldm set-variable auto-boot\?=false ldom1
12. Bind all the resources you configured in this task to the guest
domain ldom1.
13. List the logical domains.

primary active -n-cv SP 8 2G 0.2% 6d 20h 4m
ldom1 bound ----- 5000 8 2G
Note that ldom1 is currently in the bound state.
14. List the constraints for guest domain ldom1 in machine-readable
format.
primary# ldm list-constraints -p ldom1
VERSION 1.4
DOMAIN|name=ldom1
CONTROL|failure-policy=ignore
VCPU|count=8
MEMORY|size=2147483648
VARIABLES
|auto-boot?=false
VNET|name=vnet0|dev=network@0|service=primary-vsw0|mac-
addr=00:14:4f:fc:06:04|mode=|pvid=1|vid=|mtu=|linkprop=|id=0
VDISK|name=vdisk0|vol=vol0@primary-vds0|timeout=|id=0
VCONS|group=|service=|port=
15. Create a backup configuration file named /var/tmp/ldom1.xml
containing the constraints for guest domain ldom1 in XML format.
primary# ldm list-constraints -x ldom1 > /var/tmp/ldom1.xml
This XML-based file can be used to restore the logical domain (ldom1)
configuration. For example, to restore the configuration for logical domain
ldom1, you run the ldm bind-domain -i ldom1.xml command.
16. Start logical domain ldom1.
LDom ldom1 started

17. Generate a long listing of all the logical domains in the system to
verify your work.
primary# ldm list-domain -l
SOFTSTATE
Solaris running
MAC
00:14:4f:46:3e:4e
HOSTID
0x84463e4e

CONTROL
DEPENDENCY
master=
VCPU
VID PID UTIL STRAND
0 0 0.3% 100%
1 1 0.1% 100%
2 2 0.1% 100%
3 3 0.1% 100%
4 4 0.1% 100%
5 5 0.2% 100%
6 6 0.1% 100%
7 7 0.8% 100%
MAU
ID CPUSET
0 (0, 1, 2, 3, 4, 5, 6, 7)
MEMORY
RA PA SIZE
0xe000000 0xe000000 2G
IO
pci@400 pci_0
pci@500 pci_1
VCC
NAME PORT-RANGE
primary-vcc0 5000-5100
VSW
NAME MAC NET-DEV ID DEVICE LINKPROP DEFAULT-VLAN-ID PVID VID MTU MODE
primary-vsw0 00:14:4f:fb:79:88 nxge0 0 switch@0 1 1 1500
VDS
NAME VOLUME OPTIONS MPGROUP DEVICE
primary-vds0 vol0 /dev/dsk/c1t1d0s2
VCONS
NAME SERVICE PORT
SP
------------------------------------------------------------------------------
ldom1 active -t---- 5000 8 2G 12% 16s
SOFTSTATE
OpenBoot Running
MAC
00:14:4f:fa:61:06
HOSTID
0x84fa6106
CONTROL

DEPENDENCY
master=
VCPU
VID PID UTIL STRAND
0 8 100% 100%
1 9 0.0% 100%
2 10 0.0% 100%
3 11 0.0% 100%
4 12 0.0% 100%
5 13 0.0% 100%
6 14 0.0% 100%
7 15 0.0% 100%
MEMORY
RA PA SIZE
0xe000000 0x8e000000 2G

VARIABLES
auto-boot?=false
NETWORK
NAME SERVICE ID DEVICE MAC MODE PVID VID MTU LINKPROP
vnet0 primary-vsw0@primary 0 network@0 00:14:4f:fc:06:04 1 1500
DISK
NAME VOLUME TOUT ID DEVICE SERVER MPGROUP
vdisk0 vol0@primary-vds0 0 disk@0 primary
VCONS
NAME SERVICE PORT
ldom1 primary-vcc0@primary 5000
Task 2 – Switch Between Control and Guest Domains

To move between the control domain and guest domain, perform these
steps:
1. Log in to the guest domain.
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Connecting to console "ldom1" in group "ldom1" ....

Press ~? for control options ...
{0} ok
You can obtain the logical domain console port number from the “Cons”
field when running the ldm list-domain command.
If you don’t see the ok prompt, tap the Enter key.
2. Move back to the control domain.
{0} ok ~.
Connection to localhost closed by foreign host.
primary#

Note – For the remainder of this course, instead of using the telnet/~.
method of navigating between logical domains, you will open a window
for each logical domain and simply click the appropriate window to do
work. To open an additional window for the guest domain, click the host
terminal application on the SGD desktop. In the terminal window, run the
telnet localhost 5000 command to access the guest domain. Log in as
root. There will be times during the lab when the control domain must be
rebooted. This will cause the terminal window to close. When this
happens, simply reopen the terminal after the system has reboot.

Task 3 – JumpStart the Guest Domain
In this task you open a virtual console to the guest domain, configure the
virtual devices in the OpenBoot environment, and JumpStart the
operating system. See Figure 4-4.

primary-vsw0
nxge0 vnet0
primary-vds0 c0d0 vnet0
vol0 vdisk0
c1t1d0s2
Hypervisor
/pci@500/../network@0 /pci@400/../sd@1,0
Resources
JumpStart Server
Internal Disk 1
Figure 4-4 JumpStart Guest Domain


1. Verify that you have a terminal window open on the guest domain
and a console window open on the control domain.
2. Move to the guest domain window.
3. Run the banner command to display the guest domain ldom1
OpenBoot banner.
{0} ok banner
T5140, No Keyboard

OpenBoot 4.30.6, 2048 MB memory available, Serial #83517702.
Ethernet address 0:14:4f:fa:61:6, Host ID: 84fa6106.
4. Use the printenv command to display the OpenBoot environment
variables.
{0} ok printenv
Variable Name Value Default Value
ttya-rts-dtr-off false false

ttya-ignore-cd true true
keyboard-layout
reboot-command
security-mode none No default
security-password No default
security-#badlogins 0 No default
verbosity min min
pci-mem64? true true
diag-switch? false false
local-mac-address? true true
fcode-debug? false false
scsi-initiator-id 7 7
oem-logo No default
oem-logo? false false
oem-banner No default
oem-banner? false false
ansi-terminal? true true
screen-#columns 80 80
screen-#rows 34 34
ttya-mode 9600,8,n,1,- 9600,8,n,1,-
output-device virtual-console virtual-console
input-device virtual-console virtual-console
auto-boot-on-error? false false
load-base 16384 16384
auto-boot? false true
network-boot-arguments

boot-command boot boot

boot-file
boot-device disk disk net
multipath-boot? false false
boot-device-index 0 0
use-nvramrc? false false
nvramrc
error-reset-recovery boot boot
{0} ok

Is the auto-boot? variable configured as specified in Task 1? Yes.
5. Use the show-devs command to display the guest domain ldom1
devices. Type q to quit the command.
{0} ok show-devs
/cpu@7
/cpu@6
/cpu@5
/cpu@4
/cpu@3
/cpu@2
/cpu@1
/cpu@0
/virtual-devices@100
/virtual-memory
/memory@m0,e000000
/aliases
/options
/openprom
/chosen
/packages
/virtual-devices@100/channel-devices@200
/virtual-devices@100/console@1
/virtual-devices@100/random-number-generator@e
/virtual-devices@100/ncp@6
/virtual-devices@100/n2cp@7
/virtual-devices@100/flashprom@0
/virtual-devices@100/channel-devices@200/virtual-domain-service@0
/virtual-devices@100/channel-devices@200/disk@0
/virtual-devices@100/channel-devices@200/network@0
/openprom/client-services
/packages/obp-tftp
/packages/kbd-translator
/packages/SUNW,asr
/packages/dropins
/packages/terminal-emulator
/packages/disk-label

/packages/deblocker
/packages/SUNW,builtin-drivers
6. Use the show-disks command to display the guest domain ldom1
disks. Type q to quit the command.
{0} ok show-disks
a) /virtual-devices@100/channel-devices@200/disk@0
q) NO SELECTION
Enter Selection, q to quit:q
7. Use the show-nets command to display the guest domain ldom1

network devices. Select the virtual network by typing the letter
associated with it.
{0} ok show-nets
a) /virtual-devices@100/channel-devices@200/network@0
q) NO SELECTION
Enter Selection, q to quit: q
8. List the disk and network aliases. Use the network device name
obtained in the previous step.
Note that aliases for the virtual disk and network are automatically created
using the names you provided.
{0} ok devalias
vdisk0 /virtual-devices@100/channel-devices@200/disk@0
vnet0 /virtual-devices@100/channel-devices@200/network@0
net /virtual-devices@100/channel-devices@200/network@0
disk /virtual-devices@100/channel-devices@200/disk@0
virtual-console /virtual-devices/console@1
name aliases
{0} ok
9. JumpStart the guest domain ldom1 using the vnet0 device alias.
Note – Jumpstarting the Standard End User metacluster takes

approximately 30 minutes to complete.

Boot device: /virtual-devices@100/channel-devices@200/network@0 File and
args: - install
Requesting Internet Address for 0:14:4f:fc:XX:4
Using RARP/BOOTPARAMS...
Internet address is: 192.168.6.43
hostname: machine4-vnet0
domainname: brom.suned.com

...
Contact your instructor if the JumpStart does not begin to load the
software packages.
Note – After the OS has been installed and the SMF service descriptions
have been loaded, the JumpStart operation will run a postinstallation
script to set the root password to cangetin. This will cause the OS to
reboot. After the OS has rebooted, you can log in as root with the

password cangetin.
Task 4 – Explore the Guest Domain

In this task you open a virtual console to the guest domain, log in to the
guest domain operating system, and explore the guest domain.

1. After the Solaris 10 operating system has been completely installed
in the guest domain ldom1, log in to the Solaris OS as root. Use the
password cangetin.
machine4_vnet0 console login: root
Password: cangetin
Jan 20 12:43:42 machine4-vnet0 login: ROOT LOGIN /dev/console
Sun Microsystems Inc. SunOS 5.10 Generic January 2005
Welcome to SA345LDOM_B on machine4-vnet0
2. Check the /etc/path_to_inst file to determine if the network
interfaces nxge and e1000g are present.
guest# more /etc/path_to_inst
#
# Caution! This file contains critical kernel state
#
"/iscsi" 0 "iscsi"
"/pseudo" 0 "pseudo"
"/scsi_vhci" 0 "scsi_vhci"
"/options" 0 "options"
"/ramdisk-root" 0 "ramdisk"
"/virtual-devices@100" 0 "vnex"
"/virtual-devices@100/channel-devices@200" 0 "cnex"
"/virtual-devices@100/channel-devices@200/network@0" 0 "vnet"
"/virtual-devices@100/channel-devices@200/disk@0" 0 "vdc"
"/virtual-devices@100/channel-devices@200/virtual-domain-service@0" 0 "vlds"
"/virtual-devices@100/console@1" 0 "qcn"

"/virtual-devices@100/ncp@6" 0 "ncp"
"/virtual-devices@100/random-number-generator@e" 0 "n2rng"
"/virtual-devices@100/n2cp@7" 0 "n2cp"
Are the on-board network interfaces present? No.
Why?
The network interfaces nxge and e1000g are not present in guest domain
ldom1 because neither the pci@400 PCI bus nor pci@500 PCI bus is
currently bound to ldom1.

Verify that the virtual network interface vnet is present.
3. Run the dladm show-link command to view network links
available on the operating system.
guest# dladm show-link
vnet0 type: non-vlan mtu: 1500 device: vnet0
4. Verify the new IP configuration.
guest# ifconfig -a
8232 index 1
vnet0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index
2
ether 0:14:4f:fc:6:4
5. Verify that guest domain ldom1 can access the subnet discovered in
the previous step. For example:
guest# ping -s 192.168.XX.255
...
^C
You should see responses from other systems on the subnet.
6. Use the psrinfo command to determine how many virtual CPUs
can be seen by the operating system.
guest# psrinfo
0 on-line since 02/09/2010 12:42:25
1 on-line since 02/09/2010 12:42:26
2 on-line since 02/09/2010 12:42:26
3 on-line since 02/09/2010 12:42:26
4 on-line since 02/09/2010 12:42:26
5 on-line since 02/09/2010 12:42:26
6 on-line since 02/09/2010 12:42:26
7 on-line since 02/09/2010 12:42:26

7. Use the prtdiag command to determine how much memory can be

seen by the operating system.
8. Run the format command to determine which disks are available on
the operating system. Be sure to view the partition table.
guest# format

0. c0d0 <SUN300G cyl 46873 alt 2 hd 20 sec 625>
Specify disk (enter its number): 0
selecting c0d0
[disk unformatted]
Warning: Current Disk has mounted partitions.
/dev/dsk/c0d0s0 is currently mounted on /. Please see umount(1M).
/dev/dsk/c0d0s1 is currently used by swap. Please see swap(1M).
...
format> partition
...
partition> print
Current partition table (original):
Total disk cylinders available: 46873 + 2 (reserved cylinders)
Part Tag Flag Cylinders Size Blocks

0 root wm 84 - 46872 278.88GB (46789/0/0) 584862500
1 swap wu 0 - 83 512.70MB (84/0/0) 1050000
2 backup wm 0 - 46872 279.38GB (46873/0/0) 585912500
3 unassigned wm 0 0 (0/0/0) 0
partition> ^D
guest#
Note the disk name c0d0. Virtual disk device names in a logical domain
differ from physical disk device names in that they do not contain a target
ID (tN) in the device name. Instead of the normal cNtNdNsN format,
virtual disk device names are of the format cNtNdNsN, where cN is the
virtual controller, dN is the virtual disk number, and sN is the slice.


!
?
● Experiences
● Interpretations
● Conclusions

● Applications

Notes:

Module 5
Performing Logical Domains Administration

Objectives
This module shows you how to perform a variety of Logical Domains
administration tasks.

● Reconfigure logical domains resources.
● Use virtual disks.
● Use virtual networks.
● Manage logical domains configurations.
5-1


Introduction
Introduction
In this module you will be shown how to perform several key Logical
Domains administrative tasks.
First, you will learn how to reconfigure the logical domain resources you
set up during your initial configuration of the system. You will also learn
about dynamic and delayed reconfiguration.

In the second and third sections you will be shown how to use virtual
disks and configure virtual networks.
In the last section of this module you will learn how to manage the logical
domain configurations you have set up. The tasks include removing and
restoring guest domain configurations and resetting a Logical Domains
configuration to either a user-defined or factory default configuration.
Note – There is no lab for this module. The tasks presented in this module
are included in the lab exercise for Module 6.
Performing Logical Domains Administration 5-3

Reconfiguring Logical Domain Resources

Reconfiguration operations on logical domains are handled by the Logical
Domains Manager as either a dynamic reconfiguration operation or a
delayed reconfiguration operation, depending on the resource and the
state of the logical domain under reconfiguration.
In this section you are introduced to the concepts of dynamic and delayed
reconfiguration and shown how to reconfigure virtual CPUs and memory

in logical domains.
Overview of Dynamic and Delayed Reconfiguration

Operations
This section explains the differences between dynamic and delayed
reconfiguration and provides a brief introduction to dynamic resource
management (DRM).
Dynamic Reconfiguration
Dynamic reconfiguration (DR) is the ability to add or remove resources

while the operating system is running. The ability to perform dynamic
reconfiguration of a particular resource type is dependent on having
support in the OS running in the logical domain.
This depends on the OS and on the Logical Domains (LDoms) version:

● Virtual CPUs: supported since LDoms 1.0 with at least Solaris 10
11/06 OS
● Virtual device services: supported since LDoms 1.1 with at least
Solaris 10 10/08 OS
● Virtual I/O devices: supported since LDoms 1.1 with at least Solaris
10 10/08 OS
● Cryptographic units: supported since LDoms 1.3 with at least Solaris
10 10/09 OS
To use the dynamic reconfiguration capability, the Logical Domains

dynamic reconfiguration daemon, drd, must be running in the domain
that you want to change. See the drd(1M) man page for more information.

To reconfigure a resource that does not support dynamic reconfiguration,

the domain has to be stopped before it can be reconfigured. This applies
to all domains except the control domain. On the control domain, a
resource that does not support dynamic reconfiguration is reconfigured
using delayed reconfiguration.
Note – A new feature introduced with the Logical Domains 1.3 software is
dynamic resource management (DRM). DRM allows you to automatically
perform dynamic reconfiguration activities. At this time, you can only

govern the dynamic resource management of virtual CPUs. For more
information about using dynamic resource management to automatically
add and remove virtual CPUs from a logical domain, see the “Using
Dynamic Resource Management Policies” section in Chapter 9 Managing
Resources in the Logical Domains 1.3 Administration Guide.
Delayed Reconfiguration
Delayed reconfiguration is used to reconfigure a resource of the control

domain that cannot be reconfigured using dynamic reconfiguration (for
example, memory or physical I/O devices). In such cases, the
reconfiguration operation is deferred and takes place when the control
domain is rebooted.
Note – Before the Logical Domains 1.2 software, delayed reconfiguration

was available for any domain. This feature is now restricted to the control
domain only.
Reconfiguring Virtual CPU and Memory

This section shows you how to reconfigure virtual CPUs and memory in
logical domains.
Note – To make your reconfiguration changes persistent across

powercycle of the platform, you must save the configuration information
on the system controller. Use the ldm add-config command to save the
configuration. You can only store up to eight configuration files. You will
learn more about this topic later in the module.

Reconfiguring Virtual CPUs
You can use the ldm set-vcpu command from the control domain to
dynamically reconfigure virtual CPUs in any domain. You simply modify
the amount, and the Solaris OS instance running in the domain will see
them immediately.
For example, to assign sixteen virtual CPUs to the guest domain ldom1,
you would type the following:

primary# ldm set-vcpu 16 ldom1
Note – You can also use the ldm add-vcpu command to increase the
number of virtual CPUs. For example, if the guest domain ldom1 already
had eight virtual CPUs assigned to it and you wanted to allocate an
additional eight CPUs for a total of 16 CPUs, you would use the
command ldm add-vcpu 8 1dom1.
You can verify the number of CPUs now assigned by accessing the Solaris
OS running in ldom1 and querying the CPU resources seen by the
operating system.
guest# psrinfo -vp
The physical processor has 16 virtual processors (0-15)
UltraSPARC-T2+ (chipid 0, clock 1165 MHz)
...
To decrease the number of virtual CPUs, you can use the ldm remove-
vcpu command. For example, to remove eight virtual CPUs from the
guest domain ldom1, you would type the following:
primary# ldm remove-vcpu 8 ldom1
Note – The alias for remove is rm.

Reconfiguring Memory
To reconfigure memory in any domain except the primary domain, you

must stop the domain first. You can then reconfigure the memory, and the
new memory configuration will be available when the domain is
restarted.
To reconfigure memory in the primary domain, the domain will be

running (because it is the control domain, and this is where the memory
reconfiguration command has to be issued). In this case, you must

reconfigure the memory while the domain is running, and a delayed
reconfiguration will be used. The new memory configuration will only be
available after the domain has been rebooted.
To add memory to a domain, you can use the ldm set-memory

command. For example, to assign two gigabytes of memory to the
primary domain, you would type:
Similarly, to assign two gigabytes of memory to guest domain ldom1, you

would type:
primary# ldm set-memory 2G ldom1
Note – You can also use the ldm add-memory command to increase the
amount of memory. For example, if the guest domain ldom1 already had
two gigabytes of memory assigned to it and you wanted to allocate an
additional two gigabytes for a total of 4 gigabytes, you would use the
command ldm add-memory 2G 1dom1.
To decrease the amount of memory in a domain, you can use the ldm
remove-memory command. For example, to remove one gigabyte of
memory from the primary domain, you would type:
primary# ldm remove-memory 1G primary
Similarly, to remove one gigabyte of memory from guest domain ldom1,

you would type:
primary# ldm remove-memory 1G ldom1

Using Virtual Disks
Using Virtual Disks

In this section you are introduced to virtual disks and shown how to
create an image file-based virtual disk as well as how to use ZFS to store
virtual disk images.
Introduction to Virtual Disks

A virtual disk contains two components: the virtual disk itself as it
appears in a guest domain and the virtual disk backend, which is where
data is stored and where virtual I/O ends up. The virtual disk backend is
exported from a service domain by the virtual disk server (vds) driver. A
logical domains channel (LDC) enables communications, through the
hypervisor, between the vds driver in the service domain and the virtual
disk client (vdc) driver in the guest domain. Finally, a virtual disk appears
as /dev/[r]dsk/cXdYsZ devices in the guest domain (see Figure 5-1).
Virtual Disk Virtual Disk

Backend /dev/[r]dsk/cXdYsZ
Virtual Virtual
Disk Server Disk Client
(vds) (vdc)
LDC
Hypervisor
Figure 5-1 Virtual Disk With Logical Domains
The virtual disk backend can be physical or logical. Physical devices can
include the following:
● Physical disk or disk logical unit number (LUN)
● Physical disk slice
Logical devices can be any of the following:

● File on a file system, such as ZFS or UFS
● Logical volume from a volume manager, such as ZFS, VERITAS
Volume Manager (VxVM), or SolarisTM Volume Manager (SVM)
● Any disk pseudo device accessible from the service domain

Using Virtual Disks
Note – For more information about using volume managers in a Logical

Domains environment, see the “Using Volume Managers in a Logical
Domains Environment” section in Chapter 6 Using Virtual Disks in the
Logical Domains 1.3 Administration Guide.
Virtual Disk Appearance

When a backend is exported as a virtual disk, it can appear in the guest
domain either as a full disk or as a single slice disk. The way it appears
depends on the type of the backend and on the options used to export it.
Full Disk
When a backend is exported to a domain as a full disk, it appears in that

domain as a regular disk with 8 slices (s0 to s7). Such a disk is visible
with the format(1M) command. The disk's partition table can be changed
using either the fmthard(1M) or format(1M) command.
A full disk is also visible to the OS installation software and can be

selected as a disk onto which the OS can be installed.
Any backend can be exported as a full disk except physical disk slices that
can only be exported as single slice disks.
Single Slice Disk
When a backend is exported to a domain as a single slice disk, it appears

in that domain as a regular disk with 8 slices (s0 to s7). However, only
the first slice (s0) is usable. Such a disk is visible with the format(1M)
command, but the disk's partition table cannot be changed.
Although most of the time you will use a full disk, you will want to use a
single slice disk if:
● You want to export a disk slice.
● You want to export an already existing volume that contains some
data.
● You want to store data that you also want to be able to access
without using a virtual disk.

Using Virtual Disks
A single slice disk is also visible from the OS installation software and can
be selected as a disk onto which you can install the OS. In that case, if you
install the OS using the UNIX File System (UFS), then only the root
partition (/) must be defined, and this partition must use all the disk
space.
Any backend can be exported as a single slice disk using options.
Note – Prior to the Solaris 10 10/08 OS release, a single slice disk

appeared as a disk with a single partition (s0). Such a disk was not visible
with the format(1M) command. The disk also was not visible from the OS
installation software and could not be selected as a disk device onto
which the OS could be installed.
Virtual Disk Backend Options

Different options can be specified when exporting a virtual disk backend.
These options are indicated in the options= argument of the ldm add-
vdsdev command as a comma-separated list. The valid options are: Read-
only (ro), Exclusive (excl), and Slice (slice).
Most of the time, you do not need to specify any virtual disk backend
options. For more information about the options, see the "Virtual Disk
Backend Options" section in Chapter 6 Using Virtual Disks in the Logical
Virtual Disk Backend

The virtual disk backend is the location where data on a virtual disk is
stored. The backend can be a disk, a disk slice, a file, or a volume, such as
ZFS, SVM, or VxVM.
The following compares the differences and benefits of using a physical

disk or slice with a file or volume:
● Physical disk or slice. Offers the best performance. Limits the
number of disks. Is more complex to manage.

Using Virtual Disks
● File or volumes. Offers less performance than physical disks, as

access is through volume management and/or the file system layer.
Is easier to manage data, such as creating or copying files. Can take
advantage of volume management features, such as ZFS snapshots
and cloning.
A backend appears in a guest domain either as a full disk or as single slice

disk, depending on whether the slice option is set when the backend is
exported from the service domain. By default, a virtual disk backend is
exported non-exclusively as a readable-writable full disk.

Exporting a Physical Disk as a Full Disk
A physical disk or disk LUN is exported by default as a full disk. In that

case, virtual disk drivers (vds and vdc) forward I/O from the virtual disk
and act as a pass-through to the physical disk or disk LUN.
A physical disk or disk LUN is exported from a service domain by

exporting the device that corresponds to slice 2 (s2) of that disk without
setting the slice option.
To export a physical disk as a full disk, you perform the following steps:
1. Export a physical disk as a full disk.
For example, to export the physical disk c1t48d0 as a full disk, you
must export slice 2 of that disk (c1t48d0s2).
primary# ldm add-vdsdev /dev/dsk/c1t48d0s2 \
disk1@primary-vds0
2. Assign the disk to a guest domain.
For example, assign the disk (vdisk1) to guest domain 1dom1.
primary# ldm add-vdisk vdisk1 disk1@primary-vds0 ldom1
3. After the guest domain is started and running the Solaris OS, verify
that the disk is accessible and is a full disk.
A full disk is a regular disk that has eight (8) slices.
For example, the disk being checked is c0d1.
ldom1# ls -1 /dev/dsk/c0d1s*
/dev/dsk/c0d1s0
/dev/dsk/c0d1s1
/dev/dsk/c0d1s2
/dev/dsk/c0d1s3
/dev/dsk/c0d1s4
/dev/dsk/c0d1s5

Using Virtual Disks
/dev/dsk/c0d1s6
/dev/dsk/c0d1s7
Exporting a Physical Disk Slice as a Single Slice Disk
A physical disk slice is always exported as a single slice disk. In that case,
virtual disk drivers (vds and vdc) forward I/O from the virtual disk and
act as a pass-through to the physical disk slice.

A physical disk slice is exported from a service domain by exporting the
corresponding slice device. If the device is different from slice 2, then it is
automatically exported as a single slice disk whether or not you specify
the slice option. If the device is slice 2 of the disk, you must set the slice
option to export slice 2 as a single slice disk. Otherwise, the entire disk is
exported as a full disk.
To export a physical disk slice as a single slice disk, perform the following
steps:
1. Export a slice of a physical disk as a single slice disk.
For example, to export slice 0 of the physical disk c1t57d0 as a
single slice disk, you must export the device corresponding to that
slice (c1t57d0s0) from the service domain as follows:
primary# ldm add-vdsdev /dev/dsk/c1t57d0s0 \
disk2@primary-vds0
You do not need to specify the slice option, because a slice is
always exported as a single slice disk.
2. Assign the disk to a guest domain.
For example, assign the disk (vdisk2) to guest domain ldom1:
primary# ldm add-vdisk vdisk2 disk2@primary-vds0 ldom1
3. After the guest domain is started and running the Solaris OS, you
can list the disk (c0d13, for example) and see that the disk is
accessible:
/dev/dsk/c0d13s0
/dev/dsk/c0d13s1
/dev/dsk/c0d13s2
/dev/dsk/c0d13s3
/dev/dsk/c0d13s4
/dev/dsk/c0d13s5
/dev/dsk/c0d13s6
/dev/dsk/c0d13s7

Using Virtual Disks
Although there are 8 slices, because the disk is a single slice disk,
only the first slice (s0) is usable.
Exporting Slice 2
To export slice 2 (disk c1t57d0s2, for example) as a single slice disk, you
must specify the slice option. Otherwise, the disk is exported as a full
disk. For example:
primary# ldm add-vdsdev options=slice \

/dev/dsk/c1t57d0s2 disk2@primary-vds0
Exporting a File or Volume
A file or volume (for example from ZFS or SVM) is exported either as a

full disk or as single slice disk depending on whether the slice option is
set. In this section you are shown how to export a file or volume as a full
disk or as a single slice disk.
Exporting a File or Volume as a Full Disk
If you do not set the slice option, a file or volume is exported as a full
disk. In that case, virtual disk drivers (vds and vdc) forward I/O from the
virtual disk and manage the partitioning of the virtual disk. The file or
volume eventually becomes a disk image that contains data from all slices
of the virtual disk and the metadata used to manage the partitioning and
disk structure.
When you export a file or volume as a full disk, it appears in the guest
domain as an unformatted disk, that is, a disk with no disk label. Then,
you need to run the format(1M) command in the guest domain to define
usable partitions and to write a valid disk label. Any I/O to the virtual
disk fails while the disk is unformatted.
As we go through the example that follows, keep in mind that the

primary domain is also the service domain.
Note – Prior to the Solaris 10 5/08 OS release, when a file was exported as
a virtual disk, the system wrote a default disk label and created default
partitioning. This is no longer the case with the Solaris 10 5/08 OS release,
and you must run format(1M) in the guest domain to write a disk label.

Using Virtual Disks
To export a file as a full disk, you need to perform the following steps:
1. From the primary domain, create a file (fdisk0 for example) to use
as the virtual disk.
primary# mkfile 100m /ldoms/domain/test/fdisk0
The size of the file defines the size of the virtual disk. This example
creates a 100-megabyte blank file to get a 100-megabyte virtual disk.
2. From the control domain, export the file as a virtual disk.
primary# ldm add-vdsdev /ldoms/domain/test/fdisk0 \

fdisk0@primary-vds0
In this example, the slice option is not set, so the file is exported as
a full disk.
3. From the control domain, assign the disk to a guest domain.
For example, assign the disk (fdisk) to guest domain ldom1.
primary# ldm add-vdisk fdisk fdisk0@primary-vds0 ldom1
4. After the guest domain is started and running the Solaris OS, verify
that the disk is accessible and is a full disk.
A full disk is a regular disk with 8 slices.
The following example shows how to list the disk, c0d5, and verify
that it is accessible and is a full disk.
/dev/dsk/c0d5s0
/dev/dsk/c0d5s1
/dev/dsk/c0d5s2
/dev/dsk/c0d5s3
/dev/dsk/c0d5s4
/dev/dsk/c0d5s5
/dev/dsk/c0d5s6
/dev/dsk/c0d5s7
Exporting a File or Volume as a Single Slice Disk
If the slice option is set, the file or volume is exported as a single slice
disk. In this case, the virtual disk has only one partition (s0), which is
directly mapped to the file or volume backend. The file or volume only
contains data written to the virtual disk with no extra data such as
partitioning information or disk structure.

Using Virtual Disks
When a file or volume is exported as a single slice disk, the system

simulates a fake disk partitioning that makes the file or volume appear as
a disk slice. Because the disk partitioning is simulated, you do not create
partitioning for that disk.
For example, /dev/zvol/dsk/foo/vol0 is a ZFS volume in a service

domain. You export this volume as a vdisk to a guest domain where it
appears as /dev/dsk/c0d1s0.
In that domain, you can do the following:

# newfs /dev/rdsk/c0d1s0
# mount /dev/dsk/c0d1s0 /mnt
# echo test > /mnt/file
Then if you stop the guest domain, you can access the data on the volume
without using the virtual disk.
For example:
primary# mount /dev/zvol/dsk/foo/vol0 /mnt
primary# cat /mnt/file
test
You can also do this with a slice instead of a ZFS volume or with a file.
With a file, you can access the data from the service domain using lofi
instead of directly mounting the backend.
For example, if you exported /ldoms/file as a single slice disk, you

could directly access data from the service domain as follows:
primary# lofiadm -a /ldoms/file
primary# mount /dev/lofi/1 /mnt
primary# cat /mnt/file
Exporting Volumes and Backward Compatibility
Prior to the Solaris 10 5/08 OS release, the slice option did not exist, and
volumes were exported as single slice disks. If your configuration exports
volumes as virtual disks and you upgrade to the Solaris 10 5/08 OS,
volumes are exported as full disks rather than single slice disks.

Using Virtual Disks
To preserve the previous behavior and to have your volumes exported as

single slice disks, you need to do one of the following:
● Use the ldm set-vdsdev command in Logical Domains 1.3
software, and set the slice option for all volumes you want to
export as single slice disks. See the ldm(1M) man page.
● Add the following line to the /etc/system file on the service
domain:
set vds:vd_volume_force_slice = 1

Note – Setting this tunable forces the export of all volumes as single slice
disks, and prevents the export of any volume as a full disk.
Summary: How Different Types of Backends Are Exported
Backend No slice option slice option set
Disk (disk slice 2) Full disk1 Single slice disk2

Disk slice (not slice 2) Single slice disk3 Single slice disk
File Full disk Single slice disk
Volume, including ZFS, Full disk Single slice disk
SVM, or VxVM
1 Export the entire disk.

2 Export only slice 2.
3 A slice is always exported as a single slice disk.
For instructions on how to export files and disk slices as virtual disks, see
the “Guidelines for Exporting Files and Disk Slices as Virtual Disks” in
Chapter 6 Using Virtual Disks in the Logical Domains 1.3 Administration
Guide.
Exporting CD, DVD and ISO Images

You can export a compact disc (CD) or digital versatile disc (DVD) the
same way you export any regular disk. To export a CD or DVD to a guest
domain, export slice 2 of the CD or DVD device as a full disk, without the
slice option.

Using Virtual Disks
Note – You cannot export the CD or DVD drive itself. You only can export
the CD or DVD that is inside the CD or DVD drive. Therefore, a CD or
DVD must be present inside the drive before you can export it. Also, to be
able to export a CD or DVD, that CD or DVD cannot be in use in the
service domain. In particular, the Volume Management file system,
volfs(7FS) service must not use the CD or DVD.
If you have an International Organization for Standardization (ISO) image

of a CD or DVD stored in a file or on a volume and export that file or
volume as a full disk, it appears as a CD or DVD in the guest domain.
When you export a CD, DVD, or an ISO image, it automatically appears
as a read-only device in the guest domain.
If you export a Solaris OS installation DVD, you can boot the guest
domain on the virtual disk corresponding to that DVD and install the
guest domain from that DVD. To do so, when the guest domain reaches
the ok prompt, use the following command:
ok boot /virtual-devices@100/channel-
devices@200/disk@n:f
Where n is the instance of the virtual disk representing the exported
DVD.
Note – You can use boot vdisk:f instead of boot /virtual-

devices@100/channeldevices@200/disk@n:f; where vdisk is the
devalias name automatically created for the vdisk.
For step-by-step instructions on how to export a CD, DVD or ISO image,

see the appropriate section in Chapter 6 Using Virtual Disks in the Logical
Using ZFS to Create Virtual Disks for Guest Domains

ZFS provides a convenient and powerful solution to store and manage
virtual disk backends, especially with snapshots and clones. ZFS enables:
● Creating space in ZFS volumes or ZFS files
● Using snapshots to back up file systems and volumes
● Using clones to duplicate OS images stored within the ZFS space and
provision additional domains

Using Virtual Disks
Refer to the Solaris ZFS Administration Guide for more information about
using ZFS.
In this section you are shown how to create a ZFS space to use as a virtual
disk onto which a Solaris OS is to be installed.
Note – In the following descriptions and examples, the primary domain is

also the service domain where these files and volumes are stored.

Overview of Creating Virtual Disks Within ZFS
You can create the space for the virtual disk on ZFS volumes or ZFS files.
Creating a ZFS volume, whatever its size, is quick using the zfs create
-V command. On the other hand, ZFS files have to be created using the
mkfile command. The command can take some time to complete,
especially if the file to create is quite large, which is often the case when
creating space to contain an OS image.
Both ZFS volumes and ZFS files can take advantage of ZFS features such
as snapshots and clones, but a ZFS volume is a pseudo device while a ZFS
file is a regular file.
If the ZFS space is to be used as a virtual disk onto which the Solaris OS is
to be installed, then it should be large enough to contain:
● Installed software – about 6 gigabytes
● Swap partition – about 1 gigabyte
● Extra space to store system data – at least 1 gigabyte
Therefore, the size of the ZFS allocated space to install the entire Solaris
OS should be at least 8 to 10 gigabytes.
To create the ZFS pool and the corresponding volume, perform the
following steps:
1. Create a ZFS storage pool in the service domain.
For example, to create a ZFS pool named tank1 using disk c1t2d0,
type:
primary# zpool create -f tank1 c1t2d0

Using Virtual Disks
2. Create a ZFS volume.

For example, to create a 10-gigabyte volume named vol1, type:
primary# zfs create -V 10g tank1/vol1
3. Run the following command to verify that the zpool (tank1) and
ZFS volume (tank1/vol1) have been created.
primary# zfs list
4. Export the ZFS volume as a virtual disk.

For example, add the ZFS volume /dev/zvol/dsk/tank1/vol1 to
the virtual disk service.
primary# ldm add-vdsdev /dev/zvol/dsk/tank1/vol1 \
zvol@primary-vds0
5. Assign the ZFS volume to a guest domain.
For example, to add a disk named zvdisk, type:
primary# ldm add-vdisk zvdisk zvol@primary-vds0 ldom1
To create the ZFS pool and the corresponding file, perform the following
steps:
1. Create a ZFS storage pool in the service domain.
For example, to create a ZFS pool named tank1 using disk c1t2d0,
type:
2. Create a ZFS file.
For example, to create a ZFS file system to store the ZFS files (for
example, to create 10-gigabyte disk image):
primary# zfs create tank1/ldoms
primary# mkfile 10g /tank1/ldoms/file0
ZFS file system (tank1/ldoms) have been created.
primary# zfs list
4. Export the ZFS file as a virtual disk.
primary# ldm add-vdsdev /tank1/ldoms/file0 \
zvfile@primary-vds0
5. Assign the ZFS file to a guest domain.
For example, to add a file named zvfile, type:
primary# ldm add-vdisk zvfile zvfile@primary-vds0 ldom1

Using Virtual Disks
After you have created the ZFS volume or file that is to be used as a
virtual disk, the next step is to jumpstart the OS image onto the ZFS
volume or file. You can then use the ZFS snapshot and clone capabilities
to easily provision new domains. You want to do the snapshot after the
jumpstart but before the domain goes through the sysconfig phase. This
approach ensures the snapshot will not contain any predefined
configuration.
Note – Because you should already know how to jumpstart an OS image,

this task is not covered in this module.
Creating a Snapshot of a Virtual Disk OS Image Overview
After you have stored an OS image on a ZFS volume or on a ZFS file, you
can create snapshots of this image by using the ZFS snapshot command.
Before you create a snapshot of the OS image, you want to make sure that
the disk is not currently in use in the guest domain. The data currently
stored on the image must be coherent. There are several ways to ensure
that a disk is not in use in a guest domain. You can either:
● Stop and unbind the guest domain. This is the safest solution, and
this is the only solution available if you want to create a snapshot of
an OS image used as the boot disk of a guest domain.
● Unmount any slices of the disk you want to snapshot that are used
in the guest domain, and ensure that no slice is in use on the guest
domain.
In the example that follows, because of the ZFS layout, the command to
create a snapshot of the OS image is the same whether the OS image is
stored on a ZFS volume or on a ZFS file.
To create a snapshot of the OS image, enter the appropriate command:
For a ZFS volume:

primary# zfs snapshot tank1/vol1@snapshotname
For a ZFS file system:

primary# zfs snapshot tank1/ldoms@snapshotname

Using Virtual Disks
For step-by-step instructions on how to create a snapshot of a disk image

of an unconfigured system, see the “Create a Snapshot of a Disk Image of
an Unconfigured System” section in Chapter 6 Using Virtual Disks in the
Using a Clone to Provision a New Domain
Once you have created a snapshot of an OS image, you can duplicate this
image by using the ZFS clone command. Then the cloned image can be

assigned to another domain.
Cloning a boot disk image quickly creates a boot disk for a new guest
domain without having to perform the entire Solaris OS installation
process.
For example, if the virtual disk created was the boot disk of domain
ldom1, do the following to clone that disk to create a boot disk for domain
ldom2 given the snapshot you just created.
For a ZFS volume:

primary# zfs clone tank1/vol1@snapshotname tank1/vol2
For a ZFS file system:

primary# zfs clone tank1/ldoms@snapshotname tank1/ldom2
You can now export the corresponding volume or file as a virtual disk and
assign it to the new ldom2 guest domain. The guest domain ldom2 can
directly boot from that virtual disk without having to go through the OS
installation process.
For more information about cloning a boot disk image, see the “Cloning a
Boot Disk Image” section in Chapter 6 Using Virtual Disks in the Logical

Using Virtual Networks

A virtual network allows domains to communicate with each other
without using any external physical networks. A virtual network also can
allow domains to use the same physical network interface to access a
physical network and communicate with remote systems. A virtual
network is created by having a virtual switch to which you can connect
virtual network devices.

In this section you are shown how to configure a virtual switch and
service domain for NAT and routing and also how to configure a VLAN.

Configuring a Virtual Switch and the Service Domain

for NAT and Routing
The virtual switch (vsw) is a layer-2 switch that also can be used as a
network device in the service domain. The virtual switch can be
configured to act only as a switch between the virtual network (vnet)
devices in the various logical domains but with no connectivity to a
network outside the box through a physical device. See Figure 5-2.

vsw vnet
IP Routing
Legacy NIC
Hypervisor
/../../network@0 Resources
Subnet
Figure 5-2 Configuring a Virtual Switch and the Service Domain for
NAT and Routing
In this mode, plumbing the vsw as a network device and enabling IP

routing in the service domain enables virtual networks to communicate
outside the box using the service domain as a router. This mode of
operation is essential to provide external connectivity to the domains
when the physical network adapter is not GLDv3-compliant.
The advantages of this configuration are:

● The virtual switch does not need to use a physical device directly
and can provide external connectivity even when the underlying
device is not GLDv3-compliant.

● The configuration can take advantage of the IP routing and filtering

capabilities of the Solaris OS.
For information about how to set up the virtual switch for NAT and
routing, see the “Set Up the Virtual Switch to Provide External
Connectivity to Domains” section in Chapter 7 Using Virtual Networks in
the Logical Domains 1.3 Administration Guide.
Configuring Virtual Local Area Networks

As of the release of Solaris 10 10/08 OS and LDoms 1.1 software, 802.1Q
VLAN-Tagging support is available in the Logical Domains network
infrastructure.
Note – Tagged VLANs are not supported in any of the previous releases
for LDoms networking components.
The virtual switch (vsw) and virtual network (vnet) devices support
switching of Ethernet packets based on the virtual local area network
(VLAN) identifier (ID) and handle the necessary tagging or untagging of
Ethernet frames.
You can create multiple VLAN interfaces over a vnet device in a guest
domain. You can use the Solaris OS ifconfig(1M) command to create a
VLAN interface over a virtual network device, the same way it is used to
configure a VLAN interface over any other physical network device. The
additional requirement in the LDoms environment is that you must assign
the vnet to the corresponding VLANs using the Logical Domains
Manager CLI commands. Refer to the ldm(1M) for complete information
about the Logical Domains Manager CLI commands.
Similarly, you can configure VLAN interfaces over a virtual switch device
in the service domain. VLAN IDs 2 through 4094 are valid. VLAN ID 1 is
reserved as default-vlan-id.
When you create a vnet device on a guest domain, you must do the
following:
● Assign the vnet to the required VLANs by specifying a port VLAN
ID.
● Use ldm add-vnet command to specify zero or more VLAN IDs for
this vnet by setting the pvid and vid properties.

This configures the virtual switch to support multiple VLANs in the

LDoms network and switch packets using both MAC address and VLAN
IDs in the network.
Similarly, configure the vsw device to specify any VLANs to which the
vsw device itself should belong when plumbed as a network interface. To
perform this configuration, use the ldm add-vsw command to set the
pvid and vid properties.
Use the ldm set-vnet or ldm set-vsw commands to change the VLANs

to which a device belongs.
Port VLAN ID
The port VLAN ID (PVID) indicates a VLAN to which the virtual network
device needs to be a member, in untagged mode. In this case, the vsw
device provides the necessary tagging or untagging of frames for the vnet
device over the VLAN specified by its PVID. Any outbound frames from
the virtual network that are untagged are tagged with its PVID by the
virtual switch. Inbound frames tagged with this PVID are untagged by
the virtual switch before sending it to the vnet device. Thus, assigning a
PVID to a vnet implicitly means that the corresponding virtual network
port on the virtual switch is marked untagged for the VLAN specified by
the PVID. You can have only one PVID for a vnet device.
The corresponding virtual network interface, when configured using the

ifconfig(1M) command without a VLAN ID and using only its device
instance, results in the interface being implicitly assigned to the VLAN
specified by the virtual network's PVID.
For example, if you were to plumb vnet instance 0, using the following
command, and if the pvid property for the vnet has been specified as 10,
the vnet0 interface would be implicitly assigned to belong to VLAN 10.
# ifconfig vnet0 plumb

VLAN ID
The VLAN ID (VID) indicates the VLAN to which a virtual network

device or virtual switch needs to be a member, in tagged mode. The
virtual network device sends and receives tagged frames over the VLANs
specified by its VIDs. The virtual switch passes any frames that are tagged
with the specified VID between the virtual network device and the
external network.
For information about how to assign VLANs to a virtual switch and

virtual network device, see the “Assign VLANs to a Virtual Switch and
Virtual Network Device” section in Chapter 7 Using Virtual Networks in
the Logical Domains 1.3 Administration Guide.

Managing Logical Domains Configurations

In this section you are shown how to save, remove, and restore a guest
domain configuration and how to reset a Logical Domains configuration
to either a user-defined or factory default configuration.
Saving, Removing, and Restoring a Guest Domain

Configuration

Saving a Guest Domain Configuration – The Autosave Operation
Starting with the Logical Domains 1.2 release, a copy of the current
configuration is automatically saved on the control domain whenever the
Logical Domains configuration is changed. The autosave operation occurs
immediately.
The Logical Domains autosave configuration data is found in the

/var/opt/SUNWldm/autosave-* directories. This autosave operation
enables you to recover a configuration when the configurations that are
saved on the service processor (SP) are lost.
This operation also enables you to recover a configuration when the

current configuration was not explicitly saved to the SP when the system
powercycled. In these circumstances, the Logical Domains Manager can
restore that configuration on restart if it is newer than the configuration
marked for the next boot.
You can automatically or manually restore autosave files to new or

existing configurations. By default, when an autosave configuration is
newer than the corresponding running configuration, a message is written
to the LDoms log (/var/svc/log/*ldmd*). Thus, you must use the ldm
add-spconfig -r command to manually save your configuration
changes to an existing configuration or create a new one based on the
autosave data.
Note – For information about how to use the ldm *-spconfig commands
to manage configurations and to manually recover autosave files, see the
ldm(1M) man page.

When a delayed reconfiguration is pending, the configuration changes are

immediately autosaved. As a result, if you run the ldm list-config -r
command, the autosave configuration is shown as being newer than the
current configuration.
The autorecovery policy specifies how to handle the recovery of a

configuration when one configuration that is automatically saved on the
control domain is newer than the corresponding running configuration.
The autorecovery policy is specified by setting the autorecovery_policy
property of the ldmd SMF service. The autorecovery_policy property

can have the following values:
● autorecovery_policy=1 – Logs warning messages when an
autosave configuration is newer than the corresponding running
configuration. These messages are logged in the ldmd SMF log file.
The user must manually perform any configuration recovery. This is
the default policy.
● autorecovery_policy=2 – Displays a notification message if an
autosave configuration is newer than the corresponding running
configuration. This notification message is printed in the output of
any ldm command the first time an ldm command is issued after
each restart of the Logical Domains Manager. The user must
manually perform any configuration recovery.
● autorecovery_policy=3 – Automatically updates the configuration
if an autosave configuration is newer than the corresponding
running configuration. This action overwrites the SP configuration
that will be used during the next powercycle. This configuration is
updated with the newer configuration that is saved on the control
domain.
This action does not impact the currently running configuration. It
only impacts the configuration that will be used during the next
powercycle. A message is also logged, which states that a newer
configuration has been saved on the SP and that it will be booted the
next time the system is powercycled. These messages are logged in
the ldmd SMF log file.
For step-by-step instructions on how to change the autorecovey_policy

property value, see the “Modify the Autorecovery Policy” section in
Chapter 10 Managing Configurations in the Logical Domains 1.3
Consider archiving the configuration files off-line to help reduce recovery

time in the event of a catastrophic failure.

Removing a Guest Domain Configuration
There may be times when you need to remove a guest domain

configuration. To remove a guest domain configuration, you must stop the
guest domain, unbind the guest domain resources, and then remove the
guest domain. In the example that follows you are shown how to remove
guest domain ldom1.
To remove a guest domain configuration, perform the following steps:

1. Stop the guest domain.
primary# ldm stop-domain ldom1
The stop-domain subcommand sends a shutdown request to the
logical domain if the Solaris OS is booted. If the domain cannot be
stopped by any other means, use the -f option of the stop-domain
subcommand to force the domain to stop.
2. Unbind all the resources attached to the guest domain.
primary# ldm unbind-domain ldom1
Note – You might also want to clean up the resources used by this domain
by removing the vdsdev and backend (file/volume).
3. Remove the guest domain.

primary# ldm remove-domain ldom1
Note – The alias for remove is rm.
Restoring a Guest Domain Configuration
You can only restore domains for which you have explicitly saved the
configuration using the ldm ls-constraints -x command. Then you
can restore the configuration by using the ldm bind-domain -i
command.
In the example that follows you are shown how to restore the
configuration for guest domain ldom1. The configuration was saved using
the following command:
# ldm ls-constraints -x ldom1 > ldom1.xml

To restore a guest domain configuration, perform the following steps:

1. Restore the guest domain configuration.
primary# ldm bind-domain -i ldom1.xml
2. Start the domain.
Note – These steps restore the domain configuration only, not the virtual

device services it might use (for example, vds and vsw). Therefore, you
must configure the virtual device services as appropriate to support the
restored configuration.
Resetting the Logical Domains Configuration

The Logical Domains Manager software allows you to store multiple user-
defined configurations on the system controller along with the factory-
default configuration. By using the ldm set-config command from the
control domain or the bootmode config command from the system
controller, you can select one of these configurations to be loaded upon
the next system reset.
If you reload the factory default configuration, the control domain is

returned to its initial configuration. That is, all the system resources are
returned to the control domain.
The sections that follow provide instructions on how to reset the system
to either a user-defined or factory default configuration.
Resetting a User-Defined Configuration From the Control

Domain
To reset a user-defined configuration from the control domain:

1. Select the configuration.
For example, you want to select a configuration you called
myconfig.
primary# ldm set-config myconfig
2. Stop all domains by using the -a option.
primary# ldm stop-domain -a

3. Stop the control domain.

4. Powercycle the system so that the user-defined configuration is
loaded.
sc> poweroff
sc> poweron

Resetting the System to a User-Defined Configuration From the
Service Processor
You can reset a user-defined configuration that you previously created

and stored on the service processor by using the ldm add-config
command. To reset this configuration, run the ILOM bootmode command
and specify the same configuration name as the value of the config
property.
For example, assume you stored the configuration with the name
myconfig. To reset the configuration, type:
-> set /HOST/bootmode config=myconfig
Next, powercycle the system to load the new configuration.
Resetting the System to the Factory Default Configuration From

the Control Domain
To reset the system to the factory default configuration from the control
domain:
1. Select the factory default configuration.
primary# ldm set-config factory-default
2. Stop all domains by using the -a option.
primary# ldm stop-domain -a
3. Stop the control domain.
4. Powercycle the system so that the factory-default configuration is
loaded.
sc> poweroff
sc> poweron

Resetting the System to the Factory Default Configuration Using

the ILOM Service Processor
To reset the system to the factory default configuration using the ILOM
service processor with the Logical Domains Manager, use the following
command:
-> set /HOST/bootmode config=factory-default

Module 6
Managing Advanced Logical Domains

Configurations

Objectives
This module shows you how to manage advanced Logical Domains
configurations.

● Migrate an active guest domain (warm migration).
● Migrate a bound or inactive guest domain (cold migration).
● Create an additional I/O domain.
● Configure virtual network multipathing with multiple I/O domains.
● Configure virtual disk multipathing with multiple I/O domains.
6-1


Introduction
Introduction
In this module you will be shown how to manage advanced Logical
Domains configurations.
First, you will learn how to migrate a logical domain from one server to
another. You will be shown the process for migrating both an active
(warm migration) and a bound or inactive domain (cold migration).

Next, you will be shown how to use multiple I/O domains. Your
instructor will start by explaining how to create an additional I/O domain
and then how to configure virtual network and virtual disk multipathing
with multiple I/O domains.
The module concludes with a lab exercise designed to give you the
opportunity to practice the tasks you were shown during the lecture.
Managing Advanced Logical Domains Configurations 6-3

Migrating a Logical Domain from One Server to Another

Logical domain migration, or domain mobility, provides the ability to
migrate a logical domain from one host machine to another. The host
where the migration is initiated is referred to as the source machine, and
the host where the domain is migrated to is referred to as the target
machine. Similarly, once a migration is started, the domain to be migrated
is referred to as the source domain and the shell of a domain created on
the target machine is referred to as the target domain while the migration

is in progress.
In this section you are presented with an overview of the migration

process and then given the requirements and restrictions for migrating an
active domain and a bound or inactive domain. You are then shown how
to perform a migration.
Migration Process Overview

The migration process begins with the Logical Domains Manager on the
source machine accepting the request to migrate a domain and
establishing a secure network connection with the Logical Domains
Manager running on the target machine. Once this connection has been
established, the migration occurs.
The migration itself can be broken down into different phases (see
Figure 6-1):
● Phase 1: After connecting with the Logical Domains Manager
running in the target host, information about the source domain is
transferred to the target host. This information is used to perform a
series of checks to determine whether a migration is possible. The
checks differ depending on the state of the source domain. For
example, if the source domain is active, a different set of checks are
performed than if the domain is bound or inactive.
● Phase 2: When all checks in Phase 1 have passed, the source and
target machines prepare for the migration. In the case where the
source domain is active, this includes shrinking the number of CPUs
to one and suspending the domain. On the target machine, a domain
is created to receive the source domain.
● Phase 3: For an active domain, the next phase is to transfer all the
runtime state information for the domain to the target. This
information is retrieved from the hypervisor. On the target, the state
information is installed in the hypervisor.

● Phase 4: After all state information is transferred, the handoff occurs

when the target domain resumes execution (if the source was active)
and the source domain is destroyed. From this point on, the target
domain is the sole version of the domain running.
Phase 1: Information Transfer Phase 2: Migration Preparation
Secure Network Connection Secure Network Connection
Source Machine Target Machine Source Machine Target Machine

Logical Domains Logical Domains Logical Domains Logical Domains
Manager Manager Manager Manager
Source Domain Source Domain Target Domain
Information is transferred from the source to Source and target machines prepare for migration.
the target host.
Phase 3: Runtime State Information Transfer Phase 4: Handoff
Secure Network Connection
Source Machine Target Machine Source Machine Target Machine
Logical Domains Logical Domains Logical Domains Logical Domains

Manager Manager Manager Manager
Source Domain Target Domain

Source Domain Target Domain
Hypervisor Hypervisor
All runtime state information for the domain is Target domain resumes execution and the source
transferred to the target. is destroyed.
Figure 6-1 Logical Domains Migration Process Phases

Software Compatibility
For a migration to occur, both the source and target machines must be
running compatible software:
● The hypervisor on both the source and target machines must have
firmware that supports domain migration.
If you see the following error, you do not have the correct version of
system firmware on either the source or target machine.

System Firmware version on <downrev machine> does not
support Domain Migration
Domain Migration of LDom <source domain> failed
● A compatible version of the Logical Domains Manager must be
running on both machines.
Authentication for Migration Operations
Since the migration operation executes on two machines, a user must be

authenticated on both the source and target host. In particular, the user
must have the solaris.ldoms.write, file_dac_read, and
file_dac_search authorizations on both machines. See “Adding the
Privileges Needed to Migrate Domains” in Chapter 3 Security of the
The ldm command line interface for migration allows the user to specify
an optional alternate user name for authentication on the target host. If
this is not specified, the user name of the user executing the migration
command is used. In both cases, the user is prompted for a password for
the target machine unless the -p option is used to initiate an automatic
migration.
Migrating an Active Domain (Warm Migration)

For the migration of an active domain (referred to as a warm migration) to
occur with Logical Domains 1.3 software, there is a certain set of
requirements and restrictions imposed on the source domain, the source
machine, and the target machine.

Note – The migration operation speeds up when the primary domain on

the source and target systems have cryptographic units assigned. Starting
with Logical Domains 1.3, you can speed up migration by adding more
virtual CPUs to the primary domains of both the source and target
systems.
Migrating CPUs in an Active Domain

Following are the requirements and restrictions on CPUs when
performing a migration.
● The source and target machines must have the same processor type
running at the same frequency.
● The target machine must have sufficient free strands to
accommodate the number of strands in use by the domain. In
addition, full cores must be allocated for the migrated domain. If the
number of strands in the source are less than a full core, the extra
strands are unavailable to any domain until after the migrated
domain is rebooted.
● After a migration, CPU dynamic reconfiguration (DR) is disabled for
the target domain until it has been rebooted. Once a reboot has
occurred, CPU DR becomes available for that domain.
● Either the source domain must have only a single strand, or the
guest OS must support CPU DR, so that the domain can be shrunk to
a single strand before migration. Conditions in the guest domain that
would cause a CPU DR removal to fail would also cause the
migration attempt to fail. For example, processes bound to CPUs
within the guest domain, or processor sets configured in the source
domain, can cause a migration operation to fail.
Migrating Memory in an Active Domain
The target machine must have sufficient free memory to accommodate the
migration of the source domain. In addition, the layout of the available
memory on the target machine must be compatible with the memory
layout of the source domain or the migration will fail.
In particular, if the memory on the target machine is fragmented into

multiple small address ranges, but the source domain requires a single
large address range, the migration will fail.

Migrating Physical I/O Devices in an Active Domain
Virtual devices that are associated with physical devices can be migrated.
However, domains that have direct access to physical devices cannot be
migrated. For instance, you cannot migrate I/O domains.
Migrating Virtual I/O Devices in an Active Domain
All virtual I/O (VIO) services used by the source domain must be

available on the target machine. In other words, the following conditions
must exist:
● Each logical volume used in the source domain must also be
available on the target host and must refer to the same storage.
Caution – A migration fails when the logical volume used by the source
as a boot device exists on the target but does not refer to the same storage.
The migration appears to succeed; however, the machine is not usable
because it is unable to access its boot device. To avoid leaving the target
domain in an inconsistent state, stop the domain, correct the configuration
issue, and restart the domain.
● For each virtual network device in the source domain, a virtual

network switch must exist on the target host, with the same name as
the virtual network switch the device is attached to on the source
host.
For example, if vnet0 in the source domain is attached to a virtual
switch service name switch-y, then there must be a logical domain
on the target host providing a virtual switch service named switch-
y.
Note – The switches do not have to be connected to the same network for
the migration to occur; however, the migrated domain can experience
networking problems if the switches are not connected to the same
network.
MAC addresses used by the source domain that are in the

automatically allocated range must be available for use on the target
host.
● A virtual console concentrator (vcc) service must exist on the target
host and have at least one free port. Explicit console constraints are
ignored during the migration. The console for the target domain is
created by using the following:

● Target domain name as the console group

● Any available port on the first vcc device in the control domain
Migrating NIU Hybrid Input/Output in an Active Domain
A domain using Network Interface Unit (NIU) Hybrid I/O resources can
be migrated. A constraint specifying NIU Hybrid I/O resources is not a
hard requirement of a logical domain. If such a domain is migrated to a
machine that does not have available NIU resources, the constraint is

preserved, but not fulfilled.
Migrating Cryptographic Units in an Active Domain
Starting with Logical Domains 1.3, you can migrate a guest domain that
has bound cryptographic units if it runs an operating system that
supports cryptographic unit dynamic reconfiguration (DR).
The following Solaris OS versions support cryptographic unit DR:

● At least the Solaris 10 10/09 OS
● At least the OpenSolaris 2009.06 OS
● At least the Solaris 10 5/08 OS plus patch ID 142245-01
At the start of the migration, the Logical Domains Manager determines

whether the source domain supports cryptographic unit DR. If supported,
the Logical Domains Manager attempts to remove any cryptographic
units from the domain. After the migration completes, the cryptographic
units are re-added to the migrated domain.
Note – If the constraints for cryptographic units cannot be met on the

target machine, a migration operation might still complete successfully. In
such a case, the domain might end up with fewer cryptographic units
than it had prior to the migration operation.

Note – Any active delayed reconfiguration operations on the source or

target host prevent a migration from starting. Delayed reconfiguration
operations are blocked while a migration is in progress. While a migration
is in progress on a machine, any operation that could result in the
modification of the machine description (MD) of the domain being
migrated is blocked. This includes all operations on the domain itself as
well as operations such as bind and stop on other domains on the
machine.

Migrating a Bound or Inactive Domain (Cold Migration)
Because a bound or inactive domain is not executing at the time of the
migration (referred to as a cold migration), there are fewer restrictions
than when you migrate an active domain. The migration of a bound
domain requires that the target is able to satisfy the CPU, memory, and
I/O constraints of the source domain. Otherwise, the migration will fail.
The migration of an inactive domain does not have such requirements.
However, the target must satisfy the domain's constraints when the
binding occurs. Otherwise, the domain binding will fail.
Migrating CPUs in a Bound or Inactive Domain
You can migrate a bound or inactive domain between machines running

different processor types and machines that are running at different
frequencies. The Solaris OS image in the guest must support the processor
type on the target machine.
Migrating Virtual Input/Output Devices in a Bound or Inactive

Domain
For an inactive domain, there are no checks performed against the virtual
input/output (VIO) constraints. So, the VIO servers do not need to exist
for the migration to succeed. As with any inactive domain, the VIO
servers need to exist and be available at the time the domain is bound.

Performing the Migration

After you have ensured that you have met the requirements and
restrictions associated with migrating either an active domain or a bound
or inactive domain and you have met the authentication requirements,
you are ready to start the migration operation.
Assume you want to migrate a domain called ldom1 to a machine with

the host name Hostname_Target. To do this, you would enter the

following command and the target password:
# ldm migrate-domain ldom1 Hostname_Target
Target Password:
The migration operation can take anywhere from several seconds to

several minutes depending of the complexity of your configuration.
Performing the Dry Run Option
When you provide the -n option to the migrate-domain subcommand,

migration checks are performed, but the source domain is not migrated.
Any requirement that is not satisfied is reported as an error. This allows
you to correct any configuration errors before attempting a real migration.
Note – Because of the dynamic nature of logical domains, it is possible for

a dry run to succeed and a migration to fail and vice-versa.
Monitoring a Migration in Progress
When a migration is in progress, you can monitor the status of each

machine.
To obtain the status of the source domain, type the following on the
source domain machine:
# ldm list ldom1
To obtain the status of the target domain, type the following on the target
machine:
# ldm list ldom1

The source and target domains are shown differently in the status output.
The output of the ldm list command indicates the state of the migrating
domain and includes the following fields:
● NAME – Name of the domain, either the source or target
● STATE – State of the domain, for example, suspended or bound
● FLAGS – Status of the domain
● CONS – Console port of the domain

● VCPU – Number of virtual CPUs
● MEMORY – Amount of memory
● UTIL – Percentage of CPUs utilization of the domain
● UPTIME – Length of time the domain has been active
The sixth column in the FLAGS field shows one of the following values:
● The source domain shows an s to indicate that it is the source of the
migration.
● The target domain shows a t to indicate that it is the target of a
migration.
● If an error occurs that requires user intervention, an e is shown.
The following shows that ldom1 is the source domain of the migration:
# ldm list ldom1
ldom1 suspended -n---s 8 2G 0.0% 2h 7m
The following shows that ldom1 is the target domain of the migration:
# ldm list ldom1
ldom1 bound -----t 5000 1 2G

In the long form of the status output, additional information is shown

about the migration. On the source, the percentage of the operation
completed is displayed along with the target host and domain name.
Similarly, on the target, the percentage of the operation completed is
displayed along with the source host and domain name.
# ldm list -o status ldom1
NAME
ldom1

STATUS
OPERATION PROGRESS SOURCE
migration 17% ldom1
For information about canceling a migration in progress or recovering

from a failed migration, see the associated sections in Chapter 8 Migrating
Logical Domains in the Logical Domains 1.3 Administration Guide.
Performing Automated Migrations

Until the release of the Logical Domains 1.3 software, migrations were
interactive operations. When you initiated the migration, you were
prompted for the password to use for the target machine. Starting with
Logical Domains 1.3, you can use the ldm migrate-domain -p filename
command to initiate an automated migration operation. The file name you
specify as an argument to the -p option must have the following
properties:
● The first line of the file must contain the password.
● The password must be plain text.
● The password must not exceed 256 characters in length.
A newline character on the end of the password and all lines that follow
the first line are ignored.
The file in which you store the target machine's password must be
properly secured. If you plan to store passwords in this manner, ensure
that the file permissions are set so that only the root owner, or a
privileged user, can read or write the file (400 or 600).

Using Multiple I/O Domains

In this section you are shown how to create an additional I/O domain and
then shown how to configure virtual network and virtual disk
multipathing with multiple I/O domains.
Creating an Additional I/O Domain

This section describes how to set up additional I/O domains in a Logical
Domains environment.
An I/O domain is a domain that has direct ownership of and direct access
to physical I/O devices. It can be created by assigning a PCI EXPRESS
(PCI-E) bus to a domain. PCI-E buses that are present on a server are
identified with names such as pci@400 (pci_0). Use the ldm command to
assign each bus to a separate domain.
The maximum number of I/O domains that you can create depends on
the number of PCI-E buses available on the server. For example, the Sun
SPARC Enterprise T5440 server has four PCI-E buses, so it can have up to
four I/O domains, whereas the Sun SPARC Enterprise T5140 server has
only two PCI-E buses and can, therefore, have up to two I/O domains.
See Figure 6-2 for the Sun SPARC Enterprise T5140 server PCI-E bus
configuration.
I/O Domain 1 I/O Domain 2
Hypervisor
pci@400 pci@500
Resources
Figure 6-2 SPARC Enterprise T5140 Server PCI-E Bus Configuration

In the example that follows you are shown how to create a new I/O
domain from an initial configuration where several buses are owned by
the primary domain. By default the primary domain owns all buses
present on the system. This example is for a Sun SPARC Enterprise T5140
server. This procedure can also be used on other servers. The instructions
for different servers might vary slightly from these, but you can obtain the
basic principles from this example.
First, you must retain the bus that has the primary domain's boot disk.
Then, remove another bus from the primary domain and assign it to

another domain.
Caution – All internal disks on the supported servers are connected to a

single PCI bus. If a domain is booted from an internal disk, do not remove
that bus from the domain. Also, ensure that you are not removing a bus
with devices (such as network ports) that are used by a domain. If you
remove the wrong bus, a domain might not be able to access the required
devices and could become unusable. To remove a bus that has devices
that are used by a domain, reconfigure that domain to use devices from
other buses. For example, you might have to reconfigure the domain to
use a different onboard network port or a PCI card from a different PCI
slot.
In this example, the primary domain only uses a ZFS pool (rpool
(c1t0d0s0)) and network interface (nxge0).
To add an additional I/O domain, perform the following steps:

1. List the primary domain’s current bindings to determine PCI bus
ownership.
2. Determine the device path of the boot disk that needs to be retained.
● For UFS file systems, run the df / command to determine the
device path of the boot disk.
primary# df /
● For ZFS file systems, first run the df / command to determine
the pool name, and then run the zpool status command to
determine the device path of the boot disk.
primary# df /
...
primary# zpool status rpool

3. Determine the physical device to which the block device is linked.

The following example uses block device c1t0d0s0:
primary# ls -l /dev/dsk/c1t0d0s0
4. Determine the network interface that is used by the system.
...
For purposes of this example, assume nxge0 is currently being used

by the control domain.
5. Determine the physical device to which the network interface is
linked.
To determine the physical path of the onboard network interfaces
(nxge) currently configured in the system, check
/etc/path_to_inst:
primary# grep nxge /etc/path_to_inst
Note – If you discover that both buses are in use, you need to reconfigure
the control domain so that it is no longer using the bus you want to
remove.
6. Remove the PCI bus that is not currently being used by the control
domain based on your current configuration.
In this example, bus pci@500 is being removed from the primary
domain on a T5140 server.
primary# ldm remove-io pci@500 primary
7. Save this split configuration to the service processor.
In this example, the configuration is config_split.
primary# ldm add-spconfig config_split
This configuration, config_split, is also set as the next
configuration to be used after the reboot.
Note – Currently, there is a limit of eight configurations that can be saved

on the SP, not including the factory-default configuration.
8. Reboot the primary domain so that the change takes effect.

primary# shutdown -y -i6 -g0

9. Stop the domain to which you want to add the PCI bus.
The following example stops the ldom1 domain:
primary# ldm stop ldom1
10. Add the available bus to the domain that needs direct access.
The available bus is pci@500 and the domain is ldom1.
primary# ldm add-io pci@500 ldom1
11. Bind the resources to the domain.

The following command binds the resource to the ldom1 domain:
primary# ldm bind ldom1
12. Restart the domain so that the change takes affect.
The following command restarts the ldom1 domain:
primary# ldm start ldom1
13. Confirm that the correct bus is still assigned to the primary domain
and the correct bus is assigned to domain ldom1.
primary# ldm list-bindings primary ldom1
Note – If you have an Infiniband Host Channel Adapter (HCA) card, you
might need to turn on the I/O memory management unit (MMU) bypass
mode. For information about how to perform this task, see “Enabling the
I/O MMU Bypass Mode on a PCI Bus” in Chapter 5 Setting Up I/O
Domains of the Logical Domains 1.3 Administration Guide.
Configuring Virtual Network Multipathing With Multiple

I/O Domains
Internet Protocol Network Multipathing (IPMP) provides fault-tolerance
and load balancing across multiple network interface cards. Using IPMP,
you can configure one or more interfaces into an IP multipathing group.
After configuring IPMP, the system automatically monitors the interfaces
in the IPMP group for failure. If an interface in the group fails or is
removed for maintenance, IPMP automatically migrates, or fails over, the
failed interface’s IP addresses. In a Logical Domains environment, either
the physical or virtual network interfaces can be configured for failover
using IPMP.

The Logical Domains 1.3 release introduces support for link-based IPMP
with virtual network devices. When configuring an IPMP group with
virtual network devices, configure the group to use link-based detection.
If using older versions of the Logical Domains software, you can only
configure probe-based detection with virtual network devices.
For information about older versions of the Logical domains software, see
“Configuring and Using IPMP in Releases Prior to Logical Domains 1.3”
in Chapter 6 Using Virtual Networks in the Logical Domains 1.3

Configuring Virtual Network Devices Into an IPMP Group in a
Logical Domain
Reliability can be achieved in a logical domain by connecting each virtual

network device to virtual switch instances in different service domains.
Figure 6-3, for example, shows two virtual networks (vnet1 and vnet0)
connected to virtual switch instances (vsw1 and vsw0) in different service
domains (Service_1 and Service_2).
Service_1 LDom_A Service_2
vnet0 vsw0 nxge0
IPMP GRP
nxge1 vsw1 vnet1
Figure 6-3 Each Virtual Network Device Connected to Different Service

Domains
In the event of a physical link failure in the service domain, the virtual
switch device that is bound to that physical device detects the link failure.
Then, the virtual switch device propagates the failure to the
corresponding virtual network device that is bound to this virtual switch.
The virtual network device sends notification of this link event to the IP
layer in the guest LDom_A, which results in failover to the other virtual
network device in the IPMP group.
In addition to physical network failure, LDom_A can detect a virtual

network failure and trigger a failover following a service domain crash or
shutdown.

Refer to the Solaris 10 System Administration Guide: IP Services for more

information about how to configure and use IPMP groups.
Configuring and Using IPMP in the Service Domain
IPMP can be configured in the service domain by configuring virtual

switch interfaces into a group. Figure 6-4 shows two virtual switch
instances (vsw0 and vsw1) that are bound to two different physical
devices.

Service LDom
IPMP GRP
vsw0 vsw1
nxge0 nxge1
Figure 6-4 Two Network Interfaces Configured as Part of IPMP Group
The two virtual switch interfaces can then be plumbed and configured
into an IPMP group. In the event of a physical link failure, the virtual
switch device that is bound to that physical device detects the link failure.
Then, the virtual switch device sends notification of this link event to the
IP layer in the service domain, which results in failover to the other
virtual switch device in the IPMP group.
Using Link-Based IPMP in Logical Domains Virtual Networking
With Logical Domains 1.3, the virtual network and virtual switch devices
support link status updates to the network stack. By default, a virtual
network device reports the status of its virtual link through its LDC to the
virtual switch. This setup is enabled by default and does not require you
to perform additional configuration steps.
Sometimes it might be necessary to detect physical network link state

changes. For instance, if a physical device has been assigned to a virtual
switch, even if the link from a virtual network device to its virtual switch
device is up, the physical network link from the service domain to the
external network might be down. In such a case, it might be necessary to
obtain and report the physical link status to the virtual network device
and its stack.

The linkprop=phys-state option can be used to configure physical link

state tracking for virtual network devices as well as for virtual switch
devices. When this option is enabled, the virtual device (virtual network
or virtual switch) reports its link state based on the physical link state
while it is plumbed as an interface in the domain. You can use standard
Solaris network administration commands, such as dladm and ifconfig,
to check the link status. See the dladm(1M) and ifconfig(1M) man pages.
In addition, the link status is also logged in the /var/adm/messages file.

Note – You can run both link-state-unaware and link-state-aware vnet
and vsw drivers concurrently on a Logical Domains system. However, if
you intend to configure link-based IPMP, you must install the link-state-
aware driver. If you intend to enable physical link state updates, upgrade
both the vnet and vsw drivers to the Solaris 10 10/09 OS, and run at least
Version 1.3 of the Logical Domains Manager.
Configuring Virtual Disk Multipathing With Multiple I/O

Domains
If a virtual disk backend is accessible through different service domains,
then you can configure virtual disk multipathing so that the virtual disk
in a guest domain remains accessible if a service domain goes down. The
following are examples of a virtual disk backend that is accessible through
different service domains:
● A file on a network file system (NFS) server
● A shared physical disk that is connected to several service domains

To enable virtual disk multipathing, you must export a virtual disk

backend from the different service domains and add it to the same
multipathing group (mpgroup). The mpgroup is identified by a name and
is configured when the virtual disk backend is exported. Figure 6-5
illustrates how to configure virtual disk multipathing. In this example, a
multipathing group named foo is used to create a virtual disk, whose
backend is accessible from two service domains: primary and alternate.
Virtual Disk Backend

(NFS file or shared disk)

Service Service
Domain 1 Guest Domain Domain 2
(primary) (alternate)
vdisk
disk@primary-vds0 disk@primary-vds0
mpgroup=foo mpgroup=foo
Virtual Disk Server vdc Virtual Disk Server

(primary-vds0) (alternate-vds0)
LDC LDC
Hypervisor
Active Channel Backup Channel
Figure 6-5 Logical Domain Virtual Disk Multipathing
To configure virtual disk multipathing, perform the following steps:

1. Export the virtual backend from the primary service domain.
# ldm add-vdsdev mpgroup=foo backend-path1 \
volume@primary-vds0
Where backend-path1 is the path to the virtual disk backend from
the primary domain.
2. Export the same virtual backend from the alternate service domain.
# ldm add-vdsdev mpgroup=foo backend-path2 \
volume@alternate-vds0
Where backend-path2 is the path to the virtual disk backend from
the alternate domain.

Note – backend-path1 and backend-path2 are paths to the same virtual

disk backend, but from two different domains (primary and alternate).
These paths might be the same or might be different depending on the
configuration of the primary and alternate domains. The volume name is
a user choice. It might be the same or different for both commands.
3. Export the virtual disk to the guest domain.

# ldm add-vdisk disk-name volume@primary-vds0 ldom

For information about configuring virtual disk multipathing, see the
“Configuring Virtual Disks Multipathing” in Chapter 6 Using Virtual
Disks in the Logical Domains 1.3 Administration Guide.


Now that you know how to migrate a logical domain from one server to
another and how to use multiple I/O domains, try applying what you
have learned in the lab exercise that follows.

● Remove and restore a guest domain.

● Reconfigure guest domain virtual CPUs.
● Reconfigure guest domain memory.
● Split the PCI configuration to create I/O domains.
● Use ZFS volumes as virtual disks.
● Use a file as a virtual disk.
● Migrate an active guest domain.
● Reset the system to the factory default configuration.
Preparation
● Review the LDom services you configured in the previous exercise.
● Login name root
Guest domain operating system:
● Login name root
● Task 7 requires that you partner with another student to migrate a
guest domain from your machine to their machine. Contact your
instructor if you need help.

command responses shown in the lab are examples only. Depending upon

your lab configuration, the responses to the commands in the labs might
vary slightly.
Task 1– Remove and Restore a Guest Domain

In this task you stop, unbind resources, and remove the guest domain.
After the guest domain is removed, you restore it from a backup
configuration file.

1. Move to the control domain window.
2. List the logical domains currently configured on the system.
Name State Flags Cons VCPU Memory Util Uptime
primary active -n-cv- SP 8 2G 0.1% 1h 11m
ldom1 active -n---- 5000 8 2G 12% 10s
3. Stop the guest domain ldom1.
LDom ldom1 stopped
The stop-domain subcommand sends a shut down request to the logical
domain if the Solaris OS is booted. If the domain cannot be stopped by any
other means, use the -f option of the stop-domain subcommand to force
the domain to stop.
4. Release (unbind) all the resources attached to the guest domain
ldom1.
5. Remove the guest domain ldom1.


7. Restore the guest domain ldom1 configuration from the XML file you
previously stored in the /var/tmp directory.
primary# ldm bind-domain -i /var/tmp/ldom1.xml
8. List the guest domain ldom1 bound resources.

ldom1 bound ------ 5000 8 2G
MAC
00:14:4f:f8:d6:15
HOSTID
0x84f8d615
CONTROL
DEPENDENCY
master=
VCPU
VID PID UTIL STRAND
0 12 100%
1 13 100%
2 14 100%
3 15 100%
MEMORY
RA PA SIZE
0xe000000 0x8e000000 2G
VARIABLES
auto-boot?=false
boot-device=/virtual-devices@100/channel-devices@200/disk@0
NETWORK
PEER MAC MODE PVID VID MTU LINKPROP

primary-vsw0@primary 00:14:4f:fa:6a:f8 1 1500
DISK
VCONS
NAME SERVICE PORT
9. Start guest domain ldom1.

LDom ldom1 started

11. Boot the Solaris OS. Log in to the guest domain ldom1 as root.
{0} ok boot
...
machine4-vnet0 console login: root
Password: cangetin
...
12. Verify that the bound resources are available to the guest domain
ldom1 operation system.
guest# psrinfo

0 on-line since 02/09/2010 16:19:46
1 on-line since 02/09/2010 16:19:47
2 on-line since 02/09/2010 16:19:47
3 on-line since 02/09/2010 16:19:47
4 on-line since 02/09/2010 16:19:47
5 on-line since 02/09/2010 16:19:47
6 on-line since 02/09/2010 16:19:47
7 on-line since 02/09/2010 16:19:47
guest# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>
mtu 8232 index 1
vnet0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500
index 2 inet 192.168.XX.43 netmask ffffff00 broadcast
192.168.100.255 ether 8:0:20:ab:1:40
guest# format

Specify disk (enter its number): ^D

Task 2 – Reconfigure Guest Virtual CPUs

Dynamic reconfiguration (DR) is the ability to add or remove resources
while the operating system is running. In this task you use the Logical
Domains Management utility to dynamically add virtual CPUs to a guest
domain. You then remove the virtual CPUs. See Figure 6-6.

Hypervisor
CPUs
Resources
Figure 6-6 Dynamically Reconfiguring Guest Domain vCPUs

1. Verify that you have a terminal window open on the guest domain
and a console window open on the control domain.
3. Verify the Logical Domains dynamic reconfiguration daemon, drd, is
running in the guest domain ldom1.
guest# svcs drd
online 11:46:05 svc:/platform/sun4v/drd:default
4. Use the psrinfo command to determine how many virtual CPUs
Note – The output for the following commands are specific to the Sun
SPARC Enterprise T5140 server, which is used as an example in this
course. Based on the server you are using, your system configuration and
server architecture, the output and your responses will vary.
guest# psrinfo
0 on-line since 02/09/2010 16:19:46
1 on-line since 02/09/2010 16:19:47

2 on-line since 02/09/2010 16:19:47

3 on-line since 02/09/2010 16:19:47
4 on-line since 02/09/2010 16:19:47
5 on-line since 02/09/2010 16:19:47
6 on-line since 02/09/2010 16:19:47
7 on-line since 02/09/2010 16:19:47
6. List all the host server CPU resources.
primary# ldm list-devices -a vcpu

VCPU
PID %FREE PM
0 0 no
1 0 no
2 0 no
3 0 no
4 0 no
5 0 no
6 0 no
7 0 no
8 0 no
9 0 no
10 0 no
11 0 no
12 0 no
13 0 no
14 0 no
15 0 no
16 100 ---
17 100 ---
18 100 ---
...
Are there sufficient resources available to allocate a total of 16 virtual
CPUs to the guest domain ldom1? Yes, based on the output of the
previous command.
7. Allocate a total of 16 virtual CPUs to guest domain ldom1.
or
8. List the bindings of guest domain ldom1.
ldom1 active -n---- 5000 16 2G 0.1% 38m

...
VCPU
VID PID UTIL STRAND
0 8 0.2% 100%
1 9 0.0% 100%
2 10 0.0% 100%
3 11 0.0% 100%
4 12 0.0% 100%
5 13 0.0% 100%
6 14 0.3% 100%
7 15 0.0% 100%

8 16 0.0% 100%
9 17 0.0% 100%
10 18 0.1% 100%
11 19 0.0% 100%
12 20 0.1% 100%
13 21 0.0% 100%
14 22 0.0% 100%
15 23 0.0% 100%
...
9. Move to guest domain window.
10. Run the psrinfo command to determine how many virtual CPUs
guest# psrinfo
0 on-line since 02/09/2010 16:19:46
1 on-line since 02/09/2010 16:19:47
2 on-line since 02/09/2010 16:19:47
3 on-line since 02/09/2010 16:19:47
4 on-line since 02/09/2010 16:19:47
5 on-line since 02/09/2010 16:19:47
6 on-line since 02/09/2010 16:19:47
7 on-line since 02/09/2010 16:19:47
8 on-line since 02/09/2010 16:28:08
9 on-line since 02/09/2010 16:28:08
10 on-line since 02/09/2010 16:28:08
11 on-line since 02/09/2010 16:28:08
12 on-line since 02/09/2010 16:28:08
13 on-line since 02/09/2010 16:28:08
14 on-line since 02/09/2010 16:28:08
15 on-line since 02/09/2010 16:28:08
12. Remove eight vCPUs from guest domain ldom1.
primary# ldm remove-vcpu 8 ldom1
or


14. Run the psrinfo command to determine how many CPUs can be
guest# psrinfo
0 on-line since 02/09/2010 16:19:46
1 on-line since 02/09/2010 16:19:47
2 on-line since 02/09/2010 16:19:47
3 on-line since 02/09/2010 16:19:47
4 on-line since 02/09/2010 16:19:47

5 on-line since 02/09/2010 16:19:47
6 on-line since 02/09/2010 16:19:47
7 on-line since 02/09/2010 16:19:47
Task 3 – Reconfigure Guest Domain Memory

To reconfigure memory in any domain except the primary domain, you
must stop the domain first. You can then reconfigure the memory, and the
new memory configuration will be available when the domain is
restarted. In this task, you use the Logical Domains Management utility to
add memory to and remove memory from a guest domain. See Figure 6-7.
Hypervisor
memory
Resources
Figure 6-7 Guest Domain Delayed Memory Reconfiguration

2. Run the prtdiag command to determine how much memory can be

3. Shut down the guest domain operating system.

guest# shutdown -y -i0 -g0
Shutdown started. Tuesday, February 9, 2010 2:41:47 PM MST
...
{0} ok
5. List all the Sun SPARC EnterpriseT5140 memory resources.
primary# ldm list-devices -a memory

MEMORY
PA SIZE BOUND
0x0 512K _sys_
0x80000 1536K _sys_
0x200000 94M _sys_
0x6000000 32M _sys_
0x8000000 96M _sys_
0xe000000 2G primary
0x8e000000 2G ldom1
0x10e000000 3872M
Are there sufficient resources available to allocate a total of four
gigabytes of memory to the guest domain ldom1? Yes.
6. Stop guest domain ldom1.
LDom ldom1 stopped
primary active -n-cv- SP 8 2G 0.4% 1d 3h
ldom1 bound ------ 5000 8 2G
7. Allocate four gigabytes of memory to guest domain ldom1.
primary# ldm set-memory 4G ldom1
or
Before you change the memory configuration, the guest domain must be in
the bound or inactive state.

8. List the bindings of guest domain ldom1.

ldom1 bound ------ 5000 8 4G
...
MEMORY
RA PA SIZE
0xe000000 0x8e000000 4G
...

LDom ldom1 started
11. Boot the Solaris 10 operating system and log in as root.
{0} ok boot
Boot device: vdisk0 File and args:
...
Password: cangetin
...
12. Run the prtdiag command to determine how much memory can be
13. Shut down the guest domain operating system.
guest# shutdown -y -i0 -g0
Shutdown started. Tuesday, February 9, 2010 4:48:47 PM MST
...
{0} ok
15. Stop guest domain ldom1.
LDom ldom1 stopped
primary active -n-cv- SP 8 2G 0.4% 1d 3h 28m
ldom1 bound ------ 5000 8 4G

16. Remove two gigabytes of memory from guest domain ldom1.

primary# ldm remove-memory 2G ldom1
Before you change the memory configuration, the guest domain must be in
the bound or inactive state.
LDom ldom1 started

19. Boot the Solaris 10 operating system. Log in as root.
{0} ok boot
...
Password: cangetin
...
20. Run the prtdiag command to verify the memory configuration

change.
Task 4 – Split the PCI Configuration to Create I/O

Domains
The PCIe bus architecture on the Sun SPARC Enterprise T5140 server
consists of two ports (leaves) with various bus devices attached to them.
These are identified on the server with the names pci@400 and pci@500.
In a multidomain environment, the PCIe bus can be programmed to
assign each bus to a separate domain using the Logical Domains Manager.
Thus, you can enable more than one domain with direct access to physical
devices instead of using I/O virtualization.

In this task you use the Logical Domains Management utility to split the
PCI bus such that the control (primary) domain maintains access to
network and disk devices on one PCI bus. You then bind the other PCI
bus to the guest domain ldom1. Finally, you configure the guest domain
physical network interface to provide direct access to the network. See
Figure 6-8.
Control/Service Domain Guest Service/IO Domain

Hypervisor
pci@400 pci@500
Resources
Figure 6-8 Split PCI Configuration

2. List the primary domain’s current bindings to determine PCI bus
ownership.

...
IO
pci@400 pci_0
pci@500 pci_1
...
Note that pci@400 and pci@500 are currently bound to the primary
domain.

3. Determine which disk is being used as the boot disk.

primary# df /
/ (/dev/dsk/c1t0d0s0 ):260974732 blocks 16750277 files
If using ZFS, use the zpool status command to determine the

physical disk
4. Determine the physical device to which the boot disk is linked.
primary# ls -l /dev/dsk/c1t0d0s0

lrwxrwxrwx 1 root root 49 Jan 15 15:32 /dev/dsk/c1t0d0s0 -
> ../../devices/pci@400/pci@0/pci@8/scsi@0/sd@0,0:a
On which PCI bus is the control domain boot disk located?
PCI pci@400.
5. Determine which network interfaces are currently used (direct I/O
and virtual service) by the control (service) domain operating
system.
8232 index
1
vsw0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
ether 0:14:4f:1d:e9:b6
VCC
VSW
primary-vsw0 primary 00:14:4f:fa:6a:f8 nxge0 0 switch@0 1 1 1500
VDS
primary-vds0 primary vol0 /dev/dsk/c1t1d0s2
Which network interface is currently being used by the control

domain? Based on the above example, nxge0 is currently being used by
the control domain.

6. Check /etc/path_to_inst to determine the physical path of the

network interfaces currently configured in the system.
primary# grep network /etc/path_to_inst
"/virtual-devices@100/channel-devices@200/virtual-network-switch@0" 0 "vsw"
"/pci@400/pci@0/pci@c/network@0" 0 "e1000g"
"/pci@400/pci@0/pci@c/network@0,1" 1 "e1000g"

Based on the information gathered in Step 1 through Step 6, you
should now be able to determine which PCI bus the control
domain’s devices are associated with. Is there a bus that can be
removed from the control domain without reconfiguring the current
disks and network interfaces?
Based on the above example, the answer is no. In the example, physical
network interface nxge0 (mapped to vsw0) is attached to PCI bus
pci@500. The boot disk is on PCI bus pci@400. To split the PCI buses, all
the devices used by the control domain services must be moved to the same
PCI bus where the service domain boot disk is located.
Note – If the devices are on different buses, Step 7 will be required to

move the network device to the same bus as the boot device. If the devices
are already on the same bus, then Step 7 can be skipped.
7. To reconfigure virtual switch vsw0, run the ldm set-vswitch

command. Replace network interface nxge0 (PCI bus pci@500) with
e1000g0 (PCI bus pci@400).
This example assumes that the boot device for the control domain is on PCI
bus pci@400, in which case, the network device would also need to be
associated with PCI bus pci@400. Note that if the devices are on different
buses when the split occurs, the server may require alternative steps to
recover because the control domain may not boot.
a. Change the virtual switch (primary-vsw0) network device
assignment to e1000g0.
primary# ldm set-vswitch net-dev=e1000g0 primary-vsw0
take effect.

b. Run the ldm list-domain -l primary to determine the

service domain status.
primary active -ndcv- SP 8 2G 0.1% 5h 25m
FLAGS
normal,delayed(modify),control,vio-service

SOFTSTATE
Solaris running
...
c. Reboot the service domain. Log back in as root.
...
console login: root
Password: cangetin
...
The will cause the guest domain window to close. Reopen the terminal
window and reconnect to the guest domain.
d. Verify that the virtual switch service has been updated.
VCC
VSW
primary-vsw0 primary 00:14:4f:fb:79:88 e1000g0 0 switch@0 1 1 1500
VDS
e. Move to the guest domain window.

f. Log in as root.
Password: cangetin
...
g. Run the ping command to verify that you have access to the
subnet your guest domain is assigned to. For example, to ping
the 192.168.XX.0 network, use the following command:
guest# ping -s 192.168.XX.255
....
^C

9. Remove the PCI bus that is not currently being used by the control
domain.
The following is an example of removing a PCI bus on a T5140 server.
primary# ldm remove-io pci@500 primary
take effect.
10. Save the split configuration to the system controller. Name this

configuration config_split.
primary# ldm add-spconfig config_split
11. Reboot the control domain.
...
console login: root
Password: cangetin
....
The will cause the guest domain window to close. Reopen the terminal
window and reconnect to the guest domain.
Caution – If you happen to remove the primary bus by error, you can return to
the SC and do a reset. This voids the remove-io command used above and you
can then remove the correct bus.
Upon reboot, if you see an error message such as the following:
Boot device: net File and args:

ERROR: boot-read fail
Evaluating:
Can’t locate boot device
The error occurs because you removed the wrong PCI bus. Therefore, make sure
that you remove the correct PCI bus.
12. List the configurations on the system controller to verify that
config_split is current.
factory-default
config_initial
config_split [current]

13. Verify that the PCI bus that was removed in the previous steps is not
bound to the control domain.
...
IO
pci@400 pci_0

...
14. Place guest domain ldom1 in the bound state.
ldom1 active -n---- 5000 8 2G 25% 10m
LDom ldom1 stopped
ldom1 bound ------ 5000 8 2G
15. Add the PCI bus that was removed in the previous steps (from the
control domain) to guest domain ldom1.
primary# ldm add-io pci@500 ldom1
Note that this operation will turn the ldom1 domain in to a direct I/O
domain.
16. Verify that the PCI bus is now bound to guest domain ldom1.
Note that the output for the following command might vary from
the example shown, based on hardware.
ldom1 bound ------ 5000 8 2G
...
IO
pci@500 pci_1
...

19. Boot the Solaris OS. After the Solaris OS is completely booted, log in
as root.
{0} ok boot
...
Password: cangetin
...
20. Run the grep network /etc/path_to_inst command to

identify the network devices that can be seen by the guest domain
ldom1 operating system.
guest# grep network /etc/path_to_inst
"/virtual-devices@100/channel-devices@200/network@0" 0 "vnet"
21. Plumb the first network interface attached to the PCI bus pci@500.
guest# ifconfig nxge0 plumb
...
Jan 20 16:31:07 machine4-vnet0 nxge: NOTICE: nxge0: xcvr addr:0x1d - link
is up 100 Mbps full duplex
...
22. Manually configure the IP addressing information. Use the IP

information for your lab machine in the /etc/hosts file.
The following example is from machine # 4.
guest# ifconfig nxge0 192.168.XX.41 netmask 255.255.255.0 broadcast
+ up
23. Verify that the operating system can access the subnet associated
with this interface. Use the information you gathered in previous
steps.
guest# ping -i nxge0 -s 192.168.XX.255
...
^C

Task 5 – Use a File as a Virtual Disk

In this task, you create a disk image file, export it to the guest domain,
and create a file system on it (see Figure 6-9). Then you remove it from the
system.

primary-vds0

vol1 vdisk1
c0d1s0
S10U8-5g.img
c1t0d0s0
Hypervisor
/pci@400/../sd@0,0 Resource
Internal Disk 0
Figure 6-9 Exporting an Image File to the Guest Domain

2. Create a directory named /ldoms/images. This directory will be
used to store the disk image file.
primary# mkdir -p /ldoms/images
3. Run the following command to create a disk image.
primary# mkfile 5G /ldoms/images/S10U8-5g.img
This will take a couple of minutes to complete.

4. Add a virtual disk service device to virtual disk service vds0 using
the /ldoms/images/S10U8-5g.img file. Name this device vol1.
primary# ldm add-vdiskserverdevice /ldoms/images/S10U8-5g.img \
vol1@primary-vds0
5. Assign virtual disk vol1 to guest domain ldom1 using the
add-vdisk subcommand. Name the virtual disk vdisk1.

7. Log in as root.
Console login: root
Password: cangetin
...
8. List the contents of the /dev/rdsk directory to determine the
currently configured raw devices.
The output of the following command varies based on your system
configuration:
guest# ls /dev/rdsk
c0d0s0 c0d0s2 c0d0s4 c0d0s6 c0d1s0 c0d1s2 c0d1s4 c0d1s6
Note that the special files for the new disk (c0d1) are now available.
Note – If the special files for the new disk (c0d1) are not present, run the
devfsadm -v command to create the new special file for the virtual disk.
9. Run the format command to view the new virtual disk. Display the
partition table.
guest# format

1. c0d1 <SUN-DiskImage-5GB cyl 17474 alt 2 hd 1 sec 600>
selecting c0d1
[disk formatted, no defect list found]
FORMAT MENU:
disk - select a disk
type - select (define) a disk type

partition - select (define) a partition table

current - describe the current disk
format - format and analyze the disk
repair - repair a defective sector
show - translate a disk address
label - write label to the disk
analyze - surface analysis
defect - defect list management
backup - search for backup labels
verify - read and display labels

save - save new disk/partition definitions
volname - set 8-character volume name
!<cmd> - execute <cmd>, then return
quit
format> partition
PARTITION MENU:
0 - change `0' partition
select - select a predefined table
modify - modify a predefined partition table
name - name the current table
print - display the current table
label - write partition map and label to the disk
quit
partition> print

2 backup wm 0 - 17473 5.00GB (17474/0/0) 10484400

partition> modify
Select partitioning base:
0. Current partition table (original)
1. All Free Hog
Choose base (enter number) [0]? 1

0 root wm 0 0 (0/0/0) 0
1 swap wu 0 0 (0/0/0) 0
2 backup wu 0 - 17473 5.00GB (17474/0/0) 10484400

6 usr wm 0 0 (0/0/0) 0
Do you wish to continue creating a new partition

table based on above table[yes]? y
Free Hog partition[6]? 0
Enter size of partition '1' [0b, 0c, 0.00mb, 0.00gb]:

0 root wm 0 - 17473 5.00GB (17474/0/0) 10484400
1 swap wu 0 0 (0/0/0) 0
2 backup wu 0 - 17473 5.00GB (17474/0/0) 10484400
6 usr wm 0 0 (0/0/0) 0
Okay to make this the current partition table[yes]? yes

Enter table name (remember quotes): "test1"
Ready to label disk, continue? y
partition> ^D

10. Run the newfs command to create a file system on the raw disk
device, which you partitioned in step 7.
Example: guest# newfs /dev/rdsk/c0d1s0
newfs: construct a new file system /dev/rdsk/c0d1s0: (y/n)? y
/dev/rdsk/c0d1s0: 10484400 sectors in 17474 cylinders of 1 tracks,
600 sectors 5119.3MB in 137 cyl groups (128 c/g, 37.50MB/g, 4800 i/g)
super-block backups (for fsck -F ufs -o b=#) at: 32, 76832, 153632,
230432, 307232, 384032, 460832, 537632, 614432, 691232, 9753632, 9830432,
9907232, 9984032, 10060832, 10137632, 10214432, 10291232, 10368032,

10444832
11. Mount the new file system as /mnt.
guest# mount /dev/dsk/c0d1s0 /mnt
12. Run the df -h /mnt command to verify the new file system
configuration.
guest# df -h /mnt
Filesystem size used avail capacity Mounted on
/dev/dsk/c0d1s0 4.9G 5.0M 4.9G 1% /mnt
13. Unmount /mnt.
guest# umount /mnt
15. Remove virtual disk vdisk1 from guest domain ldom1.
primary# ldm remove-vdisk vdisk1 ldom1
17. Log in as root.
Console login: root
Password: cangetin
...
18. Run the format command to verify that disk c0d1 has been
removed.
guest# format

19. Run the devfsadm -vC command to remove the unused special files.
# devfsadm -vC
...

devfsadm[852]: verbose: removing file: /dev/dsk/c0d1s0

devfsadm[852]: verbose: removing file: /dev/rdsk/c0d1s0

21. Remove virtual disk device vol1 from the service domain.
primary# ldm remove-vdiskserverdevice vol1@primary-vds0
22. Verify the configuration change by listing the guest domain ldom1
bindings and primary domain services.
ldom1 active -n---- 5000 8 2G 0.2% 20m
...
DISK
NAME VOLUME TOUT ID DEVICE SERVER
MPGROUP
...

Task 6 – Export a ZFS Volume as a Virtual Disk

In this task you create a ZFS volume in the control domain and make that
volume available to a guest domain as a virtual disk. See Figure 6-10.

primary-vds0
zvol zvdisk
c0d1s0

tank1/vol1
c1t2d0
Hypervisor
/pci@400/../sd@2,0 Resources
Internal Disk 2
Figure 6-10 Exporting a ZFS Volume to the Guest Domain

1. In the control domain window, run the following command to create
a ZFS storage pool using the unused disk drive on the control
domain. The following example assumes that the disk devices are on
c1. Use the format command to determine which device to use.
2. Run the following command to create a 500 megabyte ZFS volume
named vol1.
primary# zfs create -V 500m tank1/vol1

ZFS volume (tank1/vol1) have been created.
primary# zfs list
NAME USED AVAIL REFER MOUNTPOINT
tank1 500M 273G 21K /tank1
tank1/vol1 500M 274G 16K
4. Add the /dev/zvol/dsk/tank1/vol1 device to the control domain
virtual disk service. Name the virtual disk device zvol.
primary# ldm add-vdiskserverdevice /dev/zvol/dsk/tank1/vol1 \

zvol@primary-vds0
5. Assign the disk zvol to guest domain ldom1 using the add-vdisk
subcommand. Name the virtual disk zvdisk.
primary# ldm add-vdisk zvdisk zvol@primary-vds0 ldom1
7. List the contents of the /dev/rdsk directory to determine the
currently configured raw devices.
Note that the out for the following command varies based on the server and
current configuration.
guest# ls /dev/rdsk
Note that the special files for the new disk (c0d1) are now available.
8. Run the format command to label and partition the new disk.
You need to label the disk to use any disk partitions.
guest# format

1. c0d1 <SUN-DiskImage-500MB cyl 1704 alt 2 hd 1 sec 600>
selecting c0d1
[disk formatted, no defect list found]
FORMAT MENU:
disk - select a disk
type - select (define) a disk type
partition - select (define) a partition table
current - describe the current disk

format - format and analyze the disk

repair - repair a defective sector
show - translate a disk address
label - write label to the disk
analyze - surface analysis
defect - defect list management
backup - search for backup labels
verify - read and display labels
save - save new disk/partition definitions
volname - set 8-character volume name

quit
format> partition
PARTITION MENU:
select - select a predefined table
modify - modify a predefined partition table
name - name the current table
print - display the current table
label - write partition map and label to the disk
quit
partition> print

2 backup wm 0 - 1703 499.22MB (1704/0/0) 1022400
partition> modify

Select partitioning base:

0. Current partition table (original)
1. All Free Hog
Choose base (enter number) [0]? 1

0 root wm 0 0 (0/0/0) 0
1 swap wu 0 0 (0/0/0) 0
2 backup wu 0 - 1703 499.22MB (1704/0/0) 1022400

6 usr wm 0 0 (0/0/0) 0
Do you wish to continue creating a new partition

table based on above table[yes]? yes
Free Hog partition[6]?
Enter size of partition '0' [0b, 0c, 0.00mb, 0.00gb]: $
Warning: no space available for '1' from Free Hog partition

0 root wm 0 - 1703 499.22MB (1704/0/0) 1022400
1 swap wu 0 0 (0/0/0) 0
2 backup wu 0 - 1703 499.22MB (1704/0/0) 1022400
6 usr wm 0 0 (0/0/0) 0
Okay to make this the current partition table[yes]? yes

Enter table name (remember quotes): "test2"
Ready to label disk, continue? yes
partition> ^D

9. Run the newfs command to create a file system on the new ZFS
virtual disk discovered in the previous step.
guest# newfs /dev/rdsk/c0d1s0
newfs: construct a new file system /dev/rdsk/c0d1s0: (y/n)? y
/dev/rdsk/c0d1s0: 1022400 sectors in 1704 cylinders of 1 tracks, 600
sectors 499.2MB in 107 cyl groups (16 c/g, 4.69MB/g, 2240 i/g)
super-block backups (for fsck -F ufs -o b=#) at: 32, 9632, 19232, 28832,
38432, 48032, 57632, 67232, 76832, 86432, 931232, 940832, 950432, 960032,
969632, 979232, 988832, 998432, 1008032, 1017632

10. Mount the new file system as /mnt.
guest# mount /dev/dsk/c0d1s0 /mnt
11. Run the df -h /mnt command to verify the file system
configuration.
guest# df -h /mnt
Filesystem size used avail capacity Mounted on
/dev/dsk/c0d1s0 468M 1.0M 420M 1% /mnt
12. Unmount the new file system.
guest# umount /mnt
14. Remove virtual disk zvdisk from guest domain ldom1.
primary# ldm remove-vdisk zvdisk ldom1
15. Run the format command to verify that disk c0d1 has been
removed.
guest# format

16. Run the devfsadm -vC command to remove the unused special files.
guest# devfsadm -vC


18. Remove virtual disk device zvol from the virtual disk service.

primary# ldm remove-vdiskserverdevice zvol@primary-vds0
19. Verify the configuration change by listing the guest domain ldom1
bindings and the control domain services.
ldom1 active -n---- 5000 8 2G 0.2% 50m
...
DISK
NAME VOLUME TOUT ID DEVICE SERVER
MPGROUP
...
...
VDS
20. Run the following commands to destroy the ZFS pool tank1.
primary# zpool destroy -f tank1
primary# zfs list
no datasets available

Task 7 – Migrate an Active Guest Domain

In this task you migrate an active guest domain to another system. You
reconfigure the system so that your guest domain can be migrated. You
create a bootable Solaris 10 image file and share it with your lab partner’s
guest domain. You then perform the migration. Note that you must work
with a lab partner to complete all the steps.

Note – Migrating active guest domains requires planning and preparation
to ensure a successful migration. For example, adequate resources must
be available on the target system. This not only includes resources such as
CPUs and memory, but also I/O services, boot environment, and software
applications. In production environments, it is highly recommended that
you use shared storage between the source and target systems of the
migration to ensure software consistency. The storage could be a shared
LUN from a SAN or a file from an NFS server.
Perform the following steps to migrate an active guest domain:

1. Verify that you have been assigned a lab partner who is working on
another machine. If you need assistance, contact your instructor.
2. In the control domain window, list the services currently configured
in the primary domain.
VCC
VSW
primary-vsw0 primary 00:14:4f:fa:6a:f8 e1000g0 0 switch@0 1 1 1500
VDS
3. Run the ldm list-bindings ldom1 command to determine the

resources that are currently bound to guest domain ldom1.
ldom1 active -n---- 5000 8 2G 0.2% 15h 57m
MAC
00:14:4f:f9:b7:b4
HOSTID
0x84f9b7b4
CONTROL

DEPENDENCY
master=
VCPU
VID PID UTIL STRAND
0 8 0.8% 100%
1 9 0.1% 100%
2 10 0.1% 100%
3 11 0.1% 100%
4 12 0.1% 100%
5 13 0.1% 100%

6 14 0.2% 100%
7 15 0.0% 100%
MEMORY
RA PA SIZE
0xe000000 0x8e000000 2G
VARIABLES
auto-boot?=false
boot-device=vdisk0
IO
pci@500 pci_1
NETWORK
PEER MAC MODE PVID VID MTU LINKPROP

primary-vsw0@primary 00:14:4f:fa:61:06 1 1500
DISK
VCONS
NAME SERVICE PORT
Based on the information shown in step 2 and step 3, can guest

domain ldom1 be migrated to another system?
No. Guest domain ldom1 is currently in the active state and it is
configured as a direct I/O domain. Direct I/O domains cannot be migrated
in the active state. In the following steps, you revert the guest domain
ldom1 to the config_initial configuration you stored on the system
controller.

4. Set the system controller configuration to config_initial.

primary# ldm set-spconfig config_initial
factory-default
config_initial [next poweron]
config_split
5. Exit to the system controller.

primary# #.
Serial console stopped.
->
6. In the system controller, change to the /SYS directory and run the
reset command.
-> cd /SYS
/SYS
-> reset
Are you sure you want to reset /SYS (y/n)? y
Performing reset on /SYS
Note that the reset command performs a graceful shutdown of the system.
The will cause the guest domain window to close. Reopen the guest domain
window after the system has rebooted.
7. Start the serial console. After the system has booted, log in as root.
Are you sure you want to start /SP/console (y/n)? y
Serial console started. To stop, type #.
...
console login: root
Password: cangetin
...
8. Verify that config_initial is current.
factory-default
config_initial [current]
config_split
...

9. Generate a long listing of guest domain ldom1.

primary# ldm list-domain -l ldom1
ldom1 inactive ------ 8 2G
...
IO
DEVICE OPTIONS
pci@500

...
Note that PCI bus pci@500 is bound to ldom1.
10. Remove PCI bus pci@500 from ldom1.
primary# ldm remove-io pci@500 ldom1
Note – In the following steps, you create an image file to be used as a

shared storage during the guest domain migration.
11. Working with your lab partner, designate one of your lab systems as
the source machine and the other as the target machine.
The source machine will contain the bootable image file. The image
file will then be shared with the target machine using NFS.
12. On the source machine, create an image file. Use NFS to share it with
the target machine.
primary# mkfile 10g /ldoms/images/bootdisk
primary# vi /etc/dfs/dfstab
...
share -F nfs -o anon=0 /ldom/images
...
primary# shareall
13. On the source machine, remove the vdisk vdisk0 from ldom1.
primary# ldm remove-vdisk vdisk0 ldom1
14. On the source machine, add the new image file to disk service
primary-vds0. Name the new disk vol1.
primary# ldm add-vdsdev /ldoms/images/bootdisk vol1@primary-vds0
15. On the source machine, add the vdisk vdisk0 to ldom1. Use vol1
from the disk service.
16. Bind the configuration to guest domain ldom1.

17. Open a console session on ldom1 and JumpStart the guest domain.
...
Boot device: /virtual-devices@100/channel-devices@200/network@0 File and
args: - install
Requesting Internet Address for 0:14:4f:fc:6:4
Using RARP/BOOTPARAMS...

Internet address is: 192.168.6.43
hostname: machine4-vnet0
domainname: brom.suned.com
...
This will take approximately 30 minutes to complete.
18. On the target machine, add the NFS file system to disk service
primary-vds0. Name the new disk vol1.
primary# ldm add-vdsdev /net/IP_Addr/ldoms/images/bootdisk
vol1@primary-vds0
19. Remove guest domain ldom1 from the target machine.
primary active -n-cv SP 8 2G 0.2% 36m
20. On the source machine, verify that the JumpStart operation has
completed.
21. Log in to the guest domain as root and verify that the Logical
Domains dynamic reconfiguration daemon, drd, is running in the
guest domain ldom1.
Console login: root
Password: cangetin
...
guest# svcs drd
online 11:46:05 svc:/platform/sun4v/drd:default
22. Move back to the control domain on the source machine.
~.
23. Run the ping command to verify communication between the
control domains of the source and target machines involved in the
migration.
primary# ping <IP_Addr_Target>

<IP_Addr_Target> is alive
24. On the source machine, run the ldm migrate -n command to
perform a dry run of the migration of the active guest domain ldom1.
In the command, specify ldom2 as the new name of the migrated
domain.
This example shows you how to change the name of the guest domain. If
you wish to retain the same name, simply omit the target name field.
primary# ldm migrate-domain -n ldom1 root@IP_Addr_Target:ldom2

Target Password: cangetin
primary#
The following message is returned when the dynamic reconfiguration
daemon (drd) is not running in the host domain. For guest domains with
more then one virtual CPU, drd must be running.
Migrating a domain with more than one vcpu requires CPU
DR, which is not available for LDom ldom1.
If no error messages are returned, the active guest domain migration
should proceed normally. If errors are indicated, resolve them before
continuing on to the next step.
25. Migrate the active guest domain to the target machine. In the
command, specify ldom2 as the new name of the migrated domain.
primary# ldm migrate-domain ldom1 root@IP_Addr_Target:ldom2
primary#
The migrate can take a couple minutes to complete.
You can check the progress of the migration by running the
ldm list -o status or ldm list-domain command.
For example, to check migration status on the target machine:
primary# ldm list -o status ldom2
NAME
ldom2
STATUS
migration 37% ldom01
or
primary active -n-cv- SP 8 2G 15% 18h 28m
ldom2 bound -----t 5000 1 2G

26. After the migration is complete, list all available domains on the
source machine.
Note that ldom1 has been destroyed.
target machine.

ldom2 active -n---- 5000 8 2G 0.1% 5m
Note that ldom2 is present and in the active state.
28. On the target machine, open a console session on the guest domain
and log in as root.
Console login: root
Password: cangetin
...
29. Verify the guest domain ldom2 configuration.
guest# prtdiag
======================== Virtual CPUs ============================

------ --------- ---------------------- -------
1 1165 MHz SUNW,UltraSPARC-T2+
=========================== IO Devices ===========================

Slot + Bus Name + Model
Status Type Path
------------------------------------------------------------------

guest# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index
1
vnet0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
guest# format

30. Move back to the control domain.
~.
Note – In the following steps, the guest domain ldom2 will be migrated
back to the original machine. The roles of source and target machines is
now reversed.
31. On the source machine (old target machine), run the ldm migrate -
n command to perform a dry run of the migration of active guest
domain ldom2. In the command, specify ldom1 as the new name of
the migrated domain.
primary# ldm migrate-domain -n ldom2 root@IP_Addr_Target:ldom1
primary#
If no error messages are returned, the active guest domain migration
should proceed normally. If errors are indicated, resolve them before
continuing on to the next step.
32. Migrate the active guest domain ldom2 to the target machine (old
source machine). In the command, specify ldom1 as the new name of
the migrated domain.
primary# ldm migrate-domain ldom2 root@IP_Addr_Target:ldom1
primary#
The migrate can take a couple minutes to complete.
You can check the progress of the migration by running the
ldm list -o status or ldm list-domain command.
For example, to check migration status on the target machine:

primary# ldm list -o status ldom1

NAME
ldom1
STATUS
migration 43% ldom02
or

primary active -n-cv- SP 8 2G 15% 22h 44m
ldom1 bound -----t 5000 1 2G
source machine.
Note that ldom2 has been destroyed.
target machine.
ldom1 active -n---- 5000 8 2G 0.1% 3m
Note that ldom1 is present and in the active state.
35. On the target machine, move to guest domain and log in as root.
...
Console login: root
Password: cangetin
...

36. Verify the guest domain ldom1 configuration.

guest# prtdiag
======================== Virtual CPUs ============================

------ --------- ---------------------- -------
=========================== IO Devices ===========================

Slot + Bus Name + Model
Status Type Path
------------------------------------------------------------------
guest# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index
1
vnet0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
guest# format


Task 8 – Reset the System to the Factory Default

Configuration
In this task you remove the guest domain ldom1 and reset the primary
domain back to the factory default configuration. Then you remove the
user-defined configuration files stored on the system controller.
Note – The guest domain ldom1 might already be removed from your

server as a result of the previous lab.

2. List the available domains on your machine. If a guest domain exists,
proceed to step 3. If there are no guest domains, proceed to step 4.
ldom1 active -n---- 5000 8 2G 8.2% 14m
In this example, the guest domain ldom1 exists.
3. Remove guest domain ldom1.
LDom ldom1 stopped
primary active -t-cv SP 8 2G 0.2% 25m
5. List the logical domain configuration files stored on the system
controller.
factory-default
config_initial [next poweron]
config_split
6. Set the next logical domain configuration to factory-default.
primary# ldm set-spconfig factory-default
7. Disable the vntsd service.
primary# svcadm disable vntsd

8. Move the interface configuration file to the original interface name.

primary# mv /etc/hostname.vsw0 /etc/hostname.nxge0
9. Move to the system controller.
primary# #.
Serial console stopped.
->
10. In the system controller, change to the /SYS directory and run the

reset command.
-> cd /SYS
/SYS
-> reset
Are you sure you want to reset /SYS (y/n)? y
Performing reset on /SYS
11. Start the serial console. After the system has booted, log in as root.
Are you sure you want to start /SP/console (y/n)? y
Serial console started. To stop, type #.
...
console login: root
Password: cangetin
...
controller.
primary# ldm list-config
config_initial
config_split
Note that the factory-default configuration is the current
configuration.
13. Remove all the user-defined configuration files stored on the system
controller.
primary# ldm remove-config config_initial
primary# ldm remove-config config_split
controller.
primary# ldm list-config

15. Generate a long list of the primary domain to verify that it has
returned to the factory default state.
primary active -n-c-- SP 64 7968M 0.1% 3m
SOFTSTATE
Solaris running

MAC
00:14:4f:46:3e:4e
HOSTID
0x84463e4e
CONTROL
DEPENDENCY
master=
VCPU
VID PID UTIL STRAND
0 0 0.5% 100%
1 1 0.0% 100%
2 2 0.0% 100%
3 3 0.1% 100%
4 4 0.1% 100%
5 5 0.0% 100%
6 6 0.0% 100%
7 7 0.0% 100%
8 8 0.0% 100%
9 9 0.0% 100%
10 10 0.0% 100%
11 11 0.0% 100%
12 12 0.0% 100%
13 13 0.0% 100%
14 14 0.0% 100%
15 15 0.0% 100%
16 16 0.0% 100%
17 17 0.0% 100%
18 18 0.0% 100%
19 19 0.1% 100%
20 20 0.0% 100%
21 21 0.0% 100%
22 22 0.0% 100%

23 23 0.0% 100%
24 24 0.2% 100%
25 25 0.0% 100%
26 26 0.0% 100%
27 27 0.0% 100%
28 28 0.2% 100%
29 29 0.0% 100%
30 30 0.0% 100%
31 31 0.0% 100%
64 64 0.1% 100%

65 65 0.1% 100%
66 66 0.0% 100%
67 67 0.0% 100%
68 68 0.0% 100%
69 69 0.0% 100%
70 70 0.0% 100%
71 71 0.0% 100%
72 72 0.0% 100%
73 73 0.0% 100%
74 74 0.0% 100%
75 75 0.0% 100%
76 76 0.0% 100%
77 77 0.0% 100%
78 78 0.0% 100%
79 79 0.0% 100%
80 80 0.0% 100%
81 81 0.0% 100%
82 82 0.0% 100%
83 83 0.7% 100%
84 84 0.0% 100%
85 85 0.0% 100%
86 86 0.0% 100%
87 87 0.0% 100%
88 88 2.9% 100%
89 89 0.0% 100%
90 90 0.0% 100%
91 91 0.0% 100%
92 92 0.0% 100%
93 93 0.0% 100%
94 94 0.0% 100%
95 95 0.0% 100%

MAU
ID CPUSET
0 (0, 1, 2, 3, 4, 5, 6, 7)
1 (8, 9, 10, 11, 12, 13, 14, 15)
2 (16, 17, 18, 19, 20, 21, 22, 23)
3 (24, 25, 26, 27, 28, 29, 30, 31)
4 (64, 65, 66, 67, 68, 69, 70, 71)
5 (72, 73, 74, 75, 76, 77, 78, 79)
6 (80, 81, 82, 83, 84, 85, 86, 87)
7 (88, 89, 90, 91, 92, 93, 94, 95)

MEMORY
RA PA SIZE
0xe000000 0xe000000 7968M
IO
pci@400 pci_0
pci@500 pci_1
VCONS
NAME SERVICE PORT
SP

!
?
● Experiences
● Interpretations
● Conclusions
● Applications

Notes:


Student Guide - SA-345 Sun Virtualization - Solaris 10 Logical Domains Administration

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Student Guide - SA-345 Sun Virtualization - Solaris 10 Logical Domains Administration

Uploaded by

Copyright:

Available Formats

THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS CLASSROOM ONLY.

COPYING eKIT MATERIALS FROM THIS COMPUTER IS STRICTLY PROHIBITED

Oracle University and BOS-it GmbH & Co.KG use only

Copyright © 2010, Oracle and/or its affiliates. All rights reserved.

Sun Microsystems, Inc. Disclaimer

Oracle University and BOS-it GmbH & Co.KG use only

Restricted Rights Notice

U.S. GOVERNMENT RIGHTS

This page intentionally left blank.

Oracle University and BOS-it GmbH & Co.KG use only

This page intentionally left blank.

Oracle University and BOS-it GmbH & Co.KG use only

Oracle University and BOS-it GmbH & Co.KG use only

Installing Logical Domains Software ............................................. 2-1

Oracle University and BOS-it GmbH & Co.KG use only

2 Sun Virtualization: Solaris™ 10 Logical Domains Administration

Oracle University and BOS-it GmbH & Co.KG use only

Managing Advanced Logical Domains Configurations................ 6-1

Oracle University and BOS-it GmbH & Co.KG use only

4 Sun Virtualization: Solaris™ 10 Logical Domains Administration

About This Course

Oracle University and BOS-it GmbH & Co.KG use only

Oracle University and BOS-it GmbH & Co.KG use only

Preface-ii Sun Virtualization: Solaris™ 10 Logical Domains Administration

Topics Not Covered

Oracle University and BOS-it GmbH & Co.KG use only

About This Course Preface-iii

How Prepared Are You?

Oracle University and BOS-it GmbH & Co.KG use only

Preface-iv Sun Virtualization: Solaris™ 10 Logical Domains Administration

Oracle University and BOS-it GmbH & Co.KG use only

About This Course Preface-v

How to Use Course Materials

Oracle University and BOS-it GmbH & Co.KG use only

Preface-vi Sun Virtualization: Solaris™ 10 Logical Domains Administration

Oracle University and BOS-it GmbH & Co.KG use only

Discussion – Indicates a small-group or class discussion on the current

Caution – Indicates that there is a risk of personal injury from a

About This Course Preface-vii

Courier is also used to indicate programming constructs, such as class

Oracle University and BOS-it GmbH & Co.KG use only

Courier italics is used for variables and command-line placeholders

Courier italic bold is used to represent variables whose values are to

Preface-viii Sun Virtualization: Solaris™ 10 Logical Domains Administration

Logical Domains Fundamentals

Oracle University and BOS-it GmbH & Co.KG use only

Upon completion of this module, you should be able to:

The following references provide additional information about the topics

Oracle University and BOS-it GmbH & Co.KG use only

1-2 Sun Virtualization: Solaris™ 10 Logical Domains Administration

Introduction to Logical Domains

What Are Logical Domains?

Oracle University and BOS-it GmbH & Co.KG use only

How Is Logical Domains Positioned in Sun

Dynamic System Solaris Zones Solaris Resource

Trend to Flexability Trend to Isolation and Security

Figure 1-1 Sun Virtualization Technologies for SPARC

Logical Domains Fundamentals 1-3

● Dynamic System Domains (DSD) are engineered to remain isolated

Oracle University and BOS-it GmbH & Co.KG use only

Two other virtualization technologies you should be aware of are Sun

1-4 Sun Virtualization: Solaris™ 10 Logical Domains Administration

● Sun VirtualBox is a multi-operating environment virtualization

Oracle University and BOS-it GmbH & Co.KG use only