Category Archives: Uncategorized

VMware Launch Event!

This is great – vSphere 6 already announced along with VSAN 6.0.. Can’t wait for more things from VMware.

http://vmw.re/1yGzFLu

Leave a comment

Filed under Uncategorized

Note to self

If you decommission a datacenter in China don’t expect any of the equipment to work when it arrives back in the states… Just saying.. 

Leave a comment

Filed under Uncategorized

Powershell – List WWNs per cluster

Ever build a new cluster and have to send the WWNs to your storage team for zoning? 

This script will make that a littler easier for you. 

Get-Cluster ClusterName| Get-VMhost | Get-VMHostHBA -Type FibreChannel | Select VMHost,Device,@{N=”WWN”;E={“{0:X}”-f$_.PortWorldWideName}} | Sort VMhost,Device| export-csv c:\storage\blahblahyaya.csv

 

Leave a comment

Filed under Uncategorized

VMotion between two different clusters with different CPUs (Same family though!) Without Permanent EVC Clusters

Have you ever wanted to VMotion a VM from lets say a Nehalem based cluster to a Westmere based cluster but got that pesky error message saying the CPUs aren’t compatible? Do you have using EVC mode for clusters?

I’ve used this method in the past to move a couple thousand QA/Dev Linux/Windows VMs without downtime.

We are essentially creating a Jump EVC cluster that will allow you to hop VMs from nehalem hardware to westmere hardware while online. 

  • Create a new cluster at based at the lowest CPU EVC level that you are using.. My case was Nehalem. 
  • Place a Nehalem host and a Westmere host into Maintenance mode. 
  • Move both hosts into the EVC Cluster.. 
  • Remove them from Maintenance mode. 
  • VMotion a VM from your Nehalem Cluster to the Nehalem server in the EVC Cluster.
  • Then VMotion it to the Westmere blade inside the same cluster. 
  • Then VMotion it to it’s final resting place in the Westmere non-EVC cluster.

A few things to mention.

Obviously both hosts need to be on the same VMotion subnet for this to work.

Some of the newer processors are coming with AES-NI pre-enabled in the BIOS which makes this process moot. (Unless you go into each server’s bios and disabled AES-NI.

Ensure DRS is disabled in your EVC cluster – this gives you the most control over where the VM will go so you don’t screw anything up.

I do not suggest you do this in a production environment unless you’re feeling like a cowboy.. I cannot take blame for you blowing up your VMs in the very unlikely event that you do something wrong.

One more caveat is that if you look at the processors inside the VM after the move they will still show as the original processors.. This will not cause a problem – just reboot the VM when you have a patching window and/or maintenance windows. 

 

 

 

2 Comments

Filed under Uncategorized

vCenter Converter Failure after Linux P2V – ERROR: kernel version has to be in format 2.6.*

I’ve done quite a few CentOS 5.x P2Vs but this was a first for me..

Baseline first.

I use 5.1 Converter to do all Linux P2Vs.. This allows you to preserve the LVM partition state of a CentOS/Redhat system without having to convert the partitions to standard EXT3 partitions..

I’ve disabled SSL which is enabled by default in the installation of the 5.1 converter (this should be disabled at all times – it extends a simple P2V that should only take an hour to sometimes 5 to 8 hours..

I enable the “UseSudo” parameter in the Converter configuration file since Sudo is used throughout my organization and I don’t manage the Linux/Unix systems.

Down to the nitty-gritty.. I recently received the following error when trying to P2V a CentOS server..

ERROR: kernel version has to be in format 2.6.*, version 2.6.18-348.6.1.el5 is not supported.

I’ve seen this a couple times on some systems but i was able to get past it (since converter didnt delete the VM on me). I was able to boot the VMs in Linux Recovery mode and remake the INITRD myself and boot the servers fine.. But for some reason now Converter wants to delete the VMs on me *grumble grumble*…

To get around this you can edit this the converter-worker.xml file located here

C:\ProgramData\VMware\VMware vCenter Converter Standalone\Converter-Worker.xml

Edit the following line and change it to false.

<powerOffHelperVm>True</powerOffHelperVm>

Restart the Converter Services after you make this change.

This will ensure that the VM is not deleted after the P2V “fails”. Since you cannot delete a Powered on VM we can essentially tell Converter to screw off..

2 Comments

Filed under Uncategorized

First Post

Yes this is my attempt to create a VM blogging site.. More to come soon.. Maybe.. 

Leave a comment

Filed under Uncategorized