This section explains advisory notes for when using OVM for SPARC.
OS Startup Configuration while Starting Domains
When starting an OS while starting up an L-Server, specify "true" for the auto-boot? variable of the guest domain.
In addition, when an L-Server is created using this product, the following values are set for the auto-boot? variable.
When an L-Server with an image specified is created
"true" is set for the auto-boot? variable.
When an L-Server with no image specified is created
"false" is set for the auto-boot? variable.
Connection with the console of the guest domain during L-Server creation
If it is connected with the console of a guest domain during L-Server creation, L-Server creation may fail.
Therefore, do not connect with the console of a guest domain during L-Server creation.
IP address specified during L-Server creation
In order to connect to an installation server, an IP address of the admin LAN is needed for creation of an L-Server an image specified.
Therefore, if an IP address of the admin LAN is not specified when creating the L-Server, a NIC for connection with the admin LAN is temporarily added to the L-Server, and an IP address from the network resources of the admin LAN is set for the guest domain.
The temporarily added NIC for connection to the admin LAN is automatically deleted after creation of the L-Server.
When the default gateway is configured for the admin LAN network resource and an admin LAN IP address is temporarily configured, a default gateway is also set.
Do not specify multiple default gateways when creating an L-Server, considering that an IP address of the admin LAN default gateway is configured.
About operation when a Solaris 11 image is specified
When an L-Server is created with a Solaris 11 image specified, the number of the IP addresses set for the guest domain is one.
This is because the number of IP addresses which can be set during OS installation is one, due to the specifications of Solaris 11.
Since the IP address of the admin LAN is essential when creating an L-Server with an image specified, the IP address set for the guest domain becomes the IP address for the admin LAN.
Therefore, even if the public LAN IP address is specified during L-Server creation, the public LAN IP address is not set for the guest domain.
Also, when the admin LAN IP address is not specified during L-Server creation, the IP address of the admin LAN network resource that is used temporarily is set for the guest domain. The setting of this IP address remains on the OS after creation of the L-Server.
Therefore, it is necessary to perform the following operations on the OS of a guest domain after L-Server creation.
Delete the setting of the admin LAN IP address used temporarily
Set the admin LAN IP address specified when creating the L-Server
In addition, please refer to "8.8.6 Creating L-Servers" of "Operations after creating an L-Server" for the above-mentioned operation.
Display of CPU Performance and the Number of CPUs for L-Servers
The number of CPUs for L-Servers are calculated using the number of CPU threads configured for the domain, and is displayed per core.
The CPU performance of CPUs for L-Servers is calculated using the CPU performance and the number of CPU threads configured for the VM host.
The calculation formula is as below.
Number of CPUs = number of threads / number of threads per core (round-up any decimal values)
CPU performance = (number of threads * physical CPU performance) / (number of threads per core * number of CPUs)
Example
When creating an L-Server to which 2 cores (16 threads) are allocated on a VM host with a 2.8 GHz CPU, 1 core, and 8 threads
Number of CPUs = 16 / 8 = 2
CPU performance = (16 * 2.8) / (8 * 2) = 2.8 (GHz)
When creating an L-Server to which 12 threads are allocated on a VM host with a 2.8 GHz CPU, 1 core, and 8 threads
Number of CPUs = 12 / 8 = 1.5 ≑ 2
CPU performance = (12 * 2.8) / (8 * 2) = 2.1 (GHz)
CPU Capacity and Memory Capacity when Settings are Configured for Conversion Using Reservation Values
When the settings are configured to calculate using the reservation values, the same CPU capacity and memory capacity as used by a virtual machine are configured as the values for conversion using a maximum value.
Max. Number of Possible L-Servers View
In OVM for SPARC, CPU performance is the VM host's CPU performance. Therefore, the CPU performance of the L-Server template is disregarded. The number of possible L-Servers is calculated based on "the VM host's CPU performance multiplied by the number of CPUs" and memory size.
Creating an L-Server
This product only supports creation of guest domains.
When creating the I/O domain and the service domain, do so on the control domain.
Also, setting of a global zone is not performed for the created guest domain. When using a guest domain as a global zone, perform settings for the global zone on the OS of the guest domain after creating the L-Server.
Display of Disk Information
The identifier information (ID number) is displayed for the device path.
L-Server Power Operations
When functions are not supported by OVM for SPARC, stopping and rebooting of L-Servers cannot be performed.
Depending on the statuses of virtual machines, either operate virtual machines directly, or perform a forced stop or a forced reboot.
When executing power operations of VM guests in this product, binding and unbinding of resources is also executed.
When starting a VM guest
Binding of resources is executed.
When stopping a VM guest
Unbinding of resources is executed.
When restarting a VM guest
Binding/unbinding of resources is not executed.
When two or more virtual L-Servers are sharing a specific disk on a VM host, when one of the virtual L-Server has been started, the other L-Server which is sharing the disk cannot be started.
I/O Domain
In Resource Orchestrator, I/O domains are detected as VM guests.
An I/O domain may affect other guest domains when performing power operations.
It is recommended to perform management without linking an I/O domain with an L-Server.
This is to avoid performing incorrect operations due to confusion of the I/O domain with another guest domain, as a result of the I/O domain being managed as an L-Server or an L-Platform.
Number of VM Host CPUs
The number of cores that are recognized by the control domain is displayed for the number of CPUs of the VM host.
Adding Disks to L-Servers
When adding disks to L-Servers, the disk name of guest domains are set using the following rule.
vdiskN |
N is the disk number (0-63) which was specified when adding the disk.
Migration Operations
When performing migration of virtual L-Servers between servers, disk resources must be linked with all disks detected by the L-servers. The candidates for the migration target are the resources which meet all of the following conditions:
VM hosts which share the disk resources already allocated to an L-Server
VM hosts which have the same spare server settings for the VM host
When migrating an L-Server to the VM host using one of the following methods, the L-Server after migration may be unlinked from the disk resources or the disk information may not be updated.
Migration between servers from the server tree of the ROR console
Migration between servers using a command with the destination VM host specified
As a product specification of OVM for SPARC, no check of whether a disk allocated to a guest domain is shared between source VM host and the target VM host is performed.
Therefore, check the following items to confirm sharing settings of disks.
All disks allocated to the guest domain are shared with the target control domain
The disk service and volume name are the same in the source control domain and target control domain
When executing migration of a guest domain with unshared disks, migration may be successful, but operation is not guaranteed.
After migration, it is necessary to execute the "ldm add-spconfig" command on the control domain to save VM guest configuration information on the service processor. This means the VM host configuration is retained even after a reboot.
In this product, VM guest configuration information is saved when migration of a VM guest is detected. When disabling automatic saving of configuration information of this product, disable the definition in the definition file indicated in "Definition File of Whether to Save the Configuration Information".
When a VM host fails during migration, VM guests may be started twice.
In order to prevent this, when the value of VM guest's auto-boot? variable is set as "true", please change the value of auto-boot? using the following procedures.
Before performing migration, change the value of auto-boot? to "false" and save configuration information.
After execution of migration, return the value of auto-boot? to the original value (true).
In addition, when all of the following conditions are satisfied, it is possible to perform step 1 and step 2 above automatically by including the definition in the file mentioned in "Validation of the auto-boot? change function on migration".
The auto-save function of configuration information is enabled (*1)
"true" is configured for the value of auto-boot? of the guest domain (*2)
*1: For details on auto-saving of auto configuration, refer to "Definition File of Whether to Save the Configuration Information".
*2: Use the following ldm command to check the auto-boot? value which is configured for the guest domain.
# ldm list-variable auto-boot? Guest domain name <RETURN> |
As the result of command execution, true is configured for auto-boot? when "auto-boot?=true" is displayed.
When auto-execution of the process in steps 1 and 2 described above fails, the migration process of servers, the message number 67375 or the message number 67385 is output and migration fails.
When an error occurs, as the auto-boot? value may not be returned to the original value, check the auto-boot? value referring to the corrective actions of the error message.
As a product specification of OVM for SPARC, during execution of migration other operations cannot be performed for guest domains.
So, if operations for other VM guests or L-Servers are performed during migration, those operations may fail.
When [Automatic] is specified, the L-Server does not migrate to the VM host where the L-Server (guest domain) which is sharing the disk allocated to the L-Server is located.
When the following VM host is specified as the migration point for a powered on L-Server, the operation is dependent on the specifications of OVM for SPARC.
A VM host in which another powered on L-Server (guest domain) which is sharing the disk exists
When the following VM host is specified as the migration target and cold migration of a powered on L-Server is performed, the guest domain will fail to start after being moved to the VM host of the migration target.
A VM host in which another powered on L-Server (guest domain) which is sharing the disk exists
CPU Performance Values of L-Servers
Resource Orchestrator calculates the CPU performance values of virtual L-Servers based on the CPU performance value of the VM host.
Therefore, even when the number of CPUs of a virtual L-Server is the same, virtual L-Server's CPU performance value may change due to the VM Host's CPU performance value.
Deletion of L-Servers
When a VM guest who assigned to an L-Server is registered with this product as a VM host, the L-Server cannot be deleted.
When deleting an L-Server registered as a VM host, delete the L-Server after using the following procedures to cancel the VM host's registration.
When a Solaris Zone L-Server exists in a VM host, delete or release the relationship with the L-Server.
Delete the disk resource relationship with the VM host from the storage pool.
Delete unnecessary network resources from the network pool.
Release registration of unnecessary cloning images from the image pool.
Carry out registration release of the VM host from the VM pool.
Cancel the VM host's registration from the server tree.
Delete the L-Server from the orchestration tree.
Linking of a Guest Domain with Virtual L-Servers
When Solaris Zones are constructed on the guest domain, and the guest domain is registered as a VM host, virtual L-Servers linked with the guest domain cannot be imported into the L-Platform.
In addition, the virtual L-Servers that configured a Solaris Zone on a guest domain must be managed by the administrator in charge of the entire system (a supervisor or a dual-role administrator).
When the following operations are performed for a virtual L-Server created on a Solaris Zone in a guest domain, the non-global zone will also be affected, so check the scope of effect before performing the operations.
Power operations
Moving an L-Server between Servers (Migration)
Modifying L-Server specifications
Detaching a Disk
Users are advised to exclude the virtual L-Servers which configured a Solaris Zone on a guest domain from the targets of batch power control.
When using batch power control in an environment where a Solaris Zone is configured on a guest domain, set the startup priority of the virtual L-Servers which configure the Solaris Zone on the guest domain as higher than that of the virtual L-Servers configured on that Solaris Zone.
As power control uses the function of the VM management software, if power control fails, perform power operations on each L-Server.
When modifying virtual L-Server specifications, assign more resources to the guest domain than the resources of all the non-global zones created on the Solaris Zone.
When fewer resources than the resources of all of the non-global zones constructed on the Solaris Zone are assigned, the following phenomena may occur.
It becomes impossible to start the non-global zone
The performance of the non-global zone deteriorates
Saving of VM Guest Configuration Information
When the following operations are performed on VM guests or L-Servers using this product, it is necessary to save configuration information on a service processor.
Power Operations (ON/OFF/OFF(Forced)/Reboot/Reboot(Forced))
When using the function for auto-saving of VM guest configuration information, VM guest configuration information is maintained even after reboot/force reboot is executed.
The reason for this is that auto-save of configuration information is executed when the statuses of VM guests or L-Servers change.
Migration
Creating and Deleting Virtual L-Servers
Modification of virtual L-Server specifications (the number of CPUs, memory size)
Adding / removing disks of virtual L-Servers
In Resource Orchestrator, configuration information is automatically saved when the operations above are performed.
Configuration information is also automatically saved when the following operations for guest domains are performed from the control domain.
Creation/removal of guest domains
Binding/unbinding of resources
Stopping/starting of a guest domain
Modification of the number of CPUs and memory size
Addition/deletion of virtual disks
Migration of a guest domain
When saving VM guest configurations manually, set the definition value in the definition file indicated in "8.8.1 Creating Definition Files" to false, and execute the "ldm add-spconfig" command in the control domain.
When using the function for auto-saving of VM guest configurations, be careful of the following points.
Since auto-save of configuration information is performed when change is detected in the periodic update of servers, there is a time lag between completion of the operation and saving of composition information.
Also, when changing of the state or configuration of a guest domain is directly performed on a VM host, auto-save of the configuration information is carried out when change is detected in the periodic update of servers.
However, there will be a time lag when configuration information is saved. When directly operating the guest domain on a VM host, it is recommended to manually save the configuration information, after canceling auto-save of configuration information.
When a VM guest/L-Server which has carried out migration is detected, saving of configuration information is performed on the source and destination VM hosts
In the auto-saving of configuration, this product overwrites the newest configuration information to the configuration with the [current] state. However, overwrite the configuration information with the [next poweron] status, when there is no configuration information with the [current] status.
When factory-default is chosen as configuration information for updating, this product does not save configuration information (when factory-default is in [current] or the [next poweron] state).
With this product, since the newest configuration is saved temporarily, this product creates the composition information using the name config_tmp. Therefore, do not create configuration information named config_tmp.
In Fujitsu M10s, a maximum of eight sets of configuration information can be saved, including factory-default.
In Resource Orchestrator, as the configuration information, config_tmp, is temporarily created, only seven sets of configuration information, including the factory-default, can be created.
Single quotes (') cannot be used in configuration names. This product does not save configurations when a single quote (') is contained in the name of the configuration information used as the candidate for updating.
Due to the specifications of OVM for SPARC, this product cannot save configuration during execution of migration. Therefore, when migration is performed continuously, the configuration information is not saved until the final migration is completed.
If saving of configuration information and operation of a VM host of configuration are performed simultaneously, saving of the configuration information may fail.
It such cases Message number 41127 is displayed in the event log, when this occurs, save the configuration information again. For details on how to restore configurations, refer to "3.1.1 411XX Series" in "Messages".
When executing power operations of VM hosts, it is recommended to execute power operations after canceling automatic collection of configuration information and manually saving configuration information.
CPU Dynamic Resource Management
When the CPU values of virtual L-Servers are modified in Resource Orchestrator, CPUs are allocated per core.
Therefore, the function of CPU Dynamic Resource Management becomes unable to be used (*).
When using CPU Dynamic Resource Management, it is necessary to allocate CPUs per thread for the guest domain in the control domain.
If the calculation of usage charges is enabled, the usage charge for CPUs will be calculated based on the number of CPUs changed dynamically by CPU Dynamic Resource Management.
*Note: The CPU Dynamic Resource Management function dynamically changes the number of CPUs for each thread. When CPUs are allocated per core, it is not possible to change the number of CPUs per thread. This means the CPU Dynamic Resource Management function cannot be used. For details, refer to the manual of OVM for SPARC.
Sharing disks
During L-Server creation and disk addition, disks used by other L-Servers (guest domains) cannot be specified. When sharing a disk between two or more L-Servers (guest domains), set up the disk to share on the VM host after creating the L-Server.
When deleting disks from L-Servers, disks shared with other L-Servers (guest domains) cannot be deleted. Delete the disk shared by two or more L-Servers (guest domains) from the VM host.
L-Servers with disks shared with other L-Servers (guest domains) cannot be deleted. For guest domains, delete the disk shared with another L-Server (guest domain) from the VM host. Delete the L-Server after checking that the disk has been deleted in the detailed information of the L-Server.
Check the disk information of the L-Server using the GUI.
Display the ROR console.
Select the L-Server on the orchestration tree.
Check that the disk which was being shared is not displayed on the [Disk Information] on the [Resource Details] tab in the main panel.
