During preparation and preliminary information gathering for a new internal project, I had a need to emulate various networking conditions and scenarios. More specifically I’m looking at the possibility of running the vCenter Client over high latency satellite links, with varying bandwidth availability and even packet loss scenarios.

Obviously the best way of testing this, in a controlled environment, is to use some kind of WAN emulator that lets you control the various networking characteristics. WANem is a free WAN emulator and it even comes as a VMware virtual appliance.

Setup is pretty straight forward, and I won’t get into the detailed instructions at this point. If someone requests it, perhaps I’ll make a HOWTO post later on.

After the WANem Virtual Appliance has been started and setup in your network environment, all you have to do is to route your traffic through it. In my test environment, I decided to route all traffic between my local computer and my vCenter Server through the WANem appliance. Doing so is pretty straight forward; Open up a cmd window, with administrator privileges, on your local computer and use the route command to force traffic through WANem:

the command itself is:
route add {destination IP} mask 255.255.255.255 {WANem IP}

To tune the network properties of the traffic going through WANem, open the WANem admin page in your browser and work some magic. The screenshots below are from the advanced tab:

WANem Advanced Mode Screenshot #1WANem Advanced Mode Screenshot #2

As a simple test, I decided to add 500ms latency (delay time) and a packet loss of 25%, and as you can see from the video below it works as expected


(Video has been scaled to fit, watch it in fullscreen mode for details).

Conclusion

If you need to test out how your applications or networking infrastructure works when issues like latency, jitter and even dropped packets affects your clients, WANem seems like an easy and free route (pun intended) for testing purposes.

SolarWinds has released a new free vSphere tool called SolarWinds VM Console.

    Free VM Console Highlights:

  • Bounce (shutdown & restart) VMs without logging into vCenter or vSphere
  • Get end-to-end visibility into your VMware environment—from vCenter through ESX hosts to VM guests
  • Track the real-time up/down status of your VMs from your desktop — without logging into VMware apps
    Additional VM Monitoring Features:

  • Take a snapshot of your VM prior to shutdown
  • Search on VM names or IP addresses
  • Use your vCenter/vSphere credentials to view a top-down hierarchy of your virtual environment

I’m not sure why you as an admin might want to use this tool instead of the vSphere Client, but in environments where you have delegated control over certain VMs (like a test environment etc.) it might be a useful addition to your tool-belt.

Dwayne Lessner who runs IT Blood Pressure, has written a guest post on GestaltIT called Is My Favourite VSphere Tool Is Going Away?

In his article, Dwayne talks about vCenter Update Manager 4.1, and the fact that it seems to be the last version of the tools that will allow you to patch your Windows and Linux guests:

VMware vCenter Update Manager Features. vCenter Update Manager 4.1 and its subesquent update releases are the last releases to support scanning and remediation of patches for Windows and Linux guest operating systems and applications running inside a virtual machine. The ability to perform virtual machine operations such as upgrade of VMware Tools and virtual machine hardware will continue to be supported and enhanced.
VMware vSphere 4.1 release notes

Dwayne talks about this as being a bad thing, and that’s where I disagree. I have never understood why VMware saw it as their job to patch the operating systems the guests are running, and I have yet to see anyone actually use this feature. Obviously I was wrong, someone does indeed use it, but I really can’t understand why.

I’m a keen believer in doing what you know, and doing it well. Let “native” patching solutions take care of the guests, Windows Server Update Services (WSUS) comes to mind, and leave vCenter Update Manager (VUM) to take care of patching your VMware products.

I wouldn’t mind seeing vCenter Update Manager (VUM) extended into patching the VMware Workstation, Fusion and Player installations your enterprise might have, but I really think that losing the fat that is guest OS patching can only be a good thing.

VMware has published a new whitepaper called VMware vCenter Server Performance and Best Practices.

This is a must read if you manage a vCenter 4.1 installation, or are currently planning your upgrade.

The whitepaper highlights the performance improvements in the latest version, sizing guidelines, best practices and some really good real world information from several case studies. One simple, but probably often overlooked tip, is that the amount of vCenter Clients connected to your vCenter Server has an impact on it’s performance. How many admins consider that when they start up their clients?

The whitepaper also comes complete with performance graphs comparing the latest release with the 4.0 release, based on real data from several case studies.

vCenter Performance Graph

If you only read one whitepaper (this week), let it be this one. You will not regret it, I promise.

Over at PlanetVM Wil van Antwerpen posted The Future of VMware Server back in May 2010. Wil makes the argument that it seems like VMware is indeed abandoning VMware Server as a product, leaving us with VMware Workstation and VMware Player as the two Windows installable virtualization solutions from the company.

This has caused some reactions, including my own comment, where I question the smartness of abandoning what might just be one of the best virtualization “gateway drugs” VMware has to offer.

In my opinion, abandoning VMware Server would be a bad move, but re-reading the documentation from VMware and thinking more about the consequences this might have made me realize something;

What if VMware is working on a replacement product or management solution?

I seriously doubt VMware would want to abandon the use case that VMware Server has, even if they do indeed abandon the VMware Server product itself. I don’t have any inside knowledge about this, but lets say that VMware is working on a management framework for VMware Player?

Something that you can install, in addition to VMware Player, that lets you set auto-start parameters for VMs, let them run headless and remotely manage them? Wouldn’t that pretty much allow us to do the same with VMware Player, that we today use VMware Server for?

The more I think about it, the more it makes sense.


Finally USB pass-through is possible on ESX hosts with the new vSphere 4.1 release! This feature ha been available in VMware Workstation/Fusion and Player for quite a while. The freshly added feature in vSphere 4.1 even works if you vMotion the guest from one host to another, which is in itself pretty amazing functionality!

In this post, I’ll show how to setup and use the new USB pass-through feature in vSphere 4.1.

Setting up USB pass-through in vSphere 4.1

First off, we need to add an USB controller to the VM we want the USB pass-through working on. This is done by firing up the vSphere Center Client and right-clicking the VM. Then select Edit Settings

Click on Add and find USB Controller from the list then click Next

Click Next and you’ll be presented with a list of the currently host-connected available USB devices. If none show up, make sure it’s actually connected to the host. If your device is indeed connected, but still not listed in the vSphere Center Client it’s not supported.

In my test setup I have a small APC UPS connected to the host, so I’ll add that to the VM. Also note that this is where you enable vMotion support! Find your device, and click on Next

Review your changes and click on Finish

This will return you to the Edit Settings window. Click on Ok to have the USB controller and device(s) added to your VM.

Connect to your VM and install the drivers, if needed, and you should be able to use your USB device directly inside the VM.

Usage Scenarios

What could you possibly use this new feature to accomplish? Well, for one you could use it to connect your UPS to your management software, without having to install any management software on the host itself. In general I would recommend using UPS vendors that offer direct vCenter integration instead, but for a lab environment this should work out nicely.

Another obvious usage pattern would be to connect USB dongles that some software require, either for security or for licensing purposes.

The one thing that springs to my mind, and one that would probably be the most useful in my environment, is to connect USB HDDs to the host and use those as a backup target for Veeam Backup and Recovery. Being able to directly connect some cheap storage to the host and then connecting it directly into the Veeam Backup and Recovery VM makes it easy to backup/replicate your VMs for manual off-site storage. Kendrick Coleman (kendrickcoleman.com) had the same idea, but unlike him I’ll try to make sure my HDDs are located off-site before the fire starts! :-)

I’m sure that there are other usage scenarios as well, like connecting scanners, cameras and whatnot, I’m just not sure I’d like all sorts of devices connected to my hosts.

If you run your vCenter on SQL Server Express 2005, you are missing the ability to set up scheduled backup jobs with SQL Maintenance Plans, a feature available in the full version of SQL Server.

This might not be a problem if your backup software has SQL Server agents that you use to backup your vCenter databaser, but in smaller environments or even in your lab, you might not have that kind of backup scheme available to you, so what do you do? Thankfully there are ways of setting up the same kind of scheduled backups in SQL Server Express, without being a SQL Server Guru.

Creating a Backup Script

If you don’t have SQL Server Management Studio Express installed already, download and install it now.

Fire it up and log on with a user that has sufficient permissions to access the vCenter database

Find your vCenter database by expanding Databases and select VIM_VCDB

Right click on VIM_VCDB and select Tasks and then Back Up…

This opens the Back Up Database window, where you set your backup options. Set your options in a manner that fits your environment. You can set options like the backup file location, retention policy etc.

So far, this is all fine and dandy. You can create a manual backup this way, without much hassle. How can we turn that into a scheduled job?
The first bit is to turn your backup options into a SQL script that can be scheduled. You do this by finding the Script drop-down menu on the top of the Backup Database window. Select Script Action to New Query Window.

This opens the script window, where you can see the script and test it to make sure it works as intended.

The next step is to save the generated script, you do so my going to File and select Save … As. I’ve created a folder called c:\scripts\ that I use to store my SQL scripts in, so I’ll save the backup script there as FullBackupVCDB.sql.

Scheduling the Backup Script

Now that we have a working backup script, we need to be able to schedule it to run. As we can’t do that within the SQL Server Management Studio Express application, we need to find another way of scheduling it. Windows Server 2008 R2 (and other versions) include a scheduling tool, and that’s what we’ll use to create our schedule.

On my standard vCenter installation, the SQL Server is installed in the default location of C:\Program Files (x86)\Microsoft SQL Server\. This means that the actual command we need to schedule will be (be sure to replace the server-/instance-name and script name if your values differ from mine):

“C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn\SQLCMD.EXE” -S [servername]\SQLEXP_VIM -i c:\scripts\FullBackupVCDB.sql

Go to the Control Panel and select Schedule Tasks. Click Create Basic Task, give it a name and set an appropriate schedule.

Select Start a program as the action for the task, and when it asks for Program/Script enter “C:\Program Files (x86)\Microsoft SQL Server\90\Tools\Binn\SQLCMD.EXE” -S [servername]\SQLEXP_VIM -i c:\scripts\FullBackupVCDB.sql.

Click next and check the box that says Open the Properties dialog for this task when I click Finish then click Finish. In the VCDB Backup properties, make sure the Run whether user is logged on or not option is selected, to make sure the schedule runs as planned.

Once you have verified that the schedule works as intended, make sure that you include the location for your vCenter database in your regular backup scheme, and you should we a lot safer than you were.

That’s it! Scheduled vCenter backups on SQL Server Express 2005.

Thanks to Chris Dearden over at J.F.V.I who helped me out with getting my sqlcmd.exe syntax corrected for the scheduled task!

As you may or may not know, the new vCenter 4.1 requires that the host it runs on is 64 bit. As 4.0 and previous versions weren’t supported on 64 bit at all, this probably means that when you upgrade you will need to move your existing database to a new host.

There are several ways of doing the migration, but one way is to backup your existing database, and restore it on a new host and point the new vCenter 4.1 installation to the existing database and have it upgrade it for you during install.

I’m sure that you would like to automate that process, just to limit the possibility of manual screw ups, right? Thankfully, VMware had the same idea.

In chapter 5 of the vSphere Upgrade Guide, VMware outlines the different methods you can use when migrating your vCenter database, and on page 39 a data migration tool makes it’s appearance.

This two step process takes a backup of your existing vCenter SQL Server Express database and dumps it to a predefined local folder. You then copy the entire migration tool folder to the new host and run the second part of the tool to install vCenter 4.1 and import the old database.

I used this tool to migrate our setup, from Windows Server 2003 32bit to Windows Server 2008 R2 64bit without problems.

The only thing you need to be aware of is that VMware Update Manager is still a 32bit application and requires that you manually create a 32bit DSN to the database. This is mentioned in the VUM Installation and Administration Guide, but it is not mentioned in the vSphere Upgrade Guide.

All in all, this tool is a great assistant for all of you that need to migrate to a new host for 64bit support in vCenter Server 4.1. While it could be more polished, brand a GUI and let you use network storage for the backups, it does the job at hand very well. After all, who needs a polished GUI based application for a one off job like this?

Related VMware Knowledgebase Articles

Welcome to my new playground. I used to post quite a lot over at my old site, h0bbel.p0ggel.org but given it’s weird domain name and it’s long history I’ve decided to start fresh.

This new site will be dedicated to all things virtualization, PowerShell, Windows Server management and possibly even some Citrix products thrown in here and there. I might even go on about APP-V, but that remains to be seen.

My main focus will be solutions for SMB users. There is a lot of information out there, but lots of it are focused on large corporations that have large IT teams. Sadly thats not the reality for many of us, and we have to fill lots of different roles (e.g server admin, network admin, storage admin, etc).

For now, there isn’t a whole lot of content here but it’ll start trickling in as soon as I have new content to share. If you have any topics or ideas for posts I should do, please do not hesitate to leave a comment.