Prepare the Target System

Language:

Use this procedure to ensure that the target system is configured to provide CPU, memory, and storage resources for the incoming guest domain.

CPU Resources – During the shift, you can assign any amount of CPU resources to the guest domain that are appropriate for the guest domain's workload. However, prior to the lift and shift, you must ensure that those CPU resources are available as described in this procedure.

If you are uncertain about the CPU utilization of the guest domain's workload on the target system, then the target system should provide at minimum the same available CPU and memory resources that the guest domain had on the source system. This conservative approach helps maintain the same or better performance level of the workload after the migration. On the other hand, if the CPU utilization is estimated to be significantly lower for the guest domain on the target system, for example, if the target system has faster CPUs, then the target system can provide fewer CPU resources to the guest domain. In some cases, using fewer CPU cores reduces software licensing costs.
Memory Resources – By default, the target guest domain is allocated the same amount of memory that it had on the source system. Ensure that there is at least the same amount of memory is available on the target system as described in this procedure.
Storage Resources – The number of available virtual disks and sizes on the target must match what the guest domain has the source system as described in this procedure.

For the lift and shift example in this document, the guest domain is allocated the same amount of resources that it had on the target system, as shown in this diagram.

image:A diagram showing the resources that need to be created on the target system.

Check the target system's storage capacity.

In this example, the LUNS on the target system's control domain are provisioned with the exact same capacity as in the source system (see Obtain Configuration Details from the Source Control Domain).

The disks are provisioned in this fashion:

Disk Number	Contents
5, 6	Root disks (rpool)
7, 8	u01 zpool (Oracle binaries)
9, 10	ASM disks

Obtain disk names.

In this example, six disk names are displayed as c0t600144F09F2C0BFD00005A2865A20004d0, c0t600144F09F2C0BFD00005A2865B50005d0, and so on.

root@TargetControlDomain# format
Searching for disks...done

       5. c0t600144F09F2C0BFD00005A2865A20004d0 . . .

       6. c0t600144F09F2C0BFD00005A2865B50005d0 . . .

       7. c0t600144F09F2C0BFD00005A2865C30006d0 . . .

       8. c0t600144F09F2C0BFD00005A2865D30007d0 . . .

       9. c0t600144F09F2C0BFD00005A2865E20008d0 . . .

      10. c0t600144F09F2C0BFD00005A2865F40009d0 . . .

Specify disk (enter its number): Specify disk (enter its number): CTRL-C

Display the disk capacities.
The disk topology and capacities must match the disk topology and capacities that the source provided to the guest domain. See Obtain Configuration Details from the Source Control Domain.

You can use the iostat -En command with each disk name that was provided in the previous step. For example:

iostat -En c0t600144F09F2C0BFD00005A2865A20004d0

Repeat for each disk.

Alternatively, in this example, the iostat command used in a for/do ksh shell script so that sizes are reported for each disk listed in the previous step.
```
root@TargetControlDomain# for d in c0t600144F09F2C0BFD00005A2865A20004d0  \ 
c0t600144F09F2C0BFD00005A2865B50005d0 c0t600144F09F2C0BFD00005A2865C30006d0  \
c0t600144F09F2C0BFD00005A2865D30007d0 c0t600144F09F2C0BFD00005A2865E20008d0  \
c0t600144F09F2C0BFD00005A2865F40009d0; do iostat -En $d | egrep "c0|Size" | sed -e 's,d0.*.d0,,"; done

c0t600144F09F2C0BFD00005A2865A20004d0
Size: 322.12GB <322122547200 bytes>
c0t600144F09F2C0BFD00005A2865B50005d0
Size: 322.12GB <322122547200 bytes>
c0t600144F09F2C0BFD00005A2865C30006d0
Size: 161.06GB <161061273600 bytes>
c0t600144F09F2C0BFD00005A2865D30007d0
Size: 161.06GB <161061273600 bytes>
c0t600144F09F2C0BFD00005A2865E20008d0
Size: 214.75GB <214748364800 bytes>
c0t600144F09F2C0BFD00005A2865F40009d0
Size: 214.75GB <214748364800 bytes>
```
Note that the sizes shown represent the raw whole disk capacity including reserved area. The actual usable sizes are as follows, respectively:

c0t600144F09F2C0BFD00005A2865A20004d0 300 GB

c0t600144F09F2C0BFD00005A2865B50005d0 300 GB

c0t600144F09F2C0BFD00005A2865C30006d0 150 GB

c0t600144F09F2C0BFD00005A2865D30007d0 150 GB

c0t600144F09F2C0BFD00005A2865E20008d0 200 GB

c0t600144F09F2C0BFD00005A2865F40009d0 200 GB

This example shows that the target system is configured to provide the exact same virtual disks and capacities that the guest domain had on the source system.
(If needed) Configure virtual disks for the incoming guest domain.
For information about configuring virtual disks, refer to Using Virtual Disks in the Oracle VM Server for SPARC 3.5 Administration Guide at:

https://docs.oracle.com/cd/E80106_01/html/E80109/usingvirtualdiskswithldoms.html

Configure CPU and memory resources to support the incoming guest domain.
1. Ensure that the path of the ovmtdeploy command is in your PATH variable.
  For example:
```
root@TargetControlDomain# export PATH=$PATH:/opt/ovmtutils/bin
```
2. Determine the amount of resources that are required for the guest domain.
  When the ovmtdeploy command is used, by default it assigns resources based on what is specified in the archive. You can use the -l option to list the contents of the archive without deploying the domain to verify the configuration.
  
  In this example, when the guest domain is moved to the target system, it will have the same CPU and memory resources that it had in the source system, which is 80 vCPUs, and 128 GB of memory.
```
root@TargetControlDomain# ovmtdeploy -l /ovas/solaris10.ova
Oracle VM for SPARC Deployment Utility
ovmtdeploy Version 3.6.0.0.10.2483

STAGE 1 - EXAMINING SYSTEM AND ENVIRONMENT
...
STAGE 2 - ANALYZING ARCHIVE & RESOURCE REQUIREMENTS
---------------------------------------------------
...
Virtual machine 1
------------------------
Name: solaris10
Description: source S10 domain with 80 vCPUs, 128G memory, 6 disk image(s)
vcpu Quantity: 80
Memory Quantity: 128G
Disk image 1: ovf:/disk/devicedisk0 -> devicedisk0
Disk image 2: ovf:/disk/devicedisk1 -> devicedisk1
Disk image 3: ovf:/disk/devicedisk2 -> devicedisk2
Disk image 4: ovf:/disk/devicedisk3 -> devicedisk3
Disk image 5: ovf:/disk/devicedisk4 -> devicedisk4
Disk image 6: ovf:/disk/devicedisk5 -> devicedisk5
Network adapter 1: Ethernet_adapter_0 -> primary-vsw0
source S10 domain:
        name
```
3. List the target system's CPU and memory resources.
  If your system has multiple domains, add the vCPU and memory resources for all domains to determine the total allocated resources.
  
  In this example, the target system is set to factory defaults, and all of the resources are currently assigned to the control domain. To make resources available for the guest domain, some resources must be removed from the control domain.
```
root@TargetControlDomain# ldm ls
NAME       STATE    FLAGS   CONS     VCPU   MEMORY    UTIL   NORM   UPTIME
primary    active   -n-c--  UART     128    260352M   0.3%   0.3%   1d
```
  Note that the ldm ls command only displays resources that are allocated to domains. If there are unallocated resources, they are not displayed. If you need to identify unallocated resources, run these commands.
  - List the number of unallocated cores:
    
    # ldm list-devices -p core | grep cid | wc -l
  - List the unallocated memory (add the values displayed under the size column):
    
    # ldm list-devices memory
4. Set aside CPU and memory resources for the guest domain.
  In this example, the target control domain's resources are reduced to free up resources for the incoming guest domain, while maintaining an optimal amount of resources to continue providing services.
```
root@TargetControlDomain# ldm set-core 2 primary
root@TargetControlDomain# ldm set-mem 32G primary
```
Save the new logical domain resource configuration.
This ensures that the configuration is saved and used after a power cycle. If it isn't saved, the configuration is lost after a power cycle.
1. Add a logical domain configuration to the service processor.
```
root@TargetControlDomain# ldm add-spconfig solaris10config
```
2. Check the current logical domain configuration on the service processor.
  In this example, the output shows that the newly created solaris10config configuration will become active after the next power cycle.
```
root@TargetControlDomain# ldm ls-spconfig

factory-default
solaris10config [next poweron]
```
3. Power cycle the target system.
  1. Log in to the service processor (SP) as the SP admin or root user.
  2. Stop the system:
```
-> stop /SYS
```
  3. After the system is completely stopped, start the system:
```
→ start /SYS
```
    The system takes a few minutes to initialize the new SP configuration and boot the OS.
After the system boots, log in and check the SP configuration.
Ensure that the new configuration is the current configuration.
```
root@TargetControlDomain# ldm ls-spconfig

factory-default
solaris10config [current]
```
Verify the CPU and memory configuration.
In this example, the output shows that the control domain has reduced resources. Unallocated resources are now available to be allocated to the incoming guest domain.
```
root@TargetControlDomain# ldm ls

NAME             STATE      FLAGS   CONS    VCPU  MEMORY   UTIL  NORM  UPTIME
primary          active     -n-cv-  UART    16    32G      0.7%  0.7%  1m
```

Related Information

Lifting and Shifting the Virtual Disks Separately (Alternate Method)