Visitors

HOW TO: Configure syslog server for VMware NSX for vSphere Controllers using REST API

After installing Management Pack for NSX for VMware vRealize Operations Manager, I got a warning that “There is no syslog server configured on the NSX Controller”

There is no syslog server configured on the NSX Controller

The only “supported” method of configuring syslog server for VMware NSX for vSphere 6.x Controllers is using the REST API.

Before you begin configuring the Syslog service using the REST API, there are a couple of things you need to have in place:

  1. REST API Client. For example, RESTClient Add-On for Mozilla Firefox browser.
  2. Authentication header.

The request body to configure this is fairly straight forward, as there are only a few elements that can be configured.

<controllerSyslogServer>
<syslogServer>10.160.20.1</syslogServer>
<port>514</port>
<protocol>TCP</protocol>
<level>INFO</level>
</controllerSyslogServer>

Before we begin configuring the Syslog service using the REST API, let us take a brief look at what REST client(s) are available to enable us to quickly perform this configuration programatically.

Once you are done with enabling either of these plug-ins, you need to know couple of other pieces of information before you send the REST request body to the NSX for vSphere Manager to setup the Syslog for NSX for vSphere Controller.

First of all REST API Requests require Authentication header (REST Client will Base 64 Encode the Credentials for NSX for vSphere Manager. Also PUT or POST (If sending HTTP Body) will require you to set an additional Header. There are as below:

  • Name = Content-Type
  • Value = application/xml

Confirm Authorization & Content-Type headers are properly setup.

  • If you want to retrieve details about the configured syslog exporter on the specified controller node, you need to send this HTTP request.
    Method: GET
    Request: https://<nsxmgr-ip>/api/2.0/vdn/controller/{controller-id}/syslog

    No Syslog configured:
    VMware NSX Configuring Syslog for NSX for vSphere Controller - GET

  • To configure syslog server(s) paste the request in the Request Body and change the method to POST:
    Method: POST
    Request: https://<nsxmgr-ip>/api/2.0/vdn/controller/{controller-id}/syslog
    VMware NSX Configuring Syslog for NSX for vSphere Controller - PUT
  • If you want to delete the syslog exporter on the specified controller node then use this HTTP request.
    Method: DELETE
    Request: https://<nsxmgr-ip>/api/2.0/vdn/controller/{controller-id}/syslog

Please refer to VMware KB Article “Configuring syslog server for VMware NSX for vSphere 6.x controllers (2092228)” for more details.

By Mark Strong, on February 8th, 2016 | Tags: , , | Category: VMware | One comment

VMware vCenter Single Sign-On (SSO) upgrade runs out of disk space and fails

VMware: vCenter 5.5 Update 2d in Linked Mode
OS: Windows Server 2012 R2
vCenter SSO: Multisite deployment
VMware vCenter 5.5 Update 2e: Release Notes & Installation and Upgrade Issues

I tried to upgrade VMware vCenter 5.5 from Update 2d to Update 2e. The Linked Mode was unconfigured prior to upgrade.

All services were running OK and the server had 20GB of disk space available on the C: drive. After launching the vCenter SSO installer it detected a previous version and prompted to upgrade. The upgrade took a long time and eventually prompted that the server ran out of disk space on the C: drive. On close inspection there were quite a few hs_err_PID*(.log) (where PID – Process ID) Java crash dump files generated in the following folders:

  • C:Program FilesVMwareInfrastructurevSphereWebClientserver
  • C:Program FilesCommon FilesVMwareVMware vCenter Server - tc Serverbinwinx86_64

When the Java error dump files were deleted, I clicked on Retry and SSO upgrade completed successfully. Although no new Java error dump files were generated, the VMware Identity Management Service failed to start. Obviously, the vCenter Server was broken and it was not possible to upgrade other vCenter Services/Modules.

Suspecting something is not right with the VMware JRE, I rolled back the snapshot, restarted the server and tried to upgrade VMware JRE (Java Running Environment) by running VMware-jre.exe from {vCenterInstallationMedia}:vJRE folder (same as from {vCenterInstallationMedia}:Single Sign-Onprerequisites) . The upgrade completed successfully but when I attempted to upgrade SSO, I had exactly the same issues as described. Back to the snapshot… :(

Here is what you need to do to resolve this issue:

  1. Stop all VMware services that rely on VMware JRE:
    • VMware vSphere Profile-Driven Storage Service
    • VMware VirtualCenter Management Webservices
    • VMware vSphere Web Client
    • VMware vCenter Inventory Service
    • VMware Secure Token Service
    • VMware Log Browser
    • VMware Identity Management Service
  2. Uninstall VMware vCenter Server – Java Components
    • There are no files left in C:Program FilesCommon FilesVMwareVMware vCenter Server - Java Componentsbin folder
    • There are no running processes using java: tasklist | findstr java
  3. Map the vCenter media of the currently installed version of the vCenter. In my environment, vCenter 5.5 Update 2d
  4. Install VMware vCenter Server – Java Components from {vCenterInstallationMedia}:vJRE folder.
    All services that were stopped in Step 1 will start automatically.
    Restart the server to make sure all vCenter services start successfully…
  5. Map the target version vCenter media
  6. Upgrade vCenter Server

A couple of post-upgrade tips:

  1. Logging in to the Web Client took a VERY long time after the upgrade… As I have quite a few Web Client Plug-ins and some of them have multiple versions, I stopped VMware vSphere Web Client, copied all Plug-in folders from ‘C:ProgramDataVMwarevSphere Web Clientvc-packagesvsphere-client-serenity’ to a new Backup folder and then started VMware vSphere Web Client. Only the latest versions of The Web Client Plug-ins were copied back into the folder. That seems to help with logging in to the Web Client;
  2. vCenter Upgrade Manager upgrade failed but completed successfully when I enabled Internet access on the VUM server;
  3. If you need to check VMware Java version installed, run the following command: 
    C:Program FilesCommon FilesVMwareVMware vCenter Server - Java Componentsbin
>java.exe -version
java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b32)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)

Hope this will help.

By Mark Strong, on January 28th, 2016 | Tags: , , , | Category: VMware | Leave a comment

HOW TO: Reset admin password on EMC ESRS VE

The root and admin passwords for the EMC ESRS VE virtual appliance are configured during VA deployment, there is no ‘default‘ password.

EMC ESRS VE admin password failed change

If you have EMC ESRS VE 3.04 and below installed and lost admin password, you have no other option other than to re-deploy the ESRS VA.

In 3.06+ you can login to the VA console or through SSH as root and run the following command to reset admin’s password:

login as: root

emcsrs001:~ # cd /opt/esrs/webuimgmt-util/

emcsrs001:/opt/esrs/webuimgmt-util # ls
passwordAdmin passwordAdmin.sh

emcsrs001:/opt/esrs/webuimgmt-util # ./passwordAdmin.sh
************************************************************************************************
******************************************Password Reset Util***********************************
************************************************************************************************
------------------------------------------Password Specifications-------------------------------
1. Be 8 or more characters in length, with a maximum of 16 characters
2. Contain at least one numeric character
3. Contain at least one uppercase and one lowercase character
4. Contain at least one special character such as ` ~ ! @ # $ % ^ & * ( ) - _ = + [ ] { } ; < >
5. Do not use special characters / ? : , . |  ' and " as part of the password
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
************************************************************************************************
************************************************************************************************
Provide the password to be set for the user admin:Margarin001!
Confirm the new password to be set for the user admin:Margarin001!
Password has been successfully reset for the user admin

I hope this will help.

By Mark Strong, on January 14th, 2016 | Tags: , | Category: Storage | One comment

Configuring Syslog on VMware vSphere ESXi host fails with 'Got no data from process' error

I installed VMware vRealize Log Insight and configured all ESXi hosts to send logs to it. Automatic configuration failed and Log Insight suggested to configure Syslog service manually.

Here are a couple of VMware Knowledge Base articles that will help you:

OK, let’s check syslog configuration:

Default Network Retry Timeout: 180
Local Log Output: /scratch/log
Local Log Output Is Configured: false
Local Log Output Is Persistent: true
Local Logging Default Rotation Size: 10240
Local Logging Default Rotations: 20
Log To Unique Subdirectory: false
Remote Host: 10.100.20.1

Remote Host configuration is incorrect.

Configure Syslog service to send logs to a remote host:

~ # esxcli system syslog config set --loghost='udp://10.100.20.1:514,udp://10.100.150.100:514'
Got no data from process
/usr/lib/vmware/vmsyslog/bin/esxcfg-syslog --plugin=esxcli --loghost='udp://10.100.20.1:514,udp://10.100.150.100:514'

Configuration command failed with “Got no data from process” error message.

Let’s check if the syslog service is running:

~ # ps | grep -i syslog
38072906 38072906 vmsyslogd  /bin/python
38072907 38072906 vmsyslogd  /bin/python
38072908 38072906 vmsyslogd  /bin/python
38072909 38072906 vmsyslogd  /bin/python

..and check the syslog service log:

~ # tail /var/log/.vmsyslogd.err
2016-01-04T17:22:02.499Z vmsyslog.loggers.file : ERROR ] Gzip logfile /scratch/log/vmkernel.0.gz failed <type 'exceptions.MemoryError'>
2016-01-04T17:22:04.451Z vmsyslog.loggers.file : ERROR ] Gzip logfile /scratch/log/vmkernel.0.gz failed <type 'exceptions.MemoryError'>
2016-01-04T17:22:06.364Z vmsyslog.loggers.file : ERROR ] Gzip logfile /scratch/log/vmkernel.0.gz failed <type 'exceptions.MemoryError'>
2016-01-04T17:22:08.312Z vmsyslog.loggers.file : ERROR ] Gzip logfile /scratch/log/vmkernel.0.gz failed <type 'exceptions.MemoryError'>

There are error messages in the log.

OK, let’s kill syslog processes:

~ # kill -9 `ps -Cuv | grep syslog | awk '{print $1}'`

…and reconfigure syslog again:

~ #  esxcli system syslog config set --loghost='udp://10.100.20.1:514,udp://10.100.150.100:514'

No error message this time.

Check syslog configuratio again:

~ #  esxcli system syslog config get
Default Network Retry Timeout: 180
Local Log Output: /scratch/log
Local Log Output Is Configured: false
Local Log Output Is Persistent: true
Local Logging Default Rotation Size: 10240
Local Logging Default Rotations: 20
Log To Unique Subdirectory: false
Remote Host: udp://10.100.20.1:514,udp://10.100.150.100:514

All good.

Hope this will help.

By Mark Strong, on January 7th, 2016 | Tags: , | Category: VMware | Leave a comment

VMware PowerCLI script to get VM's virtual and RDM disk information

I have been tasked to migrate several VMs with RDM disks between storage arrays / datastores. The data LUNs have been migrated/copied and all was left is the migration of the VM configuration files and RDM pointers. To make matter even worse, VMs in question were Oracle RAC clustered VMs therefore is was imperative to migrate the disks and SCSI IDs in “like it was before” way.

Let me start with a script that lists VM’s virtual and RDM disks, SCSI IDs and Disk Device Name and files names:

$DiskInfo= @()
foreach ($VMview in Get-VM node001, node002 | Get-View){
foreach ($VirtualSCSIController in ($VMView.Config.Hardware.Device | where {$_.DeviceInfo.Label -match "SCSI Controller"})) {
foreach ($VirtualDiskDevice in ($VMView.Config.Hardware.Device | where {$_.ControllerKey -eq $VirtualSCSIController.Key})) {
$VirtualDisk = "" | Select VMname, SCSIController, DiskName, SCSI_ID, DeviceName, DiskFile, DiskSize
$VirtualDisk.VMname = $VMview.Name
$VirtualDisk.SCSIController = $VirtualSCSIController.DeviceInfo.Label
$VirtualDisk.DiskName = $VirtualDiskDevice.DeviceInfo.Label
$VirtualDisk.SCSI_ID = "$($VirtualSCSIController.BusNumber) : $($VirtualDiskDevice.UnitNumber)"
$VirtualDisk.DeviceName = $VirtualDiskDevice.Backing.DeviceName
$VirtualDisk.DiskFile = $VirtualDiskDevice.Backing.FileName
$VirtualDisk.DiskSize = $VirtualDiskDevice.CapacityInKB * 1KB / 1GB
$DiskInfo += $VirtualDisk
}}}
$DiskInfo | sort VMname, Diskname | Export-Csv -Path 'd:DiskInfo.csv'
# You can also use FT -AutoSize or Out-GridView if it helps

The script output shows everything you need to complete the migration successfully:

VMname SCSIController DiskName SCSI_ID DeviceName DiskFile DiskSize
Node001 SCSI controller 0 Hard disk 1 00:00 [My_Datastore_1] Node001/Node001.vmdk 70
Node001 SCSI controller 1 Hard disk 10 01:08 vml.0200240000514f0c5ff200006e587472656d41 [My_Datastore_1] Node001/Node001_11.vmdk 2
Node001 SCSI controller 1 Hard disk 11 01:09 vml.0200470000514f0c5ff200006f587472656d41 [My_Datastore_1] Node001/Node001_12.vmdk 10
Node001 SCSI controller 1 Hard disk 12 01:10 vml.0200480000514f0c5ff2000070587472656d41 [My_Datastore_1] Node001/Node001_13.vmdk 2
Node001 SCSI controller 0 Hard disk 2 00:01 vml.02000d0000514f0c5ff2000047587472656d41 [My_Datastore_1] Node001/Node001_1.vmdk 30
Node001 SCSI controller 0 Hard disk 3 00:02 vml.0200290000514f0c5ff2000048587472656d41 [My_Datastore_1] Node001/Node001_2.vmdk 30
Node001 SCSI controller 1 Hard disk 4 01:00 vml.02002c0000514f0c5ff200004b587472656d41 [My_Datastore_1] Node001/Node001_3.vmdk 5
Node001 SCSI controller 1 Hard disk 5 01:06 vml.0200450000514f0c5ff2000064587472656d41 [My_Datastore_1] Node001/Node001_9.vmdk 100
Node001 SCSI controller 1 Hard disk 6 01:04 vml.0200440000514f0c5ff2000063587472656d41 [My_Datastore_1] Node001/Node001_7.vmdk 5
Node001 SCSI controller 1 Hard disk 7 01:03 vml.0200430000514f0c5ff2000062587472656d41 [My_Datastore_1] Node001/Node001_6.vmdk 125
Node001 SCSI controller 1 Hard disk 8 01:05 vml.0200420000514f0c5ff2000061587472656d41 [My_Datastore_1] Node001/Node001_8.vmdk 5
Node001 SCSI controller 0 Hard disk 9 00:03 [My_Datastore_1] Node001/Node001_10.vmdk 21
Node002 SCSI controller 0 Hard disk 1 00:00 [My_Datastore_2] Node002/Node002.vmdk 70
Node002 SCSI controller 1 Hard disk 10 01:08 vml.0200240000514f0c5ff200006e587472656d41 [My_Datastore_1] Node001/Node001_11.vmdk 2
Node002 SCSI controller 1 Hard disk 11 01:09 vml.0200470000514f0c5ff200006f587472656d41 [My_Datastore_1] Node001/Node001_12.vmdk 10
Node002 SCSI controller 1 Hard disk 12 01:10 vml.0200480000514f0c5ff2000070587472656d41 [My_Datastore_1] Node001/Node001_13.vmdk 2
Node002 SCSI controller 0 Hard disk 2 00:01 vml.02002a0000514f0c5ff2000049587472656d41 [My_Datastore_2] Node002/Node002_1.vmdk 30
Node002 SCSI controller 0 Hard disk 3 00:02 vml.02002b0000514f0c5ff200004a587472656d41 [My_Datastore_2] Node002/Node002_2.vmdk 30
Node002 SCSI controller 1 Hard disk 4 01:00 vml.02002c0000514f0c5ff200004b587472656d41 [My_Datastore_1] Node001/Node001_3.vmdk 5
Node002 SCSI controller 1 Hard disk 5 01:06 vml.0200450000514f0c5ff2000064587472656d41 [My_Datastore_1] Node001/Node001_9.vmdk 100
Node002 SCSI controller 1 Hard disk 6 01:04 vml.0200440000514f0c5ff2000063587472656d41 [My_Datastore_1] Node001/Node001_7.vmdk 5
Node002 SCSI controller 1 Hard disk 7 01:03 vml.0200430000514f0c5ff2000062587472656d41 [My_Datastore_1] Node001/Node001_6.vmdk 125
Node002 SCSI controller 1 Hard disk 8 01:05 vml.0200420000514f0c5ff2000061587472656d41 [My_Datastore_1] Node001/Node001_8.vmdk 5
Node002 SCSI controller 0 Hard disk 9 00:03 [My_Datastore_2] Node002/Node002_3.vmdk 21

To migrate both VMs to another Datastore you just need to (BTW, please refer to ‘Migrating virtual machines with Raw Device Mappings (RDMs) (1005241)‘ VMware KB article for more info):

  1. Using vCenter Web Client you migrate Node001 to the new datastore (this will move the RDM pointers as well);
  2. Remove RDM disk from the Node002;
  3. Migrate Node002 to the new datastore;
  4. Add cluster RDM disks to Node002 using the information provided by the script.

Job done.

You may also play with where command:

# Find VM with a specific RDM disk name or LUN ID :

Get-VM | Get-View | where {$_.Config.Hardware.Device.Backing.DeviceName -match "514f0c511580009f"}

# Find VM with a RDM disk on s specific storage array – c5cc2 is the LUN ID prefix :

Get-VM | Get-View | where {$_.Config.Hardware.Device.Backing.DeviceName -match "c5cc2"}

I hope this will help.

By Mark Strong, on December 16th, 2015 | Tags: , , | Category: Script, VMware | Leave a comment

EMC VNXe 3200 upgrade completed with error message "The DPE has faulted"

We recently upgraded EMC VNXe 3200 storage array from 3.1.1.5395470 to 3.1.1.5803064 (VCE RCM 5.0.10 or 6.0.3). Upgrade completed successfully (the NFS services failed over and back between Storage Processors without any issues and the hosts did not lose connectivity to the storage) but at the last minute we received the following error messages:

“The DPE has faulted
It is unsafe to remove SP B now
It is unsafe to remove SP A now
System VNXe has experienced one or more problems that have had a major impact”

EMC VNXe 3200 upgrade The DPE has faulted

This is a known issue and fix is being developed. A permanent fix will be available in MR1SP2 code (3.1.2.). Since this does not impact production and also hardware is not actually faulted, these alert messages can be safely ignored.

Cause: Baseboard Management Controller (BMC) is onboard device which queries all hardware components periodically. At some point some of the components take long time to process this request. This delay results in ‘timeout’ according to BMC which thinks components are bad. However, next cycle of device query may work fine and result in ‘operating normally’ message.  This software bug has been identified and timeout value has been enhanced to accommodate any delay.

I hope this will help.

By Mark Strong, on December 8th, 2015 | Tags: , , , , | Category: Storage, Vblock | Leave a comment

Cisco UCS B200 M4: FlexFlash FFCH_ERROR_OLD_FIRMWARE_RUNNING error

After upgrading Cisco UCS B200 M4 blade firmware from 2.2(3e) to 2.2(5c) the following minor fault appeared:

Cisco UCS B200 M4 - FlexFlash FFCH_ERROR_OLD_FIRMWARE_RUNNING error - 1

Apparently, it is known Cisco bug.

Cisco Bug: CSCut10525: FlexFlash FFCH_ERROR_OLD_FIRMWARE_RUNNING error on B200 M4

Quickview: https://tools.cisco.com/quickview/bug/CSCut10525
Details: https://tools.cisco.com/bugsearch/bug/CSCut10525/?referring_site=bugquickviewclick

Symptom:
After updating B200 M4 server firmware using MR3 build 169 bundle B, FFCH_ERROR_OLD_FIRMWARE_RUNNING is displayed on fault summary. Please see the attached screenshot in Enclosures.

Conditions:
B200 M4 Server after upgrade to 2.2.4b code

Workaround:
Reset FlexFlash Controller manually to make that error disappear

Here is how you do it:

  1. Open properties of the blade that that shows this error. Navigate to Inventory / Storage / Controller
    Under FlexFlash Controller 1 click on Reset FlexFlash Controller:
  2.  Click Yes.
    Cisco UCS B200 M4 - FlexFlash FFCH_ERROR_OLD_FIRMWARE_RUNNING error - 3
  3. Click OK.
    Cisco UCS B200 M4 - FlexFlash FFCH_ERROR_OLD_FIRMWARE_RUNNING error - 4
  4. The error message should go away.

Hope this will help.

By Mark Strong, on December 5th, 2015 | Tags: , , , | Category: VMware | 3 comments

VMware Host zoning for multi X-Brick EMC XtremIO storage array

VMware vSphere ESXi 5.5 and 6.0 have a limit of 256 LUNs per host:

https://www.vmware.com/pdf/vsphere5/r55/vsphere-55-configuration-maximums.pdf
https://www.vmware.com/pdf/vsphere6/r60/vsphere-60-configuration-maximums.pdf

In an environment where a host with two HBAs (VMware Best Practice) is connected to two fabrics and storage array with two Storage Controllers (EMC VNX, for example) the host will have four paths to a LUN: 2 Controllers x 2 HBAs = 4 paths

When we apply the same approach to EMC XtremIO clusters (two or more X-Bricks, 8 maximum), we should also consider another limit, the ‘Number of total paths on a server‘ which is 1024. With two X-Bricks, you have four controllers, multiply by two HBAs and you have eight paths per LUN. Therefore the max number of LUNs will be 128 LUNs (1024 / 8 = 128).

The following diagram displays the logical connection topology for 8 paths.
Host zoning EMC XtremIO dual X-Brick configuration - 8 paths

If you go to the extreme and configure your XtremIO with eight X-Brick, you have 16 controllers. Again, two HBAs per host and the max number of LUNs you can attach to an ESXi host will be 32… I understand, different OS’es may have different limits than VMware and this logic will not be applicable.

If you have hit the limit of 1024 paths per host (1024 / 4 controllers / 2 HBAs = 128 LUNs) and need to provision more LUNs, the best way will be to re-zone the host to limit the number of X-Bricks / Controllers the host HBA can connect to.

The following diagram displays the logical connection topology for 4 paths.
Host zoning EMC XtremIO dual X-Brick configuration - 4 paths

OK, let see how to reconfigure the zoning. Please refer to ‘HOW TO: Configure smart zoning on Cisco MDS 9148s‘ blog post to see how it was configured in the first place.

  1. To begin with, lets check the current zoning configuration:
    • Fabric1: 
      zone name Cluster01_hosts_XIO vsan 10
  fcalias name Cluster01_hosts vsan 10
    pwwn 20:00:00:25:b5:03:a0:04 [Cluster01n01_vhba0]  init
    pwwn 20:00:00:25:b5:03:a0:05 [Cluster01n02_vhba0]  init

  fcalias name Cluster01_XIO vsan 10
    pwwn 21:00:00:24:ff:5e:f7:4a [X1_SC1_FC1]  target
    pwwn 21:00:00:24:ff:5f:0b:90 [X1_SC2_FC1]  target
    pwwn 21:00:00:24:ff:8c:9b:78 [X2_SC1_FC1]  target
    pwwn 21:00:00:24:ff:3d:5c:32 [X2_SC2_FC1]  target
    • Fabric2: 
       zone name Cluster01_hosts_XIO vsan 11
    fcalias name Cluster01_hosts vsan 11
      pwwn 20:00:00:25:b5:03:b1:04 [Cluster01n01_vhba1]  init
      pwwn 20:00:00:25:b5:03:b1:05 [Cluster01n02_vhba1]  init

    fcalias name Cluster01_XIO vsan 11
      pwwn 21:00:00:24:ff:5e:f7:4b [X1_SC1_FC2]  target
      pwwn 21:00:00:24:ff:5f:0b:91 [X1_SC2_FC2]  target
      pwwn 21:00:00:24:ff:8c:9b:79 [X2_SC1_FC2]  target
      pwwn 21:00:00:24:ff:3d:5c:33 [X2_SC2_FC2]  target
  2. The idea is to configure one HBA to one X-Brick zones therefore I will create an FCalias for X-Brick1 and X-Brick2 (X-BrickN, if you have more…).
    • Fabric1: 
      fcalias name XIO_X1 vsan 10
member device-alias X1_SC1_FC1 target
member device-alias X1_SC2_FC1 target

fcalias name XIO_X2 vsan 10
member device-alias X2_SC1_FC1 target
member device-alias X2_SC2_FC1 target
    • Fabric2: 
      fcalias name XIO_X1 vsan 11
member device-alias X1_SC1_FC2 target
member device-alias X1_SC2_FC2 target

fcalias name XIO_X2 vsan 11
member device-alias X2_SC1_FC2 target
member device-alias X2_SC2_FC2 target
    • N.B. These aliases can also be used to zone hosts to all X-Bricks in the normal fashion if the LUN/path limit is not going to be an issue: 
       zone name Cluster01_X1_X2 vsan 11
member Cluster01_hosts 
member fcalias XIO_X1
member fcalias XIO_X2
  3. Let’s configure the zones. There is only one HBA per zone, therefore I will not be configuring the fcalias but use device alias instead:
    • Fabric1: 
      zone name Cluster01N01_X1 vsan 10
member device-alias Cluster01n01_vhba0 initiator
member fcalias XIO_X1

zone name Cluster01N02_X2 vsan 10
member device-alias Cluster01n02_vhba0 initiator
member fcalias XIO_X2
    • Fabric2: 
      zone name Cluster01N01_X1 vsan 11
member device-alias Cluster01n01_vhba1 initiator
member fcalias XIO_X1

zone name Cluster01N02_X2 vsan 11
member device-alias Cluster01n02_vhba1 initiator
member fcalias XIO_X2
  4. Add the zones to the zoneset:
    • Fabric1: 
      zoneset name zs_vsan10 vsan 10
member Cluster01N01_X1
member Cluster01N02_X2
    • Fabric2: 
      zoneset name zs_vsan11 vsan 11
member Cluster01N01_X1
member Cluster01N02_X2
  5. Activate zoneset and commit the zone:
    • Fabric1: 
      zoneset activate name zs_vsan10 vsan 10
zone commit vsan 10
    • Fabric2: 
      zoneset activate name zs_vsan11 vsan 11
zone commit vsan 11
  6. Remove the old zones and fcaliases:
    1. Fabric1: 
      no zone name Cluster01_hosts_XIO vsan 10
no fcalias name Cluster01_hosts vsan 10
no fcalias name Cluster01_XIO vsan 10
    2. Fabric2 
      no zone name Cluster01_hosts_XIO vsan 11
no fcalias name Cluster01_hosts vsan 11
no fcalias name Cluster01_XIO vsan 11
  7. Commit the zones again.
  8. Rescan HBAs and confirm the number of path has changed.

I hope this will help.

By Mark Strong, on November 18th, 2015 | Tags: , , | Category: Cisco, Storage, VMware | Leave a comment

Michael Dell spells out his plans for VMware:…

Michael Dell spells out his plans for @VMware: “Crown jewel of the EMC federation”


Michael Dell spells out his plans for VMware:…

“We believe it is very important to maintain VMware’s successful business model supporting an open and independent ecosystem,” Dell said. “We do not plan to do anything proprietary with VMware as regards Dell or EMC, nor place any limitations on VWware’s ability to partner with any other company.”

VMware Advocacy

By Mark Strong, on November 10th, 2015 | Category: VMware | Leave a comment

HOW TO: Upgrade EMC Virtual Storage Integrator (VSI) for VMware vSphere Web Client

The EMC Virtual Storage Integrator (VSI) for VMware vSphere Web Client is a plug-in for VMware vCenter. It enables administrators to view, manage, and optimize storage for VMware ESX/ESXi servers and hosts and then map that storage to the hosts.

VSI consists of a graphical user interface and the EMC Solutions Integration Service (SIS), which provides communication and access to the storage systems.

Depending on the platform, tasks that you can perform with VSI include:

  • Storage provisioning
  • Setting multipathing policies
  • Cloning
  • Block deduplication
  • Compression
  • Storage mapping
  • Capacity monitoring
  • Virtual desktop infrastructure (VDI) integration
  • Data protection using EMC AppSync or EMC RecoverPoint

Using the Solutions Integration Service, a storage administrator can enable virtual machine administrators to perform management tasks on a set of storage pools.

Some light reading and the OVA package:

OK, let’s discuss the upgrade procedure!  Well, it is not actually an upgrade (not an in-place upgrade) but rather a database backup, deployment of the new version and then the DB restore (migration).

I am going to upgrade VSI for VMware vSphere Web Client from 6.4.1.1 to 6.6.3.

Note: For migration from VSI 6.1 only: A known limitation causes the migration of VMAX storage systems from 6.1 to 6.6 to fail. Before creating a backup of the existing database, the storage administrator must delete all VMAX storage systems and then re-register them and the VMAX users after the upgrade.

  1. Log in to your current version of the Solutions Integration Service https://<SIS IP Address>:8443/vsi_usm/, click Database and select Take a Backup from the Task drop-down and click Submit to create a backup file of the existing database, and save the backup to a secure location.
    EMC VSI SIS - Database backup
  2. Deploy the new Solutions Integration Service .
    I will actually power the existing VA off and rename it as the new VA will have the same VM name and be running in the same cluster.

    1. Deploy EMC Solutions Integration Service OVA file;
    2. Power On virtual machine with EMC Solutions Integration Service and wait for the deployment to finish;
    3. Log in to the new Solutions Integration Service as admin/ChangeMe (see Default Password for details) and change the default password;
      https://<SIS IP Address>:8443/vsi_usm/
      There is no need to configure the EMC SIS, the configuration will be restored from the DB backup

    4. Just to be safe, log in to the new Solutions Integration Service, click Database and select Take a Backup to create a backup of the new Solutions Integration Service database, and save the backup to a secure location.

    5. Log in to the new Solutions Integration Service, click Database and select Data Migration from the Task drop-down menu. Click Choose File and locate the database backup of the previous version. Click Submit.
      It should not matter but in my environment the Data Migration did not work in Mozila FireFox 41.0.2 but worked in Internet Explorer 11.
      EMC VSI SIS - Database migration
    6. If the migration is successful, all Solutions Integration Service data for the previous version are moved to the new version, including users, storage systems, and access control information.
      If you changed VM name (host name), deactivate the previous version of the Solutions Integration Service.
      Follow Step 8.
    7. If the migration fails:
      a. Restore the new Solution Integration Service database from the backup file you created in step 4.
      b. Manually provision all required elements.
    8. Register the VSI plug-in with vCenter:
      1. Log in to the new Solutions Integration Service  https://<SIS IP Address>:8443/vsi_usm/admin
      2. Click VSI Setup;
      3. Enter the values for the following parameters and click Register.
        • vCenter IP/Hostname: The IP address that contains the VSI plug-in package.
          This is the IP address of the vCenter to which you are registering the VSI plug-in. If you are using the vCenter hostname, ensure that DNS is configured.
        • vCenter Username: The username that has administrative privileges.
        • vCenter Password: The administrator’s password.
        • Admin Email (Optional): The email address to which notifications should be sent.
      4. If the registration was successful, the following will be displayed in the Status window: 
        10/30/2015 17:23:12 sending your request ...
10/30/2015 17:23:21 receiving your response ...

The operation was successful.

Registered VSI Plugin:
Key: com.emc.vsi.plugin
Version: 6.6.3.39
Name: EMC VSI Plugin
Description: Integrated management support for EMC storage systems
Admin Email: none
      5. Browse to the vSphere Web Client address.
        After you log in, the VSI plug-in is downloaded and deployed.
        Note: The download takes several minutes.
        If you have installed previous versions of the VSI plug-in, clear your browser cache to ensure that you use the newest version of VSI.

Hope this will help.

By Mark Strong, on November 2nd, 2015 | Tags: , , , | Category: Storage, VMware | Leave a comment
 
  Older Entries »