Think IPM

Wednesday, June 29, 2011

Adding ESX host to vCenter : QueryConnectionInfo Failed

While at a client, I received a really weird error while trying to add a brand new ESXi server to VirtualCenter.  I was working on a fresh built workstation and was adding a new ESXi server.

image

After a quick Google search, I came across Duncan’s post detailing the issue and solution.

image

Adding the correct DNS suffix to the vCenter server allowed me to add the ESXi to the host without issue.

Click Here to Continue Reading >>

Monday, June 27, 2011

Citrix Provisioning with VMXNET3 : Blue Screen of Death on Clones

imageIf you have been streaming Windows 7 or Windows 2008 R2 vDisks using Citrix Provisioning Services to VMware’s ESX, you’ve probably run into a Blue Screen of Death once or twice.  Frequently, this is related to the networking drivers and it has become a pretty standard practice to change the Virtual Machine’s NIC adapter from the default VMXNET3 to the more compatible E1000 driver to get around the issue.

Citrix acknowledged that this was an issue with the way new virtual machines registered the NICs using a portion of their unique MAC address.  This would cause Provisioning Services to fail with a BSOD during boot.  This did not affect the golden image but did break every subsequent clone from that image.  More about this issue is detailed in CTX125361.

In the last few months though, Citrix has released a Provisioning Services hotfix to deal with this specific issue.  You can find the specific hotfix in CTX128160.

Unfortunately, to apply this particular hotfix, you will need to reverse image the vDisk to the VM’s local drive and boot from it.  Once you have applied the hotfix and reinstalled the PVS Agent software (or run BindCFG), you can recreate your vDisk using XenConvert or the image wizard.  Be sure to switch the VM’s NIC driver to VMXNET3 as well.

Click Here to Continue Reading >>

Monday, June 20, 2011

Lessons learned: Data Migrations (VMs or otherwise)

imageWhether you are moving files, Virtual Machines or other types of data from SAN to SAN or LUN to LUN, there are a few guiding principles that can help prevent long late nights of troubleshooting and apologizing. Smile 

  • Verify all systems are in working condition – If something (Virtual Machine, OS or Application) is broken before the migration, it will most likely be broken as much or more, after the migration. Verify the working condition of applications and VMs BEFORE migrating so you are not chasing ghosts AFTER the migration.
  • Verify there is enough room to migrate all the data from Point A to Pont B.  Try to determine best practices on distributing data across RAID sets, shared volumes and datastores.  Note whether the source data is thin provisioned, deduped or compressed on the source and that the formatting will remain intact on the destination BEFORE the migration.
  • DO NOT move critical data during business hours. These systems are best moved (even if no perceived downtime is anticipated) later in the day presumably when people are commuting home or sleeping. Things go wrong and it is better for everyone involved when they happen outside of business hours.
  • VERIFY your backups. Verify your Backups. Verify your backups. Try a restore here and there to PROPERLY verify your backups.  You may have successful backup jobs but you do NOT have verified backups until you successfully test a restore.
  • Verify your support contacts (Phone numbers, emails, response times, and contracts) and let appropriate people know the schedule at which you plan to migrate data if possible.  If something goes wrong, it is comforting to know who to call and if they are likely to answer.
  • Create a spreadsheet outlining the systems to be migrated. Size and time to migrate are also useful pieces of information on this spreadsheet. Note any important information that could be lost during migration. (IP addresses, local Admin Passwords for instance).
  • Know the local Administrator passwords for ALL SYSTEMS. This is useful when an Active Directory goes down or a system loses its IP settings and network connectivity.


This list is by no means complete; so please feel free to add your favorites in the comments.

Click Here to Continue Reading >>