I am very honored to be selected as a VMware vExpert this year. This is a great program to encourage contributions within the community, and I’m thankful to be selected. Congratulations to all others that made it: Full vExpert List.
The VMware vExpert Award is given to individuals who have significantly contributed to the community of VMware users over the past year. vExperts are book authors, bloggers, VMUG leaders, tool builders, and other IT professionals who share their knowledge and passion with others. These vExperts have gone above and beyond their day jobs to share their technical expertise and communicate the value of VMware and virtualization to their colleagues and community.
I recently ran into a case of a missing button after trying to enable 2-step verification for GMail. I figured that had to do with using a Google Apps domain account instead of a regular GMail account, so I did some poking around under Domain Management. You can find the setting to enable it under Advanced Tools -> Authentication -> Allow Users to turn on 2-step authentication:
Now you should see the option under Account Overview:
The setup process is painless, and since enabling the process it hasn’t been as obtrusive as I anticipated. Most people are using 2-factor authentication for games (such as Starcraft, WoW, and SW:TOR), and it certainly makes just as much sense to apply this to e-mail as well.
There is a great post over on thelowercasew.com by Matt Liebowitz, which discusses Microsoft’s stance on virtual machine snapshots in respect to MSSQL and Exchange. The gist being that Microsoft will not support snapshots, and consequently virtual machines restored using this policy.
Some hypervisors include features for taking snapshots of virtual machines. Virtual machine snapshots capture the state of a virtual machine while it’s running. This feature enables you to take multiple snapshots of a virtual machine and then revert the virtual machine to any of the previous states by applying a snapshot to the virtual machine. However, virtual machine snapshots aren’t application aware, and using them can have unintended and unexpected consequences for a server application that maintains state data, such as Exchange. As a result, making virtual machine snapshots of an Exchange guest virtual machine isn’t supported.
Virtualization Snapshots for Hyper-V or for any virtualization vendor are not supported to use with SQL Server in a virtual machine. It is possible that you may not encounter any problems when using snapshots and SQL Server, but Microsoft will not provide technical support to SQL Server customers for a virtual machine that was restored from a snapshot.
As mentioned in the article, most popular virtualization backup tools (Veeam, PHD, BackupExec w/ VMware Agent) all use snapshots for their backup process. Why would Microsoft not support this if it is so popular? As mentioned by Microsoft, plain snapshots (e.g. snapshots taken from the vSphere client) are not application-aware. That’s a problem for applications like SQL and Exchange. Fortunately, backup vendors have added application-awareness into their products. Also, another issue that you may run into is related to the stunning of the VM when deleting a snapshot.
In addition to the above, it’s worth noting that a fairly large number of more novice users treat regular snapshots as backups. VMware’s Snapshot Best Practices (KB 1025279) reiterates that plain snapshots are not backups.
I can certainly see where Microsoft is coming from, and I doubt they will give you trouble if you restore a VM from a backup using one of the popular tools, despite the disclaimer. I predict most instances in which you would call Microsoft support, you would already have restored the VM and you’ve now encountered an issue inside the application. If you have a problem with the restore itself, you’re likely going to head to your backup vendor for support. Microsoft engineers are going to have a hard time telling exactly how you got to the point you’re at unless you explicitly tell them, so it might be worth keeping that close to your chest if possible. Of course, Microsoft support could always try to play hard ball, so it’s certainly worth keeping the fact they’ve stated they won’t support snapshots in mind.
With SQL servers, I have always chosen to back up SQL traditionally in conjunction with our virtualization-based backups, as well. I imagine most others follow the same practice.
This tip is a pretty simple one, but can be confusing to some. For example, when a delete fails, it’s natural to want to just click delete again. To that point, in the past, I have seen virtual desktops go into the ‘Error’ state when deletions or recomposures fail. For example, a recompose failed because it couldn’t join the domain due to the DHCP range running out of addresses, and I know what went wrong and just want to do the operation again.
Trying the same operation again won’t do anything. Getting back to a good state, assuming the root cause has hopefully been resolved, is accomplished via a simple refresh:
We can, assuming deletion was our goal, then re-delete the desktop and it should do so cleanly:
After a very long P2V process, I booted up the new VM and was greeted with the following error:
The parent virtual disk has been modified since the child was created.
Upon which, the VM would not power on. After waiting on a 12 hour conversion, this is a depressing error to receive. Luckily, it is fixable. Using KB 1007969, the vmdks can be edited to fix the mismatch.
Essentially, you have to rebuild the parent-child chain within the VMDKs. The KB does a very detailed job of explaining what to do, but I will note to make sure you’re changing the parentCID of the file once you modify and not the CID itself, and I’d recommend commenting what you change in case you need to revert. After getting the VM to power on, be sure that the VM behaves in an expected state.
Recently when trying to browse through statistics within vCenter, a colleague was confused why many of the metrics were not shown when trying to look at historical data. This can be explained by the default behavior of vCenter and how it collects the data.
In the standard configuration, vCenter is not setup to keep all of this information due to the size of the data. However, this can be viewed and changed via Administration->vCenter Server Settings->Statistics:
There are four statistics levels:
- Level 1: This level includes the basic metrics – Average Usage for CPU, Memory, Disk and Network; System Uptime, System Heartbeat and vSphere DRS metrics. Statistics for devices are not included at this level.
- Level 2: This level includes all metrics for CPU, Memory, Disk and Network counters (average, summation, and latest rollup types – maximum and minimum rollup types are excluded); System Uptime, System Heartbeat and vSphere DRS metrics. Statistics for devices are not included at this level.
- Level 3: This level includes all metrics (including devices) for all counter groups (average, summation and latest rollup types – maximum and minimum rollup types are excluded).
- Level 4: This level includes all metrics supported by vCenter Server.
As these settings are modified, the ‘Estimated space required’ will adjust, so the database can be properly sized.
When upgrading to vSphere 5.0, it is possible to simply upgrade datastores to VMFS5 without any downtime. It is an online and non-disruptive upgrade operation. However, there are some negatives to upgrading the datastores instead of deleting and re-creating, such as:
- VMFS-5 upgraded from VMFS-3 continues to use the previous file block size which may be larger than the unified 1MB file block size.
- VMFS-5 upgraded from VMFS-3 continues to use 64KB sub-blocks and not new 8K sub-blocks.
- VMFS-5 upgraded from VMFS-3 continues to have a file limit of 30720 rather than new file limit of > 100000 for newly created VMFS-5.
- VMFS-5 upgraded from VMFS-3 continues to use MBR (Master Boot Record) partition type; when the VMFS-5 volume is grown above 2TB, it automatically & seamlessly switches from MBR to GPT (GUID Partition Table) with no impact to the running VMs.
- VMFS-5 upgraded from VMFS-3 continue to have its partition starting on sector 128; newly created VMFS5 partitions will have their partition starting at sector 2048.
|From||To||Duration in minutes|
|FC datastore 1MB blocksize||FATA datastore 4MB blocksize||08:01|
|FATA datastore 4MB blocksize||FC datastore 1MB blocksize||12:49|
|FC datastore 4MB blocksize||FATA datastore 4MB blocksize||02:36|
|FATA datastore 4MB blocksize||FC datastore 4MB blocksize||02:24|
The latest version of the VMware View app has been released for both the iPad and Android. Several new documented changes in this version, as well as some other slight undocumented modifications. Here is the documented list:
- Optimized for VMware View 5 with improved performance
- Support for iOS 5 including AirPlay
- Presentation Mode for use with external display and AirPlay
- Embedded RSA soft token simplifies login to desktop
- Background tasking to move between Windows and iOS apps
- Updated look and feel
- Integrated online help
- Buffered text input for multibyte text entry
- Now in French, German, Japanese, Korean, Simplified Chinese
- Bug fixes
The three bolded are my top choices for best new features. It was a complete pain having to reconnect when switching between apps, and made me almost not want to even use it. I’m very happy to see that is now fixed.
The included online help is also a blessing as it gives novice users (which should be a large portion of the userbase of this app, if VDI is successful) a way to figure out how to maneuver and operate the application.
Lastly, Presentation Mode will be very handy for a lot of users.
Two of the undocumented features that I have noticed are:
- Passwords are no longer savable. You must authenticate every time you log in. Previously you could save the password to the iPad, but this was removed for security reasons.
- The screenshot of desktops used as icons for the specific Virtual Desktops is now blurred, which is likely for security reasons as well.
SAN HeadQuarters is a free tool for Equallogic arrays that allows for centralized monitoring, logging, alerting ,reporting, and analysis across multiple Equallogic Groups. While the default alerts are usual sufficient, there may be times when it is a little too verbose. One hypothetical situation is if a vendor sets up the array and configures it in a manner that SAN HQ would typically send a warning for, e.g. allocating more than 95% of the array. While it would be best to resolve the issue, circumstances may not allow for that, so one would want to stop sending warnings for that issue. To do that, we can go into SAN HQ and then:
- Select Settings -> Email Settings
- Change to the Notifications Tab
- Select the Group
- Uncheck ‘Enabled’ for the message to ignore
I ran into this error when upgrading one of our hosts to ESXi 5.0 from 4.1u1 via format and re-install. Everything joined back normally, I was able to vMotion machines back onto the new host, etc.; however, once I tried to open the console I was greeted with: Unable to connect to the MKS: The remote host certificate has these problems: *unable to get local issuer certificate * Host name does not match the DNS name in certificate.
After some tinkering (and googling to no avail), my solution was to reboot the host, remove the host from vCenter, and then re-add the host back. I believe the issue was compounded by a couple of unique issues, but I’ll spare the boring details on reproducing. Simple fix, but since I wasn’t able to find a solution when googling the error message, I figured it would be worth tossing this blog post up to hopefully expedite someone else’s troubleshooting.
Update (8/23/12): A reader sent me an email saying they ran into the issue due to the following as well: “In my case in turned out to be a local hosts file had an entry for one of the esxi hosts that was pointing at the wrong IP.”