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.
Category Archives: Automation
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.
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().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:
Once you know that you know which plan you want to run the report on and you know whether to pass a  or a  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:
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.
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!
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:
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.
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
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.
The VMware Mobile Knowledge Portal iOS and Android app has recently been updated. It sports a great new look and feel and makes finding the information you need even easier by grouping it by area in our SDDC vision.
You have probably heard the terms “Big Data” and “Hadoop” mentioned somewhere in the industry lately – they are both very popular subjects of discussion at the moment. This blog gives you an introduction to the core technology and explains some of the contributions that VMware continues to make to the Hadoop world.
Save time deploying vCAC by using the vCAC6-PreReq-Automation script. This article will get you up to speed on the changes with the vCAC6 installation and provide you with an automated installation script for the vCAC 6 prerequisites, allowing you to more quickly and efficiently deploy your server.