Home > Blogs > VMware vSphere Blog > Monthly Archives: September 2010

Monthly Archives: September 2010

Meet the Engineer

This video presents an interview with Lance Berc, Corporate Architect and one of the main driving forces behind the ESXi architecture.  Hear his thoughts on why ESXi is the hypervisor of choice for VMware.


You see other videos in the "Meet the Engineer" series on the VMware Office of the CTO Community.

VMware vCenter Site Recovery Manager and Scripting

Hello all,

I thought I would start a new series of blog posts, over the next few months, on scripting in the SRM world. This is important to many of you I know as I hear about it a lot.  This first blog is about setting up to do scripting.  We will use a simple script as an example but really this blog is about making scripts work with SRM.  In the next several articles in this series I will use realistic examples that everyone can use like ones connected to IP customization, Oracle, and Apache .

I should point out that I am not a script writing guy.  But I am learning and will have help along the way to make sure you all get great value.  But if you ask me hard script questions, I may have to suggest you look in a different place.

Today we will use a batch file, but our next articles are going to concentrate on PowerShell and PowerCLI.  This is what I see most often, and for me, and many of the customers I meet, it is also the easiest way to get into scripting.  So that is what I will use too!

Lets get started and have a script executed as part of our failover!  This script is to track when VM's start, and if they start.  It will generate a log file of the start up of VMs.


I suggest you create a folder called scripts on the recovery side SRM server.  This is where the scripts will be held, and they will be executed from the SRM server using the Local Security of that server.  Which means you may have issues if the scripts are on network shares and that is why I strongly reccomand that local folder!

We are going to copy our scripts to that folder.  It is important to understand that you should have a script that SRM executes, to call the actual script.

Calling script

This script is called call.cmd and it contains almost nothing.  See below what mine looks like.  The purpose of this script is to execute the 'real' script.


Test script

This is the script that is going to do some work!  It looks a little more interesting than the call.cmd file.

There is a number of interesting things here.  It is a simple batch file, but it is calling some environment variables that SRM provides during the execution of the recovery plan.  On page 51 of the SRM Admin guide you can learn more about these variables.  I show some here as an example and something cool to play with!  This script will write the date / time and several environment variables to a text file.

It is important to note, that in both scripts, full paths are used.  This is important as it will prevent issues.  Do not forget.

Testing the script

You should now execute the script from the DOS prompt on the SRM server in the scripts folder.  In my experience, I use the DOS prompt as I can see more errors or potential errors that way.  In our case here, we make sure the date / time is in the log file.  Our SRM environment variables will not be in the log but that is ok since we are not doing a recovery.

Adding the script to SRM

Now that we know the script works fine, we need to add it to SRM.  Do we need to execute this script before a VM starts, or after it starts?  Before means pre, and after it starts it is post.

  1. Start on the Recovery Side in the vSphere client,
  2. Once in SRM, select the Recovery Plan you wish to add the script to.
  3. Change to the Virtual Machine tabs, and highlight the VM you wish to make changes to.  See below for what this should look like.


 Use the Edit button as shown above to edit the VM you wish to add the script to.  You will end up in a dialog like you see below.

Now use the Next button to proceed until you are on the Post Power On screen.  You will need to use the Add Command option to enter your calling script information.  This information is:

c:\windows\system32\cmd.exe /C "c:\scripts\call.cmd"

See below for what this looks like.

You can have a variety of different commands, or message callouts here but in my example above there is only the calling script.

Once you press the Finish button the script will execute the next time that VM is recovered.

In our example we are executing a script after a VM is running.  This is because we want information about that VM in a log file. But there are other places you can execute a script.  See another blog I wrote about this here.


You will be able to see a reference to your script in the recovery plan.  You can see it in a screen shot below from during the recovery plan operation.

As soon as the VMware Tools notify SRM that the VM has started successfully, the script will be the next thing done – as seen above.

If we look in the test.log file to see what the log looks like after our plan has finished executing, we can see below what it would look like.


As well, you can look in the history report to see how things went.  Below is a snippet that covers off our script.



You have learned to use a local folder on the SRM server, where you will have your calling batch file, and your script.  In our case the script was a batch file as well.  It is important in both batch files (or scripts) to always use full path information.  Also always use a calling batch file to start your script.


You have now learned how to execute a script from within SRM.  In our case here today we did a simple batch file that just wrote to a log and in the future we will cover off other types of scripts that do important and useful things.

Further Learning

Developer Community at VMware 

API that scripters can use to impact inside of VM's – called VIX 

PowerCLI – add in for PowerShell that provides access to vSphere

SRM Admin Guide – for the environment variables you can call from within a script.

Can a script stop recovery plan?

Getting started with PowerCLI – this is a great blog to get started with PowerShell and PowerCLI which are likely the tools you will most frequently use with scripting and SRM.  At least in the Windows world.

Thank you for reading and have  great day!


The New Lockdown Mode in ESXi 4.1

ESXi 4.1 provides the ability to fully control all direct access to the host via the Host Configuration Tab in vCenter Server. Once a host has been joined to vCenter Server, every direct communication interface with the host is configurable as an independent service in the Security Profile section of the Configuration Tab for the host in vSphere client.  These interfaces include:

  • DCUI
  • Local Tech Support Mode
  • Remote Tech Support Mode

Each of these can be turned on and off individually.  (Tech Support Mode was described in an earlier blog post).

On the other hand, access based on the vSphere API — for example, the vSphere client, PowerCLI, vCLI and so on — is normally governed by granting local privileges to specific users. The root user is the only one that has an administrator role on the host by default; all other users must be explicitly granted a local role on the host in order to access it.

But, what if you wanted to disable all direct access to the host?  In other words, you wanted to force all interaction with the host to occur via vCenter Server, so that you could take advantage of the centralized roles and privileges, and event auditing?  

Continue reading

VMware vCenter Site Recovery Manager and per-vm licensing

Hello everyone,

I had not planned on blogging on this subject yet, but I have gotten a number of questions from people and thought I should.  I head out on the road tomorrow to visit customers and partners – in the wonderful city of Boston so I am looking forward to it but it does mean that my ability to blog with screenshots will be harder.

So here is the scoop on SRM and the new per-vm licensing.

Immediate info

You will be able to continue using your per-processor licensing, and purchase more of it, until December 15th of this year.  After that time you will only be able to purchase per-vm licenses.  You can use only one or the other – meaning per-vm or per-proc.  So you can start using the per-vm licenses now, or wait.

Background Info

  • You purchase in 25 protected VM packages.
  • You can, in the license portal change a 25 protected VM package into something else like a 10 and 15 protected VM packages.
  • You could than put one of those on the protected site, and the other on the recovery site.
  • You can also use Linked Mode with VC and install the entire 25 pack on the protected site, and it would use the licenses as necessary on the recovery site.
  • Protected VM means a VM inside of a protection group.  It can be powered up, or not, it doesn't matter.
  • Failback doesn't need new licenses.  For failback you can reuse existing licenses.  This is confirmed in the EULA.
  • If you have unexpected growth, and protects additional VM's, past the 25 they own, they will still be protected and able to do a failover, but they will be alerted that are out of licenses.
  • You add the license as you have in the past.  No change.
  • You can use the Licensing Reporting Manager (new with 4.1) to report on license usage.
  • You cannot mix old style licenses with the new per-vm licenses.  One or the other must be used.

You can find out more info here.

How to install and use

The instructions below will help you get going with per-vm licenses.

You need to be in the Licensing applet from the vSphere Client home screen.   Also do you see the Licensing Reporting Manager icon?  It is new from vSphere 4.1.

Enter the Licensing app, and you will see a license screen with a per-proc license in use.

 Now in the top right corner you ned to select the Manage Licenses option.

Once selected, you will see the Add License Keys option.  You should see a screen like the one shown below.

You should copy and paste your new license to the appropriate box above.  It will than look like the screen below. 


You can use the Add License button to add your licenses.  

In the screen below you will see what happens after you use the add button.

Note that this license code allows for protecting 40 VM's.  Use the Next button to continue.

Once you press the Next button, you should select the Solutions tab.  SRM is a solution and thus shown on that tab.

On the screen shot above, you can see how the selected license is for 63 CPU's which is what I was using before I started to do this per-VM thing.  You can select the option that is per-VM option and you will see a small change in the Action column.  See below for an example.

With that green check mark, we can now continue by using the Next button.  Also, note the information about the license that is available near the bottom of the dialog. 

You will now see the old CPU license being removed.  This is acceptable since we are changing from one license system to the new per-vm system.

 Use the Next button to continue.

You will have an option to confirm your changes now.

Notice at the bottom of the screen you can see the change from per-proc to per-vm?

Now if you look into the  Licensing app you will see a change.

Notice how there is no CPU's used, but there is 1 VM protected?  Just what we wanted to see.

The Licensing app is real time.  However, the Licensing Reporting Manager is not.  It does have a delay, and it is generally around 40 minutes.

We can check the Licensing Reporting Manager to see what our license usage is, and it should show our new way of licensing SRM.  



I hope you now know enough about per-vm licensing so that you are comfortable, and you have some screen shots to help you get it going.  If you have any questions, or comments, please leave them for me!


Would you like an email when VMware Data Recovery finishes a job?

Hello all,

In answer to the question above, I know I certainly do.  I use VMware Data Recovery (vDR) to backup my main lab, and I have another lab coming online (depending if I go hiking this weekend or not!) and I will use vDR in that lab as well.  This means, if I wish to check on the status of my backups, I will need to proactively each morning connect to those labs, and see if the backups went well.  Now, quite frankly, they normally do, but on occasion they don't and I must know that so I can take action.  Sometimes a backup that doesn't execute is actually a clue for something else – such as lately for me an Active Directory issue and thus blocking vDR from accessing an AD protected CIFS share.  The backup not going was a clue I had an issue with my AD and the first indication of the issue.  But I do not want to access the appliances to check things if there is no issue!  Thus, I need to be alerted to the status of the backup jobs and not look at the appliance each morning and instead only look when I need too.

But, in case you would like to have an email that says how your backup went – successful or not than read on.


It is important to understand that in a future major release, we will have email reports available without any of the work we are going to do below.  In addition, what we will do below will NOT work in the next major release.  I will update this article for those changes so this article will work, but the fact is you will have real email reports available so you likely do not need this information in the future.

We will be using something called syslog to create our messages.  We will configure vDR to deliver syslog messages to a syslog server that will be able to filter for them, and than forward them as email messages that arrive in your mailbox.  Not hard, or time-consuming for us to do but it is a little different.

The little secret that makes this work is that vDR generates syslogs messages with the facility of uucp.  This is of course not what we want it to be done with, and that will be fixed in a future major version that has email reports.  But once you know that, if you know syslog already, you are good to go.  But we will provide additional information below in case you are not familiar with syslog.

I am using a syslog server called Kiwi as I have used it in the past and am familiar with it.  It is important to note that most syslog servers should be able to do what we are doing with Kiwi.

vDR changes

We will start by accessing the vDR console to configure syslog to send vDR messages to our syslog server.

  1. Using a tool like Putty, access the console with the root account and the root password.  The password starts out as vmw@re and hopefully you have changed it!
  2. Change to the /etc folder.
  3. Use your favorite linux editor (insert smile here), VI to add the following to the last line of syslog.conf:  uccp.* @your_syslog_server_ip_here
  4. Important to understand that only tabs should be used between the uucp.* parameter and the @your_syslog_server_ip_here value.
  5. See the screen-shot below for what your syslog.conf should look like when you are finished.

Note: one of the things that will change in a future release is we will not use uccp but rather something more appropriate.


To make this change live, you will need to restart syslog in the vDR appliance.

The command to do that is:

service syslog stop

service syslog start

Once the syslog service starts it will use the new configuration that includes your changes.

See below what you should see when you restart the service.



You should now trigger a backup job.  If you do, and a moment after it finishes, you will see something in your syslog server like the following.

Syslog displayjpg

Now for a little background on what you see.  

I have a backup job in my vDR appliance called Local Apps, and it backs up a number of VM's.  So I have a line above for each VM that is backed up as part of that job.  That explains why I see Script "Local Apps (sql1)" completed successfully.  It means that the VM SQL1 was backed up as part of the job Local Apps successfully.  So script means the job you created in vDR.  Plus, the name in brackets is the name of the VM.

As well, you can see a line that has Script "Verify" and Verify is actually an internal name (one of the things that will be changed in a future release) and it means Integrity Check.  Another script is called "Grooming" and it means Reclaim.  It too is an internal name that will be replaced in a future release.

Once you have this information in your syslog server, you can now start to filter it, and report on it.

I created a filter to capture syslog messages from my two appliances.  See below for an example of that.


Once the traffic from those two appliances is captured, we need to turn it into an email.  I created an action to do that which you can see below.


I did not change much in this screen, but added my email address, and the vDR traffic part to the subject line.  This will send to me every syslog message from either of my appliances.  At some point that will be too many, and I will change the filter.  For example, once I am over the excitement of receiving emails on the job status, I will likely change the filter so that I will only get emails on failed jobs.

Summary so far

I have modified the syslog.conf on the appliance so that any vDR messages are sent to my syslog server.  Plus I have created a filter on my syslog server that will capture any messages from either of two different hosts – which are my vDR appliances.  Then I created an action that will email the syslog message to me.

The interface of Kiwi may be different than what you are familiar with, but I hope the information here  it still provides you with what you need!

So does it work?

The email

See below for an example of an email that originated with vDR and is seen in Zimbra.  This is, after all, what this blog is about!



With the information above – primarily the facility uucp, you can have your vDR appliance forward vDR syslog messages to a syslog server.  Once that is done you can filter for them and turn them into email messages.  I showed using the Kiwi syslog server how to do this.

Please remember that several things in this blog will change in the future with a new release, but with that release you will have native email reporting and this blog will not be necessary for most people.

Any questions, comments or clarifications please do not hesitate to leave them in the comments.


VMworld 2010 Wrap-up

It sure was a busy week at VMworld 2010 for the ESXi team at VMware, what with the big focus on ESXi migration.  Numerous sessions (including several by yours truly) focused on ESXi and related topics, such as vMA and scripting.  In case you missed them, and have a VMworld account, here is a (partial) list of ESXi-related sessions that you can view as soon as they are posted.

  • TA9767: Why You Should Migrate to ESXi with vSphere 4.1 – we had one of our customers, Travis Goodfellow of Medtronic, on stage with us to talk about his experience with ESXi, which they’ve been running in production for quite some time now. 
  • SS8222: Transitioning to ESXi – this session was more technical, and provided a survey of the differences between ESXi and ESX, focusing on aspects that affect day-to-day management.
  • TA8245: ESXi Internals: Better Understanding for Better Management and Troubleshooting – one of the principal ESXi engineers, Olivier Cremel, presented a deep dive into the inner workings of ESXi.
  • MA6580: Bridge the ESX/ESXi Management Gap Using the vSphere Management Assistant (vMA) – Tips & Tricks Included – the presenters gave a very nice overview of vMA, including instructions and recommendations for deploying and configuring, as well as examples of how to use vMA to manage ESXi hosts.

Of course, there was more: hands-on lab exercises on ESXi management (part of the vSphere 4.1 lab) and scripting, as well as even more sessions and labs on PowerCLI (which represents a much more powerful alternative to COS scripting).  

We all had a great time meeting our customers and talking about ESXi.  Everybody I met said that, once they learned about the new features of ESXi in vSphere 4.1 (as described in an earlier blog), they felt comfortable about making the transition.  Even long-time, die-hard adherents to the classic ESX version told me that they felt ready to move on.   Plus, the fact that you can mix ESXi and ESX hosts in the same cluster, and can mix both 4.0 and 4.1 hosts in the same cluster as well, makes it possible to have a smooth transition. 

Next, it’s off to Copenhagen for VMworld Europe 2010 on October 12!



vNetwork Journey

By Howie Xu, Director, Networking R&D, VMware Inc.

At VMworld 2010, VMware executives Paul Maritz and Steve Herrod did a great job in articulating "business agility" and "IT as a Service" vision for the "new infrastructure" we and the ecosystem are building.

The networking industry is peeling the next (networking) layer of the onion to make the vision a reality to our joint customers — there is obviously a big opportunity ahead to transform to an elastic, efficient, just-in-time, and almost invisible cloud era infrastructure.

Network virtualization is precisely a means to the end aforementioned. With network virtualization, we can help fulfill the vision of provisioning, managing, and securing application workload in an increasingly complex and scalable environment with predictable performance and with "cloud economics".

Let me show you a few introduction slides in case you missed my "vNetwork Journey" talk (a talk on technology vision NOT VMware's product roadmap).

"Your vision makes the networking interesting again", said one customer after my talk. Thank you so much for the feedback — we didn't need a full page ad on USA Today to convince our customers we are the thought leader and have the track record in this space.

VMware is not dictating whether/which network services need to run in what form factors ("virtual form factor" or not etc), whether intelligence should reside on point A vs. point B — plenty of people know how to make the right trade-off for their own products.

What we are determined to do is to have a platform to enable the "just-in-time", "nearly transparent", and "multi-tenancy friendly" infrastrucuture. As I discussed at VMworld, we have a few tricks in the bag to help to make the vision real.

At TA8361, we discussed the need for a standard management/orchestration layer so that various networking vendors can map their solutions into this uniform management layer. We also discussed the platform support for a new class of networking services that are elastic, on-demand, pay-as-you-go, multi-tenancy aware, and highly performing.

Finally, it is the "cloud" that will be driving any paradigm shift. Customers voted with their feet by spreading "cloud fever", demanding "cloud agility", and evaluating "cloud economics". VMware and its ecosystem can choose to be either the innovator or the witness.

"Water flows downhill", said one executive of a key networking vendor when we discussed the "disruption" in a casual party this week. Who is going to deny the "cloud" if it means efficiency, control, and business agility at lower cost? Have a nice ride on the vNetwork Journey!

Backing up, and restoring, VMware vCloud Director provisioned virtual machines

Hello everyone,

I hope that everyone is enjoying a long weekend, and for those of you that attended last weeks VMworld, are recovering nicely.  VMworld 2010 was one of the best that I have been too.  There should be lots of stories on it for weeks to come.  Keep an eye on www.vmworld.com to see when the sessions are going to be available since there was some amazing sessions that you can really learn from (you will need a VMworld ID for this).

One of the many things we announced this past week was the arrival of VMware vCloud Director (vCD).  You can see the release notes here.  One of the things I have worked on recently is how to do backup and restores of virtual machines that have been provisioned by vCD.  The restore, in particular, is a little different due to the nature of Cloud Computing and the fact that vCD is 1.0.  But what you need to know to successfully do backup and restore is below.  In the future hopefully backup applications can use an API based backup mechanism to backup and recover vCD provisioned VM's easier and directly with vCD.

A strong suggestion

When deploying virtual machines (as part of a vApp) I recommend that you use the Full name and Computer name fields to specify realistic names that will help you describe the virtual machines.  This is important as if you do not do this, the generic information in these fields will make it hard to specify individual virtual machines.  Virtual machines that are provisioned by vCD have a large GUID-template_name that means many VM's could appear to be very similar and make it hard for a user or admin to ask for a specific VM to be restored.


If you are using agent based backups already in your organization, you can continue to do that.  This may not work for you depending on the security that you have enabled in your cloud.  If you are using the vStorage API set for the backup it may or may not work for you.  Currently, the VMware Data Recovery (vDR) product will not work when backing up vCD provisioned VM's.  This should be fixed in the next release of vDR.  But generally, your software should work.  In my testing I used vDR v1.2 (which didn't work), Backup Exec 2010 R2 13.0 Rev 4164 (agent based and worked) and Veeam (which worked).


When you restore a virtual machine (s) it is important to not restore them to the location they came from.  If this is done, vCD will NOT be able to import it back into the system.  Use the instructions below to do a restore.

  1. Restore the complete VM to a new location that is accessible to the vCD infrastructure.
  2. Now log into vCD as the Cloud Admin.
  3. Import the restored VM.  See below for a screen shot of the import. 


  1. You may need to import this VM to an existing vApp.
  2. Once it is restored, you will need to change the owner of the VM to the correct owner.
  3. You will need to enable the network on this VM.  This is done in the VMs view – see below for an example.


You should now ask the owner of this VM to power it on and use it to recover files or just use it as a replacement VM.  Remember that the original VM may or may not still be available to the user.

We should have a KB article soon that will provide more information.  In addition, if you leave comments with this blog I will be notified and will add details as needed.


Updated – 2/11/11

I do have some links to backup tools that can protect vAPPs or VMs inside of vCD.  I am posting them in case Google finds this article so that you know there is more options available than when I created this article.

NetApp – http://blogs.netapp.com/virtualization/2010/08/vmware-vcloud-director-and-netapp-unified-storage.html (I should have found this one sooner!)

Acronis – http://kb.acronis.com/content/18104

Commvault – http://tinyurl.com/4qbs5ak