VMware vCenter™ Infrastructure Navigator is an application awareness plug-in to vCenter Server, and provides continuous dependency mapping of applications. Infrastructure Navigator offers application context to the virtual infrastructure administrators to monitor and manage the virtual infrastructure inventory objects and actions. Administrators can use Infrastructure Navigator to understand the impact of the change on the virtual environment in their application infrastructure. Infrastructure Navigator helps virtual infrastructure administrators perform the following tasks:

• Make accurate first-level triage to help either eliminate the problem or associate the problem with the virtual infrastructure when business service users report problems.
• Assess change impact, manage, and communicate virtual infrastructure issues for critical applications.
• Understand the application and business impact of changes to the virtual infrastructure on applications.

The Open Source Licenses (OSL) file for the virtual appliance is available at /root/open_source_licenses.txt. You can retrieve the file by running the scp root@<appliance IP>:open_source_licenses.txt command.

Infrastructure Navigator is supported on vCenter Server 5.0 with the vSphere Web Client. The supported ESX versions include ESX/ESXi 3.5 (build 425420), ESX/ESXi 4.0 (build 398348), ESX/ESXi 4.1 (build 433742), and all builds of ESXi 5.x.

Features

This section describes the key features for the Infrastructure Navigator 1.0.0 release.

Simplifies and automates the deployment and the discovery process and keeps manages Application Component Knowledge Base (KB) current

• Eliminates physical switch spanning or credential based discovery.
• Discovers and maps the application components and dependencies using KBs and presents this knowledge through maps or search for relevant use cases.

Provide Infrastructure Navigator data for vCenter Server and related solutions

• Ensures that the application and dependency data is available to the rest of the vCenter Server entities and its various solutions through the vCenter extensibility APIs.
• Supports SRM integration to set up more focused and accurate site recovery and backup plans.

VMware vCenter Operations Manager is an automated operations management solution that provides integrated performance, capacity, and configuration management for highly virtualized and cloud infrastructure. Deep VMware vSphere integration provides the most comprehensive management of VMware environments. VMware vCenter Operations Manager is purpose-built for VMware administrators to more effectively manage the performance of their VMware environments as they move to the private cloud.

Key Benefits

• Actionable intelligence to automate manual operations processes
• Visibility across infrastructure and applications for rapid problem resolution
• Proactively ensures optimal resource utilization and virtual and cloud infrastructure performance

New in v1.2 (see notes below):

• Migrate virtual machines without downtime using vMotion.  This feature is available via Host & VM action menus.  Virtual machines can also be two-finger flicked/dragged from the Host detail view to enter vMotion mode
• Ability to email vMotion validation error details to others
• View task progress reporting on VM cards
• Ability to refresh vCenter host list
• Support of ESX 3.5
• Support for vSphere 5.0

Release Notes:

• This version requires vCMA 1.2, available at: http://labs.vmware.com/flings/vcma
• Min iOS version: 4.0

• vSphere Replication – The biggest feature add.  An additional replication option which allows you to replicate your VMs without having the storage perform the replication.  Even allows you to replicate to/from local storage on the ESXi hosts.  There are some important limits to vSphere Replication.  It’s not for everything/everyone but it does do quite a bit for the first release.
  • Requires vSphere 5
  • Managed from the vSphere client directly
  • ISOs and Floppys are not replicated
  • Powered off/Suspended VMs are not replicated
  • Non-critical files are not replicated (swap files, dumps, logs, etc.)
  • VMs can have snapshots on the protected side but they are automatically collapsed on the recovery side
  • Physical RDMs not supported (but virtual RDMs are)
  • Fault Tolerant VMs, Linked Clones and VM Templates are not supported
  • Automated Failback of vSphere Replicated VMs is not supported in SRM 5.0
  • Requires VM Hardware version 7 or 8 (required for Change Block Tracking)
  • Supports up to 500 VMs
  • Asynchronous only
  • Minimum replication frequency is every 15 minutes, max is every 24 hours
  • Initial copy can be seeded by sneaker net (taking the initial on a portable HD and importing at the destination, i.e. does not need to seed the initial copy over the wire)
  • File-level consistency (except for planned migration – see below) quiesces OS file system before sending changed blocks to the DR site (does not quiesce applications)
  • Included in both Standard and Enterprise Editions of SRM
  • vSphere Replication is not available outside SRM5
• Scalability Improvements
  • 1000 Total Protected VMs (Same as SRM4.1)
  • 500 Protected VMs in a single protection group (same as SRM v4.1)
  • 250 Protection Groups (Up from 150 in v4.1)
  • 30 Simultaneous running recovery plans (Up from 3 in v4.1 – this is the biggest improvement in scalability)
• Planned Migration – This is a big feature add.  This is another option when you are going failover.  In 4.1 the only option was to start up the VMs from the last good replication and go.  This option now allow you to migrate when there is an impending disaster and the protected side is still up.  Planned migration will shut down the VMs on the protected side then initiate a replication of the storage frames (or vSphere Replication) to get the last drop of changed data to the recovery side before powering on the VMs and bringing them up.  One extremely important advantage to this method: the VMs are always in a application-consistent state when they come up in DR.  (Absolutely love this feature)
• Failback – the single most-requested feature in SRM4.  Once a failover occurs, the admin clicks the “Reprotect” link to reset the recovery plan for failback and reverse replication.  Once completed, the recovery plan can be tested or run in the reverse direction and recovery the VMs to the origional protected site.  (This is outstanding for enterprises that are required to do a true failover for DR testing.
• User Interface improvements – Slightly different look and feel.
  • both sides are visible without vCenter linked mode
  • IP changes for VMs during recovery can now be entered in the GUI (thank you VMware!)
  • Placeholder VMs at the DR side now have a unique icon (with a thunderbolt thru it) to identify them easily in the DR vCenter.
  • Reports now include the user ID that initiated the Failover or DR test.
  • Reports now include more information about the storage steps (including the device friendly names)
• IPv6 Support – Ipv6 is now supported for all links.
• IP Customization performance increase – big performance improvement in the actual IP conversion in the VM
• In guest callouts – now you can run a script inside the VM, run a script on the SRM server or insert a breakpoint to post a message (these also now have maximum timeouts as an option) during the recovery plans
• New APIs on both the Protected and Recovery Sides – new commands for 3^rd party integration (note these are SOAP based and not PowerShell or PowerCLI)
• Dependency Improvements – There are now 5 priority groups for each recovery plan.  Each priority group has to finish completely before the recovery plan will start with the next group.  Within a single priority group, you can also set dependencies (similar to how Windows Services set dependencies) so that a particular VM will not recover before it’s dependencies have recovered (note-this is within a single priority group and cannot span priority groups.)
• Licensing – There are now two editions of SRM, Standard and Enterprise.  Both are feature identical.  Standard is for sites up to 75 VMs and Enterprise is for sites up to 1000 VMs (the technical limit).  All existing customers who maintain support will get SRM Enterprise when they go to SRM5.  SRM Standard is a new offering for SMBs and Remote Offices.  When customers need to grow beyond 75 VMs at a site, they can upgrade their existing VMs to SRM Enterprise and then continue buying SRM5 Enterprise VM-Packs.  Licensing still sold in packs of 25 VMs.  Only need to purchase for the VMs that you are going to protect.

VMware vSphere 5.0

• ESXi Convergence – No more ESX, only ESXi (they said they would do it, they meant it)
• New VM Hardware:  Version 8 – New Hardware support (VS5 still supports VM Hardware 4 & 7 as well if you still want to migrate to the old hosts)
  • 3D graphics Support for Windows Aero
  • Support for USB 3.0 devices

• Platform Enhancements (Blue Requires Hardware v8)
  • 32 vCPUs per VM
  • 1TB of RAM per VM
  • 3D Graphics Support
  • Client-connected USB devices
  • USB 3.0 Devices
  • Smart-card Readers for VM Console Access
  • EFI BIOS
  • UI for Multi-core vCPUs
  • VM BIOS boot order config API and PowerCLI Interface
• vSphere Auto Deploy – mechanism for having hosts deploy quickly when needed ( I’m going to wait and see how customers use this one.)
• Support for Apple Products – Support for running OSX 10.6 Server (Snow Leopard) on Apple Xserve hardware. (although I betting technically, you can get it to run on any hardware, you will just not be compliant in your license)
• Storage DRS – Just like DRS does for CPU and Memory, now for storage
  • Initial Placement – Places new VMs on the storage with the most space and least latency
  • Load Balancing – migrates VMs if the storage cluster (group of datastores) gets too full or the latency goes too high
  • Datastore Maintenance Mode  - allow you to evacuate VMs from a datastore to work on it (does not support Templates or non-registered VMs yet…)
  • Affinity & Anti-Affinity – Allows you to make sure a group of VMs do not end up on the same datastore (for performance or Business Continuity reasons) or VMs that should always be on the same datastore.  Can be at the VM or down to the individual VMDK level.
  • Support for scheduled disabling of Storage DRS – perhaps during backups for instance.
• Profile-Driven Storage – Creating pools of storage in Tiers and selecting the correct tier for a given VM.  vSphere will make sure the VM stays on the correct tier(pool) of storage.  (Not a fan of this just yet.  What if just 1GB of the VM needs high-tier storage? This makes you put the whole VM there.)
• vSphere File System – VMFS5 is now available.  (Yes, This is a non-disruptive upgrade, however I would still create new and SVmotion)
  • Support for a single extent datastore up to 64TB
  • Support for >2TB Physical Raw Disk Mappings
  • Better VAAI (vStorage APIs for Array Integration) Locking with more tasks
  • Space reclamation on thin provisioned LUNs
  • Unified block size (1MB) (no more choosing between 1,2,4 or 8)
  • Sub-blocks for space efficiency (8KB vs. 64KB in VS4)
• VAAI now a T10 standard – All 3 primitives (Write Same, ATS and Full Copy) are now T10 standard compliant.
  • Also now added support for VAAI NAS Primitives including Full File Clone (to have the nas do the copy of the vmdk files for vSphere) and Reserve Space (to have the NAS create thick vmdk files on NAS storage)
• VAAI Thin Provisioning – Having the storage do the thin provisioning and then vSphere telling the storage which blocks can be reclaimed to shrink the space used on the storage
• Storage vMotion Enhancements
  • Now supports storage vMotion with VMs that have snapshots
  • Now supports moving linked clones
  • Now supports Storage DRS (mentioned above)
  • Now uses mirroring to migrate vs change block tracking in VS4.  Results in faster migration time and greater migration success.
• Storage IO Control for NAS – allows you to throttle the storage performance against “badly-behaving” VMs also prevents them from stealing storage bandwidth from high-priority VMs.  (Support for iSCSI and FC was added in VS4.)
• Support for VASA (vStorage APIs for Storage Awareness) – Allows storage to integrate tighter with vcenter for management.  Provides a mechanism for storage arrays to report their capabilities, topology and current state.  Also helps Storage DRS make more educated decisions when moving VMs.
• Support for Software FCoE Adapters – Requires a compatible NIC and allows you to run FCoE over that NIC without the need for a CNA Adapter.
• vMotion Enhancements
  • Support for multiple NICs.  Up to 4 x 10GbE or 16 x 1GbE NICs
  • Single vMotion can span multiple NICs (this is huge for 1GbE shops)
  • Allows for higher number of concurrent vMotions
  • SDPS Support (Slow Down During Page Send) – throttles busy VMs to reduce timeouts and improve success.
  • Ensures less than 1 second switchover in almost all cases
  • Support for higher latency networks (up to ~10ms)
  • Improved error reporting – better, more detailed logging (thank you vmware!)
  • Improved Resource Pool Integration – now puts VMs in the proper resource pool
• Distributed Resource Scheduling/Dynamic Power Management Enhancements
  • Support for “Agent VMs” – These are VMs that work per host (currently mostly vmware services – vshield, edge, app, endpoint, etc)  DRS will not migrate these VMs
  • “Agents” do not need to be migrated for maintenance mode
• Resource pool enhancements – now more consistent for clustered vs. non-clustered hosts.  No longer can modify resource pool settings on the host itself when it is managed by vcenter.  It does allow for making changes if the host gets disconnected from vCenter
• Support for LLDP Network Protocol – Standards based vendor-neutral discovery protocol
• Support for NetFlow – Allows collection of IP traffic information to send to collectors (CA, NetScout, etc) to provide bandwidth statistics, irregularities, etc.  Provides complete visibility to traffic between VMs or VM to outside.
• Network I/O Control (NETIOC) – allows creation of network resource pools, QoS Tagging, Shares and Limits to traffic types, Guaranteed Service Levels for certain traffic types
• Support for QoS (802.1p) tagging – provides the ability to Q0S tag any traffic flowing out of the vSphere infrastructure.
• Network Performance Improvements
  • Multiple VMs receiving multicast traffic from the same source will see improved throughput and CPU efficiency
  • VMkernel NICs will see higher throughput with small messages and better IOPs scaling for iSCSI traffic
• Command Line Enhancements
  • Remote commands and local commands will now be the same (new esxcli commands are not backwards compatible)
  • Output from commands can now be formatted automatically (xml, CSV, etc)
• ESXi 5.0 Firewall Enhancements
  • New engine not based on iptables
  • New engine is service-oriented and is a stateless firewall
  • Users can restrict specific services based on IP address and Subnet Mask
  • Firewall has host-profile support
• Support for Image Builder – can now create customized ESXi CDs with the drivers and OEM add-ins that you need.  (Like slip-streaming for Windows CDs) Can also be used for PXE installs.
• Host Profiles Enhancements
  • Allows use of an answer file to complete the profile for an automated deployment
  • Greatly expands the config options including: iSCSI, FCoE, Native Multipathing, Device Claming, Kernel Module Settings & more)  (I don’t think Nexus is supported yet)
• Update Manager Enhancements
  • Can now patch multiple hosts in a cluster at a time.  Will analyze and see how many hosts can be patched at the same time and patch groups in the cluster instead of one at a time.  Can still do one at a time if you prefer.
  • VMTools can now be scheduled at next VM reboot
  • Can now configure multiple download URLs and restrict downloads to only the specific versions of ESX you are running
  • More management capabilities: update certificates, change DB password, proxy authentication, reconfigure setup, etc.
• High Availability Enhancements
  • No more Primary/Secondary concept, one host is elected master and all others are slaves
  • Can now use storage-level communications – hosts can use “heartbeat datastores” in the event that network communication is lost between the hosts.
  • HA Protected state is now reported on a per/VM basis.  Certain operations no longer wait for confirmation of protection to run for instance power on.  The result is that VMs power on faster.
  • HA Logging has been consolidated into one log file
  • HA now pushes the HA Agent to all hosts in a cluster instead of one at a time.  Result:  reduces config time for HA to ~1 minute instead of ~1 minute per host in the cluster.
  • HA User Interface now shows who the Master is, VMs Protected and Un-protected, any configuration issues, datastore heartbeat configuration and better controls on failover hosts.
• vCenter Web Interface – Admins can now use a robust web interface to control the infrastructure instead of the GUI client.
  • Includes VM Management functions (Provisioning, Edit VM, Poer Controls, Snaps, Migrations)
  • Can view all objects (hosts clusters, datastores, folders, etc)
  • Basic Health Monitoring
  • View the VM Console
  • Search Capabilities
  • vApp Management functions (Provisioning, editing, power operations)
• vCenter Server Appliance – Customers no longer need a Windows license to run vCenter.  vCenter can come as a self-contained appliance (This has been a major request in the community for years)
  • 64-bit appliance running SLES 11
  • Distributed as 3.6GB, Deployment range is 5GB to 80GB of storage
  • Included database for 5 Hosts or 50 VMs (same as SQL Express in VS4)
  • Support for Oracle as the full DB (twitter said that DB2 was also supported but I cannot confirm in my materials)
  • Authentication thru AD and NIS
  • Web-based configuration
  • Supports the vSphere Web Client
  • It does not support:  Linked Mode vCenters, IPv6, SQL, or vCenter heartbeat (HA is provided thru vSphere HA)
• vCenter Heartbeat 6.4 Enhancements
  • Allows the active and standby nodes to be reachable at the same time, so both can be patched and managed
  • Now has a plug-in to the vSphere client to manage and monitor Heartbeat
  • Events will register in the vSphere Recent Tasks and Events
  • Alerts will register in the alarms and display in the client
  • Supports vCenter 5.0 and SQL 2008 R2

That’s what I have on vSphere 5, next up is SRM5, vShield5, Storage Appliance, and vCloud Director 1.5.

Let’s go thru an example.  First things first, before you export, make sure you have all the information you need.  In the vSphere client, pick your level to look at the Storage View (the vCenter Server, the datacenter, a cluster, a host, etc) and select the Storage Views tab on the right.  Right-click the title bar in the right pane and make sure you have all of the fields you need.  The menu will look something like this one here:

Make sure you select all of the columns of data that you want (or don’t want).  Once you have that cleaned up, we go for the export.  Your instinct would be to go to File and Export like this:

Notice how the Export List option is greyed out?  That’s where you would expect to find the export function for the Storage Views.  I think there is a bug in the interface as that is not really where it is located in this case.  For Storage Views, move the cursor to some white space on the right or the bottom of the right pane and right-click.  You should see a popup menu that looks like something like this:

Select “Export List” from the menu and you can save the storage view as Excel, HTML, CSV, etc.  There, now you have some great data for graphs or whatever you like.

One more tip:  If you export the fields to Excel, the cells will all be text and the data values will have “GB” in the cells with them.  If you want to remove the “GB” and convert to numeric so you can work with the values here’s how:

Let’s say Cell C3  has a value of “7.77 GB”.  Create a new column and for the value put in  =VALUE(LEFT(C3,LEN(C3)-3))

The LEFT() function will cutoff the “GB” and the VALUE() function will convert the TEXT to a numeric value that you can add, subtract, etc.

Now you can add a cell at the bottom and use the AVERAGE() function and find out what your average VM size really is!  Or SUM() the Snapshot column and find out how much space your VM snaps are taking up on storage.  There are all kinds of options, have fun and enjoy!

Beginning on March 15, 2011, VMware began sending out the email notifications with the Redemption Codes in email.  The customer contact on the original order for the products should have received the email.  It has instructions for redeeming the code and getting the Ops Manager licenses.  If you have not received (or can’t find) the email and believe you are eligible, you should contact your VMware Sales team.  Here’s the main point: If you have received your email, you only have until May 31, 2011 to redeem your code and get your licenses.

If you think you are eligible, make sure to find your email and get your licenses, time is running out.

When we renamed the service account to have a different name from the vCenter server itself, all installed fine.  I had to post it, this issue really surprised me.

Duncan wrote an explanation in the community thread for what is going on:

“It most definitely has to do with the type of datamover used. When a different blocksize is used for the destination the legacy datamover is used which is the FSDM. When the blocksize is equal the new datamover is used which is FS3DM. FS3DM decides if is will use VAAI or just the software component, in either case unfortunately the zeroes will not be gobbled. I have validated it and reported it to engineering that this is desireable. The team will look into it but unfortunately I cannot make any promises if or when this feature would be added.”

It sounds to me like if your storage supports VAAI and ESXi offloads the svmotion to it, there’s no hope of shrinking because VAAI is not that intelligent.  When you svmotion between two different LUN block sizes (or between iSCSI, NFS or FC) it uses old-school svmotion (probably because the VMFS block layout changes) which will actually convert the VM to thin when it moves.

Hopefully VMware engineering will change svmotion to automatically use old-school svmotion when you select to change from thick or thin and only use VAAI when you choose to keep the same format during the move.  We’ll have to wait and see….

Here’s why:  In a true failover in SRM, the first step of the Recovery Plan is to shut down all of the VMs in the primary site that are protected.  This is so that when the VMs restart in the recovery site, they do not conflict on the network with the original VMs.  Here in Miami the typical disaster is, of course, hurricanes.  Hurricanes are typically predictable with a decent notice.  I can then assume that my odds are higher than normal that when the person hits the failover button here, both sites are still available and I will be avoiding a disaster and not recovering from one.  For this reason, I recommended to my customer that they add a message in their recovery plan right above “Prepare Storage” in the Recovery Plan.  You can do this by right-clicking “Prepare Storage” and selecting “Add Message”.

I added the following message to their Recovery Plan:

License Sale

Upgrade to vSphere Enterprise for $495 per CPU (normally $685/CPU) – Support and Subscription is required with purchase.  Pretty self-explanatory on the differences.  I’m a huge fan of Host Profiles, distributed switches and storage IO control.

50 Seats of View Premier with vSphere Enterprise Plus Upgrades – Customers who purchase Enterprise Plus (Ent+) will get 50 concurrent Desktops of View Premier Edition and 1 year of Production Support and Subscription.  This promo also includes all of the bundles that upgrade vSphere to Ent+ (including the $495 upgrade above).

15 VMs of CapacityIQ with upgrades to Standard, Advanced, Enterprise and Ent+ – Customers who purchase or upgrade upgrade to any of these editions or bundles containing any of these editions get 15 VMs of CapIQ.  Essentials and Essentials Plus bundles are not eligible.

The official disclaimer from VMware: “VMware reserves the right to amend the terms, conditions and requirements of these promotions.  List Pricing is for reference purposes only and is subject to change without notice and my vary within region. Please refer to your reselling partner or www.vmware.com for a quotation or actual product pricing.”

PerVM Licensing

CapIQ, AppSpeed, Chargeback, and Site Recovery Manager are switching to perVM licensing from perCPU.  Customers can stay on their perCPU licenses or they can convert.  Customers who convert will get 10 VMs of Appspeed for each CPU, 10VMs of CapIQ for each CPU, 20 VMs of Chargeback for each CPU and 5 VMs of Site Recovery Manager per CPU, respectively.  As I mentioned, customers can stay on their existing licenses and renew support for them if they want.  They will not be able to buy any new perCPU licenses after December 15th, 2010 for these 4 products listed above.  This is where I see a bit of a storm brewing.  Customers who run many VMs per host and want to protect most of them are in for a bit of a rude awakening.

My take on PerVM Licensing

Let’s say a customer runs SRM perCPU today.  They have 4 hosts running 100 VMs total and SRM protects them all.  Each host has 2 CPUs.  In the old licensing model, they needed 8 CPUs of SRM that retailed for $1,750 each.  8 x 1,750 = $14,000 (let’s exclude Support and Subscription for the moment to make the numbers easier but I recognize that SnS is required).  Under the new model, the PerVM licensing comes in packs of 25 VMs.  For our example we need 4 packs of 25 VMs that retail for $11,250 each or 4 x 11,250 = $45,000.  Yes, you just read that right.  The customers cost for SRM in our example just went from $14k to $45k.

The new licensing does benefit some customers however.  Those with large farms that want to protect a minority of their VMs.  Those customers can now just buy a pack of VMs and protect only the ones they need.  They can even split the licenses between sites and cross-replicate.  This is where this licensing model really helps.  It helps the customers who just want to do some SRM.

The last point I want to make is buried in the FAQ on PerVM Licensing.  If you are currently running perCPU SRM in a cluster, if you need to add a host after December 15th and you need SRM licenses for that new host, you will need to convert your licenses at a ratio of 5:1 for SRM and then purchase perVM for all your existing protected VMs that are not covered by your converted licenses.  I have a bad feeling this is going to be a wakeup call for some customers.  Another note: there’s no switching back.  Once you go perVM, you cannot go back to perCPU.

I try very hard to look out for my customers and keep them informed.  These licensing changes may benefit some customers wanting to start out with a small number of protected VMs with SRM.  However, most of my SRM customers are like the $45k example shown above.  I don’t see these licensing changes being a benefit to them.  Normally, I don’t discuss licensing in my blog articles.  Some customers have negative attitudes when it comes to licensing.  Some maybe got burned in the past, or just don’t like to talk about spending money.  My goal here is to make sure you can see how these changes can affect you before the impending deadline.  Sometimes I can see a storm brewing from off in the distance.  I just hope that the storm does not cause a disaster, the likes of which even SRM cannot recover from.

CapacityIQ 1.5 includes the following new features and enhancements:

• Storage Analytics – Adds disk space and disk I/O trending and storage analysis. The dashboard and views provide visibility into consumption of storage resources and ways to identify capacity bottlenecks. The data is optimized for vSphere and accounts for thin provisioning, I/O control, and linked clones.
• Resource optimization – Adds storage-aware workload modeling and what if scenarios to forecast future capacity needs. CapacityIQ provides outlier detection and filtering capabilities for improved analytics.
• Scheduled Reports – Adds report scheduling with email capabilities for automated delivery of capacity utilization and optimization reports.
• Performance and scalability improvements – Improves the response time in the interface and raises the scalability limits to 6000 powered on virtual machines and 8000 registered virtual machines.
• Virtual machine-based licensing – Supports virtual machine and CPU-based licensing. If you obtain a virtual machine-based license for CapacityIQ, install and manage the license from vCenter Server instead of the Administration Portal. You can continue to manage CPU-based licenses in the Administration Portal.

My initial take on it: Storage trending is a good addition.  It’s nice that it takes into account thin disks, etc.  Scheduled Reports is a nice add for proactive reporting.  Licensing going to vCenter for managing the license keys should have been done in v1.0.  I don’t like managing per-cpu licenses one way and per-vm another.  Overall sounds like a worthwhile release.  I’ll be plugging this into the lab later this week to kick the tires first hand.  Any additional pros and cons will be posted in an update.

I found a few references here and there.  Most customers keep the paging file inside the standard VM disks to avoid making the environment too complex.  I was about to give up and suggest he not separate the paging file, until I came across this discussion in the VMware communities.  I was stunned to see one customer report that they were seeing a reduction of 60% of the replication traffic on certain VMs.  They even saw a 80% reduction of replicated traffic from one of their Citrix servers.  Now I was cooking.  This was amazing and made perfect sense to me how some servers could be more defined by this than others.  I was off to find a documented procedure from VMware to do so.  Unfortunately I came up empty in the Knowledge Base, white papers and best practices.  If you know of such a VMware documented procedure, please post in the comments with a reference link and I will update my article.

After reviewing the communities discussion line-by-line, I came across this NetApp SRM technical paper written by Jeremy Merill and Larry Touchette (whom I was fortunate enough to work with while I was at NetApp).  It contains some great procedures for optimizing NetApp storage and Site Recovery Manager.  Beginning on page 41 however, is a great vendor-agnostic procedure for separating out the Windows Paging file to reduce it’s impact on storage replication.  Jackpot.  Basically there are a few points to consider.  First the windows swap file is configured for a specific drive letter and path.  How do you make sure the recovered machine gets the same drive letter when it comes up in the recovery plan?  The answer is in the procedure.  Jeremy and Larry describe how to configure the source VM with it’s Windows Paging file seperated.  Then they clone the VMDK where the paging file resides and copy it to the destination side.  The reason they do this is because the disk has a signature on it that tells Windows what drive letter it is.  Then they altered the recovery plan for SRM to mount that destination disk to the VM before it powers on.  So that when the recovery VM does come online, it has it’s page file disk as the same letter with the page file intact.  Because the Windows paging file gets wiped on every boot, the data in it is not important, only the location where it’s stored.  They repeat this procedure for every VM in the recovery plan.  I realize that this could be a large undertaking to separate all these page files but the more VMs, the more replication data saved.

I’m very curious if some have tried separating out the page file and what replication improvements you have seen.  Please report those in the comments if you have tried it.  I’d love to hear the results.

The VMware vCenter Converter Standalone 4.3 includes the following new functionality:

• Support for VMware vSphere 4.1 as source and destination targets
• Support for importing powered-off Microsoft Hyper-V R1 and Hyper-V R2 virtual machines
• Public API and sample code for submitting and monitoring Converter jobs
• Support for importing Windows 7 and Windows 2008 R2 sources
• Ability to throttle the data transfer from source to destination based on network bandwidth or CPU
• IPv6 support

Discontinued Support

• Support of the following operating systems is discontinued:
  • Windows 2000
  • Windows NT
• Support for OVF format is discontinued
• Support for VCB image sources is discontinued
• Linux installation support is discontinued

You probably noticed by now that there is a limitation in Standard and Enterprise editions of vSphere to a maximum of 6-cores per CPU.  The Advanced and Enterprise-Plus editions of vSphere have a licensed limit of 12-cores per CPU.  Now that Intel’s 8-core CPUs and AMD’s 12-cores are out, what’s next?  Intel and AMD are sure to develop a proc with more than 12 cores (and probably sooner than we all think).  What will happen to VMware’s licensing then?  You have to remember that from a revenue standpoint, when a 24 core proc comes out, customers will be able to run twice as many workloads on that proc (or at least 50% more).  Moore’s Law states that processing performance of CPUs will double every two years.  With the processors doubling in power so quickly, customers are typically not doubling their number of VMs in the same time period.  The result is that customers tend to have a diminishing need to increase their ESX per-CPU licensing.  I know that there are exceptions to this rule, but in the SMB space the majority are not growing that fast (at least not in this economy).  The increase in processor performance actually works against VMware’s current licensing model. It not good to have a direct connection between your main revenue stream and someone else’s CPU release schedule.  What will happen?  What’s the right answer?  Your guess is as good as mine.  Will they go to a per-vm model?  Increase their current limits?  Find some middle-ground between the two?  Will they “grandfather” their customers like AT&T did with the iPad data plans?  Only VMware knows.  My opinion is that this is an issue that has to be dealt with eventually.  Maybe this will be the year, maybe next.

The second licensing dilemma that I run into is in Site Recovery Manager.  It’s no secret that SRM is my favorite non-ESX product from VMware.  As you probably know, SRM is licensed by the physical CPU where the protected virtual machines reside or could reside.  Here’s where that model breaks down:  let’s say I have a smaller customer who’s policy is only to have a DR plan for 5 of their most critical Virtual Machines.  Those five VMs run in a cluster comprise of 5 dual CPU hosts with HA and DRS enabled.  According to the SRM licensing model, I need 10 CPUs of SRM for those 5 VMs.  That does not fly well.  The solution I’ve heard some engineers mention is to create a separate smaller cluster for just the protected VMs.  I’m not fond of that idea because it goes against the consolidation principal.  I’ve never felt that lowering your consolidation ratio was justified because it did not fit a licensing model.

I know there are people much smarter than me at work trying to find a solution to both of these scenarios.  I’m hopeful that they will get resolved in a way that’s fair to both sides.  Maybe this is the year, maybe it is not.  Either way, we’ve made it thru half of 2010, perhaps the answers lie in the last 6 months of the year.

PCoIP Display Protocol: Information and Scenario-Based Network Sizing Guide – (12 pages) A good paper with very good insight on the PCoIP protocol used in VMware View.  It gives some good suggestions and the required bandwidths needed to satisfy the end users on their desktop experience.  A must have for view deployments.  (****, 4 of 5 stars)

Application Presentation to VMware View Desktops with Citrix XenApp – (3 pages) This is a whitepaper to show how to deploy applications in VMware View desktops from XenApp.  While I can see this being useful for View admins who use XenApp, the description and instructions are very minimal.  Probably something better suited for a KB article. (**, 2 of 5 stars)

Timekeeping in VMware Virtual Machines – (26 pages) This is a very important topic for all VM Admins to know.  Time is relevant to everything in a VM, whether you are trying to authenticate to Active Directory or troubleshooting using event logs, accurate time is very important.  This paper goes into some really great detail on how VMware maintains accurate time in VMs.  If you are a VMware admin, this should be a standard read.   (*****, 5 of 5 stars, vKeeper)

SAN System Design and Deployment Guide – (244 pages of storage goodness)  I have a storage background so I specifically enjoy this one.  If you are running ESX on SAN shared storage (you should be on some type of shared storage) then this is a must read.  This whitepaper is also very helpful if you are studying for the VCP or one of the new VCAP exams.  This is another paper I keep local and definitely one all VM admins with SAN should review.  (*****, 5 of 5 stars, vKeeper)

Best Practices for Running vSphere on NFS Storage – (14 pages) On the heels of the SAN design and deployment guide, this paper describes the best practices for running NFS on vSphere.  I like the fact that this article references outdated best practices that have changed and why they have changed.  This is a HUGE help to admins who google a topic only to find conflicting information.  My only regret on this paper is that I would like to see more detail on the advanced options and how they affect the performance of NFS.  Still a important doc for VM Admins using NFS storage.  Should be reviewed by all of them to make sure they are current in their deployment of NFS best practices.  (****, 4 of 5 stars)

Location Awareness in VMware View 4 – (8 pages) Good information for View Admins to know where to find out where their clients are connecting from.  This is a common request from hospitals to have printers “follow the user” as they float from terminal to terminal.  There are some advanced topics in this article and some Active Directory knowledge is definitely required especially when using loopback mode in group policy processing.  Good info and hopefully View will include some GUI-based  native features in the future to assist with this.  (***, 3 of 5 stars)

VMware vSphere 4.0 Security Hardening Guide – (70 pages) This is a outstanding reference for any VM Admin.  Security affects everyone’s environment, from the 3-man shop to the largest infrastructure.  Setting the precedence of a solid, secure enviornment from the ground up will provide you with a infrastructure that is solid as a rock. I recommend reviewing this paper often and keeping this one handy   (*****, 5 of 5 stars, vKeeper)

VMware vStorage Virtual Machine File System – Technical Overview and Best Practices – (13 pages) This is a entry level paper on some of the very basics of VMFS and how they relate to RDMs.  This should be a good introduction to VMFS to new VM Admins.  I hoped with “Best Practices” in the title that there would be more technical references (advanced options for VMFS and how tweaking them affects the storage performance for instance).  I was also disappointed to see the LUN size question answered vaguely, suggesting to refer to the storage vendor to size your LUNs appropriately.  I prefer Duncan’s approach to LUN sizing and it’s what I recommend to all of my customers.  (***, 3 of 5 stars)

Look for the vPaper Report again next quarter (hopefully with some new releases in between). Until then, happy reading!

Then it hit me, a single ESX host currently can see up to 256 LUNs.  Initially I thought, “but they’re never going to run more than 256 VMs on a host.”  No, but they did want to start using vMotion.  Now the LUNs will need to be presented to all hosts.  This 256 LUN limit no longer relates to the single host but to the cluster as a whole.  With all LUNs presented to all hosts, as long as they keep provisioning one-LUN-per-VM, they will be limited to 255 VM’s for the cluster (one of the LUNs is for booting ESX).  This was a limit they were most certainly going to hit (and at an accelerated pace, now that they have vMotion).

This made sense quickly to the customer.  The story has a happy ending: next week we’re upgrading them to vSphere and going to storage vMotion those VMs to a place with a better design.  There’s one thing I’ve learned about storage and virtualization is that there are no wrong designs.  However, there are ones that limit functionality.

The moral of the story is to know thy vmware maximums!  Make sure to check if a single host’s limitation could affect the design of an entire cloud.

Happy Earth Day!

VMware vShield Zones – Reviewers Guide – If you haven’t figured this out yet, pay close attention to the Reviewers Guides.  If you have even slightly thought of trying out a product or technology, the reviewers guide is the next best thing to having an engineer over your shoulder walking you thru the product.  This is a really good one on Zones.  I learned quite a few things about the product that I was unaware of.  It’s a great read if you need to lock down and firewall off your VMs (or if you just want to learn how the VMs talk to each other).

Performance Brief for IBM WebSphere Application Server 7.0 with VMware ESX 4 on HP ProLiant DL380 G6 Servers – This is a very specific paper on running Websphere on HP servers.  I did find some interesting bits in it however.  Specifically, configuration tips to maximize performance running Websphere in a VM.  The performance metrics should also be evaluated if you want to run Websphere on any hardware platform (perhaps even IBM).

Best Practices for Running vSphere on NFS Storage – I’m currently in a documentation war with my EMC Channel SE who swears by running VMware on NFS (You still have to convince me Steve, I’m a block-IO bigot).  This is a must-have for all Admins running VMware on NFS.  It’s also a really good guideline if you want to compare performance between file-level or block-level IO in your VMware environment and make sure your making an accurate decision.  My favorite section of this paper: “Previously thought to be Best Practices.”  Every best practice white paper should have that to debunk outdated information.  Outstanding work VMware!

PVSCSI Storage Performance -This is a paper I was waiting to see.  It compares the performance of the PVSCSI adapter to the LSI Logic adapter.  I guessed pretty close on the outcomes.  The PVSCSI adapter does perform better under higher IO workloads (some have stated only use it >2000 IOPs.)  The only thing I didn’t like about the test was that RDMs were used.  VMware has argued for the last few years that high-performance should not be a requirement for using RDMs.  So why not use what the majority of customers use in their environments?

RIM BlackBerry Enterprise Server on VMware Virtual Infrastructure Deployment Guide – I really liked and hated this paper.  I liked it because it has some really good best practices and deployment tips depending on the size of the environment.  I hated it because it definitely contains errors: Table 2 shows a BES server with 23% utilization on ESX 3.5, Table 3 shows a BES server with 27% utilization under ESX 4, Figure 12 says the CPU load went down from 27 to 23 going to vSphere – not according to your tables kids.

That will do it for this month’s White Paper Review.  We’ll see you next month and look for more great technical information.

Dell EqualLogics, Version 1.0.2, Released 01/20/2010

EMC Celerra, Version 4.0.17, Released 01/29/2010

Fujitsu ETERNUS SF AdvancedCopy Manager, Version 1.3| Released 01/29/2010

IBM DS4000/5000, Version 01.01.35.05, Released 01/15/2010

IBM N-series SAN Adapter, Version 1.4.2, Released 01/07/2010

LSI, Version 1.01.30.05, Released 01/21/2010

You can find the updated SRAs on the SRM download site here.  As always, please check to make sure these updates are necessary for your environment.  I would have included the release notes but unfortunately the vendors are not keep track of them.  Upgrade at your own risk, and if you do, please test your recovery plans out fully with the new adapters.

Update: It appears the links are back.  Be aware they may be flaky if VMware is working on the site today.

Anti-Virus Deployment for VMware View – Great article on what to consider when deploying an anti-virus solution for your View desktops.  Great reading on how to best protect your desktop VMs.  My favorite part is the detailed exclusion list for the anti-virus scanners – very helpful.

Analysis of IBM System x3850 M2 Performance and Scalability with VMware vSphere 4 and SAP Solutions – a very specific read but has some very nice scailibility charts in it for the IBM x3850.  There’s also a nice listing of the optimized IBM BIOS settings on the server.

ESRI ArcGIS Server 9.3 for VMware Infrastructure – a good read if you are deploying the ESRI ArcGIS mapping software in your environment.  Very specifics on configuration of that software on ESX 3.5.

VMware View 4 & VMware ThinApp Integration Guide – A very nice paper on how to integrate ThinApp packages into pools of desktops in View.  It has a lot of items to consider when deploying apps this way.  I’m personally hoping for some native VMware integration coming in the future.

Application Registration with VMware ThinApp – Here’s the question: how can I associate a specific file type with a ThinApp’ed application so when I click the file, it opens in the ThinApp’ed App?  Bingo, the doc goes through how to set this up in your environment on virtual or physical desktops.

Workload Considerations for Virtual Desktop Reference Architectures Info Guide – Great paper on the RAWC (Reference Architectures Workload Code) tool.  It allows you to simulate desktop workloads in VM’s to help size them in a VDI deployment.

Reference Architecture Brief: Dell Virtual Remote Desktop Featuring VMware View 4 – A paper from Dell on a reference architecture to use for VDI deployments.  Good reading if you plan on doing VDI on Dell in 2010.

VMware Reference Architecture for Cisco UCS and EMC CLARiiON with VMware View 4 – A good reference architecture for VDI using View, Cisco UCS and a EMC Clariion CX4-480.  Good read for using VDI on this platform.

VMware View 4 Evaluator’s Guide – The standard read if you are planning on Evaluating VMware View.  This one is a must-have to make sure you test out all of the features and functionality in View.

Deploying Virtual Desktops with VMware View 4 on EMC Celerra NS-120 Validation Test Report – A paper on the results from EMC’s testing of their NS-120 as a platform for View.

VMware View on NetApp Storage Solution Brief – Nice overview of the benefits gained from running View on NetApp storage.  Lists and itemizes the integrated functionality and benefits.

VMware View 4 with PCoIP Info Guide – A nice little paper overviewing the features built into the PCoIP protocol built into View4.

Management of VMware ESXi on HP ProLiant Servers – (what? something not View related?) A good paper listing the integration and monitoring options of HP Servers running ESXi and HP Insight Manager.  Many HP customers have asked me for this information.

VMware vCenter Server 4.x: Using Database Views – A very good listing of fields stored on the vCenter4 database.  Customers have asked me many times for this kind of info and there are not many publications on it.  Great read if you want to extract some custom info from your vCenter database.

HP Reference Architecture for VMware View 4 – Good read if you are thinking of running View on HP blades.  Nice reference architecture from HP.

SAP Solutions on VMware vSphere 4 – Best Practice Guidelines – A must-read if you plan on virtualizing your SAP deployment on vSphere.  Many customers have asked for this doc.

VMware View 4 Deployment Guide – (had to end it on a View article) A must read when you are planning a View deployment.  Great points to remember and pitfalls to avoid.  Definitely a keeper if you are deploying View in 2010.

1. Open the client and connect to the vCenter server
2. From the menu bar select view/inventory/virtual machines and templates
3. on the left pane, select the level of the vm list you want to grab (if you want all of the vms, select the top-level folder)
4. on the right pane, select the virtual machines tab which will show you the list of vm’s at whatever level you’ve selected on the left pane.
5. one suggestion I have here is to right-click the titles on the right pane, this provides a list of all the fields available.  Select “DNS name” as one of the fields and it will add the “dns name” field to the rightmost column (very helpful in case you have named your vm’s in vcenter different than their actual dns names).  Another helpful field that you may want to use is “Guest OS” IMO.  You can also add any other fields that you want (or don’t want) to report on.  You can re-order them by dragging and dropping the field titles in the right pane.
6. when you have the right pane looking the way you want it, go back up to the menu bar and select File/Export/Export List…
7. Pick your format (Excel is available) and export it.  It will export everything in the right pane including your field titles in the spreadsheet.

Enjoy and good luck.

Dynamic Storage Provisioning – A very nice introduction to Thin Provisioning in vSphere.  The concept of Thin Provisioning is explained as well as when you want to use it.  Some interesting points I noted in the article: Thin disks expand in chunks the size of the vmdk’s block size (1MB by default) and the only way to defragment a vmdk currently? – Storage vMotion.

Performance Study of VMware Thin Provisioning – Very good read on the performance impact of thin provisioned disks vs. thick disks.  I was somewhat surprised by the results.  There’s not nearly as much of a performance impact as I thought there would be.  A very good read if you are looking to justify Thin Disks for some applications within your organization.

VMCI Socket Performance – This was a very interesting paper that I’m still scratching my head on.  VMCI is the interface that programmers can use to communicate between VM’s on a given host.  So if a programmer is writing an app and it requires 2 VMs that do a lot of communication to each other, they can communicate on the VMCI interface instead of traversing the TCP/IP network and going thru all of the networking stack.  This paper shows the performance of using VMCI instead of TCP/IP for Windows and Linux boxes.  I’m scratching my head because the results are not as linear as I would have expected and there are scenarios that perform much better or worse than others.  Take a read and make your own conclusions.

VMware vCenter Site Recovery Manager 4.0 Performance and Best Practices for Performance – I’m probably the #1 fan of SRM.  I think what SRM does for DR is like what a conductor does for an orchestra.  As you may know, SRM 4.0 now scales to 1,000 VMs.  It can take a while to optimize that number of VMs for recovery.  This paper is an excellent resource for optimizing the setup and config of SRM to scale effectively to a very large number of VMs.

This KB article (http://kb.vmware.com/kb/1008027) reads:

For VMware FT to be supported, the servers that host the virtual machines must each use a supported processor from the same category as documented below:

Intel Xeon based on 45nm Core 2 Microarchitecture Category:
3100 Series
3300 Series
5200 Series (DP)
5400 Series
7400 Series

Intel Xeon based on Core i7 Microarchitecture Category:
3500 Series
5500 Series

AMD 3rd Generation Opteron Category:
1300 and 1400 Series
2300 and 2400 Series (DP)
8300 and 8400 Series (MP)

Please note the requirement “same category.”  As an example, if you have a server with a 54xx series Intel Processor and a Intel 55xx series processor (both have the technology for FT), you can vMotion and DRS between them (via EVC) but you cannot run a Fault Tolerant pair across them.  The Lockstep technology from Intel changed in the 35xx and 55xx CPUs and is not compatible with the previous generations of lockstep.

Some nice updates included in the release notes:

vCenter Chargeback 1.0.1 provides the following new features:

• Support for Windows Authentication
  This release of vCenter Chargeback supports Windows Authentication for SQL Server databases. If you are using SQL Server for the vCenter Chargeback database or for the vCenter Server database, then you can configure the application to use Windows Authentication instead of SQL Authentication.
• New computing resource and billing policies added
  This release of vCenter Chargeback introduces a new computing resource, vCPU, and two new billing policies,vCPU Count and Memory Size and Fixed Cost and vCPU Count and Memory Size. These policies enable you to calculate cost based on the number of virtual CPUs and the amount of memory allocated to the virtual machines.
• Resource Summary section lists rolled-up usage data for all entities
  The Resource Summary section of the chargeback reports show the rolled-up usage data for all the entities.
• Global fixed cost history is retained
  This release of vCenter Chargeback lets you to set different cost values for different time periods on the same global fixed cost. The old values are retained and not overwritten.
• Ability to undo to the most recent operation on the chargeback hierarchy
  The most recent operation on the chargeback hierarchy can be undone. This undo feature is available for entities that are added or moved in the hierarchy. The undo option is not available for rename and delete operations.
• Ability to use the vCenter Chargeback APIs
  vCenter Chargeback APIs provide an interface to programmatically use the various features of vCenter Chargeback. As an application developer, you can use these APIs to build chargeback applications or integrate vCenter Chargeback with your internal billing systems and compliance policies. Please do note that the APIs released with this version of vCenter Chargeback are only for a technical preview.