Reconfigure the device using # cfgadm -c configure # devfsadm -Cĥ. Insert the disk and configure the disk in solaris as below. Unconfigure the disk using cfgadm and remove the disk # cfgadm -c unconfigure c3::dsk/c3t0d0Ĥ. Removal of disk hug-dg04 completed successfully. Select “Replace a failed or removed disk” from the main menuĬontinue with operation? (default: y) y The disk, allowing replacement of the disk. The disk name will be kept, along with any volumes using The requested operation is to remove disk hug-dg04 from disk group Vxvm:vxdisk: ERROR: Device c3t0d0s2: get_contents failed: The following volumes will lose mirrors as a result of this Initialized disks that are not part of a disk group, you will be This changes the stateįor the disk name to a “removed” disk. Use this menu operation to remove a physical disk from a disk Menu: VolumeManager/Disk/RemoveForReplace Inform VxVM you want to remove the # vxdiskadmġ2 Mark a disk as a spare for a disk groupġ5 Exclude a disk from hot-relocation useġ6 Make a disk available for hot-relocation useġ7 Prevent multipathing/Suppress devices from VxVM’s viewġ8 Allow multipathing/Unsuppress devices from VxVM’s viewġ9 List currently suppressed/non-multipathed devicesĢ1 Get the newly connected/zoned disks in VxVM view I took the session output and added some descriptions to be more informative.įeb 22 15:02:01 hug1 scsi: WARNING: (sd31):įeb 22 15:02:01 hug1 disk not responding to selectionįeb 22 15:02:39 hug1 scsi: WARNING: (sd31):įeb 22 15:02:39 hug1 disk not responding to selectionĢ.
#Veritas volume manager support license#
In TKU June an issue that was introduced in TKU April 2010 with the parsing of output of license command for CPU count which would cause failure to parse the CPU count was resolved.I used this procedure to replace failed disk in VxVM on Sun Firs v240(Solaris 9) and VxVM 4.
#Veritas volume manager support update#
The way the Detail Node key is generated has been improved in the update to the pattern.Īditionally, parsing of output of license command for CPU count was improved - any trailing spaces removed from the value obtained (and therefore no longer in 'allowed_cpus' Detail Node attribute). The initial implementation of storage of license information on Detail Nodes did not create the Detail Node key which was unique enough which could lead to information about multiple licenses linked to a product being lost. In TKU April an issue that was introduced in TKU October 2009 with the introduction of Detail Nodes was resolved. This condition can be easily identified through a specific Report, outlined in the relevant page. Instead, we model a containment link between the Volume Manager Licensing Detail and the Storage Foundation Licensing Detail, the latter containing the first. We no longer set an additional attribute in the Volume Manager SI. To make it easier to employ the data present in these details, we outlined a number of sample Reports in the relevant page.įurthermore, we reworked the behaviour that the pattern takes when it encounters an entity of Volume Manager which was bundled with Storage Foundation.
Each of these details are directly linked from the Volume Manager SI. Whereas this data used to be stored in Additional Attributes of the SI, it is now stored into Detail Nodes of type Licensing Details, one for each licensed entity present on the host.
In TKU October we completely reorganized the way that we handle Licensing Data for Volume Manager. This attribute is either set to True or False, and can easily be used in Reporting to filter Storage Foundation Licenses from the Licenses which were bought exclusively for Volume Manager. In July TKU we added an attribute to the Volume Manager SI which allows to monitor whether a certain Volume Manager License was purchased in a bundle with Storage Foundation.
0 kommentar(er)
