Please enter search query.
Search <book_title>...
Veritas InfoScale™ 7.4.1 Virtualization Guide - Linux on ESXi
Last Published:
2019-02-07
Product(s):
InfoScale & Storage Foundation (7.4.1)
Platform: Linux,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
- Configuring storage
- Enabling disk UUID on virtual machines
- Installing Array Support Library (ASL) for VMDK on cluster nodes
- Excluding the boot disk from the Volume Manager configuration
- Creating the VMDK files
- Mapping the VMDKs to each virtual machine (VM)
- Enabling the multi-write flag
- Getting consistent names across nodes
- Creating a file system
- 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
- Use cases for Dynamic Multi-Pathing (DMP) in the VMware environment
- How DMP works
- Achieving storage visibility using Dynamic Multi-Pathing in the hypervisor
- Achieving storage availability using Dynamic Multi-Pathing in the hypervisor
- Improving I/O performance with Dynamic Multi-Pathing in the hypervisor
- Achieving simplified management using Dynamic Multi-Pathing in the hypervisor and guest
- Improving data protection, storage optimization, data migration, and database performance
- Use cases for InfoScale product components in a VMware guest
- Protecting data with InfoScale product components in the VMware guest
- Optimizing storage with InfoScale product components in the VMware guest
- About SmartTier in the VMware environment
- About compression with InfoScale product components in the VMware guest
- About thin reclamation with InfoScale product components in the VMware guest
- About SmartMove with InfoScale product components in the VMware guest
- About SmartTier for Oracle with InfoScale product components in the VMware guest
- Migrating data with InfoScale product components in the VMware guest
- Improving database performance with 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 use cases for InfoScale Enterprise in the VMware guest
- Storage Foundation Cluster File System High Availability operation in VMware virtualized environments
- Storage Foundation functionality and compatibility matrix
- About setting up Storage Foundation Cluster File High System High Availability on VMware ESXi
- Planning a Storage Foundation Cluster File System High Availability (SFCFSHA) configuration
- Enable Password-less SSH
- Enabling TCP traffic to coordination point (CP) Server and management ports
- Configuring coordination point (CP) servers
- Deploying Storage Foundation Cluster File System High Availability (SFCFSHA) software
- Configuring Storage Foundation Cluster File System High Availability (SFCFSHA)
- Configuring non-SCSI3 fencing
- 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