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.
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:
|
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
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.
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
For example:
root@TargetControlDomain# export PATH=$PATH:/opt/ovmtutils/bin
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
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
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
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.
root@TargetControlDomain# ldm add-spconfig solaris10config
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]
-> stop /SYS
→ start /SYS
The system takes a few minutes to initialize the new SP configuration and boot the OS.
Ensure that the new configuration is the current configuration.
root@TargetControlDomain# ldm ls-spconfig factory-default solaris10config [current]
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