This section describes general known issues about this release of the Oracle VM Server for SPARC software that are broader than a specific bug number. Workarounds are provided where available.
The Oracle VM Server for SPARC 3.0 software inadvertently exposed a capability to assign multiple virtual switches to a single network adapter. This capability is intended only to be used in a specific way by the Oracle VM Manager software.
The Oracle VM Server for SPARC 3.1 software restored the original behavior, which prevents you from assigning multiple virtual switches to a single network adapter. However, if you configured your Oracle VM Server for SPARC 3.0 system to assign multiple virtual switches to a single network adapter, the ldmd daemon does not start when you upgrade to Oracle VM Server for SPARC 3.2.
Workaround: Perform the following steps:
Temporarily re-enable this capability on your Oracle VM Server for SPARC 3.2 system to enable the ldmd daemon to start.
# svccfg -s ldoms/ldmd setprop ldmd/ovm_manager=true # svcadm refresh ldmd # svcadm disable ldmd # svcadm enable ldmd
Update your configuration to assign only one virtual switch to a network device.
Disable this capability on your Oracle VM Server for SPARC 3.2 system.
# svccfg -s ldoms/ldmd setprop ldmd/ovm_manager=false # svcadm refresh ldmd # svcadm disable ldmd # svcadm enable ldmd
It is important that you set the ovm_manager property to false because this property might introduce other side effects in future Oracle VM Server for SPARC releases.
If a service domain is running a version of Oracle Solaris 10 OS prior to Oracle Solaris 10 1/13 OS and is exporting a physical disk slice as a virtual disk to a guest domain, then this virtual disk will appear in the guest domain with an inappropriate device ID. If that service domain is then upgraded to Oracle Solaris 10 1/13 OS, the physical disk slice exported as a virtual disk will appear in the guest domain with no device ID.
This removal of the device ID of the virtual disk can cause problems to applications attempting to reference the device ID of virtual disks. In particular, Solaris Volume Manager might be unable to find its configuration or to access its metadevices.
Workaround: After upgrading a service domain to Oracle Solaris 10 1/13 OS, if a guest domain is unable to find its Solaris Volume Manager configuration or its metadevices, perform the following procedure.
md_devid_destroy=1; md_keep_repl_state=1;
After the domain has booted, the Solaris Volume Manager configuration and metadevices should be available.
During the reboot, you will see messages similar to this:
NOTICE: mddb: unable to get devid for 'vdc', 0x10
These messages are normal and do not report any problems.
Historically, the Oracle Solaris OS has been installed on a boot disk configured with an SMI VTOC disk label. Starting with the Oracle Solaris 11.1 OS, the OS is installed on a boot disk that is configured with an extensible firmware interface (EFI) GUID partition table (GPT) disk label by default. If the firmware does not support EFI, the disk is configured with an SMI VTOC disk label instead. This situation applies only to SPARC T4 servers that run at least system firmware version 8.4.0, to SPARC T5, SPARC M5, SPARC M6 servers that run at least system firmware version 9.1.0, and to Fujitsu M10 servers that run at least XCP version 2230.
The following servers cannot boot from a disk that has an EFI GPT disk label:
UltraSPARC T2, UltraSPARC T2 Plus, and SPARC T3 servers no matter which system firmware version is used
SPARC T4 servers that run system firmware versions prior to 8.4.0
SPARC T5, SPARC M5, and SPARC M6 servers that run system firmware versions prior to 9.1.0
Fujitsu M10 servers that run XCP versions prior to 2230
So, an Oracle Solaris 11.1 boot disk that is created on an up-to-date SPARC T4, SPARC T5, SPARC M5, SPARC M6, Fujitsu M10 server cannot be used on older servers or on servers that run older firmware.
This limitation restrains the ability to use either cold or live migration to move a domain from a recent server to an older server. This limitation also prevents you from using an EFI GPT boot disk image on an older server.
To determine whether an Oracle Solaris 11.1 boot disk is compatible with your server and its firmware, ensure that the Oracle Solaris 11.1 OS is installed on a disk that is configured with an SMI VTOC disk label.
To maintain backward compatibility with systems that run older firmware, use one of the following procedures. Otherwise, the boot disk uses the EFI GPT disk label by default. These procedures show how to ensure that the Oracle Solaris 11.1 OS is installed on a boot disk with an SMI VTOC disk label on a SPARC T4 server with at least system firmware version 8.4.0, on a SPARC T5, SPARC M5, or SPARC M6 server with at least system firmware version 9.1.0, and on a Fujitsu M10 server with at least XCP version 2230.
Solution 1: Remove the gpt property so that the firmware does not report that it supports EFI.
From the OpenBoot PROM prompt, disable automatic booting and reset the system to be installed.
ok setenv auto-boot? false ok reset-all
After the system resets, it returns to the ok prompt.
Change to the /packages/disk-label directory and remove the gpt property.
ok cd /packages/disk-label ok " gpt" delete-property
Begin the Oracle Solaris 11.1 OS installation.
For example, perform a network installation:
ok boot net - install
Solution 2: Use the format -e command to write an SMI VTOC label on the disk to be installed with the Oracle Solaris 11.1 OS.
Write an SMI VTOC label on the disk.
For example, select the label option and specify the SMI label:
# format -e c1d0 format> label [0] SMI Label [1] EFI Label Specify Label type[1]: 0
Configure the disk with a slice 0 and slice 2 that cover the entire disk.
The disk should have no other partitions. For example:
format> partition partition> print Current partition table (unnamed): Total disk cylinders available: 14087 + 2 (reserved cylinders) Part Tag Flag Cylinders Size Blocks 0 root wm 0 - 14086 136.71GB (14087/0/0) 286698624 1 unassigned wu 0 0 (0/0/0) 0 2 backup wu 0 - 14086 136.71GB (14087/0/0) 286698624 3 unassigned wm 0 0 (0/0/0) 0 4 unassigned wm 0 0 (0/0/0) 0 5 unassigned wm 0 0 (0/0/0) 0 6 unassigned wm 0 0 (0/0/0) 0 7 unassigned wm 0 0 (0/0/0) 0
Re-write the SMI VTOC disk label.
partition> label [0] SMI Label [1] EFI Label Specify Label type[0]: 0 Ready to label disk, continue? y
Configure your Oracle Solaris Automatic Installer (AI) to install the Oracle Solaris OS on slice 0 of the boot disk.
Change the <disk> excerpt in the AI manifest as follows:
<target>
<disk whole_disk="true">
<disk_keyword key="boot_disk"/>
<slice name="0" in_zpool="rpool"/>
</disk>
[...]
</target>Perform the installation of the Oracle Solaris 11.1 OS.
Due to the way in which the Oracle Solaris OS handles the metadata for managing dynamically added memory, you might later be able to remove only the entire block of memory that was previously dynamically added rather than a proper subset of that memory.
This situation could occur if a domain with a small memory size is dynamically grown to a much larger size, as shown in the following example.
primary# ldm list ldom1 NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME ldom1 active -n-- 5000 2 2G 0.4% 23h primary# ldm add-mem 16G ldom1 primary# ldm rm-mem 8G ldom1 Memory removal failed because all of the memory is in use. primary# ldm rm-mem 16G ldom1 primary# ldm list ldom1 NAME STATE FLAGS CONS VCPU MEMORY UTIL UPTIME ldom1 active -n-- 5000 2 2G 0.4% 23h
Workaround: Use the ldm add-mem command to sequentially add memory in smaller chunks rather than in chunks larger than you might want to remove in the future.
Recovery: Perform one of the following actions:
Stop the domain, remove the memory, and then restart the domain.
Reboot the domain, which causes the Oracle Solaris OS to reallocate its memory management metadata such that the previously added memory can now be removed dynamically in smaller chunks.