Please enter search query.
Search <book_title>...
Veritas InfoScale™ Virtualization Guide - Linux on ESXi
Last Published:
2019-02-26
Product(s):
InfoScale & Storage Foundation (7.4)
Platform: VMware ESX
- Section I. Overview
- About Veritas InfoScale solutions in a VMware environment
- Section II. Deploying Veritas InfoScale products in a VMware environment
- Getting started
- Understanding Storage Configuration
- Section III. Use cases for Veritas InfoScale product components in a VMware environment
- Application availability using Cluster Server
- Multi-tier business service support
- Improving storage visibility, availability, and I/O performance using Dynamic Multi-Pathing
- How DMP works
- Improving data protection, storage optimization, data migration, and database performance
- Protecting data with Veritas InfoScale product components in the VMware guest
- Optimizing storage with Veritas InfoScale product components in the VMware guest
- Migrating data with Veritas InfoScale product components in the VMware guest
- Improving database performance with Veritas InfoScale product components in the VMware guest
- Setting up virtual machines for fast failover using Storage Foundation Cluster File System High Availability on VMware disks
- About setting up Storage Foundation Cluster File High System High Availability on VMware ESXi
- Configuring coordination point (CP) servers
- Section IV. Reference
Getting consistent names across nodes
It is likely that the VMDK files are presented in a different order on each system and that the names given by Volume Manager may vary. The recommended best practice for a consistent deployment is to rename the disk so the configuration is clear.
As an example of the initial discrepancies between cfs01 and cfs03, cfs01 the disk name associated to device ending on serial number 226 is vmdk0_5:
[root@cfs01 ~]# /etc/vx/bin/vxgetdmpnames enclosure vendor=VMware product=disk serial=vmdk name=vmdk0 dmpnode serial=6000c2993a8d6030ddf71042d4620cec name=vmdk0_1 dmpnode serial=6000c29ac083abd0a86fa46b509d69f5 name=vmdk0_2 dmpnode serial=6000c29e13f6aff58ac3d543b022dfe2 name=vmdk0_3 dmpnode serial=6000c29f2a8d6030ddf71042d4620cec name=vmdk0_4 dmpnode serial=6000c2993a8d6030ddf71042d4620cec name=vmdk0_5
Observe how cfs03 named the same device vmdk_0_0:
[root@cfs01 ~]# /etc/vx/bin/vxgetdmpnames enclosure vendor=VMware product=disk serial=vmdk name=vmdk0 dmpnode serial=6000c2993a8d6030ddf71042d4620cec name=vmdk0_1 dmpnode serial=6000c29ac083abd0a86fa46b509d69f5 name=vmdk0_2 dmpnode serial=6000c29e13f6aff58ac3d543b022dfe2 name=vmdk0_3 dmpnode serial=6000c29f2a8d6030ddf71042d4620cec name=vmdk0_4 dmpnode serial=6000c2993a8d6030ddf71042d4620cec name=vmdk0_5
In order to get the same names across all the cluster nodes the command vxddladm is used. For each node of the cluster, run the command:
# vxddladm assign names
Observe now how cfs03 got the right name for device ending at 226 serial number:
[root@cfs01 ~]# /etc/vx/bin/vxgetdmpnames enclosure vendor=VMware product=disk serial=vmdk name=vmdk0 dmpnode serial=6000c2993a8d6030ddf71042d4620cec name=vmdk0_1 dmpnode serial=6000c29ac083abd0a86fa46b509d69f5 name=vmdk0_2 dmpnode serial=6000c29e13f6aff58ac3d543b022dfe2 name=vmdk0_3 dmpnode serial=6000c29f2a8d6030ddf71042d4620cec name=vmdk0_4 dmpnode serial=6000c2993a8d6030ddf71042d4620cec name=vmdk0_5