Blog Posts

Sadly enough most my holiday was spent updating my systems and lab. With the final release of ESX 3.5, 3i and VC2.5 I embarked on an upgrade of my VDI lab. Currently, most my systems have been converted to ESX 3i. I just love it, love it, love it. More on that later.

This summer I became a switcher. Windows to MAC. Anyone that knows me, knows I started out as a Windows guy and still am to a large degree. However, after spending six years at a Unix company I have done all things desktop at this point. Windows, Linux and MAC. I was waiting for Fusion to come out of the oven before switching to the MAC and I love it.

The MacBook pro I got this summer was Santa Rosa based 2.2 with 2GB RAM. Originally I started down the bootcamp path with a Vista partition.

OSX
Vista - Bootcamp
XP - VM, my work image

I never found myself booting into Vista and felt the whole bootcamp thing was a waste as I was always using Fusion to access it. Its less flexible than a VM and really buys me nothing. Since I was running out of space, I figured i'd ask Santa for one of those smoking 200GB 7200 RPM drives that plus 4GB RAM I figured would turn my MacBook Pro into a mean VM running machine.

Well Santa delivered... I got my 7200 RPM drive. The next challenge was going to be installing it and migrating. It took some planning but all in all I am extremely satisfied with the results. Below are the steps I took to get from point A to point B

1. I copied my XP virtual machine to some shared network storage
2. Using VC 2.5 with built-in VMware Converter I imported my Vista bootcamp partition into VI3
3. Using an external USB drive I used Time Machine to backup the OSX
4. I did major surgery on the MacBook and installed the 200GB 7200 RPM drive - I recommend you buy a #6 torque!
5. Using the Leopard DVD I booted with the external USB drive attached and did a system restore using Time Machine
6. After rebooting I copied my XP VM back down to the MAC
7. Using VC 2.5 I exported the bootcamp Vista VM that I had converted to a network share and copied it to my MAC.

After copying all my VMs back to the MAC each one successfully booted with no problems. The final result left me exactly where I left off, except I have 80GB more storage, a way faster system overall, and a lot more flexibility with my VMs
2.

I was so slammed at VMworld over the last week that I have not had the
time to let everyone know the Beta 1 for VDM 2.0 is now available.

VDM 2.0 is a session broker for VDI deployments offered by VMware and is a new product built from the Propero technology we acquired back in April of this year. Over the last few months the team has been hard at work so we can deliver on the design goals we set for this release of the broker. At this stage we are really focused on simplicity and saleability. One of the biggest changes for the initial release from the original Propero technolog wasporting to Windows. This release is only supported on Windows 2003.

Technically, there are a lot of things that occur when VDM 2.0 is installed, but we have simplified that process in the installation procedure. The installation is a single MSI installer. It takes about five minutes to get the initial VDM server in a group installed and ready to configure using the web based administration. In the coming weeks I will be sharing more on the architecture and available features. Anyone thats interested in
participating in the beta can find the registration page this URL - VDM 2.0 Press Release

Early this summer I wrote a guide covering Pocket ACE that has finally made its way through the system. Pocket ACE is a new feature included in the release of ACE 2 Enterprise Edition. Pocket ACE allows an ACE Administrator to deploy a Virtual Machine to a portable storage device. A user can take that portable
device and run their virtual machine by attaching the device to any supported x86 based system.

I wanted to take the time to acknowledge a few people that were instrumental in helping along the way. Matt Ginzton, Gilad Ben Zeev, Chris Leroy and Ed Albanese. Matt is a Sr. Staff Engineer at VMware and always helps me with all things ACE and Pocket ACE related. Gilad is a Sr. MTS Engineer at
VMware and played an important role in helping me better understand our instance customization. Ed Albanese is a Product Manager at VMware. Ed plays an important role by directing and reviewing content and ensuring the highest quality. Chris Leroy is a Sr. MTS Engineer at VMware and helped in the areas of disk i/o
performance, sync performance and overall review contributions. This guide is intended for IT Architects and technical influencer's looking to better understand
Pocket ACE. I hope you find it useful. The guide can be found here, VMware Pocket ACE Guide.

The Terminal Server team has been really busy over at Microsoft and the fruits of their labor can really be seen in the latest release of Longhorn Beta 3. Potential and existing VDI customers are always telling me they really want a simple, clean, low cost and easy to manage way of delivering, existing and candidate applications compatible with Terminal Services to their desktops.

One of the features I have been waiting to see from 2008 server and the Terminal Services team is RemoteApp. RemoteApp is a new feature that introduces usability concepts that have been around for a while, but have really started to take off even more, as the desktop environment continues to change.

So what is the concept? A RemoteApp application accessed from a Terminal Server displays as if it was another application loaded on the user’s local desktop. This concept is nothing new really. On the Terminal Services front there have always been seamless windows from Citrix. Sun’s SGD product had the concept of the integrated client that took the seamless windows concept a step further by integrating the applications into the start menu and desktop.

On the virtualization front, its similar to the Unity feature of the VMware Fusion product for MAC. In order to leverage RemoteApp with VDI desktops, XP desktops will need the RDP 6.0 client installed. Vista desktops will have this by default. Getting started is simple. Any application loaded on the Terminal Server can be selected as one available, as a RemoteApp using the TS RemoteApp Manager. Once you have selected the applications that will be available, you have the option
of creating an .rdp file or .msi package. These contain the connection and configuration information of the application and can be distributed to VDI desktops using file shares or software distribution methods.



As a quick test, I loaded Dreamweaver 8, created an .msi package and published it via Software Distribution using Active Directory. Once installed, an application icon shows up in the Start Menu under Programs/Remote Programs. An icon can also be created on the users desktop if desired.

When a RemoteApp is started, a splash screen will appear indicating that an application is being started. This really is the only indication to the end user that the application is remote. An important note is if more than one RemoteApp is run simultaneously they share the same Terminal Server session.

Once the application is running you can see, not only does it run as a seamless window, but it also carries the theming from 2008.



RemoteApp should be exciting to VDI administrators because of how cleanly it’s implemented. When available, it should prove to provide a simple and clean way of
providing centrally hosted applications to VDI desktop users.

Fu - sion – noun the act or process of fusing; the state of being fused. A long time ago, early in my career I never would have imagined I would need or want to use anything beside Windows. I started out as a Windows Server and Network admin. I really had no aspirations or interest in learning other operating systems. Over time, that changed as our business was looking for alternative and innovative ways to do things.

Ever since, I have helped customers find alternative ways to do things and focused on interoperability, primarily in the desktop space. Before joining VMware, I worked for a company that ran zero Microsoft products, no Windows Operating Systems and no Windows or Windows based applications. The also were thin. They had over 38,000 thin clients deployed globally. Talk about Green. They were Green before Green was in.

I was there for six years and was exposed to every alternative imaginable. They had quite a few Macbook pro’s running around. I myself did not have one, but was always enamored by their design. I never really thought it was practical for me to use one.

I live in a VM, I have VDI in my office and work from a virtual XP desktop day to day. I use offline files and folder redirection for syncing between my VMware assigned laptop and my VDI desktop. When I came to VMware, I got the standard IT assigned laptop that was about good enough to run Word and Outlook. Trying to run all the VM’s I needed for testing and generating content, plus doing my day to day work when traveling just sucked. I could not stand it any more. I really needed something with a a little more RAM and more importantly something faster than a 4200 RPM drive. Between the pain of the IT assigned laptop, falling prey to the continued assault of MAC commercials and the day to day glow of the Fusion team. I started looking into getting a Macbook pro, as I knew Fusion would be the ticket too bring it all together. I waited and waited till the Santa Rosa systems shipped. Then a few weeks back, I officially broke down and got a Macbook Pro. I would not quite say I was a switcher yet. I really was only looking for a well designed machine that had enough power to do what I needed when traveling, doing demos, testing etc.

The plan was to run XP by moving my assigned laptop image over, piece of cake by the way using converter, built inside ACE 2. Then, I figured I would load Vista since I had not seen Aero and needed to do some VDI testing. I had been doing VDI testing and playing with the desktop environment. I like it, I think its sweet. I like the sidebar etc.Before I loaded Vista, I played with OS X a little and got familiar with Expose, the dashboard etc. I have never used a Mac and was getting my bearings. Finally, I loaded Vista in a boot camp partition. Well, Aero 3D flip was a disappointment, too me its just a 3D alt-tab. OS X expose, and the dashboard are much more appealing.

At the end of the day, I needed XP and Vista and OS X was growing on me. In steps Fusion after all, I had been dying to play with our unity feature. I am just
blown away, thus far it exceeds my expectations and really is exactly what I was hoping for, seamlessly integrates the desktop experience with Unity. It’s simple to switch between Unity or a full screen Windows desktop. I can create snapshots of my laptop image. I run can run my boot camp partitions as VM’s. USB device support. If you are considering switching but still need to hang on Fusion is the ticket. It is the ultimate interoperability tool.

Fusion

Fusion

Fusion

Fusion Unity View of my XP desktop. Each application is independent . See Outlook in the dock!
Fusion

Fusion

Fusion

Starting with ESX 3.0.1 iSCSI support was introduced. This opens up the opportunity to leveraging lower cost storage options when hosting virtual desktop instances. The topic of, what disk to store desktop images on, is one that gets tossed around like a hot potato. For some customers it seems like a non-issue. Their cost per gig is the same regardless if its enterprise fibre channel storage or low end storage. Some are not interested in introducing a second architecture into their data center as is the case when considering iSCSI.

For others, cost is an issue, and the possibility of leveraging iSCSI is very important to them. In my lab, I currently have an older NAS array
with around ½ terabyte of usable storage.

Several months back I decided it was time to start running some virtual desktops on it and see what performance is like.
I quickly realized, there was a little bug where ESX would not see iSCSI LUNs on my NAS appliance. So, for some time I ran an unsupported patch. Because it was unsupported, I left things as is and did not really watch the performance. This past week I was building some Solaris Express VMs for another test, when all hell broke
loose. Somehow, during the eternal boot of the Solaris VM my ESX system hosed. Because I was having such an issue, I decide it was time to do
some basic patch management. In all fairness, I was way behind on all my ESX patches. I had actually moved more VMs to iSCSI than I had
realized. All of which where very important.

The moral of the story is now, an official iSCSI patch is available for ESX 3.0.1. Patch number ESX-6657345 solves previous issues with iSCSI. After loading the patch on my systems I still was having an issue though. My ESX hosts could not log into the iSCSI target. What was really odd, is my NAS box did not see
the login attempts. It logs denied connection attempts and it saw nothing. The messages log on my ESX hosts were logging connection
refused. I tried removing and adding the iSCSI adapter through the VIC which also did not work. Finally, I got everything working and very
stable using the following steps.

Download patch ESX-6657345 and install it using esxupdate

• From the VIC under configuration, storage adapters disable any iSCSI adapters
• From the ESX console run esxcfg-swiscsi –d
• From the ESX console run esxcfg-swiscsi –k
• From the ESX console delete any iSCSI targets listed in /var/lib/iscsi/bindings
• From the ESX console run esxcfg-swiscsi –e
• From the ESX console run esxcfg-swiscsi –s
• From the VIC under configuration, storage adapters enable any iSCSI adapters
• From the VIC under configuration storage adapters rescan for the targets