Tag Archives: Vmware

pRDM and vRDM to VMDK Migrations

I was assisting an amazing client in moving some VMs off an older storage array and onto a newer storage platform. They had some VMs that had Physical RDMs (pRDM) attached to the VMs, and we wanted them living as VMDKs on the new SAN.
Traditionally, I have always shutdown the VM, remove the pRDM, re-add with vRDM, and then do the migration, but found an awesome write-up on a few separate ways in doing this.
(Credit of the following content goes to Cormac Hogan of VMware)

VM with Physical (Pass-Thru) RDMs (Powered On – Storage vMotion):

  • If I try to change the format to thin or thick, then no Storage vMotion allowed.
  • If I chose not to do any conversion, only the pRDM mapping file is moved from the source VMFS datastore to the destination VMFS datastore – the data stays on the original LUN.

 

VM with Virtual (non Pass-Thru) RDMs (Power On – Storage vMotion):

  • On a migrate, if I chose to covert the format in the advanced view, the vRDM is converted to a VMDK on the destination VMFS datastore.
  • If I chose not to do any conversion, only the vRDM mapping file is moved from the source VMFS datastore to the destination VMFS datastore – the data stays on the original LUN (same behaviour as pRDM)

 

VM with Physical (Pass-Thru) RDMs (Powered Off – Cold Migration):

  • On a migrate, if I chose to change the format (via the advanced view), the pRDM is converted to a VMDKon the destination VMFS datastore.
  • If I chose not to do any conversion, only the pRDM mapping file is moved from the source VMFS datastore to the destination VMFS datastore – the data stays on the original LUN

 

VM with Virtual (non Pass-Thru) RDMs (Power Off – Cold Migration):

  • On a migrate, if I chose to covert the format in the advanced view, the vRDM is converted to a VMDK on the destination VMFS datastore.
  • If I chose not to do any conversion, only the vRDM mapping file is moved from the source VMFS datastore to the destination VMFS datastore – the data stays on the original LUN (same behaviour as pRDM).

VMware vSphere ISCSI Port Bindings – You’re Probably Doing it Wrong

As a Consultant, I have the opportunity of seeing a lot of different operating environments from a variety of customers. At a high-level, most customers have the same data center infrastructure (Servers, Storage, Running Virtualization, etc). Although the configurations of these environments vary, I see one configuration mistake made by many of these customers – “ISCSI Port Binding”.

For those unfamiliar with ISCSI Port Binding, Port Binding binds/glues the ISCSI Initiator interface on the ESXi Host to a vmknic to allow for ISCSI multipathing. Binding itself technically  doesn’t  “allow multipathing”, just having multiple adapters can do that. But if you have Multiple Adapters/VMkernel ports for ISCSI used in the SAME subnet/broadcast domain, it will allow multiple paths to the ISCSI array that broadcasts one single IP Address.

Why do I need to bind my Initiator to a VMkernel anyway?
When you have multiple ISCSI Adaptors on the same subnet, there is really no control on where data flows or how to control data broadcasts of the adapters. You literally flood that network with rouge packets.
* Note: I am trying to make this easy to understand for those that don’t have a deep technical experience on this subject. And in doing so, I am only telling half-truths here to keep things simple. Don’t call me out on this 🙂

When should you enable ISCSI Port Binding?

ISCSI Port Binding is ONLY used when you have multiple VMKernels on the SAME subnet.

Pictured above, you can see there are multiple VMkernel ports on the same subnet and broadcast domain. You MUST use port binding! If you do not, you may experience the following:
– Unable to see ISCSI Storage on ESXi
– Paths to storage are reported as Dead
– Loss of Path Redundancy Errors
ISCSI Port Binding bypasses some vSwitch Functionality. No Data Path, No Acceleration.
Array Target ports must reside in the same Broadcast Domain & Subnet as the VMkernel port
All VMkernel ports used for ISCSI must reside in the same broadcast domain & subnet
All VMkernel ports used for ISCSI must reside in the same vSwitch

When should you NOT enable ISCSI Port Binding?

Do not enable Port Binding if Array Target ports are in a different broadcast domain & subnet
ISCSI VMkernel ports exist in different broadcast domain, Subnet an/or vSwitch
Routing is required to reach the array
If LACP/Link Aggregation is used on ESXi host uplinks to the pSwitch

In the above example, you should NOT use Port Binding. In doing so, you may experience:
– Rescan times take longer than usual
– Incorrect number of paths per device are seen
– Unable to see any storage from the array

So why do I say you are probably doing it wrong? Most storage arrays use the second example as a best practice for multipathing to the array. Most customers follow those best practices and use two VMkernel Ports on different subnets to connect to their arrays. But most people still enable port binding!
If you are guilty of this, you can easily remove the existing Port Bindings. Doing so will cause a temporary loss to your storage, so make sure all VMs are shutdown, and you have a maintenance window.

Now you know!

 

 

Patch an VMware ESXi Host without vCenter

Here is an easy step by step guide, how you can update this ESXi 5 host to the latest version…

1: Start your VMware Hypervisor EXSi 5 like you normal do, and connect to this host with your vSphere Client.

2: Switch the host to maintenance mode.

3: Install the needed patches (they can be found here: http://www.vmware.com/patchmgr/download.portal ) on one of you datastore’s in a folder called patch (in my case the Datastore is called Backup

4: goto the Configuration tab of your host, select Security Profile (under Software in the left) and select the Services Properties in the upper right of your screen

5: Select ESXi Shell and SSH and start these Services with the Start Service command button under Options…
make sure (just as on the screen both services are running(!)

6: Start PuTTY (you can find it here: http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html)

and login as the root to this host…

ow run the command:

esxcli software vib update -d /vmfs/volumes/[Datastorename]/[patchfilename].zip

: be patient(!) this can take some minutes(!) and repeat this for all the patch zip files (make sure you do this in the released order…

8 close puTTY, delete the patch directory from the datastore,  reboot the host. When the host is back, exit the maintenance mode and you are done!

your host is running the latest patches

 

If you found this article to be helpful, please support us by visiting our sponsors’ websites. 

Install VMware Tools on Linux VMs

Have Linux VMs and need to install VM Tools? Here are super easy instructions.

– First, open the Linux VM in a Console Window
– Click “VM” at the top Window, then “Guest”, followed by “Install/Upgrade VMware Tools”

– In a command line on the linux VM (as root or SU), run the following commands:

install rpm cdrom

Type “1” and hit Enter

After the install, Type “0” and hit Enter

Type “exit”

 

If you found this article to be helpful, please support us by visiting our sponsors’ websites. 

VMware Update Manager – Setup failed with an unknown error. vCenter credentials could not be validated

I was installing a new VUM (Vmware Update Manager) environment like I have numerous times in the past, and came upon this error I have never seen before.

“Setup failed with an unknown error. vCenter credentials could not be validated.”

While researching the error, I found one solution that has helped some, but did NOT help me.

– “Update Manager does not like passwords with weird characters. Try using a password with letter and numbers only”

So I continued to play around with Update Manager and found a fix for me. I had to give vCenter permissions for the user I was trying to use with Update Manager. To do this, I did the following:

– Login to vsphere using username: [email protected] with your SSO Password

– Select the Root vCenter Object and then click on the “Permissions” tab. Right click in the white space and select “Add Permissions”

– Click on “Add” in the left box and search for “Domain Admins” under your domain (As well as any other users you want to give permissions to. Then give Administrator privileges on the right hand side box and click OK.

– Now finish installing Update Manager, using an account you just gave permissions to.

If you found this article to be helpful, please support us by visiting our sponsors’ websites.