Unwilling to cede the market to VMware, Virtual Iron is getting in to the VDI (virtual desktop infrastructure ) game by partnering with Provision Networks, maker of Virtual Access Suite (VAS) connection broker software.
The problem with traditional fat clients that Virtual Iron and Provision are trying to eliminate are numerous: they consume a lot of power, they’re a security and regulatory problem, and “they’re an absolute nightmare to administer,” said Mike Grandinetti, chief marketing officer at Virtual Iron. Server-based hosted desktops, however, suffer from none of those problems, and benefit from additional high availability features. “We’re believers that [VDI] could absolutely take a large and rapidly growing server virtualization market and take it to a different level,” Grandinetti said.
As is often the case with Virtual Iron announcements, the announcement centers heavily on price. Rather than price per node, Virtual Iron and Provision are opting to charge $120 per desktop. That compares quite favorably with VDI prices offered by VMware and Hewlett-Packard, which don’t include a connection broker. Compared with traditional desktops, meanwhile, a Virtual Iron/Provision VDI bundle has a total cost of ownership of less than half, according to Gartner data.
Grandinetti claims the two companies are working with several “proof of concepts” with companies whose total desktops number in the tens of thousands.
The big news today is that the Hypervisor for Windows Server Longhorn (codenamed Viridian) is being delayed. See the Windows Server Division Blog for the main details. On the surface it seems like this is bad news. Many of us would like to move to the new Hypervisor ASAP. From a strategic standpoint, I think it’s most important for Microsoft to ship a rock-solid first version of the Longhorn Server Hypervisor. So is Microsoft doing the right thing?
When I first heard about the goals for Viridian (which were then pretty closely guarded), I thought that this “feature” was enough to warrant a new release the Windows Server platform (post-Longhorn Server). At the very least, it could have commanded a “Virtualization Edition” of the product. It’s no small architectural task to provide for the dynamic addition of hardware, support for large parallel processing, dozens of VMs, etc. Goals include the ability to easily transition from at least Microsoft Virtual Server (and, perhaps, competing solutions – the names of which may or may not begin with the letters “V” or “X”). And, it’s a new product – this isn’t a rebranding of another platform.
Microsoft states that scalability (and related testing) is a major reason for the delays. Given that quality (measuring by reliability, stability, performance, etc.) is not up for compromise, I would have preferred to see Microsoft do a smaller initial release of the Hypervisor. Perhaps an initial “lite” version that focused on the architecture of the product would have been a better approach. While running on 64-CPU machines is definitely a plus, I’d rather have a more scaled-down version of the Hypervisor available earlier. That would allow for determining migration paths, better understanding capacity planning, and for performing initial testing. With that available, Microsoft could then focus on scalability to very large environments.
Regardless of the release timing, I think we’ll all eventually look back and say that Viridian was worth the wait. Until then, we’ll have to rely on the many first- and third-party products that are available today.
A couple of months ago at IDC’s Virtualization Forum in New York City, I chatted over lunch with Al Gillen, who posited that not only would Microsoft probably not be late with Viridian, code name for Windows Server Virtualization that will ship with Longhorn, but that Microsoft might actually be early! A pessimist by nature, I was skeptical.
Today, we learn once again what we all know all too well: that the best predictor of future performance is past performance. Like so many products before them, Microsoft announced today that they are pushing back the betas for not one, but two, of their virtualization offerings: Windows Server Virtualization and Virtual Server 2005 R2 SP1.
Now, Mike Neil, Microsoft’s GM for virtualization strategy, gave some pretty good excuses for the delays: 64-processor systems, I/O intensive workloads, new operating system support, etc. But the delays bring up all sorts of other questions. Is this in fact the last delay Viridian is going to face? If it does ship on time, will it include all the nifty features Microsoft has been touting? Will customers holding out for Microsoft finally give up and try out VMware or Xen? Is this delay really as bad for Microsoft virtualization as it seems to me?
You can read details of the delays here.
I found another blog post-worthy blog. Rightfully called “Documenting a virtualization project“, it’s pretty darn cool. Read about one company’s experience with virtualizing their servers from the start. Most recently, the author, (Martin?) reported that they company (which remains namelesS) has 75 servers virtualized at approximately a 20:1 ratio, and 25 servers to go. They seem to be doing a lot with VDI and VMware, so if that’s your forte I highly suggest becoming a frequent visitor to this blog (after ours, of course.)
Throughout the blog, he talks about migrating Oracle servers, their VDI project, their first production HA failover:
“A quite unexpected event yesterday was the very first HA failover in production.”
The day the Oracle servers froze:
“I shoudn’t be writing that all is well on the Oracle front.
“Just now two of the Oracle servers froze with database problems. The DBA tells me that they have had block corrupts which he hasn’t seen in five years of running the things.”
Then he goes on to blog about what they learned from the Oracle freeze:
“…memory settings turned out to be highly critical in relation to the performance of the VM.”
…I guess he should have been paying more attention to his SearchServerVirtualization.com Virtualization Advisor e-newsletters. 😉
I was surfing the virtualization blogs recently and came across a gem of a Webpage. Virtualization Daily has put together a virtualization bookstore of sorts — the books link to Amazon, but it’s a great way to get a fast glance at the books and decide what you want from there. Check out the book store here.
Robin Harris of StorageMojo has procured a VMware price list, adding to his extensive collection of storage products. You can find it at:
According to the Price List introduction, “These prices are discounted “street prices”, roughly what a corporate customer would pay.” It’s unclear to me who submitted these price lists, and how current they are, but they might be useful nevertheless.
The VirtualCenter2 management service (vpxd) is not very robust. If it cannot connect to the back-end database, the service will halt. It *should* continue to run, periodically trying to connect to the database, but this is not the case. There are also problems with the service coming up before the network when the server boots, causing the service to halt upon start. IPSec SA token mismatch/renewal issues also cause the service to halt. The vpxd service is very important — it manages DRS, collects performance statistics, and allows users to manage their VMs. This is a service that should be a lot more capable of handling foreseeable circumstances. To that end I have written a script that can be used to restart the vpxd service in case it halts or fails to start. This script can be linked to an often underutilized feature of Windows — the ability for the Service Control Manager (SCM) to restart a service upon failure.
The script is fairly basic. I will not post it in its entirety in this blog because its formatting will get munged by WordPress’ draconian style settings. You can download the script from www.lostcreations.com.
A description of the script can be found in the script’s source, “This script will attempt to start the vpxd service if it is not started. If the serivce is already started or it starts successfully the first time no further action is taken. This script can also be run upon a VCMS failure. It will notify a specified e-mail address of the failure. It will check the connection to the VCMS database. If the database connection is valid then the script will start the VCMS service. If the connection is not valid then the script will go into a loop, attempting to restart the VCMS service every specified number of minutes. This script assumes your VC database is on a SQL server. If it is not then please see www.carlprothman.net for a good reference on how to build an ADO connection string to fit your needs.”
In addition to using this script to correct a vpxd service failure, it can also be run as a scheduled task, set to run 5 minutes after the server boots. This can correct the problem of the vpxd service not starting successfully on boot because it comes up before the network is available.
I hope this script helps to make your VMware VirtualCenter2 Management Server a little more robust, and a lot more script-diddly-licious!
Last week, I wrote a story entitled Virtuozzo user avoids needless Windows Server licenses. Many of you wrote in to inform me that in fact, the Windows Server licenses that the subject had not purchased were in fact required under Microsoft licensing terms. In the words of one reader:
There is a lot of misinformation occurring specific to license reduction fees and Virtuozzo. I work for a Fortune 100 with an extremely strong VMware (ESX) presence and we too were initially enamored with the ability to reduce OS licensing fees.
Quite Simply – you need to pay for each virtualized (‘VPS’ in Virtuozzo speak) instance just like you would for separate Virtual Machines in the VMware World.
SWsoft used to tout that you only have to pay for the ‘parent’ Windows OS — that was until Microsoft gave them a ‘stern reprimand’. Today you will not find a single SWsoft employee or any verbiage on their site that indicates you only have to pay for one OS license.
The only exception to this is Microsoft Datacenter Edition. John Yanekian is in breach of license obligation with his current configuration if he has not licensed all of his VPS’s.
The story has since been updated and renamed. Thanks to everyone who pointed out this error.
Since I wrote the post, P2V wins and losses, I’ve been hearing from IT managers who’ve done the P2V deed. One migration was halted by a too-proactive IT guy. Here’s the story, but I’ll let the parties in question remain anonymous.
So, this company was moving from physical to virtual servers to reinstall its Oracle ODBC drivers and number of third party support applications. During the migration of one physical server, the process failed. Why? Says the IT manager:
“The first attempt failed because our support personnel noticed the server being replaced was down and rebooted it in the middle of the P2V process.”
After that, migrations went smoothly, and no more mistakes were make. However, performance issues arose when this particular server’s virtual machines server went into production. The IT manager explained:
“The original server had been a two-processor hyper-threaded system, and it was moved to a single processor VM. After adding a second virtual processor, it ran at an acceptable level.”
This company has done successful P2V migrations since then and plans to do more.
Here’s hoping your P2V moves are blooper-free. If they aren’t, share your goofs with us by commenting or emailing me at email@example.com. We can all learn from your bloopers and chuckle at the same time.
In my last post I showed you how to get all the available updates for an ESX 3.0.0 and 3.0.1 server. This post showcases a script that will generate the commands you need to run to update your server with the downloaded patches in the order that they were released. The script, newupdates, examines installed updates and ignored updates (via a file you specify) and generates esxupdate commands that can be used to update an ESX server in one fell swoop. This script can be downloaded from www.lostcreations.com.
Note: The ignored updates file is simply a file with a list of ESX patch numbers, IF or line delimited.
# require arguments or print usage
if [ “$1” == “” ]
echo “Usage: newupdates [-r REPOS_PARENT_PATH]
# get the options
while getopts r:i: o
do case “$o” in
[?]) echo “Usage: newupdates [-r REPOS_PARENT_PATH]
# get a list of installed updates
INSTALLED_UPDATES=`esxupdate query |
grep -io “ESX-[[:digit:]]*”`
# get a list of the updates in the parent repository path
# if the user defined an ignore file then read its contents
if [ -f “$IGNORE_FILE” ]
for R in $REPOS
# get the update/patch number from the repo
# directory name (strip the date prefix off)
UPDATE=`echo $R | sed “s/(.*-)(ESX-.*)/2/gi”`
# check to see if the update is already installed
echo “$INSTALLED_UPDATES” | grep -ioq “$UPDATE”
# if the user specified an ignore file, check
# to see if the update should be ignored
if [ -f “$IGNORE_FILE” ]
echo “$IGNORED_UPDATES” | grep -ioq “R$”
# generate an update command for the repo if it is neither
# installed or ignored
if [ “$R_INSTALLED” != “0” ] && [ “$R_IGNORED” != “0” ]
U_COMMAND=”esxupdate -nr file:$REPOS_PARENT_PATH/$R update”
# strip any double slashes out of the update command.
# the esxupdate utility barfs on them
U_COMMAND=`echo “$U_COMMAND” | sed “s//////gi”`