VMware vSphere Blog: Automating Auto Expand Configuration for a dvPortgroup in vSphere 5

VMware vSphere Blog: Automating Auto Expand Configuration for a dvPortgroup in vSphere 5:

By William Lam, Sr. Technical Marketing Engineer

There was a recent blog article that references VMware KB 1022312 that provides a manual method of enabling a new feature in vSphere 5 for a distributed portgroup called Auto Expand. As the KB explains, Auto Expand is a new advanced option for a distributed portgroup (Static Binding only) that allows for the number of ports to automatically increase by a predefined amount (increment of 10) when it is about to run out of ports. This is a really neat feature with the distributed vSwitch and allows users to still continue to provision new virtual machines and not require a system administrator to manually increase the number of ports.

The one caveat is that this advanced option is disabled by default and there is no option within the vSphere Client UI to enable this feature. The VMware KB outlines the steps to enable Auto Expand using the vSphere MOB, but the the process is not very user friendly and can be tedious for enabling several dozen distributed portgroups.

Though enabling Auto Expand is not available through the vSphere Client, it is available using the vSphere API. The property autoExpand is under distributed portgroup and can be queried or reconfigured by calling the ReconfigureDVPortgroup_Task API method.

We will walk through an example of how Auto Expand works and provide a sample vSphere SDK for Perl script that allows you to check whether or not Auto Expand is enabled for your distributed portgroups and allowing you to enable or disable the feature.

Disclaimer: This script is provided for informational/educational purposes only. It should be thoroughly tested before attempting to use in a production environment.

vSphere SDK for Perl

Download script: updatedvPortgroupAutoExpand.pl

Usage: To run the script you will need to have VMware vCLI installed on either a Windows/Linux system or you can use the VMware vMA appliance.

Here is an example of a distributed vSwitch with several portgroups, we will focus on the Stage portgroup which currently is only configured with 2 ports:

To get a listing of all portgroups (Static Binding only), the number of ports configured and whether Auto Expand is enabled or not, use the “list” operation:
vi-admin@vma5:~> ./updatedvPortgroupAutoExpand.pl --server pod-vc --username root --operation list
Enter password:
dvSwitch: dvSwitch1
dvSwitch-DVUplinks-462 4 false
Development 10 false
Stage 2 false
dvSwitch: dvSwitch2
dvSwitch2-DVUplinks-476 0 false
dvPortGroup 128 false

You can also specify the optional --dvswitch flag to only view from a specific distributed vSwitch:
vi-admin@vma5:~> ./updatedvPortgroupAutoExpand.pl --server pod-vc --username root --operation list --dvswitch dvSwitch1
Enter password:
dvSwitch: dvSwitch1
dvSwitch-DVUplinks-462 4 false
Development 10 false
Stage 2 false

To enable Auto Expand for a particular dvPortgroup, use the “enable” operation and specifying the portgroup by using the --dvportgroup param (to disable just use “disable” operation):
vi-admin@vma5:~> ./updatedvPortgroupAutoExpand.pl --server pod-vc --username root --operation enable --dvportgroup Stage
Enter password:
Enabling Auto Expand for dvPortgroup "Stage" ...
Successfully reconfigured dvPortgroup!

To view the changes, you can run the “list” operation again:
vi-admin@vma5:~> ./updatedvPortgroupAutoExpand.pl --server pod-vc --username root --operation list --dvswitch dvSwitch1
Enter password:
dvSwitch: dvSwitch1
dvSwitch-DVUplinks-462 4 false
Development 10 false
Stage 2 true

Now we will create a new virtual machine with three network cards and assign all three to “Stage” distributed portgroup. Once the portgroup is about to run out, it will automatically increase the number of ports by 10 and bring the new total to 12 as you can see from the screenshot below:

Though this feature can be really useful, it would also be good to know when this occurs to ensure that the networking environment is being sized and configured correctly. You can easily do so by configuring a custom vCenter alarm to notify you when this occurs for distributed portgroups that have Auto Expand feature.

The alarm must be created on a per distributed portgroup level, click on the “Alarms” tab of the portgroup and create a new alarm:
Next you under the “Event”, add a new trigger called “dvPort group reconfigured” and then click on Advanced Conditions. Select “configSpec.autoExpand” and use the “equal to” to “true”.

This will allow you to monitor when port count is automatically increased and take the appropriate action such as an email or an SNMP trap.

Get notification of new blog postings and more by following VMware Automation on Twitter: @VMWAutomation

VMware vSphere Blog: Technical Marketing Update 2012 - Week 06

VMware vSphere Blog: Technical Marketing Update 2012 - Week 06:

By Duncan Epping, Principal Architect, VMware.

Technical Marketing Update 2012 - Week 06:

No white papers this week, but there will be at least two more out soon. I do have an enormous amount of blog posts for you to read though. Enjoy!

• Unattended Deployment of vCenter Infrastructure Navigator (William Lam) http://bit.ly/xNpqFF


• Automating vCenter Server Advanced Settings (William Lam) http://bit.ly/xm86GT


• How cool and useful is Storage DRS?! (Duncan Epping) http://bit.ly/yrMiYp


• (S)DRS (Anti-) affinity rule types and HA interoperability (Frank Denneman) bit.ly/xPXDBE


• PowerCLI 5.0.1 vCloud Director – Stopping and starting vApps (Alan Renouf) http://bit.ly/zd5wzn


• New post: Setting the default affinity rule for Storage DRS (Duncan Epping) http://bit.ly/xVVCQG


• Networking Blog site changes and VDS best practices paper available for download (Venky Deshpande) http://bit.ly/wHIyCq


• Migrating RDMs, and a question for RDM Users (Cormac Hogan) http://bit.ly/xSgVSB


• The vCloud Director Appliance (Tom Stephens) http://bit.ly/ynl8l9


• Introduction to the vSphere API Part 1 (William Lam) http://bit.ly/xVfQmg


• Using a CNAME (DNS alias) to mount an NFS datastore (Duncan Epping) http://bit.ly/wwH1Dx


• DRS VM-Host "must-rules" remain active after disabling DRS (Frank Denneman) bit.ly/w7JtGI


• Automating vCenter Server Appliance (VCSA) Configurations (William Lam) http://bit.ly/AzLNC4


• Useful vCloud API 1.5 Documentation (William Lam) http://bit.ly/yxt97S


• Using HP’s Online VIB Repository (Kyle Gleed) http://bit.ly/A1xWwN


• Distributed vSwitches and vCenter outage, what's the deal? (Duncan Epping) bit.ly/zr2zZ3


• VMFS Extents - Are they bad, or simply misunderstood? (Cormac Hogan) bit.ly/y1mZkG


• Heading to PEX 2012? Want to check out the next generation vSphere client? (Justin King) http://bit.ly/wqkXlS


• Uniquely Identifying Virtual Machines in vSphere and vCloud Part 1: Overview (William Lam) http://bit.ly/ymEVOf


• The Importance of VM Size to NUMA Node Size (Joey Dieckhans) http://bit.ly/y53xrA


• How to Run Windows 8 on vSphere 5 (for reals) (William Lam) http://bit.ly/wP9gZo


• vCheck 6.0 released (Alan Renouf) http://bit.ly/zMiVCu


• PowerCLI at Partner Exchange (Alan Renouf) bit.ly/zEJBJ3


• Storage DRS I/O load balancing and Array-based Auto-Tiering (Frank Denneman) bit.ly/xC2oW4


• New post: How to Configure Nested ESXi 5 to Support EVC Clusters (William Lam) http://bit.ly/A6FnfC


• The vCloud Director Adapter (Tom Stephens) bit.ly/y81pEO


• Stratus vCenter Uptime Appliance (Duncan Epping) bit.ly/xodebg


• Storage DRS affinity rules and alternate swapfile location (Frank Denneman) goo.gl/3UqPY

VMware vSphere Blog: Storage DRS affinity rules and alternate swapfile location #vmware

VMware vSphere Blog: Storage DRS affinity rules and alternate swapfile location:

Frank Denneman, Senior Technical Marketing Architect, VMware

By default Storage DRS applies an Intra-VM affinity rule to each virtual machine. This default rule is commonly referred to as the VMDK affinity rule. The Intra-VM affinity rule keeps the files belonging to a virtual machine, such as the VMX file, Swap files and VMDK files together on the same datastore. If a virtual machine is migrated out of a datastore, all files will be migrated.

There is one exception to this rule and that is if an alternative swapfile location is specified. This can be done either by setting a general setting on the DRS cluster “Store the swapfile in the datastore specified by the host “ or at virtual machine level “Store in the host’s swapfile datastore”

To reduce the overhead of a virtual machine migration as much as possible Storage DRS does not move virtual machine swap files if they are stored in an alternative location, even if an Intra-VMDK affinity rule is applied.

VMware vSphere Blog: The vCloud Director Adapter #vmware

VMware vSphere Blog: The vCloud Director Adapter:

by Tom Stephens, Senior Technical Marketing Architect, VMware

It’s amazing how quickly the resources in your IaaS implementation will get consumed. Leveraging the vCloud Director catalog and vApp template features, users don’t have to deal with the tedious activities associated with standing up new environments. This ease of use facilitates the consumption of resources.

As a result, it’s important for administrators of the cloud to monitor the amount of resources remaining in their environment. One method to do this is by using vCenter Operations Enterprise with an adapter for vCloud Director.

vCenter Operations supports the use of many adapters to collect information from a variety of sources. These adapters can be built by VMware Professional Services, VMware Engineering, or by yourself with the main difference between them being the supportability of the adapter. One of these adapters is the vCloud Director Adapter, developed by VMware Engineering.

By using the vCloud Director Adapter, you can monitor the health of various vCloud Director objects and also broadcast alerts in the event that a monitored provider resource is experiencing difficulties. Now the vCloud Adapter itself does not collect any metrics. Rather it focuses on collecting the resource relationships and events for the vCloud Director objects.

How does this work?

Simply put, the vCloud Director Adapter runs as part of the vCenter Operations Manager. It performs API calls via the vcdjavasdk API to vCloud Director. Through these API calls, it obtains information on:

• Provider vDCs


• Organizations


• Organization vDCs


• vApps

It then creates the corresponding resources in the vCenter Operations database.

To allow vCenter Operations Manager to present Health data without collecting performance data from vCloud Director, the vCloud entities are then mapped to resources in vCenter Operations Manager as shown in the diagram below:

While it performs this mapping, the vCloud Director Adapter also tags each entity with a ‘vCloud Entity Status’ tag to help identify the state of the entity. There are three possible values for this tag, including:

• NotExisting

This is for vCloud entities that were created in the vCenter Operations Manager database, but that do not exist any longer.

• Deployed-vApps

This is used for vApps that are deployed and started

• NotDeployed

This is for vApps that are not deployed and not started

Lastly, the vCloud Director Adapter imports events that are related to the previously imported vCloud entities where they are displayed as change events in the vCenter Operations Manager UI. Before importing these events into vCenter Operations Manager, the vCloud Director Adapter will filter them. It does this by searching for events where the Organization is "System" and the entity type is one of the supported types (Provider vDC, Organization, Organization vDC, and vApp).

The Adapter runs as the Administrator of the System Organization. As such, the Adapter only has the ability to the subset of events that are available to that user. This means the events for vApps are not available.

The vCloud Director Adapter can also provide additional filtering as desired by the user by modifying one of the vCloud Adapter configuration files to include a ‘white list’. The Adapter will then filter the events based on this white list prior to importing them into vCenter Operations Manager.

Installation

Installation of the vCloud Director Adapter is not too complex, requiring only that you run the installer package for the adapter on a vCenter Operations Manger server. After the installer completes, you’ll notice a folder for the Adapter as well as a *.jar file created under the VCOps%ALIVE_BASE%\user\plugins\inbound directory. Under the Adapter folder, you’ll see some other folders. This includes the conf directory that contains the common configuration files (such as the white list mentioned earlier) for the Adapter, the work directory that contains configuration files for the separate adapter instances, and a lib directory that holds the library files and database drivers.

Configuration

Before your able to collect any information, you first have to configure the adapter. You can do this in a couple of steps:

1. From the vCenter Operations Manager UI, select Environment -> Configuration -> Adapter Instances.


2. In the Manage Adapter Instances dialog box, click on the Add New Adapter Instance icon.


3. In the Add Adapter Instance dialog box, select the collector and the adapter type from the drop down menus.


4. Enter a name for the adapter instance you are adding.


5. Specify the IP or FQDN for the vCloud Director host. Note: If you have configured a public console proxy address in vCloud Director, you need to enter this address here. You can check for this in the vCloud Director UI.


6. You can then add filters for the resources collected by the vCloud Director Adapter. You can do this by listing the Provider vDCs or Organizations that you want to have the adapter collect information on. Multiple items can be entered, simply by separating them with a semicolon. If you don’t specify any filters, then the Adapter will import all of the supported entities from vCloud Director. Filtering only Provider vDCs or Organizations will limit the scope of the Adapter’s collection to these objects. If you specify filters for both Provider vDCs and Organizations, the Adapter will import a union of the two.


7. Finally, provide the credentials of a vCloud Director Administrator. These credentials are used by the Adapter to connect to vCloud Director.

Usage

Once you have the vCloud Director Adapter configured, you can get down to the business of using the information is collects. You can do this by creating a custom dashboard from within the vCenter Operations Manager UI.

Below, you can see an example display of what this would look like. In this example, you can see a Heat Map pane on the left, a Health Tree pane on the upper right and below that, a Root Cause Ranking pane.

Selecting a problem area in the Heat Map will display the object and any related objects in the Health Tree. Selecting an object in the Health Tree will show the symptoms in the Root Cause Ranking pane below. Reviewing these symptoms will then assist you in correcting issues.

You can even view the details of a given vApp, as the picture below illustrates:

Finally, by using the dashboard, you can visualize the health scores for a specific vCloud Director object and any anomalies through the Anomaly graph. By drilling down into an object, you can also see the health trend for that object.

How do you get the vCloud Director Adapter?

You’ll have to contact your local VMware sales rep first. They can then help you get an account setup where you can download the adapter.

Conclusion

Hopefully this gives you a little information on what the vCloud Director Adapter is and how it can be used. Of course, this is not the only way you can monitor your vCloud Director environment, but it is pretty easy to maintain and allows you to also leverage all the power of vCenter Operations Manager as well.

VMware vSphere Blog: Migrating RDMs, and a question for RDM Users.

VMware vSphere Blog: Migrating RDMs, and a question for RDM Users.:

Posted by Cormac Hogan
Technical Marketing Manager (Storage)

On a number of occasions recently, I had to investigate what happened to an Raw Device Mapping (RDM) when:

• The VM to which the RDM was attached was Storage vMotion'ed (VM Powered On)

• The VM to which the RDM was attached was Cold Migrated (VM Powered Off)

Some of you may even have been following along the comments in some of my previous postings. Well, this is what I observed, testing with both pRDMs and vRDMs.

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 VMDK on 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).

As you can see, there are 3 occasions when an RDM could be converted to a VMDK. Perhaps the most surprising is the fact that a pRDM could be converted to a VMDK, when a cold migration of the VM is attempted, and the format is changed.

I've since asked our engineering team to put a warning into the migration wizard in vSphere to highlight that this is what's going to happen. Right now, you don't get any warning about this.

I wanted to finish this post with a question to the community. How useful would you find an RDM -> RDM migration tool, i.e. the ability to move data from one LUN to another LUN via the vSphere migration wizard? Please leave me a note in the comments if you think you would use this?

Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @VMwareStorage