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

Category Archives: Automation

Virtual SAN Troubleshooting: Automating Multicast Configuration

powercli 5.8 iconWelcome to another episode of our Virtual SAN Troubleshooting series. In our last article we detailed guidelines and troubleshooting steps around the Virtual SAN networking requirement for layer 2 multicast. In today’s article we will show you how to quickly automate the modification of the Virtual SAN multicast group address in the event the need arises.

Requirements

  • PowerCLI 5.8 release 1
    - (Note: It is likely to work with PowerCLI version 5.5 or above however I just happened to have version 5.8 on my test system).
  • Microsoft .Net 2.0 or higher Continue reading

Virtual SAN Troubleshooting: Multicast

Hello and welcome to the Virtual SAN Troubleshooting blog series. This series of articles is dedicated to and driven by requests from you our readers. Today we will be focusing upon one of our most requested troubleshooting topics, Layer 2 Multicast functionality from the Virtual SAN Networking requirements.

You are probably familiar with the Virtual SAN networking requirement of Layer 2 Multicast but today we would like to discuss why Virtual SAN leverages multicast forwarding for a portion of its network traffic as well as provide troubleshooting steps when it seems as though multicast traffic is not being received by the Virtual SAN VMkernels. The goal of this article is to educate the networking novice as well as provide clarification for the networking experts so we will be taking a thorough, ground up approach for our discussion.

Click the link if you need to jump directly to the testing examples Testing Multicast functionality. You will also want to make sure that you are following the guidelines below.

Continue reading

vSphere Storage Policy Based Management Overview (part 1)

Welcome to the VMware vSphere Storage Policy Based Management (SPBM) two-part blog series where we will be exploring SPBM features, components, and the major role it plays in automating storage management operations in the Software Defined Data Center.

Storage Policy Based Management (SPBM) is the foundation of the SDS Control Plane and enables vSphere administrators to over come upfront storage provisioning challenges, such as capacity planning, differentiated service levels and managing capacity headroom. Through defining standard storage Profiles, SPBM optimizes the virtual machine provisioning process by provisioning datastores at scale and eliminating the need to provision virtual machines on a case-by-case basis. PowerCLI, VMware vCloud Automation Center, vSphere API, Open Stack and other applications can leverage the vSphere Storage Policy Based Management API to automate storage management operations for the Software-Defined Storage infrastructure.

For more information on the Software-Defined Data Center and its related components, please visit the VMware SDDC Product pages.

Continue reading

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