RSS

Category Archives: BackToBasics

Back To Basics: vSphere High Availability (PowerCLI)

Creating a vSphere HA Cluster

You can name clusters in any way you see fit – Gold, Silver, Bronze or by their location in the datacenter HALL2-RACK55 for instance. The new-cluster cmdlet support the enablement of both High Availability (HA), Distributed Resource Manager (DRS) and Enhanced vMotion Compatibility (EVC). With the advent of VMware’s VSAN technology, the new-cluster cmdlet all so supports its functionality as well. We have chosen to document the enablement of all these features in this section as this is the most like the requirement in most environments.

Each setting with – often support multiple parameters not shown in the sample below. These have been documented below the sample.

Note:

The New-Cluster cmdlet does NOT support:

  • Enabling the VM Monitoring feature
  • Enabling Distributed Power Management (DPM)
  • Cannot configure the datastore heartbeat parameter. This cannot be modified until ESXi hosts have been added to the vSphere Cluster

 

This article has been donated to the VMUG Wiki – Click here to read on…

 

 

Posted by on January 7, 2015 in BackToBasics

Comments Off on Back To Basics: vSphere High Availability (PowerCLI)

Back To Basics: Viewing and Modifying vSphere HA Settings

 All the settings for vSphere HA can be found under the properties of the cluster >> Manage and the Edit button.

Host Monitoring

The host monitoring portion of the Edit Cluster Settings options control whether vSphere HA is turn on or off. As indicated earlier it is possible to turn off Host Monitoring. This controls whether the vSphere host share the network heartbeat that is used to calculate if the host is alive or dead. This can check can be temporarily turned off if you know that some network maintenance (such as physical switch or router upgrade) is likely to cause the network to be down for a period of time. The virtual machine options control what happens by default if there is a failure or isolation event. Two settings are available here, VM Restart Priority and Host Isolation Response. Restart Priority allows for four options – disabled, low, medium, high. By default is medium is selected, and all VMs would have the same restart priority of medium. It’s then possible under the VM Overrides options to add individual VMs, and indicate that some VMs have a low priority, or high priority – are started after or before any VMs with a medium priority. Alternatively, VMs can be excluded from the restart process altogether by using the VM Over-rides to disabled. This can be useful if you have non-critical VMs are that are not needed be available – and frees up resources for the more critical VMs. The Isolation Response controls what happens if a host becomes disconnected from the cluster due to some network outage or configuration error. In this case the isolated host may well be able to communicate to the router, but not the other hosts. Alternatively using what are called “datastore heartbeats” vSphere can work out that the host maybe disconnected from the network, but still connected to shared cluster resources. In such a case the host could still be running, and the VMs are unaffected. In this case the default policy would be to “Leave Powered On”. The alternatively, is assume a failure has occurred and either power of and restart, or shutdown the guest operating system, and restart on to the remaining hosts.

This article has been donated to the VMUG Wiki – Click here to read on…

 

Posted by on November 3, 2014 in BackToBasics

Comments Off on Back To Basics: Viewing and Modifying vSphere HA Settings

Back To Basics: Testing vSphere HA

There are number of different ways to test if vSphere is working correctly. By the far the most effective and realistic is to enduce a failure of a physical vSphere host by powering it off. This can be done physically with the power button or by using the BMC/DRAC/ILO card. This test would require some powered on VMs. Powering off a vSphere host does not register immediately in the vCenter/Web Client UI as the management systems has number of re-tries to connect to the vSphere host in the event of temporary network outage. So for tests you may wish to carry out a ping -t of the vSphere host that will be brought down and number of the VMs that currently located on the host.

You can find out the IP address of given VM by viewing its “Summary” page

Screen Shot 2014-09-17 at 12.57.01.png

This article has been donated to the VMUG Wiki – Click here to read on…

 

 

Posted by on October 31, 2014 in BackToBasics

Comments Off on Back To Basics: Testing vSphere HA

Back To Basics: Introduction: vSphere High Availability

HA Overview

The primary role of High Availability (HA) in vSphere environment is to restart VMs if a vSphere Host experiences as catastrophic failure. This could be caused by any number of issues such as power outage, and failure of multiple hardware components such that operation of the VM is impacted. VMware HA is part of number of “clustering” technologies including Distributed Resource Management (DRS) and Distributed Power Management – that intend to gather the individual resources of physical resources, and represent them as logical pool of resources that can be used to run virtual machines. Once the clustering technologies are enabled administrators a liberated from the constraints of the physical world, and the focus is less on the capabilities of an individual physical server, and more about the capacity and utilization of the cluster. HA is not the only availability technology available – once enabled administrator have the option to enabled “Fault Tolerance” on selected VMs that benefit from its features. In order for FT to be enabled, so must HA.

This article has been donated to the VMUG Wiki – Click here to read on…

 

 

Posted by on October 27, 2014 in BackToBasics

Comments Off on Back To Basics: Introduction: vSphere High Availability

Back To Basics: vMotion, Storage vMotion, Cold Migration (PowerCLI)

In this part of Back To Basics, I’ll look at the popular cmdlets in PowerCLI for moving VMs around by vMotion, Storage vMotion and also cold migration. Next in the series will be content all about HA, DRS, DPM, and FT…

Screen Shot 2013-10-21 at 14.01.16.png

Moving a VM with vMotion

The general purpose Move-VM cmdlet can be used to move a VM physical around the vSphere infrastructure, as well as relocating the VM object around in the vCenter inventory. So Move-VM could be used to move VMs from one VM Folder to another, or from one physical vSphere host to another. Remember if you are using VMware Distributed Resource Schedule (DRS) and it is enabled for “Fully Automation” your manual moves may well be fruitless as the system moves VMs around to improve overall performance. To empty (evacuate) a vSphere hosts of all its VMs, it is perhaps more efficent to use “maintenance mode” instead.

The -RunAsync option can be used to trigger the command, and then release the prompt to allow you carry on working whilst that the PowerCLI job completes. Without it the cursor is locked until the entire process completes. This can take somet ime especially with large Storage vMotions.

Moving a Single VM:

Move-VM corphqdb01 -Destination esx01nyc.corp.com -RunAsync

This article has been donated to the VMUG Wiki – Click here to read on…

 

Posted by on September 8, 2014 in BackToBasics

Comments Off on Back To Basics: vMotion, Storage vMotion, Cold Migration (PowerCLI)

Back To Basics: Storage VMotion (SVMotion)

Storage VMotion (SVMotion) Explained

Storage VMotion (SVMotion) was initially introduced as method of relocating VMs of older VMFS file system to a new VMFS file system. Since then its has evolved into a technology that can serve many functions. In a manual configuration it can be use to relocate the files of the VM from datastore to another, however when enabled with Storage DRS and Datastore Clusters – SVMotion provides the engine for moving VMs around to improve overall disk performance, as well as assisting with placing the right VM on the type of storage of its IOPS requirements. In the early days, SVMotion required that VMotion was first configured, since then SVMotion has become a core feature of the vSphere platform, and therefore no such dependency exists.

SVMotion are significantly more intrusive to the vSphere environment than the more common VMotion events. This makes perfect sense because by definition SVMotion means the copying of significant amounts of data. Whereas with VMotion the files of the VM stay still, where the location of the VM moves from host to host. SVMotion can be carried out with moving the VM from the host. So it can be seen as being the polar oppposite of VMotion. With VMotion the VMs files stay still, but the VM is move to different host, with SVMotion the VM stay still, but the files are moved to a different datastore. Due to this increase in on load during the period of SVMotion, it could theoretically degrade the performance of the VM, and if simuluatanous SVMotion are carried out then the overall performance of the vSphere host could be degraded. For this reason many SysAdmin opt to carry out SVMotion at times when the load on the VM and host is at it lowest. VM can be left powered on, but the overall impact is reduced.

There are many different reasons to want to use SVMotion and these include:

  • Decommisioning an old storage array who maintanance warranty is about to expire
  • Switching from one storage protocol (NFS, iSCSI, FC, VSAN) to another.
  • Relocate VMs from a LUN/Volume that is running out of capacity or IOPS (or both)
  • To convert RDM disks to virtual disks

Requirements and Recommendations

This article has been donated to the VMUG Wiki – Click here to read on…

 

Posted by on August 15, 2014 in BackToBasics

Comments Off on Back To Basics: Storage VMotion (SVMotion)

Back To Basics: Troubleshooting VMotion

This post is all about the errors and warnings you get with VMotion. For the most part VMotion works without an issue out of the box – unless the pre-reqs have been met (heck, you could say that about any piece of software I guess…) Occasionally, a setting on a vSphere host or VM can cause either a warning or an error. For the most part these are well explained in the UI which you simply read, and then fix the offending setting. Where things can tricky is when VMotion is leverage for some other function such as DRS or maintanance mode. If there errors you can find the vSphere host stuck at 2% in maintanance mode which can never complete. Remember DRS if you have it enabled does have “Faults” option which will tell you why you have a problem, and handy link to the Troubleshooting Guide…

As ever with software most problems stem from poor or inconsistent administration. Once the basic requirements have been met there are number of situations that can trigger errors or warnings on during the “compatiability” check or cause VMotion to fail altogether. These warnings occur due to setting on the physical vSphere host or the properties of the VM, and are summarized below. Errors must be resolved for the feature to work, but warnings can be bypassed in the interface – and this quite an important distinction. Errors are show-stoppers for manual or automated VMotions, warnings are much less a serious concern.

Ideally, a manual VMotion should trigger no errors or warnings to give the VM Operator a seamless experience. In my experience the best approach is to permissions can be used to disable options and features for these vCenter users to stop them making configuration changes in the first place – and to always ask if these folks have been granted more rights than they really need… That said, I find in my own daily admin I’m often inconsistent – and in a hurry. I rush to make a configuration change, get distracted, and never go back to undo the piece of admin I will know will cause problems later. It’s called human error in the trade…

VMotion Errors

  • Storage Errors

In a classic configuration VMotion requires that the VM files be accessible to both the source and destination vSphere hosts. If for example a VM is placed on a local VMFS volume, which is accessible just to the source vSphere host then an error message will appear. Most SysAdmins resolve this problem by using Storage VMotion or Cold Migrate to relocate the files. To prevent VM Operators from creating VMs on local storage there are couple of options – If the host boots via FC-SAN, iSCSI-SAN, USB/SD-CARD or PXE then there is no real requirement for a local VMFS volume. Alternatively, local storage can be grouped into datastore folders, and the permissions assigned to stop operators from accessing it.

This article has been donated to the VMUG Wiki – Click here to read on…

 

 

Posted by on August 14, 2014 in BackToBasics

Comments Off on Back To Basics: Troubleshooting VMotion

Back To Basics: VMotion – Change Host and Datastore

In VMotion’s first iteration both the source and destination hosts need access to the same shared-storage. This limited the scope of VMotion to protocols like FC, iSCSI and NFS. It also meant possible limits around moving the VM from one vSphere Cluster to another vSphere Cluster – as in many cases the storage of one cluster isn’t visable to another. Many customers worked around this problem by having at least one datastore accessible to both clusters – often referred to in popular parlance as the “Swing LUN”. Later releases of vSphere have introduced the capacity to move VMs from host to another when there isn’t a common shared datastore – its wants sometimes referred to as a “shared nothing” environment.

Essentially, the Change Host and Datastore option chains together two processes – the SVMotion of the VMs file to another hosts, followed by the switching from one host to anther of the ownership of the running VM through the process of VMotion. This means it is possible to move a running VM on local storage on one host to different hosts local storage. Additionally, it also allows for the ability to move VMs from one cluster to another where no common shared storage exists.

This article has been donated to the VMUG Wiki – Click here to read on…

 

Posted by on August 11, 2014 in BackToBasics

Comments Off on Back To Basics: VMotion – Change Host and Datastore

Back To Basics: VMotion

This post covers VMotion in the main – the use cases, the requirements, how it works and how easy it is to setup…

Introduction: VMotion

This topic all about the moving of the virtual machine from one location to another – occasionally this is referred to as workload protability or ‘live migration’ by industry experts or other virtualization vendors. VMware’s flagship technoloy is called VMotion. Indeed it was VMware who pioneered the technology that allows the SysAdmin to move a running VM from one physical host to another, without powering off the VM and without disconnecting users. Storage VMotion discribes similiar process by which the files that make up the VM (.VMX, .VMDK) are relocated from one datastore to another, again without powering off the VM and without disconnecting users. Finally, cold migrate describes a process by which the VM is relocated either to another host, another datastore or both – with the VM powered off. This can be neccessary because the requirements of VMotion or Storage VMotion for what ever reason cannot be met.

The requirement for VMotion and Storage VMotion to work have changed over various releases. With VMware introducing new requirements, and weakening or some case removing them altogether. For instance, early version of Storage VMotion, required that VMotion was enabled first – now Storage VMotion is built-in to the platform and does not require that VMotion be enabled first. Similiarly, early versions of VMotion required the VM to be located on Shared Storage (such as FC, iSCSI, NFS) and non-shared storage such as Local VMFS volumes were not supported. By combining the functionality of VMotion and Storage VMotion it is now possible to enjoy the benefits of workload portability without the need for shared storage – although this remains a desirable feature to many customers.

Initially, when VMotion was first demonstrated few people really appreciated how revolutionary the technology was going to be. However, once customers got over the initial thrill and disbelief, they quickly came to accept the capability as given. Now, where VMotion shows its value is in related features and technologies that leverage it. It’s these business benefits that really makes a VMotion an important feature in vSphere. For instance:

This article has been donated to the VMUG Wiki – Click here to read on…

 

Posted by on August 7, 2014 in BackToBasics

Comments Off on Back To Basics: VMotion

Back To Basics: Dell VSM and Data protection

This is my last post on the Dell VSM plug-in for Dell Equallogic Arrays – this finally section deals with the more “advanced” option such as Managing Replication, Data Recovery with Snapshots & Replication, Restoring a VM from Dell Snapshot, Modifying Snapshot and Replication Schedules and finally a little gotcha with using Dell VSM with linked mode…

Managing Replication using Dell VSM

In a multi-site, multi-vCenter environment one Dell VSM can be registered with the respective vCenter environment – and the Dell EqualLogic Groups at each site can be registered to the system.

If the multiple Dell EqualLogic Groups are already “paired” together this will be displayed in the interface. This same interface can be used to create the pairing process if it has not already been carried out using the Create button. The arrows pointing from New York to New Jersey, and from New Jersey to New York indicate that replication is configured in both directions.

If your environment contains multiple sites and mulitiple vCenter the model is to deploy and register a Dell VSM at to each vCenter.

This article has been donated to the VMUG Wiki – Click here to read on…

 

 

Posted by on August 4, 2014 in BackToBasics

Comments Off on Back To Basics: Dell VSM and Data protection