A glimpse of things to come? … PCoIP at 30,000 feet
Feb 8th
I’ve got to tell you, I’m pretty darn excited right now. Why? I’m typing this to you from 30,000 feet on a Delta flight from Cincinnati to Las Vegas (for VMware Partner Exchange). And why is that so special? Because, as the title suggests, I’m typing this on my VDI image which resides hundreds of miles away and thousands of feet below me.
Delta has a fairly new service from gogo called “gogo inflight … wi-fi with wings.” This is my first time using the service because the past few flights I’ve taken, I’ve either not had the need to connect or the aircraft I happened to be on did not yet have the service. But this time I have some work to do (i.e. my next “confessions” article for VSM), so I figured I’d give it a whirl. And, being a gluten for punishment, I decided to see if I could push the limits of PCoIP. After a quick sign up form (gogo isn’t free) and firing off a VPN connection back to my home office, I launched the View client and crossed my fingers.
And I can tell you that I am thoroughly impressed! The Windows are snappy, flash is decent and low-end multimedia is adequate. I was watching a youtube.com video with full sound and, while the picture was a little blurry and sound/video sync was slightly off, it was totally watchable. And furthermore, it didn’t cripple my session. Not bad, considering my latency is between 150ms and 250ms, with an estimated average about 200ms.
Is this a glimpse of things to come? Right now it may seem pretty far fetched. After all, the process to connect to my desktop image was fairly painful. I had to …
- Boot into my local OS
- Connect to the gogo inflight wireless access point
- Launch my Firefox browser and walk through the gogo signup form
- Dig trough my briefcase for my wallet and pay for the service
- Fire off my OpenVPN client to my home VPN server
- Launch the VMware View Client
Not exactly what I’d call a seamless user experience. And I believe that conquering this experience – that is, the mobile user – will be the coup de grace for traditional desktop infrastructure. Until then, virtual desktop infrastructure will certainly happen in pockets, but massive, wide scale adoption will continue to elude us. So what has to happen here? In my mind, I see the following things need to happen …
True ubiquity of wireless Internet
This means two things. First, the Internet has to be everywhere at all times. I’m a true mobile user and I need to know that no matter where I am – whether it be on a puddle jumper, or in a remote country hotel – that when I power on my laptop, I will have access.
And second, this also means the connection to the Internet has to be completely integrated and transparent. I don’t want to have to dig for my credit card every time. But even more than that, I want the connection to happen for me automatically, in the background, as part of the boot processes. My software client should auto detect the available wireless networks, connect, and debit my account. Will I have a single unified account that works across all providers? Or will I have multiple accounts that my software client will handle? Or will it be a single, wireless / satellite provider that can reach me anytime, anywhere? I don’t know and I don’t really care. The point is, I don’t want to deal with it. I want to press power and, after a short boot (maybe even zero boot?), have access. Period.
A purpose built Thin OS
Booting into a local OS just to launch a client and connect to a remote OS just isn’t going to cut it. The boot process needs to be fast and do nothing more than present me with a login GUI. If I’m remote, the VPN connection (and any necessary login parameters) need to be part of the login process. There’s no need for a full blown local OS if our goal is to do little more than connect to our primary desktop environment. Sure, us hardcore tech weenies will almost always want some sort of backdoor access to the local OS. But for 99% of the users out there, they don’t care and just want a seamless desktop experience. In fact, if done correctly, they shouldn’t even know there is a local OS and their desktop is actually running in a remote datacenter.
Does this actually exist yet? Sort of. ThinClients typically deliver this kind of user experience. But for the most part, ThinClients aren’t mobile devices. I’ve seen a ThinClient laptop model before, but I don’t know a single person actually using one. I’ve actually seen for more cases of customers converting PCs and laptops to ThinClients. Theron Conrey gives us a great example with his blog post VMware View Linux Live CD How-to. And there are enterprise solutions for converting PCs to ThinClients from both Wyse and DevonIT. So, we’re pretty darn close on this front, but still not 100%.
A rich user experience in low bandwidth, high latency environments
Like I stated earlier, my current PCoIP experience is pretty darn impressive. It is, by far, the best experience I’ve witnessed to a remote desktop. But, I’m not sure the average in-flight user would be ecstatic about it. Sure, all things considered, you can’t beat it. But I recognize all the variables working against me right now. The typical user will not know or even care. They just want it to work. The good news is that PCoIP will continue to improve and brings the promise of delivering a rich user experience, whether at 30k feet of a single switch port away.
So, I ask again, is this a true glimpse of the not-too-distant future? Ten years ago, I was the only one of my friends and family to have a cell phone. Five years ago, mainstream virtualization in the datacenter was laughed at. And a few short months ago, typing this blog post on my VMware View image was impossible. So, you tell me.
VMware pvSCSI – When and when not to use it
Feb 5th
Introduction
Hopefully you have read my previous blog posts on pvSCSI. It describes what the driver is, how it works, and how it can positively impact your performance and workloads. Part two covers the process of installing the pvSCSI driver on an existing system and a new system. Both can be found here on the site and you might find them useful:
http://www.virtualinsanity.com/index.php/2009/11/21/more-bang-for-your-buck-with-pvscsi-part-1/
http://www.virtualinsanity.com/index.php/2009/12/01/more-bang-for-your-buck-with-pvscsi-part-2/
Interrupt Coalescing
VMware recently published a KB article that answers a question that has been floating around the community for a while. The pvSCSI driver sounds superior to the LSI driver with direct I/O access to the hypervisor so why not use it in all cases? The article states that you should only use the newer driver when driving higher workloads, those that are typically 2000 IOPS or greater. For those that don’t know 2000 IOPS is a pretty big workload. Consider this, a standard fiber channel 10,000 RPM drive averages around 125 IOPS per disk.
I didn’t really understand this and the knowledge base article is lacking any detail on the rational behind the statement. I reached out to VMware performance engineer Scott Drummonds to see if he had anything he could publish to help clarify the KB article. Scott was nice enough to research this and posted his findings here.
So it appears that the technical explanation is interrupt coalescing or buffering. The paravirtual SCSI driver was designed to handle receiving multiple requests at a high rate and then “batching” the requests together for better efficiencies in throughput. If you aren’t generating high enough workloads on the virtual machine, the I/O request could unnecessarily sit in the queue while the “batch" waits to be filled up for the next transaction. This could cause storage performance problems which would typically be seen as higher latency and would negatively impact the virtual machine.
Now and Then
The great news is the current release of the driver is optimized for heavy workloads. If you are starting to virtualize SQL/Oracle systems and need the performance, go for the pvSCSI driver and get better throughput. If your deploying standard virtual machines that are doing lower workloads, continue to embrace the existing LSI Logic driver.
If you are new to vSphere 4, or have just upgraded from 3.5 and are starting to rebuild your templates to embrace virtual hardware version 7, don’t use the pvSCSI driver as part of your standard template. VMware is working on the driver and will be introducing advanced coalescing functionality. When this is built into the driver stack pvSCSI will then be able to be utilized for all workloads as it will understand when it needs to ramp up for higher workloads.
Thanks again to Scott Drummonds for taking the time out of his busy schedule to track this one down.
VMware Windows Perfmon counters missing in vSphere 4u1
Jan 31st
I am attempting to pull together a blog post around performance, it’s going to be a four part segment on each I/O component of VMware, CPU, Memory, Storage and Networking. My goal is to try and cover the various tools that you can use to help troubleshoot performance problems that you might experience in your virtual environment.
While I was going through some of the methods, I wanted to illustrate how VMware now includes Windows Performance Counters inside a guest virtual machine to assist with performance monitoring/troubleshooting. I jumped on a test virtual machine I have, and pulled up Windows perfmon. To my dismay the VMware counters are missing! We are currently running VMware vSphere 4.0 update 1 so I checked with a few other people online like Rick Vanover (@RickVanover). It confirmed it seemed to be related to this specific release of vSphere.
I reached out to Scott Drummonds via Twitter (@drummonds), a performance systems engineer who works for VMware, and also opened a service request with support. Scott validated that he saw the same issue and was launching an investigation. Unfortunately the SR didn’t get very far as I was instructed that this was an “experimental feature and was removed from vSphere”. Uhhh ok, I knew that wasn’t right so I waited to hear back from Scott.
Scott has since written a blog post that discusses this issue. It looks like a complete uninstall of the VMware tools on the client followed by a re-install resolves the issue. This does require a reboot for those that are not familiar with this process. The problem appears to be related to mofcomp which it a tool that Microsoft provides and registers WMI information (such as VMware performance counters) with Windows.
Thanks to Scott for jumping on this so quickly and posting a fix to the issue, it’s great to see social media paying off in the real world. Thanks to Rick for helping me figure out what was going on and validating some of my assumptions. Rick has also written up an excellent blog post on this same issue. Hopefully a patch will be rolled into the next minor release of vSphere 4 that will resolve this bug going forward.
VMware Virtual Center Attributes – It’s all about the details
Jan 28th
Overview
A fellow engineer extraordinaire (Mike Evans) inspired me to write up this blog post. Mike and I have been using the “notes” attribute for virtual machines for a few years. It has come in very handy to track who requested the virtual machine resource, and the date the virtual machine was provisioned. If your not familiar with the notes field, it’s at the bottom of the summary page of a virtual machine properties page.
This little piece of information might seem trivial to the layperson but the larger your virtual environment grows, the more complex it becomes. Having a way to track this fluid, ever changing infrastructure becomes more and more important as your begin to scale up and out.
Attributes
The “Notes” field was great for us except that we began to notice the variations of details that we had entered into each virtual machines properties. Not probably a huge deal if you have a small VMware environment but when you start tracking several hundreds of virtual machines, it really starts having an affect on reporting. A newer feature that was added to Virtual Center was the ability to use attributes, or pre-defined fields that can be populated. This gives a VMware administrator the ability to have a common format for reporting on Virtual Infrastructure. Below is a screen shot of the Custom Attributes you can find in Virtual Center:
Notice there are three different categories I have displayed in this view, Global, Host, and Virtual Machine. You can set attributes at multiple places in your VI environment that you wish to track. You can see we are interested in Virtual Machines attributes for certain variables (Owner, Provision Date, Provisioned By, Purpose). We have a different interest at the host level (Build Date) for maintenance tracking purposes of physical hardware assets.
Reporting
Here is where all your hard work starts to pay off.
It’s audit time, you are tasked with trimming the fat in your environment because once again you are out of capacity, and the budget just got crushed for the rest of the year because “Insert your reason here” the UPS batteries just exploded! Go into Virtual Center and generate a report of your virtual infrastructure so you can get a report of who owns what, and what date it was deployed. Go to your Virtual Machine view, select your datacenter, go to the menu option “Export” and then select “Export List”. Save the export as a Excel Spreadsheet, and view your results. Notice the highlighted columns K through N, these are the custom attributes that we added above.
Conclusion
Virtual Center custom attributes are a great way to help manage your growing environment. Sit down with your team, or your potential customer and find out what values matter most in your environment. Create the custom attributed at the various places in Virtual Center. Make sure you are diligent about filling out the details when you bring up new systems and make it part of your internal process and documentation. You will thank yourself down the road.
VMware Data Recovery (vDR) Overview
Jan 22nd
Overview
I like to try and save my employer money when possible. I am of the opinion I would be doing them a disservice if I didn’t examine and evaluate a product that we paid for. Our company decided to take the plunge and upgrade all of our licensing to vSphere Enterprise Plus. There is a new backup/data protection product that was introduced with this recent release. Here is the technical definition of VMware Data Recovery from the administration guide:
VMware® Data Recovery creates backups of virtual machines without interrupting their use or the data and services they provide. Data Recovery manages existing backups, removing backups as they become older. It
also supports deduplication to remove redundant data.Data Recovery is built on the VMware vStorage API for Data Protection. It is integrated with VMware vCenter Server, allowing you to centralize the scheduling of backup jobs. Integration with vCenter Server also enables virtual machines to be backed up, even when they are moved using VMware VMotion™ or VMware
Distributed Resource Scheduler (DRS).
Sounds pretty good right? You get a backup application (with de-dup!) that could possibly displace your primary method of backups built specifically for VMware? I did a little digging in the community and was disappointed to learn that vDR is not exactly an enterprise product. A lot of the feedback from other VMware engineers was “it’s a 1.0 product and is designed for a small installations”. The maximum supported virtual machine backup configuration is 100 virtual machines.
I decide to check it out for myself and see if it was a fit for our environment and might possibly alleviate some of our backup problems. Our primary site is rather large, but we are now implementing vSphere at our smaller satellite locations and this might be a fit for a smaller office configuration.
Installation
The installation was quite easy, VMware has provided another great virtual appliance that can be downloaded from their website. After you import the virtual appliance via Virtual center and assign the host a static IP address, you then need to install the VC plug-in so you can manage your newly installed appliance.
After I ran through the installation and configuration I was disappointed to discover that I couldn’t get VDR to launch. I kept getting prompted for authentication credentials which was odd. I thought maybe I had incorrectly set something up so I went back and reviewed the administration guide. Upon closer examination (RTFM) I discovered that vDR doesn’t support Virtual Center running in linked mode. To my dismay, we are running in a VC linked mode in anticipation of a Site Recovery Manager implementation. Our remote sites are managed by our primary site Virtual Center to save costs. I discovered a work around by pointing the VC client to the ESX server that is managing the vDR appliance. This would only give me access to backup other virtual machines hosted on the same ESX host so I could continue my testing. I hope this is something that future versions of the product will address and fix.
The Console
Once you launch the vDR console, you are immediately prompted by a configuration wizard to begin setting up your environment. Here are the following steps in the order they are presented:
- Select your Virtual Machines to backup.
- Select your destination (CIFS share, attached vmdk, or RDM).
- Select your backup window.
- Select your retention policy.
All of these are straight forward and don’t require much discussion. The only step I found a little confusing was the retention policy. Personally I would have preferred something a little more technical than “Few/More/Many”.
The retention Policy radio buttons are pre-defined settings and will change the policy details below. Change the buttons and you can see the variables change and what each setting will mean in terms of your destination data storage. Use caution here as each vDR appliance can only support up to 1TB in data store size, with a maximum of two stores.
The Backup
The underlying backup technology behind vDR is the new vStorage API (Not VCB), it takes advantage of a new feature called change block tracking. After the first full backup is performed, Change block tracking examines the virtual disk being backed up and only backs up the differences from the first backup. This means less backup traffic going across your network.
I selected a CIFS/Windows share at our disaster recovery site to perform the backup testing. The test share was a ~600GB, 5+1 (10K) of locally attached SCSI storage on a HP DL380. I selected a couple of Windows virtual machines to test with and kicked off the backup jobs. Below is a screenshot of the reporting window for vDR (sorry for all the censorship).
The jobs seemed to run pretty slow in general, but completed successfully without errors (the error listed above is because of my linked virtual center configuration). In my opinion the reporting interface is lacking some details. I would have liked to have seen what throughput I was getting during the backups. The only way I could see the throughput was by monitoring the windows host that was housing the data store. I would have liked a more detailed task status, so I could tell what was going on through out the backup operation. Data de-duplication ratio would have been another great detail to see. This could help determine the total backup and estimated completion time of each virtual machine, which is another variable I found to be missing.
The Restore
There are two approaches to restoring data using vDR, the first method is a full system restore. This method will recover the entire virtual machine, system state and all corresponding data. When performing a full system restore you can restore the data to an alternate esx host, data store, and decide if you wish the network interface connected or not. I even found that you can change the virtual disk node, and select an alternate SCSI path to recover your disk path too.
The second option is a file level restore (FLR), which typically most people would tend use on a more regular basis. Unfortunately the vDR console can’t recover individual files without some additional configuration. You need to install “VMwareRestoreClient.exe” executable on a virtual machine, which then will give you the ability to browse your data store contents and select individual files to recover. I anticipate that we will see the FLR components get rolled into the vDR console in a future release.
Conclusion
VMware Data Recovery lacks a lot of critical pieces that an enterprise backup application should and needs to provide. The product is a great start for smaller VMware implementations, but even at that I could see it quickly being outgrown. Here are the areas I would love to see improved on in future releases of the product:
- Need support for linked Virtual Center’s. Personally I could use this product at some of our smaller locations but can’t leverage vDR since we are running in a linked mode.
- Need to support larger capacity of virtual machines. 100 virtual machines is not enough, the product needs to scale to support a larger VMware implementation (not necessarily Enterprise).
- Need support for larger data stores. 1TB is not a lot of space when you are going to be backing multiple virtual machines up and retaining their data for longer periods of time.
- Need support for more data stores per vDR appliance. Again this goes back to scale, storage growth is exponential in our current environment.
- Support for a global vDR manager. I would love to see VMware develop a central master or parent vDR console that would allow you to manage your children appliances, and the data stores that they manage.
- Single console for both full system restores and file level restores.
VMware Data Recovery comes with all versions of VMware vSphere except for vSphere standard. This is a great entry level backup solution with de-duplication included. I am excited to see the product develop into a more mature product that can scale with some bigger environments. I also feel that including vDR in the standard version of vSphere would only help the SMB market embrace virtualization at a higher adoption rate.
VMware vSphere Capacity IQ Overview – I’m Impressed!
Jan 11th
With the launch of VMware vSphere came some new products that I hadn’t really paid much attention to (busy upgrading I guess). One of the newer products is a Virtual Center reporting tool called Capacity IQ. This product gives an administrator the ability to analyze, forecast and plan for future growth across your ESX environment. I have had a lot of experience with monitoring/reporting tools in the past, I won’t bore you with the details, so I was quite skeptical of a 1.0 reporting tool for Virtual Center. I must admit I was blown away by the immediate relevant reports the product was able to produce.
After pulling down the trial install and obtaining the demo key, I loaded it up for a spin. I am not going to document the installation steps needed as Eric Gray has done this for us already. It by far is the easiest reporting application I have ever installed. If your interested in taking it for a trial run, download the virtual appliance from VMware’s website here (OVF format). Once you import the virtual appliance and give it a static IP address, it will need to collect data about your environment for a while.
There are three basic views that CIQ gives you once you install the plug-in, dashboard, views and reports.
Dashboard
The dashboard tab is designed to give you a quick overview of the item you have selected. Capacity IQ uses the same approach as virtual center does, whatever object you have selected will be reported and focused on. Here is a view of one of our clusters, notice January 11th on the Trend and Forecast graph on top.
One of our clusters was out of resources, I added two more physical hosts to the cluster. You can see CIQ picks up the new physical host resources for the cluster and reflects this by increasing the number of virtual machines it believes the cluster can accommodate. Want to see something even more interesting, check out the pink graph on the 17th. Capacity IQ is already using a prebuilt formula to assume what it thinks we will have (or won’t have) a week out. Pretty impressive.
Views
The views tab is designed to give you a more detailed look on some of the specific data points. Here is a screenshot of the various reports you can execute:
So here is where you can get some great visual reports to present to either upper management, or a potential customer. This gives you a nice interface that you can customize with data points that you can tweak. Check out the first report on this cluster:
This gives you a graphical historical view of your cluster, how many virtual machines you have added over the course of time. Notice the horizontal sliding bar at the bottom of the chart. This allows you to adjust your variable time/date window. The lighter shaded line to the right is the projected or forecasted growth of how the cluster might continue to grow. The views tab is a great place to run some ad-hoc reports, gives you the ability to select the type of report, and even allows you to export the data.
Reports
The reports tab is the “pre-canned” reports that can be executed by the administrator. The one thing I was disappointed to not see here was the ability to schedule these reports to run at a particular interval (weekly/monthly). This is something that I assume will probably be introduced in future releases of the product.
After the report is executed and compiled, you are then provided with a .pdf or .csv version of your dataset to download and review. The first report totaled 17 pages and provided some great technical information. Here is the table of contents:
Conclusion
I am very impressed with Capacity IQ. There are no agents you need to install across the virtual machines you wish to report against. The installation was very straight forward, I think I had it up and running in about 15 minutes. Once the virtual appliance was in place, all it needed was a little bit of time to start crunching some data. The reports are well written and very relevant to what an administrator would desire and wish to see. If your looking for a nice reporting tool to help you forecast, give this one a test to see if it fits your needs.
Mass upgrade of VMware Tools in Linux guests
Jan 7th
Installing and/or upgrading VMware tools has always been a bit more complicated for Linux guests than for Windows guests. After the installation of the package binaries, the vmware-config-tools.pl script must be run to configure the tools for your environment. This script has to be run from the console, which is a pain when you’ve got more then just one or two Linux VMs. And may the good Lord help you if the modules aren’t suitable for your running kernel and you don’t have a compiler (or the C header files for your running kernel) already installed.
When VMware added the Automatic Tools Upgrade …
The situation certainly improved, but it is by no means a fool proof solution. In my experience, it doesn’t work 100% of the time for Linux guests (though this *could* be due to the heavy modification I’ve done in my distro). And furthermore, what if you want to automatically upgrade 100’s of Linux guests, not just one? Or what if you’ve already got a deployment tool that you’d like to use to push the tools out? (Kind of tough when the script needs to be run directly in the console)
So, I looked to see if there was a way to improve the situation. First, I needed to find a way to run vmware-config-tools.pl remotely in an automated fashion. And by the way, it’s not that you can’t run this script remotely via SSH because you can. The problem is that when you do so, you immediately get following question …
It looks like you are trying to run this program in a remote session. This program will temporarily shut down your network connection, so you should only run it from a local console session. Are you SURE you want to continue?
Unfortunately, to run vmware-config-tools.pl remotely, we need to include the –d flag so that the script will automatically select the default answers to all of the questions for us. And the problem is, the default answer to this question is “no.”
So I looked through the vmware-config-tools.pl and I found that it’s really only checking to see if the SSH_CONNECTION environment variable is set. Well, that’s easy … simply executing vmware-config-tools.pl in a different shell allows us to side step this.
Next I just created a simple bash script that gets pushed out to the /tmp directory along with the vmware tools installation package (also pushed to the /tmp directory) and gets executed remotely by my deployment tools (which for me are are just more bash scripts, but this should work with any enterprise deployment tool). Here’s the simple script I used for my guests …
#!/bin/bash
RPM=`ls /tmp | grep VMwareTools`
rpm -e VMwareTools
echo "Old VMwareTools removed" > /tmp/vmware_tools_upgrade.logrpm -i /tmp/$RPM
echo "$RPM installed" > /tmp/vmware_tools_upgrade.logsh -l root -c /usr/bin/vmware-config-tools.pl -d
echo "vmware-config-tools.pl -d executed" >> /tmp/vmware_tools_upgrade.logservice vmware-tools restart
echo "vmware-tools restarted" >> /tmp/vmware_tools_upgrade.logservice network restart
echo "network restarted" >> /tmp/vmware_tools_upgrade.logexit
This is obviously a very basic script and could easily be enhanced with better logging and error handling. Also, for Debian distros, such as Ubuntu, you’d need to modify this script to handle the tar.gz installation package … unless, of course, you’ve modified your distro to handle RPMs (as I have).
The good news is that, at least for my environment:
- This works 100% of the time and a restart of the VMs is not necessary.
- I no longer have to upgrade many guests by hand.
However keep in mind, there is still a network outage during the upgrade (usually just about a minute or two), so be sure to continue using a maintenance window for your upgrades.
vSphere 4 Update 1 with Update Manager Shenanigans
Jan 4th
Happy New Year! I hope everyone enjoyed the holiday’s and got to spend some time with friends and family. If your reading this I suggest you pay tribute to the quality of Virtual Insanity, and give the gift of voting. Eric Siebert has released a “best of 2009 blog contest”. If Virtual Insanity has helped you out in some way in the past I suggest casting a vote for this great virtualization blog space! Ok onto the real reason for this post…
I ran into an oddity while bringing a new host online today into our vSphere environment. And thought it best to publish my findings. Hopefully this might save someone a support call. With vSphere 4 update 1 came a couple of technical issues, which are detailed here and here. Personally we don’t use ESXi so only the first one was a major issue for us. We are an HP shop, so the issue around the HP agents and update 1 was a major concern (basically would render the host unbootable). Luckily VMware support is proactive about announcing issues like this to the community and most people were aware of the problem right away.
The problem I hit today was strange and I thought it was just being off from work for a week. I went to apply our update 1 baseline to a new host I was bringing up, rescanned, and then got this:
What the? I know this isn’t compliant, our base build is still at 4.0 Check out the build number, that’s proof. I have used the update 1 baseline for 50+ hosts so I know it’s not that. So maybe update manager is still on holiday as well, I restart the service and life is good? Nope. Same thing.
To make a long story longer, I poke around in the repository and check the update 1 patch and see it’s valid, yep 11/19/09 that’s the right release date. Why is this thing not working?
I kept poking and prodding thinking maybe they released an update to the update? Sure enough it slipped by me when I wasn’t looking, or it went to my spam mail. Check the date 12/9/09.
I created a new test baseline, and dropped the 12/9/09 update 1 into it and applied it to my new host. Low and behold:
That’s much better. Strange the older update 1 patch didn’t reflect anything and showed compliant. As an end user I would have liked to have seen some type of error message, or a reference to the newer released update 1. Ran the new update, (still stopped the HP agents just in case). And now things look good again (build number):
Conclusion
Go vote for this site, and make sure you update your update manager, update 1 baseline. That’s a lot of updates. See you online!
Scott
A handy new addition to the Command Line Tool for View 4
Dec 8th
First things first
Thanks to Scott Sauer (@ssauer) and John Blessing (@vTrooper) for holding down the fort here at Virtual Insanity while I’ve been finishing up some unfinished projects and preparing for the VCDX Design Exam (which I take later this month). One of Scott’s posts actually won a vSphere blog contest. Nice work Scott! These two guys are becoming pretty good friends of mine here in the Cincinnati area, so hopefully I can convince them to keep the content flowin’.
An itch I couldn’t scratch
I’ve mentioned here on this blog, at least once or twice, that I “eat the dog food” and actually run my primary XP desktop as a VMware View image. Since the conversion almost a year ago, everything has been running pretty well with only a few minor bumps along the way. And with the recent addition of PCoIP, I can’t imaging ever going back.
But there was one little reoccurring problem I was having for which I couldn’t seem to find an answer. It wasn’t a show stopper of an issue, but it was just an “itch I couldn’t scratch,” if you know what I mean. And the problem went something like this …
- Inside my desktop VM I have a Cisco VPN client, necessary for a secure connection back to corporate HQ in Palo Alto, CA.
- When connecting to my desktop with the VPN client inside the VM inactive, I had no issue.
- However, if I disconnect from my desktop while the VPN session was active, then I couldn’t reconnect to my desktop via VMware View.
The reason? The broker was sending me the new IP address of the Cisco VPN Adapter, which is an IP address on the VPN, and an IP address my local computer didn’t know about.
Now, if I were to log off instead of disconnect from my desktop, this would terminate the VPN session and therefore wouldn’t be a problem. But who wants to log off every time? More often than not, I have things open on my desktop (e.g. half written emails, documents, browsers with many many open tabs, etc.) that I don’t want to bother saving and closing every time I step away from the computer. And really the bigger issue is with unintentional disconnects that result from local power/network/OS issues.
I tried all sorts of things to fix this. Among other thins, I tried …
- Reordering the NICs, hoping the broker was just grabbing the first NIC.
- Poking around the broker and agent install files, hoping to find a way to force the IP address.
- I even tried uninstalling and reinstalling the View agent and the Cisco client, hoping the order of installation might do the trick (admittedly, this was a random shot in the dark)
But nothing seemed to work. So until recently, to reconnect I would have to connect directly to my desktop via RDP, or connect to the console via the VMware Infrastructure Client, then disconnect the Cisco VPN and then reconnect via the View client.
See what I mean? Not a show stopper, but man what a pain in the butt!
The solution
Well I found a way around this with a handy new addition to the Command Line Tool in View4. Check out page 12 of the Command Line Tool for View Manager titled “Override IP Address.” On the broker from a DOS prompt, in the c:\Program Files\VMware\VMware View\Server\bin directory, execute the following …
vdmadmin.exe –A –d <desktop name> –m <machine name> –override –i hostname
The “desktop name” is the name of the VM in the broker. The “machine name” is the name of the VM in vCenter. It’s likely they’ll be the same, but they don’t have to be and in fact, in my case they weren’t the same. The “hostname” can be either a FQDN or an IP address. Oh, and I can tell you that all parameters must be present or the command won’t execute.
But that was all there was too it. Now I can disconnect and reconnect to my desktop, regardless of the state of my VPN client.
More Bang for your Buck with PVSCSI (Part 2)
Dec 1st
Part 2 Doing the work
As you might have noticed, this blog post is a continuation to my first post about PVSCSI, you can access Part 1 here.
Hopefully now you have a better understanding of what the Paravirtual SCSI driver is all about, and we can prove there are tangible reasons to move in this direction. Let’s get on with the important part, the implementation phase.
(I need to finish off this blog post, I am running out of pictures of SCSI cables)
There are some caveats I need to start out with. In case you missed it, PVSCSI drivers on virtual machines aren’t supported on operating system disks unless you are running vSphere 4 update 1. You can use the driver on a secondary data disk if you so desire, but for this post I am going to assume you are running vSphere 4 update 1 (Virtual Center and ESX Hosts) and want to know how to get the driver working on all disks.
In most cases, it’s always easier to build new. You know you have a clean install, the drivers are updated, the configuration is solid. I would suggest updating your templates to include the new paravirtual scsi driver. Your existing virtual machines run fine with their existing configurations, and depending on your environment, it might be a lot of work to go back and target all of your virtual machines. For an upgrade path, my personal opinion would be to target your heavy I/O virtual machines. Upgrade the VM’s that will make a difference, and you will see some immediate benefits. Reducing the I/O on the disk subsystem will only benefit the other virtual machines that might share those same physical disk spindles.
Clean install
This section will walk you through the process of installing the driver with a Microsoft Windows 2003/2008 operating system. Currently these two operating systems are the only ones supported. Hopefully we will see some added support for the various Linux operating systems down the road.
Walk through the “New virtual machine Wizard” as you normally would. On step 9, ensure you select the “VMware Paravirtual” option as seen below.
Before powering your new VM up, you need to connect the virtual floppy image file that has the driver for your desired guest operating system. This is not on the VMware.com website under downloads, it already exists on your ESX host. You will need to browse to the following location on your ESX host. [Datastores]\vmimages\floppies I would wait to connect your floppy disk image after you boot off the Windows CD-ROM so it doesn’t try to boot off the floppy drive.
When you power up your new virtual machine, select the F6 option to tell the operating system you need to use a third party SCSI driver:
Now connect your floppy disk image to your virtual machine under the “edit settings” option. You should now be able to point to operating system to the driver as seen below:
Continue on with your normal installation, and you are complete. Your new virtual machine is now utilizing the Paravirtual SCSI drivers. I suggest now converting this image you created to a template for future deployments with this configuration.
Upgrading and Existing Virtual Machine
To upgrade an existing virtual machine, the process is pretty straight forward. Assuming you have already upgraded to the latest virtual hardware (Version 7), make sure your VMtools are upgraded post Update 1. Shut down the VM, and edit the settings “Change Type” as shown below:
You will get another window that will alllow you to change the type of controller as seen below:
Select the “VMware Paravirtual” and then select ok. Boot up your virtual machine and you are all set. Your system is now running with the updated drivers and you can take advantage of the newer drivers that provide better throughput and less latency!
Hope you found this post useful. Good luck!
Scott