Almost as if to segue from my recent Virtumania Podcast episode about type 2 hypervisors, VMware has announced the release of the public betas for the latest versions of their popular Workstation and Player desktop products. Touting several new features and performance improvements, VMware Workstation 7.1 and Player 3.1 betas can now be downloaded from their VMware Beta Community pages.

I am downloading my copy as I write this post, but several new features have caught my attention.

• Open GL 2.1 support for Windows 7 and Vista guests
• Improved graphics support enabling high resolution videos in VMs
• Autologin for Windows Guests
• Inclusion of the OVF 1.0 command line tool to convert VMs to .OVF files for exporting to other hypervisors
• 8 way vCPU support in VMs
• up to 2TB virtual disks
• Direct Launch – drag icon to host desktop and seamlessly start an application inside a VM – even after closing VMware Workstation or Player.
• Support for Fedora 12 as a guest OS
• VMware Ace upgraded to version 3.7

Also, I can’t help but notice Known Issues from the Release Notes such as the following:

“Display

• Exiting FIFA 08 game on Windows 7 guests and hosts with Aero enabled, might cause the desktop wallpaper to turn black.
• There are known issues with the ATI Linux driver 10.2. VMware recommends that you use ATI Linux driver 9.11 for the best 3D user experience.”

Looks like I’ve got some new testing to do! (and maybe a new 3D games video to make!)

Copying more information from the Release Notes:

With this release of VMware Workstation, VMware Player, and VMware ACE the following new features and operating systems have been added:

Operating System	Host and Guest Support
Ubuntu 8.04.4	Host and guest
Ubuntu 10.04	Host and guest
OpenSUSE 11.2	Host and guest
Fedora 12	Guest
Debian 5.0.4	Guest
Mandriva 2009.1	Guest

New Features in VMware Workstation and VMware Player

To provide feedback on the new features of the VMware Workstation 7.1 and VMware Player 3.1 Beta, go to the Beta Community site. For more information on how to provide feedback, see Product Feedback.

• OpenGL 2.1 support for Windows 7 and Vista guests — Improves the ability to run graphics-based applications in virtual machines.
• Improved Graphics Performance — Enhanced performance with better benchmarks, frame rates, and improved rendering on Windows 7 and Vista guests allows you to run various graphics-based applications. In addition, major improvements in video playback enable you to play high-resolution videos in virtual machines.
• Automatic Software Updates — Download and install VMware Tools, new, and maintenance releases updates when available.
• Autologon — Save your login credentials and bypass the login dialog box when you power on a Windows guest. Use this feature if you restart the guest frequently and want to avoid entering your login credentials. You can enable Autologon when you open guest applications from the host.
• OVF 1.0 Support — Import or export virtual machines and vApps to upload them to VMware vSphere or VMware Cloud. The VMware OVF tool is a command-line utility bundled in the VMware Workstation installer. Use this tool along with VMware Workstation to convert VMware .vmxfiles to .ovf format or vice versa. VMware recommends that you use the OVF command-line utility. For more information, see the OVF Tool User Guide.
• Eight-Way SMP Support — Create and run virtual machines with a total of up to eight-processor cores.
• 2TB Virtual Disk Support — Maximum virtual disks and raw disks size increased from 950MB to 2TB.
• Direct Launch — Drag guest applications from the Unity start menu directly onto the host desktop. Double-click the shortcut to open the guest application. The shortcut remains on the desktop after you exit Unity and close VMware Workstation or VMware Player.
• User Experience Improvement Program — Help VMware improve future versions of the product by participating in the User Experience Improvement Program. Participation in the program is voluntary and you can opt out at any time. When you participate in the User Experience Improvement Program, your computer sends anonymous information to VMware, which may include product configuration, virtual machine configuration, usage and performance data, and information about your host system specifications and configuration.The User Experience Improvement Program does not collect any personal data, such as your name, address, telephone number, or email address that can be used to identify or contact you. No user identifiable data such as the product license key or MAC address are sent to VMware. VMware does not store your IP address with the data that is collected.For more information about the User Experience Improvement Program, click the Learn More link during installation or from the WorkstationPreferences menu.

The VIRTUMANIA continues with Episode 2! Rick Vanover joins Marc and I again along with very special guest Jason Boche, the Virtualization Evangelist, for a recorded discussion about DR options in virtualized environments. The following is the podcast summary:

VIRTUMANIA Podcast Episode 2 – Virtulization Makes DR Easy. Rich Brambley (@rbrambley) of VMETC and Marc Farley (@3parfarley) of 3Par and StorageRap.com with guests and Rick Vanover (@rickvanover) of RickVanover.com and Jason Boche (@jasonboche) of Boche.net/blog. This week’s episode includes discussion about how virtualization has changed disaster recovery and site failover, explores various virtual machine backup and replication products, compares storage mirroring to purely physical solutions in the past, and thinks about DR technologies in the future. Thanks to Greg Knieriemen (@knieriemen) of Chi Corporation for this Infosmack Production.

Before, between, and after the important stuff we also have some fun with Virtumania Bucks, the ongoing danger of nipples in the data center (yes, we go there again!), and a new nickname for Greg Knieriemen.

Listen to the podcast with the embedded player or subscribe to get a weekly copy so you can listen when convenient.

Check out the VM /ETC VIRTUMANIA Page to listen to past episodes as well as episodes of Infosmack.

The following links offer more information on some of the VM Backup and DR products mentioned in VIRTUMANIA Episode 2:

Platespin Forge

DR in a Box – http://virtualizationreview.com/articles/2009/05/01/dr-in-a-box.aspx

http://www.novell.com/products/forge/

DoubleTake

http://www.doubletake.com/english/Pages/default.aspx

Veeam Backup and Replication

http://www.veeam.com/vmware-esx-backup.html

Vizioncore vRanger Pro and vReplicator

http://www.vizioncore.com/products/vRangerPro/

http://www.vizioncore.com/products/vReplicator/

esXpress

http://www.phdvirtual.com/

VMware SRM

http://vmware.com/products/site-recovery-manager/

Finally, here is the VMETC.com search results of some of the posts I’ve written about back up and DR for virtualized environments in the past

http://vmetc.com/?s=back+up+or+disaster+recovery+or+fail+over&search=

The vSphere Enterprise Plus vNetwork Distributed Switch (vDS) has been heralded as, and I might add lives up to it’s reputation of, an administrator’s time saver and single point of virtual networking configuration and visibility across many ESX/ESXi 4 hosts. However, the vDS presents some administrative challenges unique from the traditional vNetwork Standard Switch (vSS) that admins are used to. Specifically, since the vCenter 4 Server actually maintains the vDS configuration, some extra design thinking needs to be built into a vSphere 4 environment where a vDS will be used. If vCenter 4 Server itself will be a virtual machine in the environment with a vDS, the design gets even more involved.

There are a few possible problems to consider. In this post I’ll first cover (with the help of a several others) general VM and vCenter vDS networking issues, but along the way I’ll explore thoughts about designing around a vDS for keeping vCenter as a VM.

The vDS Rock and A Hard Place

I’m not the first to recognize there are problems with using a vDS if vCenter goes down. Here’s a few posts that have already addressed the pitfalls to avoid.

VMware vSphere – VMware vNetwork Distributed Switch bug or limitation

“… if you lose virtual Center you will have no way in moving virtual machines between different port groups on the vNetwork Distribute Switch. In addition, you will not be able to get a virtual machine from the traditional virtual switch to a port group on the vNetwork Distributed Switch. Extra to that, you can’t move a VM to another VMware vNetwork Distribute Switch. So that means if you are using VMware vSphere vNetwork Distributed Switches & you lose virtual center you are almost disabled on the networking part. If you lose connectivity on the classic virtual switch & your adapter on the distributed switch are OK you still can’t move your virtual machines to that distributed switch till Virtual Center is back.”

See the entire blog post for screen shot examples of vDS and vSS portgroups available to VMs with and without vCenter.

Virtualizing vCenter With vDS Catch-22 is another post that explores what happened after taking down the vCenter VM for a routine migration.

“vCenter was shut down and unavailable, therefore, I had connected my vSphere client directly to the ESX4 host in which I transferred the VM to. When trying to configure the vCenter VM to use the vNetwork Distributed Switch (vDS) port group I had set up for all VM traffic, it was unavailable in the dropdown list of networks. The vCenter server was powered down and thus the vDS Control Plane was unavailable, eliminating my view of vDS networks.

This is a dilemma. Without a network connection, the vCenter server will not be able to communicate with the back end SQL database on a different box running SQL. This will cause the vCenter server services to not start and thus I’ll never have visibility to the vDS.”

Virtualizing vCenter with vDS: Another Catch-22 is from another blogger exploring the same problem that was inspired by the last post. 

VMware has a KB Article explaining Configuring vSwitch or vNetwork Distributed Switch uplinks from the command line in ESX 4 which helps manually migrate dvPortgroups back to a vSS from the Service Console when in trouble. Interestingly enough, I couldn’t find a similar article for ESXi. I’ll assume the same process is available via “unsupported mode” in ESXi, but the potential for having to perform these actions under fire must be considered.

Use a Hybrid Mix of vSS and VDS

Does this mean a virtual infrastructure design should keep a vSS around? I would say “yes!”. Perhaps it’s now more important to dedicate 2 of the ESX host’s pNICs for the ESX Service Console / ESXi Management VMKernel isolated as a vSS. The 2 pNICs are not only for redundancy anymore, but also to support one or more standby VM portgroups in case they’re needed as a recovery network for VMs normally using the vDS. Of course, that means creating the appropriate trunking, and VLANs ahead of time. Have everything ready for a quick and easy change of critical VMs when needed.

Therefore, a hybrid design using both a vSS and a vDS is a smart “safety net” to have. Especially when an admin has to point the vSphere client directly at an ESX/ESXi host. The “safety net” vSS portgroups will be available from each host and the VMs can be easily switched via the vSphere Client GUI.

BUT, Does VMware Support vCenter As A VM Using A vDS?

Even though VMware now fully supports running vCenter virtualized, the question is not whether to run vCenter as a VM, but instead it’s whether VMware even supports a vCenter VM using a vDS!

VMware Communities: Virtual vCenter and vNetwork ….

"I called support about running vCenter within a distributed switch and they said point blank, "it is not supported". They said because vCenter governs the distributed switch environment, you can’t have vCenter within the distributed switch."

OK, so VMware support has not always told customers the correct support policy based on actual technical capabilities in the past, but it’s something serious to consider. In fact, based on what has been already explained it makes sense they wouldn’t support it. Besides, it’s more like “putting all your eggs in one basket” then ever before when a vCenter VM is placed on vDS.

I’ve brought up the logistical argument about the brains of the virtual infrastructure running in the environment it is managing before. Don’t misunderstand – I am an advocate for and I virtualize vCenter Server all the time, but I make sure to adhere to the best practices. On that note, the VMware KB Article Running VirtualCenter in a Virtual Machine (updated as of Aug 09) serves as a pointer to the VMware tech note http://www.vmware.com/vmtn/resources/798 which then points to the old VI3 tech note on this topic: http://www.vmware.com/pdf/vi3_vc_in_vm.pdf. VMware definitely needs to update the tech notes to include best practice for vCenter 4 as a VM in an environment containing a vDS!

After all of that why do I want to use a vDS again?

Finally, here is a quick reminder of why the extra design considerations are worth the trouble.

Comparing the vDS to a vSS:

vNetwork Distributed Switch on ESX 4.x – Concepts Overview

• Can forward L2 frames
• Can segment traffic into VLANs
• Can use and understand 802.1q VLAN encapsulation
• Can have more than one uplink (NIC Teaming)
• Can have traffic shaping for the outbound (TX) traffic

• Can shape inbound (RX) traffic
• Has a central unified management interface through vCenter
• Supports Private VLANs (PVLANs)
• provides potential customisation of Data and Control Planes

Managing and troubleshooting ESXi 4 can be a little alien when an administrator is used to the Service Console of ESX Classic. Specifically, troubleshooting remote connectivity to the ESX management interface after adding a second NIC involves local esxcfg-vswitch commands on ESX, but with ESXi the esxcfg commands are only available via the RCLI. Problem is you can’t use the RCLI if you lost remote management connectivity! Luckily, the local ESXi GUI lets you reconfigure your mistake and re establish remote connections.

Hit F2 on the ESXi Console and enter the System Configuration Menu

  Choose to Configure Management Network > Network Adapters

Hit the Space Bar to toggle the use of the specific physical NICs.

Hit Enter, then ESC, and then you will be prompted to restart the management network

Connectivity to ESXi 4 with the vSphere Client or RCLI should be restored. Now you can continue configuring the teaming and load balancing policies you were previously working on. Hopefully you won’t make the same mistake twice!

http://kb.vmware.com/kb/1010718 explains the normal way for disabling and removing a VMware ESX/ESXi vNetwork Distributed Switch (vDS or DVS or VDS – LOL), but when I recently tried to do so I received the following error:

“The resource ‘1′ is in use. DVS [vDS Name] port 1 is reserved by to entity <not-found.> vnic 4000, type:vmVnic”

The screen shot shows the actual error I received.

After thinking about that message, I decided to check to see if any ports were in fact being used on the vDS. Although PortID 1 dvPortGroups did not show it being used as expected, other PortIDs were, in fact, in use. See image below.

I tried messing around with disabling the ports (blocking was the terminology in the vSphere Client, I believe) but I still could not delete the vDS. It was Saturday and I had family stuff to do so I reluctantly gave up at the time. However, 3 days later I was able to easily remove it via the Remove link on vDS Configuration screen just like I was supposed to be able to do all along. Needless to say I was a bit perplexed.

After researching I discovered that

there is a 24 hour time out on the previously mentioned ports in use that was preventing the vDS removal. This is a guess because I am drawing a conclusion between my error message and the information from the following VMware KB article Changing the default timeout for locked dvPorts. The resolution section of this KB explains:

“Before you can remove a vNetwork Distribued Switch or dvPort group, all unused dvPort reservations must time out. You can either wait for the default 24-hour timeout period before removing the vNetwork Distributed Switch or dvPort group, or temporarily change the default timeout for dvPorts to free the ports before the default 24-hour timeout period. If you change the default timeout, be sure to change it back after the ports have been freed.”

The details section of the KB  is not exactly a clear match to my specific scenario, but this seems to explain what actually was preventing me from deleting the vDS.

The locked port timeout can be changed by following the KB articles instructions for changing the setting to 10 minutes:

To remove a vNetwork Distributed Switch or dvPort group with locked dvPorts

1. In vpxd.cfg, add the line <vpxd><dvs><portReserveTimeout>10</portReserveTimeout></dvs></vpxd> and save the file.
2. Restart vCenter. The default timeout is now set to ten minutes.

3. After the port reservation has timed out, remove the vNetwork Distributed Switch or dvPort group.

4. Reset the default timeout by removing the line you previous added to vpxd.cfg.

5. Restart vCenter.

A vDS is created on the vCenter 4 server, so the vpxd.cfg file was in C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter on my vCenter 4. Although I used a custom install to change the default installation directory, I believe that is the default location for the vpxd.cfg file. If you have to search for it be sure to look for hidden files too.

You can see from the following screen shot I added the line in the already existing <vpxd> section just before the closing “</vpxd>” tag. Copy everything between the <vpxd></vpxd> tags in step 1 above. I’ll point out that I first placed the entire line as it’s own section just before the final </config> file, but that caused problems and the VMware VirtualCenter Service would not start. Don’t do that!

I tested the new config changes by creating a new vDS again, adding my hosts, migrating the VMs to use the vDS, powered on and off some VMs, performed a VMotion, migrated the VMs back to the standard vSwitch, removed the hosts from the vDS, and then deleted the vDS. Interestingly enough, I did not have to wait 10 minutes to delete it.

In the end this post may only be valuable for pointing out that a 24 hour period exists by default for locked portgroups on a vDS. I can’t say for sure that the vpxd.cfg change to 10 minutes means you can remove a stubborn vDS more quickly, but I’m drawing the conclusion that it helps. Let me know in the comments if you have a definitive explanation for this scenario!

I am proud to announce a new podcast I will be hosting on a weekly basis – VIRTUMANIA!

VIRTUMANIA is an Infosmack Production that will try to focus on the operational and administrative viewpoints of all things virtualization, so expect a different guest list of bloggers, architects, administrators, and consultants with each recording.

VIRTUMANIA episodes will be announced as new posts here on VM /ETC. Be sure to subscribe to the VM /ETC RSS feed in your favorite RSS reader or download the show each week from the podcast’s RSS feed. Of course, you can subscribe to the VIRTUMANIA podcast on iTunes. Finally, download or listen to each episode from the embedded player on the VM /ETC VIRTUMANIA Page.

Ladies and Gentlemen, I present to you the first episode of VIRTUMANIA!

VIRTUMANIA Podcast Episode 1 – Virtualbox, Type 2 Hypervisors, and Security Nipples.

Rich Brambley (@rbrambley) of VMETC and Marc Farley (@3parfarley) of 3Par and StorageRap.com with guests Sean Clark (@vseanclark) of SeanClark.us and Rick Vanover (@rickvanover) of RickVanover.com. This week’s episode includes discussion about Sun Virtulabox, Teleportation, comparing all type 2 hypervisors, and Oracle’s master virtualization plan. Thanks to Greg Knieriemen (@knieriemen) of Chi Corporation for this Infosmack Production.

Listen Now:

Download

I can’t thank Greg Knieriemen and Marc Farley enough for the patience, advice, and support necessary to get this podcast off the ground. For those that don’t already know, Greg and Marc host the already widely popular Infosmack podcast covering servers, storage, and virtualization news. Tapping into their insights and experiences while planning this podcast have been, and will continue to be invaluable to me. Special thanks to Marc for the Virtumania theme music and Greg for recording and post editing each episode.

HP Blades Day ended for me with another opportunity to be a guest on an Infosmack podcast. Episode 40 was recorded mid afternoon on the last day of the event with an all-star lineup. Here’s the official podcast summary from the episode’s web page (linked above):

“Infosmack Podcast Episode 40 – HP Blades Day Wrap Up. Greg Knieriemen of Chi Corporation and Marc Farley of 3Par and StorageRap.comwith guests Rich Brambley of VM/ETC, Simon Seagrave of TechHead, Stephen Foskett of Gestalt IT, Chris M. Evans of The Storage Architect and Devang Panchigar of Storage Nerve. This week’s podcast is a special wrap up from the HP Blades Day in Houston, Texas.

Disclosure: The participants on this podcast were provided travel and accommodations by HP.”

Like when I’ve been on Infosmack before, here’s an embedded player to listen to the latest episode now.

For those wanting to know a little bit more about some of the most important topics we were discussing in Episode 40 check out the following links:

Cooling Computers with Tiny Jet Engines

http://www.technologyreview.com/read_article.aspx?id=16992&ch=infotech&a=f

Chris Evans singing La Bamba in Houston Texas

Reviews on Nigerian Palm Juice

HP Blades Tech Day 2010, Wednesday – Day 0 |

Feb 25, 2010 … Lots of chat during the dinner hours, came back to the hotel to try someNigerian Palm Juice that John Obeto brought in for the crew…it was … storagenerve.com

HP Blades Tech Day 2010: Day 1

Nigerian-Palm-Juice The Palm Wine – Picture taken by Rich Brambley. Stay tuned for more posts on the HP Blades Tech Day! This trip was sponsored by HP. …
techvirtuoso.com

The final day of HP Blades Day consisted of some quick morning sessions and then the Factory Express and HP Pod tour. The guided explanation of the HP server assembly process was clearly the pinnacle of 2 days that was already filled with many highlights.

Here’s a 30 second video of some of my photos from Friday.

Create your own video slideshow at animoto.com.

For more information about HP’s Factory Express program that let’s each customer “choose how your solution is built, tested, integrated, shipped and deployed” check out this video.

For more information about the HP POD “ship to order datacenter” check out this video.

If you’d like to see all my photos from Wednesday through Friday check out my full HP Blades Day photo album. I’ll eventually add the HP Blade Day photo album to my Photos page here on VM /ETC as well.

Disclosure – I toured the HP Houston, TX facilities during an all expenses paid blogging event hosted by HP.