Skip Navigation Links | |
Exit Print View | |
Oracle VM Server for SPARC 2.2 Administration Guide Oracle VM Server for SPARC |
Part I Oracle VM Server for SPARC 2.2 Software
1. Overview of the Oracle VM Server for SPARC Software
2. Installing and Enabling Software
3. Oracle VM Server for SPARC Security
4. Setting Up Services and the Control Domain
Introduction to Domain Migration
Security for Migration Operations
Performing Non-Interactive Migrations
Domain Migration Requirements for CPUs
Migration Requirements for Memory
Migration Requirements for Physical I/O Devices
Migration Requirements for Virtual I/O Devices
Migration Requirements for NIU Hybrid I/O
Migration Requirements for Cryptographic Units
Delayed Reconfiguration in an Active Domain
Migrating While an Active Domain Has the Power Management Elastic Policy in Effect
Migrating a Domain From the OpenBoot PROM or a Domain That Is Running in the Kernel Debugger
Migrating Bound or Inactive Domains
Migration Requirements for Virtual I/O Devices
Migration Requirements for PCIe Endpoint Devices
Monitoring a Migration in Progress
Canceling a Migration in Progress
Recovering From a Failed Migration
11. Managing Domain Configurations
12. Performing Other Administration Tasks
Part II Optional Oracle VM Server for SPARC Software
13. Oracle VM Server for SPARC Physical-to-Virtual Conversion Tool
14. Oracle VM Server for SPARC Configuration Assistant (Oracle Solaris 10)
15. Using the Oracle VM Server for SPARC Management Information Base Software
16. Logical Domains Manager Discovery
17. Using the XML Interface With the Logical Domains Manager
The Logical Domains Manager on the source machine accepts the request to migrate a domain and establishes a secure network connection with the Logical Domains Manager that runs on the target machine. The migration occurs after this connection has been established. The migration operation is performed in the following phases:
Phase 1: After the source machine connects with the Logical Domains Manager that runs in the target machine, information about the source machine and the domain to be migrated are transferred to the target machine. This information is used to perform a series of checks to determine whether a migration is possible. The checks to perform are based on the state of the domain to be migrated. For example, if the domain to be migrated is active, a different set of checks are performed than if that domain is bound or inactive.
Phase 2: When all checks in Phase 1 have passed, the source and target machines prepare for the migration. On the target machine, a domain is created to receive the domain to be migrated. If the domain to be migrated is inactive or bound, the migration operation proceeds to Phase 5.
Phase 3: If the domain to be migrated is active, its runtime state information is transferred to the target machine. The domain to be migrated continues to run, and the Logical Domains Manager simultaneously tracks the modifications being made by the OS to this domain. This information is retrieved from the hypervisor on the source machine and installed in the hypervisor on the target machine.
Phase 4: The domain to be migrated is suspended. At this time, all of the remaining modified state information is recopied to the target machine. In this way, there is little or no perceivable interruption to the domain. The amount of interruption depends on the workload.
Phase 5: A handoff occurs from the Logical Domains Manager on the source machine to the Logical Domains Manager on the target machine. The handoff occurs when the migrated domain resumes execution (if the domain to be migrated was active), and the domain on the source machine is destroyed. From this point forward, the migrated domain is the sole version of the domain running.