مفاهیم اصلی Live Migration در LDOM

One of the best features included in the Oracle VM server for SPARC 2.1 version was live migration. Live migration enables migrating active LDOMs from one physical system to other without any downtime. This may help you in doing any maintenance activity like patching or hardware changes on the physical server also helps in load balancing between 2 servers.

Live Migration phases

Phase 1 : Pre-checks
In this phase the source machine does pre-checks on the target system to ensure that the migration will succeed.
Phase 2 : Target LDOM creation
Here a LDOM is created on the target machine, which will be in bound state until the migration is complete.
Phase 3 : Run time state transfer
The run time state of the source LDOM is transferred to the target machine. Any changes to the source LDOM is also transferred to the target machine during the migration process by the LDOM manager. The information is retrieved from Hypervisor on source machine and transferred to the Hypervisor on the target machine.
Phase 4 : Source domain suspension
In this phase the source domain is suspended for a fraction of time and the remaining state information of the source LDOM is transferred to the target machine.
Phase 5 : Hand-off
In this last step a hand-off occurs between the ldom manager from source machine to ldom manager on the target machine. It occurs when the ldom is migrated and resumes execution on target machine and the source ldom is destroyed completely.

Hardware Requirements

1. CPU
a. same CPU migration
– Sufficient number of CPUs on target machine to accommodate migrating LDOM
– For system running Solris 10 , both target and source systems must have same processor type.
To check CPU type and frequency

# psrinfo -pv
The physical processor has 8 virtual processors (0-7)
  SPARC-T4 (chipid 0, clock 2548 MHz)

– Also the stick frequency of both source and target system CPU must match. Solaris 11 doesn’t have this condition.

# prtconf -pv | grep stick-frequency
    stick-frequency:  05f4bc08

b. Cross CPU migration
– UltraSPARC T2+ CPU or higher
– Both target and source systems should have Solaris 11 running.
– Set “cpu-arch” property on source machine to “generic”. generic cpu-arch uses common CPU hardware feaatures enabling LDOMs to perform a CPU independant migration. Default value is “native” which uses CPU specific hardware features, thus can be used if you don’t want to do a cross CPU migration. Generic attribute enables migration to an old or newer CPU type. To enable generic attribute

primary# ldm set-domain cpu-arch=generic ldom01

2. Memory
– Sufficient memory on target machine to accommodate migrating LDOM.
– Same number of identical sized memory blocks with same real addresses.

3. I/O related
– Domain with direct I/O access can not be migrated (I/O domains)
– Each virtual disk back end on target system must have same volume name but the path to actual back end device may be same.
for example when you add back end device to guest ldom in source machine as :

primary# ldm add-vdsdev /dev/dsk/c2t6d0s2 vol01@primary-vds0

Here vol01 should be there on target machine as vol01 only , but the disk slice c2t6d0s2 can have different name on the target machine , but referring the same device off course.

4. Virtual Services
– all 3 service vsw, vds and vcc (in case of console group only) must be present on target machine.
– arleast one free port in vcc

Software requirements

– Oracle VM version 2.1 or later for same CPU migration, version 2.2 or later for cross CPU migration

Migrating a domain (examples)

primary# ldm migrate ldom01 root@target-system
Target Password:
primary# ldm migrate -p password_file ldom01 root@target-system     (unattended migration)
primary# ldm migrate ldom01 root@target-system:ldom_other    (Migrating and renaming the ldom)

Monitoring migration status

You can check status of the migration from both source and target machines as below:

primary# ldm list ldom-source
NAME         STATE      FLAGS   CONS  VCPU  MEMORY  UTIL  UPTIME 
ldom-source  suspended  -n---s         1     1G     0.0%  2h 7m
primary# ldm list ldom-target
NAME         STATE      FLAGS   CONS  VCPU  MEMORY  UTIL  UPTIME 
ldom-target  bound      -----t  5000   1     1G

The sixth column in the FLAGS field indicates whether the system is the source or target of the migration

primary# ldm list -o status ldom-target 
NAME
ldom-target
STATUS
    OPERATION    PROGRESS    SOURCE
    migration    34%         source-system

Canceling a Migration in progress

Either a KILL signal to ldm migration command or ldm cancel-operation can terminate a migration. Both commands must be executed from the source machine. Target machine can not control the migration process. As effect of cancel operation the ldom created on target machine is destroyed.