JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle VM Server for SPARC 2.1 Administration Guide     Oracle VM Server for SPARC
search filter icon
search icon

Document Information

Preface

Part I Oracle VM Server for SPARC 2.1 Software

1.  Overview of the Oracle VM Server for SPARC Software

2.  Installing and Enabling Software

3.  Security

4.  Setting Up Services and the Control Domain

5.  Setting Up Guest Domains

6.  Setting Up I/O Domains

7.  Using Virtual Disks

8.  Using Virtual Networks

9.  Migrating Domains

Introduction to Domain Migration

Overview of a Migration Operation

Software Compatibility

Security for Migration Operations

Migrating a Domain

Performing a Dry Run

Performing Non-Interactive Migrations

Migrating an Active 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 Cryptographic Units

Delayed Reconfiguration in an Active Domain

Migrating While an Active Domain Is in Elastic Mode

Operations on Other Domains

Migrating a Domain That is Running in OpenBoot or in the Kernel Debugger

Migrating Bound or Inactive Domains

Migration Requirements for CPUs

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

Migration Examples

10.  Managing Resources

11.  Managing 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

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

Glossary

Index

Overview of a Migration Operation

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 re-copied to the target machine. In this way, there should be 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.