Home > Blogs > VMware vSphere Blog > Category Archives: Automation

Category Archives: Automation

Virtual SAN 5.5 Validation Guide

Enabling Virtual SAN, if the environment is configured and ready, is an easy click of the mouse. If the environment is not ready however, the task of troubleshooting a new product, can easily become quite daunting. As we track the issues that have arisen during Virtual SAN deployments, we see that the majority of issues are common from deployment to deployment. The great news here is that these common issues can readily be identified and resolved. The real challenge is getting the information and guidance out into the hands of those who need it, before they actually have need of it.

It is for this purpose I introduce you to, the Virtual SAN 5.5 Validation Guide. This guide began as an internal collection of the most common Virtual SAN deployment troubleshooting scenarios. After receiving a number of requests from our customers, we have decided to publish this guide publicly as well.

The Virtual SAN 5.5 Validation Guide is a collection of common gotchas and recommended practices in spreadsheet form for easy reference and checkoff during the deployment process. There are two sections to this guide, the first section contains validation steps for common issues that can occur during the install process. The second section contains validation steps potentially required during post-install activities. Where possible, it contains both manual steps (vCenter Web Client actions) and CLI steps (RVC, ESXCLI, PowerCLI). These CLI steps can readily be translated into script form for easy automation.

Continue reading

Managing Virtual SAN with RVC: Part 2 – Navigating your vSphere and Virtual SAN infrastructure with RVC

In our first article in this series, we looked at the history, features, and setup of the Ruby vSphere Console. Built upon the Ruby interface to the vSphere API (RbVmomi), the Ruby vSphere Console is a powerful management utility for the vSphere infrastructure, as well as an efficient integration option for third party applications and cli-based automation.

In today’s article, we will begin digging further into the features and usage of the Ruby vSphere Console by leveraging it to explore the vSphere and Virtual SAN infrastructure. Within RVC, the vSphere infrastructure is presented to the user as a virtual file system. This allows us to navigate its managed entities and even execute commands against them as well.

Continue reading

Managing Virtual SAN with RVC: Part 3 – RVC Usage and Command Syntax

In today’s article, we will be taking a deeper look into the features of the Ruby vSphere Console (RVC) by examining its command structure and syntax. With RVC being built in Ruby, and built upon the Ruby interface to the vSphere API (RbVmomi), it serves to offer considerable strengths that we can leverage to expedite operations in our vSphere infrastructures. RVC began its life in VMware Labs as a Fling as a Ruby based CLI for the vSphere infrastructure. VMware Lab “Flings” are really interesting Engineering side projects. As a Fling, RVC became such a considerable tool for VMware Engineering, Support, and others that it was decided to extend its functionality to include support for Virtual SAN environments. RVC has now become a robust CLI for managing vSphere and Virtual SAN infrastructures.

First though, if you need assistance with recommended practices for RVC deployment, or how to login and navigate your vSphere and Virtual SAN infrastructure, please take a look at our first two blog articles from this series.

Managing Virtual SAN with RVC Series:
Part 1 – Introduction to the Ruby vSphere Console
Part 2 – Navigating your vSphere and Virtual SAN infrastructure with RVC

Continue reading

Managing Virtual SAN with RVC: Part 1 – Introduction to the Ruby vSphere Console

Allow me to introduce you to a member of the VMware CLI family that you may have not yet met, the Ruby vSphere Console, also called RVC for short. The Ruby vSphere Console is a console user interface for VMware ESXi and Virtual Center. You may already know of the Ruby vSphere Console, as it has actually been an open source project for the past 2-3 years and is based on the popular RbVmomi Ruby interface to the vSphere API. RbVmomi was created with the goal to dramatically decrease the amount of coding required to perform simple tasks, as well as increase the efficiency of task execution, all while still allowing for the full power of the API when needed. The Ruby vSphere Console comes free with and is fully supported for both the vCenter Server Appliance (VCSA) and the Windows version of vCenter Server.  Most importantly, RVC is one of the primary tools for managing and troubleshooting a Virtual SAN environment.  

Continue reading

Virtual SAN Automatic “Add Disk to Storage Mode” Fails (Part II)

In part 1 of this article, we looked at an interesting scenario in which, despite having the Virtual SAN disk management setting set on automatic, Virtual SAN would not form disk groups around the disks present in the hosts. Upon closer examination, we discovered that the server vendor pre-imaged the drives with NTFS prior to shipping. When Virtual SAN detects an existing partition, it does not automatically erase the partitions and replace it with its own. This serves to protect from accidental drive erasure. Since NTFS partitions already existed on the drives, Virtual SAN was awaiting manual intervention. In the previous article, we displayed the manual steps to remove the existing partitions and allow Virtual SAN to build the disk groups. In this article, we will look at how to expedite the process through scripting.

Warning: Removing disk partitions will render data irretrievable. This script is intended for education purposes only. Please do not use directly in a production environment.

As promised in part 1 of this article, we will demonstrate today how to create your own utility to remove unlocked/unmounted partitions from disks located within your ESXi host. The aim of the script is to provide an example workflow for removing the partitions that insists upon user validation prior to each partition removal. This example workflow can be adapted and built upon to create your own production ready utility.

Continue reading

Reporting on Site Recovery Manager Failover via PowerCLI

Here’s another fun one!

So we’ve automated some Site Recovery Manager failovers with PowerCLI.  Say we run a weekly test for a given recovery plan.  But now we want to know how it worked.  Maybe generate a table report, maybe email it out, whatever.

Take a look at the following:

I’m assuming you’ve already done the Connect-VIServer and $SrmConnection to the appropriate systems.  What next?  Well as before the $SrmAPI mapping again gives us an entry point to the actual SRM API itself.

$PlanMoref = $SrmApi.Recovery.Listplans()[1].moref 

This is in essence retrieving the managed object reference ID for the recovery plan returned by “Listplans”.  You will need to know which recovery plan you want to report on, but that is easily determined by running the Listplans method without any reference, i.e. simply running:

$SrmApi.Recovery.Listplans

Once you know that you know which plan you want to run the report on and you know whether to pass a [0] or a [1] or whatever to the $PlanMoref variable you are creating.

Once that is done we want to pull out the managed object reference to the *history* of the recovery plan execution.  So we execute the GetHistory method against the $PlanMoref variable we have created, and assign it to the new variable $HistoryMoref.

$HistoryMoref = $SrmApi.Recovery.GetHistory($PlanMoref)

This then attaches us to the history of the particular recovery plan we want, and gives us a nice variable name to use for the next step:

$HistoryMoRef.GetRecoveryResult(1)

This, now, is the heart of the matter.  It is retrieving the data from the latest run of the recovery plan we attached to earlier.  The “1″ listed here indicates the most recent execution of the recovery plan.  If we indicated “2″ it would not retrieve the second most recent, but the last *two* executions, and so forth.  So to retrieve the details of the last run of our recovery plan, we need to know: a) The plan as listed by ListPlans, b) the Moref of the plan as listed by Listplans()[planid].moref, c) to attach to the history using the plan’s GetHistory($PlanMoref), and that we d) access the output by running GetRecoveryResult against all the prior input.

Make sense?  Fundamentally it can be reduced to the 4 or fewer lines, as per my example at the top.  What you do *with* that output is up to you!  If you check out the sample scripts for generating reports against the SRM API, or really reference any PowerCLI materials you’ll doubtless come up with some great ideas for generating tables, reports, emails, whatever is appropriate.

One last thing though – we’ve generated a test run automatically, and now run a report against the result.  What’s next?  Run a cleanup, as per my previous blog about automating execution.

Automating Failover with SRM and PowerCLI

Today we’ll take a look at running a recovery plan for SRM programatically, from the API via PowerCLI.

In almost all scenarios, falling over in an automated fashion is a poor idea.  There is a lot of risk associated with it and a lot of potential liability for failing over due to incorrect reasoning.  Failing over automatically in *test mode* however makes an awful lot of sense!

Continue reading

Virtual SAN Automatic “Add Disk to Storage Mode” Fails

The deployment and configuration of Virtual SAN, with its two-click configuration capability, is indeed “radically simple.” Upon enabling Virtual SAN and leaving the default disk management setting (“Add disks to storage”) set on automatic, Virtual SAN will detect the solid state and magnetic disks that physically exist within the Virtual SAN cluster hosts. Virtual SAN will then create two partitions on each disk, place the disks in their relative disk groups, and pool those disk groups into a single datastore.

Recently, I was working with a customer who ran into a very interesting scenario in which, despite having the disk management setting set on automatic, Virtual SAN would not form disks groups around the disks present in the hosts. Upon examination, we discovered NTFS partitions already in existence on the disks. Evidently, the customer’s server acquisition process asks that the server vendor pre-image all disks with NTFS prior to shipping. When Virtual SAN detects an existing partition, it does not automatically erase these partitions and replace it with its own. Instead, you will notice the Virtual SAN cluster being enabled without disks groups. This serves to protect from accidental drive erasure. Since NTFS partitions already existed on the drives, Virtual SAN was awaiting manual intervention.

There are a few scenarios in which we may find pre-existing partitions on disks that are slated for Virtual SAN consumption (e.g. pre-imaged disks, repurposed hardware, rebuilding Virtual SAN testing environment, etc). In order for Virtual SAN to manage these disks, they will need to have their partitions removed. This removal process can be performed with most disk format utilities. It is important to remember not to format the disk after you erase the partition; otherwise, a new partition will be created.

A quick way to erase pre-existing partitions and enable Virtual SAN to manage the disks is to use the partedUtil utility that is native to the ESXi kernel environment and available from the command line. Below you will find a step-by-step example of how to use the utility to delete the unwanted partitions:

Continue reading

PowerCLI 5.5 R2 and the Site Recovery Manager API

Recently I posted about the new PowerCLI 5.5R2 capability to interact with the SRM API, and I want to write a few posts on using those capabilities to automate some typical (and perhaps some atypical) activities one might wish to accomplish. In the next few posts I’ll be showing some of the things you can do like:

  • How the SRM API is structured and how to access it through PowerCLI
  • Walk through the examples given in the documentation
  • How to generate reports
  • How to add VMs to existing protection groups
  • How to automate test failovers

I am not a PowerCLI genius, so there is a good chance these scripts will not be the most elegant approach you could take, but hopefully this will give you an idea of what’s possible to do with this interaction.

First, let’s take a look at how we actually go about accessing the SRM API through PowerCLI.

Continue reading

PowerCLI for Site Recovery Manager

Along with the release of vSphere 5.5 U1 and the VSAN general availability, there is some other pretty exciting news that might risk getting overlooked:  The release of PowerCLI 5.5 R2.

Why is that so exciting for an availability guy?  Because for the first time you can now use PowerCLI with the SRM API directly!    Check it out in the PCLI release notes.

You can now manage the vCenter Site Recovery Manager Public API through the Connect-SRMServer and Disconnect-SRMServer cmdlets.

Great, what does *that* mean?  Well my friend Alan Renouf who now manages the product informs me that it means:

Full management of the vCenter SRM Public API: Using the Connect-SRMServer and Disconnect-SRMServer you are now able to connect to vCenter SRM and access all public APIs available, use of the $global:DefaultSrmServers object properties and methods after connection allow for access to recovery group and protection group automation, see the built in help and examples for more information.

Now be aware that this does not mean we have a full and rich set of PowerCLI cmdlets for SRM, just that PowerCLI can now view the entire existing API that SRM presents.  But for those of you who want to do things like running tests programmatically – here’s a much easier way than cracking out the java code!

Make sure you take a look at the PowerCLI User’s Guide and also examine the sample scripts for SRM.  They sure make it easy to call API functions like ListProtection Groups, GetInfo, ProtectVMs, etc.  The samples include handy things like:

  • Connecting to an SRM server with PowerCLI
  • Protecting a virtual machine
  • Creating a report on protected virtual machines
  • Creating a report of virtual machines associated with all protection groups

For more info stay tuned here as well as at the Official PowerCLI Blog where Alan and others will doubtless be providing more examples on use.  You might want to check out the SRM API Documentation as well for the context of what exactly you are capable of doing with SRM via API/PowerCLI.

-Ken