This release is significant in the fact that is the first update to vSphere which should appease all those who were waiting to upgrade to vSphere for fear of bugs and issues that can be present in the first major release of any software application. There are at least 50 patches that have been issued since vSphere was released that have been rolled into this update, which should lead to increased stability and less headaches for administrators.

This release includes updates to ESX, ESXi, vCenter Server as well as to VMware Data Recovery which has been updated from version 1.0.2 to 1.1. Enhancements to ESX(i) and vCenter Server include the following:

• VMware View 4.0 support - This release adds support for VMware View 4.0, a solution built specifically for delivering desktops as a managed service from the protocol to the platform.

• Windows 7 and Windows 2008 R2 support - This release adds support for 32-bit and 64-bit versions of Windows 7 as well as 64-bit Windows 2008 R2 as guest OS platforms. In addition, the vSphere Client is now supported and can be installed on a Windows 7 platform.

• Enhanced Clustering Support for Microsoft Windows - Microsoft Cluster Server (MSCS) for Windows 2000 and 2003 and Windows Server 2008 Failover Clustering is now supported on a VMware High Availability (HA) and Dynamic Resource Scheduler (DRS) cluster in a limited configuration. HA and DRS functionality can be effectively disabled for individual MSCS virtual machines as opposed to disabling HA and DRS on the entire ESX/ESXi host.

• Enhanced VMware Paravirtualized SCSI Support - Support for boot disk devices attached to a Paravirtualized SCSI ( PVSCSI) adapter has been added for Windows 2003 and 2008 guest operating systems. Floppy disk images are also available containing the driver for use during the Windows installation by selecting F6 to install additional drivers during setup. Floppy images can be found in the /vmimages/floppies/ folder.

• Improved vNetwork Distributed Switch Performance - Several performance and usability issues have been resolved resulting in the following:  Improved performance when making configuration changes to a vNetwork Distributed Switch (vDS) instance when the ESX/ESXi host is under a heavy load. Improved performance when adding or removing an ESX/ESXi host to or from a vDS instance.

• Increase in vCPU per Core Limit - The limit on vCPUs per core has been increased from 20 to 25. This change raises the supported limit only. It does not include any additional performance optimizations. Raising the limit allows users more flexibility to configure systems based on specific workloads and to get the most advantage from increasingly faster processors. The achievable number of vCPUs per core depends on the workload and specifics of the hardware.

• Enablement of Intel Xeon Processor 3400 Series - Support for the Xeon processor 3400 series has been added.

VMware Data Recovery has the following enhancements, most notably better support for file level restores of Windows VMs. Previously in VDR 1.0, file level restore was considered experimental and was done using a command line utility. In VDR 1.1 there is a new Windows file-level restore client to make restores much easier using a GUI interface instead. You can read more about the new FLR capabilities in the VDR 1.1 Administration Guide.

• File Level Restore Functionality is Officially Supported - File Level Restore (FLR) provides a way to access individual files within restore points for Windows virtual machines. In previous versions of Data Recovery, FLR was provided as an experimental feature. File Level Restore feature is now officially supported.

• Integrity Check Stability and Performance Improved - The integrity check process is faster and more stable. Note that integrity checks are computationally intensive processes and can take significant periods of time. The exact amount of time integrity checks take varies based on of the size of the deduplication store. Even with these enhancements, integrity checks that take several hours are not unexpected.

• Integrity Checks Provides Improved Progress Information - When an integrity check is running, a progress indicator is displayed. This progress indicator has been improved, although it does not provide the optimal level of detail.

• Enhanced CIFS Shares Support

As usual read the release notes before upgrading and make sure you follow the standard upgrade order of: vCenter ServeràHostsàVirtual Machines.

ESXi 4.0 Update 1 Release Notes

ESX 4.0 Update 1 Release Notes

vCenter Server Update 1 Release Notes

VMware Data Recovery 1.1 Release Notes

Let’s start with what a vShield Zone is.

A vShield Zone is essentially a virtual security guard for your vSwitches that protects virtual machines (VMs) based on rules you define. If you took a physical firewall and did a physical-to-virtual (P2V) conversion, you would end up with a vShield Zone appliance that is a virtual firewall that works inside an ESX(i) host to protect the VMs on it.

Why would you want a virtual firewall instead of a physical one?

In some cases, a physical firewall can’t protect a VM. For example, if you have multiple VMs on the same vSwitch and port group on a host server, the network traffic between them never leaves the host to travel over the physical network, so a physical firewall cannot provide protection. Virtual firewalls are also complementary to physical firewalls and provide an additional layer of protection for your virtual machines.

What are some uses cases for vShield Zones?

Since a vShield Zone provides a protected area inside a vSwitch you might create one for new VMs until you can properly patch and harden them. Since you can control the port access into and out of the zone you can block all inbound connections and only allow outbound ones on the ports needed to update the server. Once the VM is ready to go out into the often-hostile network world you can move it from the Zone to another vSwitch or port group.

Another use case would be in a demilitarized zone (DMZ) environment; you can configure vShield Zones to sit in front of your VMs so any traffic from the Internet must go through the vShield Zone appliance before it can reach the VMs. With this configuration you can allow only Internet traffic on HTTP ports to reach your VMs to help prevent attacks and exploits that can occur on other TCP/IP ports.

A final use case would be to satisfy some of the many compliance regulations that require segmentation and isolation of certain servers based on their roles to protect them from other VMs and clients. For example the PCI (Payment Card Industry) specification states the following:

Without adequate network segmentation (sometimes called a “flat network”) the entire network is in scope of the PCI DSS assessment. Network segmentation can be achieved through internal network firewalls, routers with strong access control lists or other technology that restricts access to a particular segment of a network.

There is an obvious benefit to implementing segmentation using firewalls to help reduce the scope of your compliance efforts. It can get costly when you try to do this physically; setting up vShield Zone appliances is simple and easy and since it is already included in many editions of vSphere it would not cost you anything.

When I last looked at vShield Zones I felt that it was a decent product that provides an extra needed layer of network security built right into vSphere but lacked some of the robustness that some of the similar third-party vendor products offer. But it does provide all the basic functionality needed to protect your VMs, and since it is already part of vSphere I would recommend checking it out and see if it works for you.

VMware vShield Zones is still a 1.0 product and when I spoke to the team that developed it a while back they seemed very excited and proud of the product so I fully expect future releases of it to get better and better.

For more information on vShield Zones, including what is, how to install and configure it, and tips for using it, see the series of tips I wrote:

Part 1 - VMware vShield Zones: What it is and how it works

Part 2 - Installing and configuring vShield Zones

Part 3 - Quick tips for managing vShield Zones

In a disaster roughly 10 percent of people panic, while 80 percent essentially do nothing. Unable to come to terms with what’s happening, they freeze. The remaining 10 percent jump into action.

Improved Storage Resources Control

As the scope of storage resources have increased significantly with large deployments of virtualization environments, so has the need for greater automation and control of these resources. In the vSphere release, vCenter has been enhanced with several new storage specific capabilities to help the virtual administrator manage these environments with a higher degree of control. These enhancements provide administrators with proactive alerts and alarms to address issues before they interrupt the availability of applications running on those resources. vCenter allows setting permissions and quota limits on datastores, as well as per VM.

His question was to explain the meaning of the following line: “vCenter allows setting permissions and quota limits on datastores, as well as per VM.” In particular he wanted to know about setting quota limits on data stores and VMs. While I know a lot about the new permissions in vSphere, particularly for data stores, the part about quota limits confused me also because I have never heard of quota limits in vSphere. I did some research, checked all the vSphere documentation and couldn’t find anything about them. So I contacted VMware to get some clarification and I received the following response from the white paper author:

The quota limit applies to the storage given to a VM.  There is not really an equivalent for a data store.  One can set alarms to notify/alert one when a certain percent-full or overcommit is hit. But I am not aware of a means to stop allocations or placement of VMs when a certain percent overcommit is hit.  That is a common request that I do not believe is there now.

So basically “quota limits” simply  means the amount of disk space assigned to a VM. I guess technically it’s a quota but once you assign the space to the VM you can’t control how much of it that it can use. If you create a 20 GB virtual disk for a VM the guest operating system is going to see all 20 GB of it regardless of whether it is a thick disk or thin disk. If you do overcommit your data stores by using thin disks you need to carefully monitor datastore free space using alarms and reporting. Currently in vSphere there is no way to set any type of quotas for snapshots, virtual disks or datastores.

So while alarms and permissions are greatly improved in vSphere there are really no quota limits that you can use. Perhaps in a future release VMware will put some type of quota controls in place. Thanks to John Troyer and Paul Manning from VMware for the clarification on this.

VMware shifts the paradigm from managing “the raw ingredients of IT”, i.e. component-level infrastructure management, to cloud-based delivery of IT services. This dramatically reduces the cost and complexity of managing IT. VMware vSphere and the VMware vCenter Product Family simplify tedious day-to-day tasks such as provisioning, hardware maintenance, patching and capacity, incident, and performance management through policy-based automation. As a result IT resources and budgets can be shifted from tactical maintenance to strategic projects and innovation that dynamically respond to and ultimately drive the business.

In my experience virtualization has not reduced administrator headcount at all. Why is that? Because the number of servers that we started with before virtualizing was about the same after we virtualized. The only difference being instead of 80 or so physical servers we now only have about six physical servers that were still running those 80 original servers as virtual machines. As a result we may have less physical servers to manage but we now have more operating systems to manage. In addition to the 80 original ones we had six new ones as a result of the ESX hypervisors. So there may be less hardware maintenance which is very minimal to begin with but there are more operating systems to patch and maintain.

One side-effect of virtualizing is VM sprawl. since VMs are so easy to create you tend to quickly end up with a lot more of them after you virtualize. Deploying a new physical server requires money, resources and data center space; deploying a new virtual machine only requires a few mouse clicks. Because of this you usually end up with even more servers to manage after you virtualize then you would have had if you had not virtualized.

When implementing virtualization, existing Windows or Linux system administrators tend to gain the additional duties and title of VMware administrator. When this happens their workloads will usually increase with the additional responsibilities of maintaining the virtual host servers.

So does virtualization really reduce the workload of administrators and allow companies to reduce headcounts? Maybe in some cases when consolidation is incorporated with virtualization projects, or highly-automated tools are put in place to manage the environment. But I’m guessing that there are not many companies that have let people go after virtualizing or have provided existing administrators with lots of extra free time.

Readers, what’s has been your experience, has virtualization reduced your headcount or reduced your server administration? Let us know in the comments.

What is PCoIP?

PCoIP is a relatively new technology developed by a company called Teradici that VMware has chosen to partner with to use this technology in VMware View. Teradici has developed a breakthrough innovation in display compression and propagation over LAN and WAN networks that uses hardware chips on both the host and remote to offload the compression overhead.

PCoIP is a type of display protocol used by remote desktops when doing desktop virtualization, other display protocols including Remote Desktop Protocol, currently used in VMware View and Microsoft Remote Desktop and ICA which is used by Citrix. A display protocol is what delivers the desktop from the host server to the remote user along with capturing mice and keyboard inputs. The current RDP protocol that is used by VMware View has some limitations when using high-resolution desktops and complex graphic situations; VMware has chosen to use PCoIP to improve this. While PCoIP is a new protocol used in VMware View 4 the RDP protocol is still available as an alternative protocol.

While similar to VoIP, PCoIP also delivers HD audio, USB and the user display as well. PCoIP will enable VMware View to deliver the true PC experience that end-users are looking for, which includes high-resolution graphics and rich multimedia, as well as streaming movies and high-definition audio capabilities. For most applications of PCoIP technology the user cannot tell that their PC is not at their desk anymore.

PCoIP implementations today are all hardware-based, meaning you need a graphics card with a Teradici chip in it on your remote host, and a thin-client device with a Teradici card in it to connect from the client end. VMware’s implementation of this in View will be all software based (Soft PCoIP) and will not require any additional hardware on either end. This is similar to the iSCSI storage protocol where you can use either software initiators that are built in to ESX or a separate hardware initiator board. While VMware View uses Soft PCoIP it still supports client hardware devices that have PCoIP built in to them for the best possible performance.

VMware’s software implementation of PCoIP uses Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) over port 50002. The TCP port is used for session establishment and control and the UDP port is used for optimal performance of media and streaming content. All traffic between the host server and remote user is encrypted with 128-bit Advanced Encryption Standard encryption. One of the biggest challenges with remote desktops is dealing with remote users that have low bandwidth and/or high latency network connections; PCoIP handles these types of situations very well and still delivers a decent remote desktop experience to a user.

Like the hardware implementation, the software implementation uses components on both the host and remote user end. The host side is built in to the user desktop that resides on the host server using a View agent and the remote side is built into the View client software.

Because this is done with software instead of hardware that can offload the additional processing needed to compress the display information you might think this will cause additional resource overhead on your host servers, specifically with CPU usage. VMware has done some initial testing and found the impact to the host was negligible and in fact performance was better allowing them to get more desktops on a host server.

This could be because VMware View 4 now runs on vSphere which provides better overall performance than VMware Infrastructure 3 which was used for View 3; VMware is still testing to provide more information on the scalability and performance of PCoIP. You can, however, can use Teradici cards in ESX host servers to offload the extra CPU processing from the host server similar to use hardware initiator cards with the iSCSI storage protocol.

For more information on VMware View 4 and PCoIP visit VMware’s website, and check out the VMware View with PCoIP Information Guide.

In a previous post I covered the basics on what virtualization is and used an analogy to describe it. I also challenged others to submit their own analogies on how they would describe virtualization and received many responses. I thought I would share a few with everyone.

The first is from Rob Bohmann:

Virtualization is like a school bus. Instead of each parent driving their kid to school each day in their car with the resulting traffic jams and waste of time and fuel or having to build lots of extra lanes on the roads, we have the kids ride a big bus that can effectively carry a lot of people. We save resources like gas and space on the highways, as well as the parents’ time.

 

So if you substitute the energy of gas for the energy in electricity, whether derived from coal or nukes or hydro, etc., and the congestion around schools for the space in your data center and the more efficient management and provisioning of servers, I think the analogy works well, especially for people who are not in the technology arena.

The next is from Guy Leech:

The analogy I like to use is that of a block of flats (an apartment building in US speak?) compared with a large house on the same site. It’s the same space but obviously the flats are self contained/isolated and share the utilities. The house has the same utilities but probably doesn’t use anywhere near as much due to the inefficient use of space.

The next is from Michael Nunn:

Imagine you are a parent of four teenage daughters. All your life you have wanted to provide your daughters with their very own “resources,” like their own bedrooms, their own bathrooms, their own computers, their own clothes, etc., but you just could not afford to do it.

What if I could tell you how to give them all everything they wanted and they really believed that they each had their own bedrooms and bathrooms, but in reality you only had to build one bedroom and one bathroom? You would be well within your budget, your daughters would be very happy, and you would not be using space, materials and money to build all those separate rooms.

The next is from Robbie Singh:

Virtualization is similar to utilizing the same resources without even knowing about it. For example, if one person lives in a house he uses the same resources as phone, heat, water, rent, etc. Add one more person and everything remains almost the same. This way both people benefit. It’s like adding two or more servers on the same physical server. Obviously the scale of people vs. resources is the same as physical server to number of virtual servers.

The next is from Kendrick Coleman:

Me: When you go to Subway, you know how they have those six-foot party subs?

Other Guy: Yea

Me: Well think of the 6ft party sub as your typical physical server. Every time you have to deploy a new server, you have to order a six-foot party sub. When you go to subway, do you order a six-foot party sub for lunch?

Other Guy: Well, no.

Me: Why not?

Other Guy: Because you would have a lot of wasted food.

Me: Exactly, so you would probably want five to 10 other people to help you eat that six-foot party sub so nothing goes to waste. With today’s hardware, there are a  lot of wasted resources when you have to deploy a single physical server. Virtualization gives you the ability to have five-10 servers running on that one physical server concurrently so your resources aren’t going to waste. Make sense?

*Editor’s note: Who else thinks Kendrick was eating a Subway sub when he came up with this?  <grin>

The final analogy is elaborate. Mike Laverick often tells it to his students.

In the past, the server was a like a very expensive hotel. It was the worst kind of hotel. It only had one big room and only one person could stay there. However, all employees, whether they were the CEO or copy-boy, had to stay there if they were away on business.

 

This is like the guest operating system being installed to a physical server. Half the time the occupant is out doing other things, asleep, or just lying on the bed surfing up and down the channels looking for the type of channels his wife wouldn’t let him have at home. This is like when Linux or Windows is idling and only using 5% - 10% of CPU or memory. It became considered too costly to build such hotels and filling them with one occupant was very wasteful – because they consume heat, water and power – and most of the time the single occupant either wasn’t there or was asleep!

 

So someone had the idea of a better hotel, one which was divided into a series of different rooms. Each could be different sizes and offer different qualities of service. It didn’t matter what one guest did in one room, as it could not affect others. This hotel had really thick sound insulation so you couldn’t hear the wedding party downstairs or the newlyweds doing newlywed things next door.

On the top floor beyond the bridal suite, were the penthouse suites which were reserved for the high rollers, specifically for Mr. Exchange, Miss, SQL and Mrs. SAP – but in other floors the rooms were barely large enough to swing a small furry animal – this is where Mr. DHCP and Dr. DNS resided. The old hotel was so expensive only people like Howard Hughes could afford a room there – but this new, more efficient, hotel cost the same to build and maintain – and everyone could find a room that was suitable for their needs – from the odd billionaire to the business man on an overnight stay before catching a flight. It also meant we had to build fewer hotels.

 

The other thing we discovered was when Mr. Exchange or Miss SQL weren’t around or sleeping – as they were consuming less resources – their resources could be divvied out to the residents in the hotel to improve their experience. It would be easier to get that table in the fancy restaurant, and it was quicker to get served in the bar. Finally, the old hotel model died a swift and untimely death when the economy fell off the end of a cliff. It became increasingly regarded as a luxury no company could afford. The Hotel Virtualization model ruled the roost because it offered the most flexible model of accommodating guest operating systems with their wildly different resource demands.

Mike provides a very detailed, nice explanation, but I like Kendrick’s the best as it’s simple and easy to remember, and involves food, which is something we all can relate to. So the next time you’re in a position where you have to explain virtualization to a layman, you now have some great analogies you can use.

I met with some of VMware Inc.’s desktop virtualization reps yesterday to discuss the next version of VMware View (4.0), which is due out next week, and learned there is a correlation between desktop virtualization adoption rates and the 2009 H1N1 flu (formerly known as Swine Flu).   

Though he couldn’t share specific numbers, Raj Mallempati, the desktop virtualization marketing manager, said VMware’s VDI adoption rates increased in direct correlation with H1N1 flu. In fact, he said VMware sold a VDI license in Australia for the first time when H1N1 started alarming people there this summer.

“It makes you think, did VMware invent swine flu?” Mallempati joked.

They saw the same spike in desktop virtualization adoption when the SARS virus hit a few years ago, he said.

VMware claims to have around 1.5 million VMware View license holders so far, which is between 6-7% of the company’s revenue, according to a VMware rep.

While these correlations could be coincidental, deploying desktop virtualization certainly makes sense for corporations that don’t want to lose productivity every time a deadly virus pops up (gotta love capitalism). With VDI, employees who don’t want to come into work because they are afraid of the sneezer in the next cubuicle can access their desktops from home. Or if they are sick, they can still work from their quarantine and not infect everyone else in the office.

So, although I haven’t seen any marketing campaigns fear-mongering customers into buying desktop virtualization as a way to avoid H1N1, it wouldn’t surprise me.

There are two methods for backing up a VM, traditional backup methods that install an agent inside the OS and back it up file-by-file and image-level backups that back up the single virtual disk VMDK file. Image-level backups are usually done by backup applications that are designed to specifically back up virtual machines, like Veeam Backup and Replication. These applications use the snapshot feature that is built in to VMware to stop disk writes to the virtual disk so it can be safely backed up. Backup applications read the original virtual disk file which is now read-only as new disk writes get written to a newly created delta virtual disk file. Once the backup application has read all the blocks from the original virtual disk file the snapshot is committed, which takes the data from the delta virtual disk and writes it to the original virtual disk. Once this is complete the delta virtual disk is deleted.

In virtual environments it’s more efficient to do image-level backups, but they also offer more options when you need to do a restore. If you want to restore the whole VM to a previous state you can simply restore the whole virtual disk file. Or, if you want to restore individual files, you can easily do this also. When using a backup application for virtual environments the process for individual file restores in virtual machines is easy and straight-forward. For example, Veeam Backup and Replication can quickly mount the backed-up VM disk file from the backup location so it is available for browsing; the files that need to be restored can then be selected and copied back to the original VM, a process that takes only minutes.

VMware’s own VM backup product, VMware Data Recovery can also do individual file restores via a command-line application that mounts the virtual disk from a selected VM/restore point to a Windows drive letter so the files can be accessed and copied. Even if you use simple scripts to back up a VM by copying its disk to another storage location you can restore files easily enough. Virtualization makes this fairly simple as you can just add the backed-up virtual disk file to another helper VM as an additional disk, browse the files on that disk and copy and paste them back to the original VM.

As you can see restoring individual files to virtual machines is a simple and easy process when using a backup application designed to work with virtual machines. It may not be the same process that is used with physical servers and traditional methods, but it is definitely possible and not all that difficult. If anything virtualization makes backup and recovery easier by providing many unique alternative backup and recovery methods then are not possible with traditional methods.

After doing some research I found out they were part of the new vApps feature in vSphere. I’ve heard a little about vApps but never looked at them in depth, so I thought I would take the time to research them and write about them.

We’ll come back to IP Pools in a bit. First we’ll cover what a vApp is and how they work in vSphere. VMware’s definition of a vApp is below:

A logical entity comprising one or more virtual machines, which uses the industry standard Open Virtualization Format to specify and encapsulate all components of a multi-tier application as well as the operational policies and service levels associated with it.

A vApp is basically a resource container for multiple virtual machines that work together as part of a multi-tier application.

An example of a multi-tier application is a typical Web-based application where you might have three tiers: Web, application and database; which are often run on three separate servers. For example, you may have Microsoft IIS running on one server (tier 1), IBM WebSphere running on another server (tier 2) and a Microsoft SQL Server running on a third server (tier 3).

The three applications on each server all work together and are mostly dependent on each other for the application to function properly. If one part of the tier became unavailable, the application will typically quit working as it relies on all the tiers for the application to work.

Virtualization can introduce some challenges with multi-tier applications. For example, if one tier is performing poorly due to resource constraints on a host, then the whole application will suffer as a result. Another challenge comes when powering on a host server, as often times one tier relies on another tier to be started first or the application will fail.

VMware introduced vApps as a method to deal with these problems by providing methods for setting power-on options, IP address allocation and resource allocation, and provide application-level customization for all the virtual machines in the vApp. When you configure a vApp in vSphere you specify properties for it, including CPU and memory resources, IP allocation, application information, and start order, as shown below.

Once you are done configuring a vApp, you can add virtual machines (VMs) to it by dragging them using the vSphere client. You can also create resource pools inside of them and nest vApps inside of vApps. If you edit the settings of a VM, select the Options tab, and then select vApp Options, you can enable the vApp functionality for the VM and set individual vApp options for the VM. Once you have created a vApp you can easily export it in Open Virtualization Format (OVF) format, as well as deploy new vApps from one that are already created. To use vApps you must have a Distributed Resource Scheduler-enabled cluster; all of the meta-data information for a vApp is stored in the vCenter Server database.

So now that you know what a vApp is, back to what IP Pools are. IP Pools, as you might have guessed, are pools of IP addresses that you can associate with vSwitch port groups. They essentially act as Dynamic Host Configuration Protocol (DHCP) servers to assign IP addresses from the pool to a VM, so essentially the vCenter Server is acting as a DHCP server. When you configure an IP Pool you specify a range of either IPv4 or IPv6 addresses, DNS and proxy settings, and finally select which vSwitch port groups that the pool will be available to.

To configure an IP address range you need to do it in the following format with the starting IP address, a pound sign and the number of IP addresses, like this:

172.20.20.155#10, 172.20.20.175#5

So the above range would make the following IP addresses available in the IP Pool:

172.20.20.155 - 172.20.20.164 and 172.20.20.175 - 172.20.20.179

Once you have an IP Pool configured, you can assign it to a vApp by editing its properties and changing the IP Allocation Policy from Fixed to Transient. For more information on configuring and using vApps and IP Pools check out the resources below.

• VMware vApp Developer Blog
• vApps and advanced VM templates in vSphere 4 (VMworld 2009 attendees or subscribers only)
• vSphere Basic System Administration (Chapter 10)