Andrew Kutz

Are offline desktops really that necessary?

I am sure by now that I am getting a reputation as a downer or naysayer at this VMworld, but as one of my colleagues pointed out, we look around and wonder how many of these products and features we see are simply solutions searching for problems. That said, I look at something like VMware View, a new product in their vClient initiative, designed to help offer offline desktop images, and I wonder, why?

Jan Stafford and I were discussing that fact that if we do not have access to the Internet we really can not do that much in the way of our jobs. She is a journalist and I am a programmer. She uses the ‘Net for research, and I use it for avoiding my job by way of YouTube :). VMware View is not the only product that promotes offline desktop use, take a look at any of the VDI solutions and four out of five of them will tout their ability to download the virtual desktop to your laptop for when you are out of the office. What does having your familiar environment provide you with, however, when you are no longer connected to the Internet?

There are three prevailing thoughts on the matter that I would like to discuss:

1. Offline desktops are a cure for network latency
2. Users demand a familiar environment
3. Offline desktops provide better application management

Curing Network Latency
The argument is that sometimes you do have an Internet connection, but it is not strong enough to access a remote desktop, so having an offline desktop will provide you with your familiar environment without the need for the fat pipe. An offline desktop, however, is not necessary to the result, as we shall see in a minute.

Familiar Environment
Users only think they need a familiar environment because they have never experienced any alternatives. What users really need is a way to access their information when they want to, how they want to, and in a secure fashion. I think offline virtual desktops are a little overkill for that (there are exceptions, for example, Windows on a Mac for a Visual Studio developer).

Better Application Management
No, no, no. Offline desktop images do not provide better application management. At that point I have to maintain an entire OS image to maintain a set of applications. Application virtualization software such as VMware’s ThinApp or InstallFree provide application management.

A Simpler Solution
As I said, offline desktops are a way to provide a way for users to access the information they want and how they want it, and in a secure fashion. Ultimately though I think that this is using an atom bomb to control the Alaskan wolf population when a single governor in a helicopter with a high powered rifle will do. I kid, I kid. But offline desktops are overkill. To me the solution is much simpler — synchronizing files and settings. Although Apple’s MobileMe has not had the best launch in the history of services, it certainly has the right intentions. I use it and it successfully keeps my files and preferences in sync across many computers. I don’t need the overhead of a local hypervisor to run my virtual image, I can access my files when I need to, how I need to, and securely. And perhaps most importantly I am not beholden to an OC-12 line. It’s a win-win.

Offline desktops… They’re a great idea, and they have their purpose. I just think people are using a wind tunnel to dry off their hair after a really long shower.

Virtual Desktops: Lose the Desktop Already!

Aside from all of the non-product announcements, the biggest disappointment to me so far has been the unsatisfied requirement with all virtual desktop platforms. From VMware Desktop Manager, to Desktone, to WebOS, I still need a desktop in order to first access my virtual or hosted desktop!

Now, the gentleman at the WebOS booth pointed out that we need to start separating the desktop and the OS, and I think that this is one of the most beautifully worded statements I’ve heard made about desktop evolution in the last 18 months. I plan to talk more about this later. However, what we cannot yet do is separate the desk from the desktop (at least not until Intel/AMD figure out how to put the RDP chip into our brains). In other words we have to have some type of device on our desk in order to provide networking, and KVM. The problem with this truth is that it means I still have to employ a desktop support team to manage what have effectively become dumb terminals.

But Andrew you say, why not just employ thin clients and remove all of that hassle? Won’t the problem be vanquished then? Perhaps, but thin clients tend to actually be a little on the cubby side. From what I have seen there is only one device on the market that can deservingly call itself a thin client — the Pano Logic Cube. The NASA engineers in Houston in the spring of 1970 had to pull of an amazing feat with the amount of power it takes to run a coffee maker. Pano Logic powers a thin client with 3 watts of power. The Hoston engineers would be proud.

VMware, Desktone, hear me. For you to impress me with VDI I want to see you acquire Pano Logic and offer an end-to-end solution for VDI. Provide the software and the desktop hardware. Create a virtual desktop solution and lose the desktop on my desk in the process.

VMworld 2008: Looking Back At Day 1

VMworld 2008 so far has been characterized by a few things:

• The smell of smoke, the crowds, the scented casino floors (Please take this convention back to the Bay!)
• The promises of features - I’m still looking for a feature announcement that is accompanied by an “Available now” announcement
• The absence of any real products - Most of the announcements are of features. While features are nice, I am still waiting for a product announcement that is not simply an umbrella view of several existing products or new features. Although, I will say that a VMware employee did give me a new perspective on this criticism. They said that one of the challenges of having so many products is that it is difficult to help people unfamiliar with their ecosystem understand how they all work together. Attaching a moniker such as “Virtual Data Center OS (VCD-OS)” gives new recruits a way to imagine how all of these separate products and features work together. I can get behind this idea — sort of. What is still lacking is a single management platform to tie all of these products together. When are we going to see a VI client that can manage Site Recovery Manager (SRM), Lab Manager (LM), ThinApp, and VMware Desktop Manager (VDM)?
• Devastatingly slow Internet speeds

Ultimately the first day was best summed up by the champion of VMware bloggers, John Troyer. I was sharing my thoughts with him and he made a pointed statement: VMworld 2008 is not about virtualization, it is not about the hypervisor; VMworld 2008 is about the ecosystem that VMware has created. What John means is that we are at a point in this field where the virtualization aspect is no longer important. We get it. We can virtualize. Now, what do we do with it?

I think this is great tact for VMware to take. This strategy essentially sets the bar for Microsoft and Citrix. The latter two companies are barely beginning to build their partner and software ecosystem, and VMware knows this. Being at the top of the hill means you get to set the rules for battle; you get to decide the area on which the skirmish will take place. And when strategizing for war you play to your strengths and the enemies’ weaknesses. This is exactly what VMware has done. By making the ecosystem the battlefield they have guaranteed themselves an competitive advantage for virtualization round three.

VDC-OS: Deja Vu?

I’ve been thinking about VDC-OS all morning, trying to figure out that nagging feeling in the back of my mind. Something feels so familiar about this new, seemingly fantastic, initiative from VMware. And then it hit me — VDC-OS is an initiative! IT professionals expecting an off-the-shelf software-in-a-box solution from VDC-OS will be disappointed. VDC-OS is made up of several components, all of which will, I am sure, have their own sets of individual highlights and disappointments.

Now there is nothing wrong with initiative. I applaud VMware for putting their weight, money and research behind the idea of a data center OS founded upon virtualization technology. This tact, however, has an all-too-familiar feel from VMware. Take VMware Consolidated Backup (VCB) or VMware Desktop Initiative (VDI) — both of these “technologies” were actually a lot closer to initiatives. I remember when I first heard of each, and I could not wait to get my hands on them. As it turns out, VCB was not the end-to-end backup solution that everyone expected it to be and VDI was little more than a partner program.

VMware recognizes that IT professionals like myself are getting a little tired of being sold initiatives instead of actual products. On their own website, out of the gate, VMware answers the charge that the Cloud vServices initiative is not simply a way to sell its customers on VMware partners. We’ll see if they live up to this promise.

One of the reasons that VI has been so successful is that it is a boxed product. It installs, you run it, and it does its thing. Software ecosystems are a harder sell, and even harder to manage. VCB and VDI have certainly not had the reception that VMware has likely hoped for. I for one am looking forward to the technologies included under the VDC-OS umbrella, so I am keeping my fingers crossed that it is not deja vu.

VMware expands education opportunities with GoVirtual.org

In the past, young men seeking their fortunes were often told “Go West, young man.” The West was pregnant with opportunity for those willing to seek it. Now VMware is offering young men and women at universities another opportunity — the opportunity to go virtual. In response to the growing number of academic institutions leveraging VMware technologies, VMware has created GoVirtual.org. The purpose of GoVirtual.org is to help professors and students in higher education learn how to teach and study virtualization.

As virtualization becomes more and more a part of the IT field, students emerging from four years at a university will need to have a basic, if not advanced, understanding of the virtualization technologies available if they are to thrive as IT professionals.

GoVirtual will offer the following virtualizaton-related items:

• Courseware
• Papers
• Downloads
• Conferences and Events

And perhaps the most important offering of GoVirtual is a community where like-minded students and faculty across the globe can meet and connect virt… Nevermind, I’m not going to make the joke. It’s been used up

Universities such as Carnegie Mellon, Ecole Polytechnique Federale De Lausanne (EPFL), Georgia Tech, Harvard University, Massachusetts Institute of Technology (MIT) and University of California at Berkeley already benefit from the VMware Academic program. And although the University of Texas is not officially listed as one of the academic institutions that has benefited from the same program, from my own experiences I can say that it certainly has.

GoVirtual.org is a great compliment of the academic program, and a great fit for higher education. I invite other educators to visit GoVirtual to see how they themselves can learn about this exciting technology field and share their knowledge with the Stephen Herrods of tomorrow.

Introducing Virtual Data Center OS (VDC-OS)

Today at VMworld 2008 those industrious developers working for a small technology company you may or may not have heard of, VMware, announced their most ambitious product to date, the Virtual Data Center OS (VDC-OS). Equal to the developers who have worked on it, the ambition of VDC-OS is to turn all of the resources in the data center — compute, storage, network and applications — into a single, manageable, secure cloud. While VMware Infrastructure has made amazing strides towards becoming an integral part of the data center, compared to VDC-OS, it is a drop in the bucket. Let’s take a closer look at this new technology:

VDC-OS allows IT professionals to aggregate their datacenter resources through four technologies:

• Application vServices
• Infrastructure vServices
• Cloud vServices
• Management vServices

Application vServices
Application vServices is the list of services that VMware provides which enable greater application functionality and uptime. This list includes existing services such as VMotion, Storage VMotion and HA. Coming in 2009, however, VMware will introduce VMware Fault Tolerance, a new technology that will enable two VMs on separate ESX servers to be kept in lock and step with each other simply by the click of a button. In this way if the first VM goes offline, the second VM is ready to step in instantly and take over services ownership.

Infrastructure vServices
Infrastructure vServices consist of technologies that have to do with compute, storage and network. Today VMware already offers CPU virtualization assist, memory virtualization, memory sharing, and its own fully-fledged virtual switch. Tomorrow, however, VMware will offer even more. In 2009 VMware is going to offer fully paravirtualized storage drivers allowing one of the last remaining bottlenecks of virtualizing intense applications to be removed. These drivers will allow for up to 200,000 IOPs / second. Additionally, VMware will also be introducing its VMDirect technology that allows hardware to be accessed directly from VMs.

2009 will also finally see VMware doing what I have said they should do all along and partner with existing network companies such as Cisco to provide the ability for others to create third-party virtual switches. Very soon network administrators will be able to manage a VMware vSwitch using the IOS! Other networking improvements include Network vMotion, the ability to migrate network statistics along with the VM from server to server. The premier networking technology on the horizon though has to be the Distributed Switch which greatly simplifies the set up of ESX networking.

VMware is not resting on its laurels when it comes to storage either. Three new storage technologies are right around the corner: vStorage Thin Provisioning, vStorage Linked Clones, and vStorage APIs. The specifics on these technologies are not known at this time, but I will report more on them as the conference progresses. I can say that with the exception of the AIis, the first two technologies do exist currently in storage vendor hardware, so I am betting that VMware has taken these technologies and integrated them directly into VI.

Cloud vServices
Cloud vServices is an ecosystem developed by VMware and its partners to provide the utmost flexibility when it comes to data center computing. Cloud services is essentially a set of APIs and promises that will allow any VMware customer to leverage any other VMware customer’s infrastructure in case of the former’s inability to do so.

This cloud will create the opportunity for small to large data centers to outsource their needs to larger partners who also participate in the VMware Cloud.

Management vServices
Management vServices are new services that add to VMware’s ever-expanding list of management capabilities. Thankfully they reigned in some of their desire to be a Windows patch management system and concentrated on increasing management and monitoring at a more fundamental level. New technologies include:

• vCenter AppSpeed - Helps in diagnosing and fixing application issues
• VCSync - Allows multiple VC instances to be synchronized to bring about federated management scenarios
• ESX Baseline - Allows ESX servers to be held accountable to a provided system configuration baseline
• vCenter Orchestrator - Allows IT professionals to create their own custom management workflows (such as how to create a VM)
• vCenter Chargeback - Finally! A charging system built into VC!

… and more!

Conclusion
VMware has once again provided us with several great technologies that will hopefully increase the case for virtualization in the data center. While these technologies may be offered under the name VDC-OS, they are far from a single solution. VMware has had a problem before with product sprawl and the inability to manage all of their offerings. Will the same thing happen in 2009? Or will these products come together and become the backbone of the data center OS that VMware hopes them to be? Only time will tell!

VMware working on patch for ESXi API exploit

Although VMware’s ESXi hypervisor is free under the VMware Infrastructure (VI) base license, it’s not without limitations.

Only some of the application programming interface (API) method calls that are typically shipped with the VI SDK are available. It’s impossible, for example, to power on and off a virtual machine directly with Java or C#, the VI Toolkit (for Windows), the VI Perl Toolkit, or any other scripting toolkit or programming language that leverages the VI SDK. Full functionality is restricted to the VI client. I believe that this is VMware’s attempt to prevent third parties from developing management solutions for ESXi and selling them at lower cost than VMware’s VirtualCenter.

Despite these restrictions, I recently discovered a workaround that allows full access to the API. The method to circumvent VMware’s lockdowns will not be discussed here because it is unintentional and violates section 3.3 part 4 of the ESXi EULA:

You may not … create, develop, license, install, use, or deploy third party software or services to circumvent, enable, modify or provide access, permissions or rights which violate the technical restrictions of the Software.

VMware has been notified and is currently working on a patch to resolve this issue. Remember that in the interim, this method or any other means used to gain full access to the API in the free version of ESXi violates the EULA and should not be used.

That said, it’s still pretty cool

Friends don’t let friends, like VMware, act like Google

I like VMware. I like Google. Heck, both of them keep me more than busy with development ideas. But I have a problem with them. Google started it with Gmail. Although it is hard to remember now, Gmail was in beta forever. Oh wait, it still is? Huh. I guess I just figured it *must* have hit production by now. Then there is Google News, Google Apps, Google Page Creator, Google everything else — all beta . I am honestly surprised search hits don’t come back with the “beta” tag next to them. I guess they thought ICQ was the cat’s meow, and that the whole beta thing had a nice ring to it.

Enter VMware, which is perilously close to become the next Google in terms of heavily pushing new features, but then labeling them as beta or experimental. Take for example Storage VMotion (SVMotion). VMware played up this new feature to VI 3.5 last fall at their North American VMworld conference, but when it was release there was no graphical user interface (GUI) option for it. How is that ready for prime-time? And then there is virtual machine (VM) high availability (HA),  another marketed feature that is so experimental you have to edit an advanced setting (as a free-form string) just to enable the functionality.

I wouldn’t actually have a problem with VMware doing this if they didn’t market the heck out these new “features.” Excuse me for being old fashioned, but it isn’t enterprise-ready if it is beta or labeled experimental. And VMware makes no bones about this; they plainly state that these features should not be used in production. However, on the other hand they make a big show about the same set of features, whipping the crowd to a fever pitch of excitement. You can’t have it both ways, guys.

Take VMware Fusion 2 or VMware Server 2. These products are in beta stages right now and VMware is not making a big deal about them. Sure, they are out there for people to get, but VMware isn’t throwing them at customers, not the way they revolved last year’s North American and this year’s European VMworld conferences on features that were not even ready for production.

Then there is the other end of the spectrum as well. I recently discovered that VMware is strategically hiding a long sought feature of ESX in the bowels of its software development kit (SDK). Since version 2.5 of the SDK (VI 3.5), VMware has included the ability (although it does not yet appear to be working correctly) to create network address translation (NAT) and dynamic host control protocol (DHCP) devices directly on ESX servers for VMs to use. This is awesome! Prior to this, the only way to create NATd networks on an ESX host was to dual home a VM to a public and private port group, have it act as the NAT and DHCP server, and then attach other VMs to the same network as its private interface. This solution was cumbersome and did not work well when VMotioning VMs. If I was VMware, I would make a little bit more noise about the fact that they are working on this feature.

I want to reiterate that I like, if not love, VMware. I just hate getting jazzed about a new feature that they have thrown at me, only to find out that it is a curve ball. VMware needs to make sure that features that are experimental should be announced with an asterisk next to their headline, while at the same time working a little harder to ensure that some other upcoming features get the love they deserve.

VMotion and RDMs

Yesterday I was a speaker at “Virtualization: Getting from Pilot to Production.” During my second session I claimed that you could VMotion a virtual machine (VM) that uses a Raw Device Mapping (RDM) to access a raw logical unit number (LUN). Two audience members challenged this claim, saying that they had previously run into a scenario where it was not possible to VMotion a VM that makes use of RDMs. I was sure I was right, and they were positive they were correct. It turns out we were *all* spot on. You can VMotion a VM that uses RDM as long as the RDM is configured in virtual compatibility mode. When you map a SAN LUN using a RDM, you choose between two modes of operation: physical and virtual. Per VMware documentation:

Virtual mode for an RDM specifies full virtualization of the mapped device. It appears to the guest operating system exactly the same as a virtual disk file in a VMFS volume. The real hardware characteristics are hidden. Virtual mode allows customers using raw disks to realize the benefits of VMFS such as advanced file locking for data protection and snapshots for streamlining development processes. Virtual mode is also more portable across storage hardware than physical mode, presenting the same behavior as a virtual disk file.

Physical mode for the RDM specifies minimal SCSI virtualization of the mapped device, allowing the greatest flexibility for SAN management software. In physical mode, the VMkernel passes all SCSI commands to the device, with one exception: the REPORT LUNs command is virtualized, so that the VMkernel can isolate the LUN for the owning virtual machine. Otherwise, all physical characteristics of the underlying hardware are exposed. Physical mode is useful to run SAN management agents or other SCSI target based software in the virtual machine. Physical mode also allows virtual-to-physical clustering for cost-effective high availability.

Additionally, you can also VMotion a VM with an RDM that uses network port ID virtualization (NPIV), as long as you use virtual compatability mode.

So there you have it. The audience members were right. My memory is not as shot as I thought it was, and everyone is happy.

VMware releases official plug-in guide

Congratulations to the VMware engineering team releasing the official guide to creating VMware plugins. Their awesome, hard work is culminated in the document Getting Started with VI Client Plug-ins. Several of you have already asked me how their official methods and plug-ins compare to my previously published guide and plug-ins. After a cursory review of the official guide, here are my thoughts:

- The VMware guide to plug-ins is official. Mine is not. Although the VMware guide is experimental, it is more likely to be supported by VMware than any plug-in you write using my guide. That said, I have heard that the team responsible for plug-ins plans on developing a shim that will continue to support my plug-in methods in the next version of VMware Infrastructure (VI). That is hearsay, however, and it could change.

- Official plug-ins function very similarly to mine (they should, they are built using the same principals), but they could be considered inferior in one very important manner. Although the user interface to activate a plug-in is the same (context menus, tabs, menu items), the interface for official plug-ins can only be a web page. For instance, a user right-clicks on a virtual machine and clicks on the context-menu item labeled Migrate storage which launches my Storage VMotion plug-in rewritten as an official plug-in. Instead of having a Windows form appear that maintains a consistent user interface, instead a web browser appears and runs a script or web application that has authentication information and object information passed to it from the VI client (much like my Invoke plug-in).

- Official plug-ins must reside on a web server to which clients have access. This can be considered a good thing and a bad thing. On one hand, it centralizes plug-in updates. On the other hand, if the web server is offline ESX admins could lose plug-in functionality that they have come to rely on. Plug-ins written using my guide reside on the local client; always online and accessible.

- Given how hard it is for developers to build consistent web applications between browsers (even the VI online web interface fails to work properly on Safari), it is a tall order to expect plug-in developers to create plug-ins that look the same between the four major web browsers available to Windows (IE, Firefox, Safari and Opera). That said, you could just force users to use IE since you know it will be there.

- One big win with the official method is that the plug-ins could be written to be standalone web applications. This means that they could be accessed outside the context of the client.

The official plugin guide is a great achievement on the part of VMware; it shows their commitment to giving users what they want. Ultimately, though, the plug-ins created with it are forced to be web applications or scripts hosted on a web server. The biggest problem with this is that it forces users to leave the consistent look and feel of the VI client, ripping them out of their experience. The official plug-in guide is probably best thought of as an online alternative to the Invoke plug-in, but not as a replacement to the plug-in architecture that I have already exposed.

Hopefully with VI4 we will see a more fully fleshed out, official plug-in architecture.

Update 4/22/08:

Carter Shanklin, Product Manager of End User Enablement at VMware, sent me an email with the following note:

One point you make is the inconsistency of browsers in rendering, etc. Inside VI Client, if you create a custom tab it will be rendered using an Explorer control, regardless of what your preferred browser might be. This may be problematic if you want to use the same interface from outside of VI Client, but from within the client it should look fairly consistent.

Carter is absolutely correct. These controls should be rendered within the VI client, however you still need to make sure your web application looks and feels like a part of the VI client. Just because your web application is displayed from within the VI client, it does not mean that the VI client is rendering your list box or text box with its own style sheets.