Weird storage vMotion issue

I had a server template that I created on a ESXi 4.1 cluster and moved to a ESXi 5 cluster. After I did that, I upgraded the hardware version and remade it into a template and left it at that. I had been successfully deploying VM's from this template for a few months so I never thought there was something wrong. Well today I've been moving VM's to a new storage cluster on my vSphere 5 data-center using storage vMotion and when I got to this particular server, I converted it back into virtual machine and tried to vMotion it to the cluster. Well at 99% it fails with an "invalid configuration for device 12" error.

Huh?

Some searching turned up a buried post saying that it was an issue with the MAC address on the vnic. So I removed the old nic and added a new one and presto! Storage vMotion worked.

Weird.

Comments...

Apparently they're broken. I need to fix them.

edit: fixed them.

Off in the Horizon...

Application virtualization has been on the rise for the last few years with all the different mobile platforms available. Citrix has been doing it for years... well they've been presenting users with a remote app type environment at least. You can't really call that "virtualized" when the user has an entire session on a terminal server all to themselves. VMware's Thinapp is a whole lot different though. When you take an entire application and box it up into an MSI package then stream it to a user... that's what I call virtualization. So the question is how do you present that Thinapp to the end user? VMware's solution is their Horizon Application Manager.

I've been a little leery of actually using Thinapps in our environment. One reason is the fact that it is a shared application package and I don't know how it will react to 300 users accessing it at the same time... but you can't find solutions to problems by sitting around worrying about the outcome so I'm delving into it a little at a time.

Last week I decided to give Horizon Application Manager a shot and see what it was all about. I needed a solution to start streaming some applications to virtual desktops so that I wouldn't have to install the software on each of them (which can be a pain). I read through the documentation and some blogs about installing it and here are my reactions to the installation process. Please note that these were jotted down as I was installing the product and therefore are in chronological order. The things I had issues with in the beginning I ended up fixing later on but you'll see what I mean.

- When deploying the template, you need to assign an IP address to the virtual machine but when powering on the machine, there must be a pool of reserved IP address on the virtual switch of the VM or else the virtual machine won't power on. But the IP address that is assigned to the VM can't be a part of that pool even though it won't be assigned an address within that pool...

- When setting up a test environment and you do NOT use the connector virtual machine (which is allowed) the local user account that gets created doesn't seem to be allowed to log in. If a password gets emailed to the administrator email, there is no option to set a SMTP server to sent the email through... and if the virtual machine assumes that it can just use the outside MX records, that's a pretty big flaw. The end result was me not being able to log in and having to delete the VM and redeploy from the template

- when setting up an organization and you wish to change the organization's name, you can't go back in the set up. you're stuck permanently with the name you've chosen

- when setting up the conntector it won't join my domain giving me a "Failed to join the domain: ERROR_INVALID_COMPUTERNAME" error.

- apparently I missed the part where during the connector set up they said it was vitally important to active directory sync to set a hostname. No option to go back and change the hostname anywhere on the connector console or in the web ui.

- when setting up the system to join our domain, I had to log into the SLES console, change the hostname and edit the /etc/HOSTNAME file. Only after I changed those values and rebooted was I able to join the domain. not fun.

- After enabling windows authentication (after I've already completed the wizard once without activating it), access to horizon stopped with a 404 error. can't log into manager. I may have to delete the connector in App Manager...

- No warning about loosing connectivity to app manager and needing to put the activation code back in after deleting the connector... and now I have to figure out how to regenerate an activation code from the app manager console

- Found out that there is a built in account named "operator" whose password I set earlier. Where was that in the documentation? 5+ hours wasted.

- No automatic agent installation from the browser... I had to go get it from VMware's site.

- No way to remove a Thinapp from the list of available apps without going into the console and deleting a file. That's kind of crazy

- The application management itself could be way better.

So the end result was finally a working Horizon installation. Repackaging previously packaged apps to work with Horizon is a little bit of a pain but it worked.

Long time no post

I apologize for the absence, but work/studying and wedding planning has taken all my time recently (not to mention I screwed up the template on this blog and after that I just didn't really feel like fixing it). I did end up taking an passing the VCP5-DT exam last month so I'm now officially a VCP5-DT. I've got a few things to write about here soon like my VMware Horizion Manager installation experience and studying for the CCNP ROUTE exam. I'll post more later.

So, what's next?

VCP5?

Done! :)

Guess I should work on VCP5-DT since it should be short and sweet (been using View since last year and I've gotten pretty intimate with it)

View 5.1 BUG Alert!

I found one!

I just upgraded our environment to the latest build of 5.1 over the weekend and in the processes upgraded the agent to 5.1 on our base virtual machines. On Tuesday, one of our users (who's using a zero client) reported they could no longer change the resolution to their desktop. I checked all the settings as recommended by KB article 1020809 and even though I could move the slider on the display settings (it is a Windows XP virtual machine) and then apply it, the display would then go dark like it was changing the resolution and when it came back, the resolution would still be the native resolution of the monitor. I even tried a little documented command:

VMwareResolutionSet.exe 0 1 , 0 0 1280 800

(btw, that command is located in "c:\Program Files\Common Files\VMware\Teradici PCoIP Server\")

which sets the resolution on the first monitor to 1280x800... no luck. Same outcome as before. One of my co-workers who also has a zero client and a Windows 7 desktop tried to change his to test and his wouldn't change either. The only resolution we could change it to was 800x600.

When I dropped the user down from agent version 5.1 to 5.0, they could again change the resolution settings. I told VMware about the bug but so far, I haven't received any type of response back from them. Hopefully they'll have a fix out for it soon.

update: Turns out it was the firmware version on the zero client. As of the time of this writing, there wasn't a firmware that supported View 5.1. This issue has since been fixed.

ESXi, vCenter and Active Directory

I don't have any confirmation on this (in fact VMware support has no idea how this happened), but after spending 11 hours on Saturday rebuilding one of my vSphere servers (which houses the entire View environment), I think I figured out why 90% of my vm's went orphaned on me after I took the server offline for some hardware upgrades (like ironically, a fibre HBA to hook into our new EMC VNX5300).

When I originally built this vSphere environment, I did so with the thought that this would be all I get to work with. I didn't have any shared storage (not even a decent iSCSI/NFS store), nor did I have vMotion... and apparently I didn't really know exactly what I was doing ("gasp!" - getting that out was hard for me because I hate to think that I did anything wrong). I had an idea of what I wanted but VMware was still a little new to me. Fast forward six months, and I've gone through "Mastering vSphere 5" twice, read most of VMware's vSphere 5 documents and have taken the vSphere 5 class (my VCP test is registered for June 4th). I have a MUCH better understanding of how the whole vSphere environment works. So this is how I think I killed 96 virtual machines - causing me to re-register each and every one of them and taking down my entire View environment.

I added the ESXi host to vCenter using a domain account whose password changes every 60 days.

See, I went through and set up access to the ESXi host before adding it to vCenter. I really didn't understand how vCenter played such an important role in management until recently. Here's my train of thought (granted, none of this is verified - just my own suspicions):

• I add the ESXi host to vCenter with a domain account
• vCenter cache's the username and password used to connect and authenticate the ESXi host
• I add some VM's to the host through vCenter
• vCenter uses those cached credentials to register those VM's with the ESXi host itself
• My domain account's password is changed
• I then proceed to build out my entire view environment on this host
• Each time a VM is created in vCenter, vCenter adds it to it's database then tries to register it with the ESXi host using the original cached credentials
• uh-oh... those credentials are expired. vCenter gets to actually create the virtual machine files on the datastore but the ESXi host refuses to add the VM to its list of hosted virtual machines
• Fast forward to Saturday and I take the host down to put the new HBA cards in it
• When I bring the host back online, vCenter tries to re-add the host but is unable to do so using the cached credentials
• I have to re-add the host to vCenter, this time realizing I need to use the ESXi host root username and password.

Again, this is my speculation, but it seems to be the only logical answer to how this happened. I mean, there's no way taking a host offline on purpose should make 90+ VM's orphaned you know?

Anyways, if anyone ever reads this and they know of official documentation from VMware that supports this theory, I'd love to read it!