Archive

Archive for the ‘VMWare’ Category

vSphere 5.1 available

September 11th, 2012 No comments

Yup – vSphere 5.1 is now available at https://my.vmware.com/group/vmware/info/slug/datacenter_cloud_infrastructure/vmware_vsphere/5_1

“Customers who have purchased VMware vSphere 5.1 can download their relevant installation package from the product download tab below. Looking to upgrade from vSphere 4 or Infrastructure 3? Visit the VMware vSphere Upgrade Center.

Deploy vSphere 5.1 on the ESXi hypervisor architecture

VMware vSphere 5.1 is available exclusively on the vSphere ESXi hypervisor architecture. ESXi is the latest hypervisor architecture from VMware and, as of the vSphere 4.1 release, VMware’s recommended best practice when deploying VMware vSphere. Users can upgrade to ESXi (from ESX) as part of an upgrade to vSphere 5.1.

For more information visit VMware ESXi and VMware ESX Info Center

Get Your vSphere License Key

Once you have purchased VMware vSphere 5.1, you will receive a licensing confirmation email with your license keys or you can retrieve your license keys from the vSphere License portal.

Other versions of VMware vSphere: 5.0 , 4.1 , 4.0”

Categories: VMWare Tags:

Useful scripts for amending the number of ports per vSwitch

May 1st, 2012 No comments

We have found that on many (most) of our ESX hosts, we run at risk of running our of vbSwitch ports when we run through our maintenance periods and reduce the number of hosts in a cluster.
Below are the scripts that I use to amend these settings:

# Calculating ports in use on each vSwitch: 
$myCol = @() 
ForEach ($VMHost in (get-cluster "prod Core" | Get-VMHost | Sort Name)) 
        { 
        ForEach ($VM in ($VMHost | Get-VM)) 
                { 
                ForEach ($NIC in (Get-NetworkAdapter -VM $VM)) 
                        { 
                        $myObj = "" | Select VMHost, VM, NIC, PortGroup, vSwitch 
                        $myObj.VMHost = $VMHost.Name 
                        $myObj.VM = $VM.Name 
                        $myObj.NIC = $NIC.Name 
                        $myObj.PortGroup = Get-VirtualPortGroup -VM $VM -Name $NIC.NetworkName 
                        $myObj.vSwitch = $myObj.PortGroup.VirtualSwitchName 
                        $myCol += $myObj 
                        } 
                } 
        } 
$myCol | Group-Object VMHost, vSwitch -NoElement | Sort Name | Select Name, Count 

“To upgrade the port numbers on vSwitch1 on myesxhost.intra to 120 ports , you need:”

# To increase number of ports on a vSwitch 
Get-VMHost "myserver1.intra" | % {Get-VirtualSwitch -VMHost $_ -Name vSwitch0 | where {$_.NumPorts -lt "128"}} | % { Set-VirtualSwitch -VirtualSwitch $_ -NumPorts "128" } 

“Note, the PowerCli says ‘128’ – the reason for this is that VMware reserves 8 ports for overhead on each vswitch.
(http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008040)

You’ll also want to vMotion the Vms off each host – you can highlight multiple VMs and drag and drop, or right click, select ‘migrate’ and follow the wizard.
If you want to PowerCli it, you can try the following:”

# For a controlled migration. moving all VMs on myserver1 to myserver2 
get-vmhost myserver1.intra | get-vm | move-vm -destination (get-vmhost myserver2.intra) 

“The above will prompt you on each VM – you can ignore all prompts with :”

# to Ignore prompts 
get-vmhost myserver1.intra | get-vm | move-vm -destination (get-vmhost myserver2.intra) -Confirm:$false 

We previously had a bug that NICs lost the connection state(i.e. – the ‘Connected’ box got unchecked) – the solution was to move the VMs to a host that had available switch ports and then set the Nic’s to connected.”

#To find disconnected NICs in Prod Core cluster:" 
$vms = Get-Cluster "Prod Core" | Get-VM 
Get-NetworkAdapter ($vms | where {$_.powerstate -eq “poweredon”}) | Where { $_.connectionstate.connected -eq “$F” } | select parent, connectionstate 
#To repair change all disconnected NICs in a cluster to connected 
$vms = Get-NetworkAdapter ((Get-Cluster "Prod Core HA" | Get-VM) | where {$_.powerstate -eq “poweredon”}) | Where { $_.connectionstate.connected -eq “$F” } | select parent, connectionstate 
foreach ($a in $vms) 
{ 
$vm = get-vm $a.parent 
write-host $a.parent -back green 
if (!(test-connection $vm.name )) 
   { 
   $nics = $vm | get-networkadapter | Where {$_.ConnectionState.Connected -eq $false -and $_.ConnectionState.StartConnected -eq $true} 
   if ($nics -ne $null) 
   { 
           foreach ( $nic in $nics ) 
           { 
                     write-host $vm.Name 
                     write-host $nic 
                        If (test-connection  $vm.Guest.HostName -count 1 -ea 0){write-host "Returning Pings!!"; return}else{write-host "Not Returning Pings"} 
         } 
                $nic | Set-NetworkAdapter -Connected $true 
        } 
  
                        If (test-connection  $vm.Guest.HostName -count 3 -ea 0){write-host "Returning Pings!!"}else{write-host "Not Returning Pings"} 
        } 
} 
Categories: Powershell, Toolbox, VMWare Tags:

Changing ESX Server root passwords using PowerCli

April 24th, 2012 No comments

It’s that time again where we need to change the passwords on all of of ESX(i) hosts. Of course, when your number of hosts becomes any more than a handful, this can be a rather arduous process.

I had a scratch around some old scripts and found this one :

 


$serverlist = read-host "Please provide the path to your list of ESX hosts"



# Get old root credential
$oldrootPassword = Read-Host "Enter old root password" -AsSecureString
$oldrootCredential = new-object -typename System.Management.Automation.PSCredential -argumentlist "root",$oldrootPassword

# Get new root credential
$newrootPassword = Read-Host "Enter new root password" -AsSecureString
$newrootCredential = new-object -typename System.Management.Automation.PSCredential -argumentlist "root",$newrootPassword
$newrootPassword2 = Read-Host "Retype new root password" -AsSecureString
$newrootCredential2 = new-object -typename System.Management.Automation.PSCredential -argumentlist "root",$newrootPassword2

# Compare passwords
If ($newrootCredential.GetNetworkCredential().Password -ceq $newrootCredential2.GetNetworkCredential().Password) {

# Create new root account object
$rootaccount = New-Object VMware.Vim.HostPosixAccountSpec
$rootaccount.id = "root"
$rootaccount.password = $newrootCredential.GetNetworkCredential().Password
$rootaccount.shellAccess = "/bin/bash"

# Get list of Host servers from textfile to change root password on
Get-Content $serverlist | %{
Connect-VIServer $_ -User root -Password $oldrootCredential.GetNetworkCredential().Password -ErrorAction SilentlyContinue -ErrorVariable ConnectError | Out-Null
If ($ConnectError -ne $Null) {
Write-Host "ERROR: Failed to connect to ESX server:" $_
}
Else {
$si = Get-View ServiceInstance
$acctMgr = Get-View -Id $si.content.accountManager
$acctMgr.UpdateUser($rootaccount)
Write-Host "Root password successfully changed on" $_
Disconnect-VIServer -Confirm:$False | Out-Null
}
}
}
Else {
Write-Host "ERROR: New root passwords do not match. Exiting..."
}

I can’t remember where I got it from, but I am pretty sure it came off the VMware communities.


Of course, if you really wanted to, you get simply gather the list of ESX hosts from your VC and trawl through those using the same code – the only difference would be that you could delete the following

$serverlist = read-host "Please provide the path to your list of ESX hosts"

and replace

# Get list of Host servers from textfile to change root password on
Get-Content $serverlist | %{

with something like

Get-VMHost | %{$_.name}

Happy days – use at own risk of course!

Categories: VMWare Tags:

Configuring VMware High Availability fails

April 24th, 2012 No comments

We had an interesting situation yesterday where we tried to add an ESX4.1 host to a cluster that had its vmkernel and Service Console ports on different VLANs to the existing cluster.

Configuring VMware High Availability fails with the error: Cannot complete the configuration of the HA agent on the host

which says:

This issue occurs if all the hosts in the cluster do not share the same service console or management network configurations. Some hosts may have service consoles using a different name or may have more service consoles than other hosts.
For example, this error may also occur if the VMkernel gateway settings are not the same across all hosts in the cluster. To reconfigure the setting, right-click on the hosts with this error and select Reconfigure for HA.
Address the network configuration differences between the hosts if you are going to use the Shut Down or Power Off isolation responses because these options trigger a VMware HA isolation in the event of Service Console or Management Network failures.
If you are using the Leave VM Powered on isolation response, the option to ignore these messages is available in VMware VirtualCenter 2.5 Update 3.
To configure VirtualCenter to ignore these messages, set the advanced option das.bypassNetCompatCheck to true:
Note: When using the das.bypassNetCompatCheck option, the heartbeat mechanism during configuration used in VirtualCenter 2.5 only pairs symmetric IP addresses within subnets across nodes. For example, in a two node cluster, if host A has vswif0 “Service Console” 10.10.1.x 255.255.255.0 and vswif1 “Service Console 2” 10.10.5.x and host B has vswif0 “Service Console” 10.10.2.x 255.255.255.0 and vswif1 “Service Console 2” 10.10.5.x, the heartbeats only happen on vswif1. Starting in vCenter Server 4.0, they can be paired across subnets if pings are allowed across the subnets. However, VMware recommends having them within subnets.
  1. Right-click the cluster, then click Edit Settings.
  2. Deselect Turn on VMware HA.
  3. Wait for all the hosts in the cluster to unconfigure HA.
  4. Right-click the cluster, and choose Edit Settings.
  5. Select Turn on Vmware HA, then select VMware HA from the left pane.
  6. Select Advanced options.
  7. Add the option das.bypassNetCompatCheck with the value True.
  8. Click OK on the Advanced Options screen, then click OK again to accept the cluster setting changes.
  9. Wait for all the ESX hosts in the cluster to reconfigure for HA.

We made the changes in a test environment, and tested and voila! problem solved.

Now I would not really advocate running  production environment using this, as a router / switch outage could cause false alerts, or even HA to be invoked – but for test environments that are sometimes not as ‘pretty’ as you’d like, It is worth considering using this to still be able to use/test  HA.

Categories: VMWare Tags:

vExpert 2012!

April 21st, 2012 No comments

I am very honored and very pleased to be awarded the VMware vExpert Award for the first time! Especially when I look at this list and notice names like Alaric, Renouf etc!!  -I really though that my chances were slim, as I have been too busy over the second half of this year to keep my usual levels of community interaction and contribution up and running.

Thanks to VMware for continuing this award. Also congratulations to all new vExperts 2012.

The VMware vExpert Award is given to individuals who have significantly contributed to the community of VMware users over the past year. vExperts are book authors, bloggers, VMUG leaders, tool builders, and other IT professionals who share their knowledge and passion with others. These vExperts have gone above and beyond their day jobs to share their technical expertise and communicate the value of VMware and virtualization to their colleagues and community.

Check out the official announcement and have a look at the complete list on : http://blogs.vmware.com/vmtn/2012/04/announcing-vexpert-2012-title-holders.html

Categories: VMWare Tags:

Troubleshooting SCCM

September 1st, 2011 No comments

Straight from – http://w ww.experts-exchange.com/OS/Microsoft_Operating_Systems/Server/Systems_Management_Server/A_1259-SCCM-OSD-Basic-troubleshooting.html

Duplicated here as information keeps disappearing from all my bookmarks -then I am unable to find it . .

 

All Credit to the guys  at expertsexchange

SCCM OSD Basic troubleshooting

SCCM 2007 OSD is a fantastic way to deploy operating systems, however, like most things SCCM issues can sometimes be difficult to resolve due to the sheer volume of logs to sift through and the dispersed nature of the blog posts that deal with some of these issues. This article will help SCCM OSD newbies with some of these issues.

Integrating SCCM and MDT 2008
For our deployments, we always install MDT 2008 on our SCCM server and select Configure ConfigMgr Integration from the MDT area on the start menu. This gives us:

  • Templated task sequences we can import into SCCM
  • Additional TS Variables for use in our task sequences
  • Additional options and flexibility around computer backup, USMT etc.

For beginners, the template task sequences are a very quick way to get up and running while being guided through the process, while for more advanced users the additional functionality comes in handy when your task sequences become more complex.

Setting yourself up
In order to have any chance at troubleshooting SCCM OSD issues, you need to do the following:

1
Install trace32.exe which is part of the SMS 2003 Toolkit 2
(download from Here)
2
Enable command line support within your boot images:
a.  Go to the properties of your boot image(s) (right click and choose Properties)
b.  Go to the Windows PE tab and tick the Enable command support (testing only) option.
c.  When prompted, click on Yes to update your distribution points.
d.  From within your boot image (Windows PE) environment, you can now press F8 to
open up a command window — very useful for troubleshooting
3
Be familiar with your OS setup log files (e.g. WindowsXP has setupapi.log, netsetup.log etc.)

Log files
The root of all Task Sequence troubleshooting is called smsts.log — and this log is always the first step to troubleshooting any TS issue — if you have an issue, look in here first!

Unfortunately, the smsts.log can be stored in one of 7 locations, depending on the stage of the build and the architecture of the OS:

  • WindowsPE, before HDD format:
    x:\windows\temp\smstslog\smsts.log
  • WindowsPE, after HDD format:
    x:\smstslog\smsts.log and copied to c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
  • Full version windows, before SCCM agent installed:
    c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
  • Full version windows, after SCCM agent installed:
    c:\windows\system32\ccm\logs\Smstslog\smsts.log
  • Full version x64 windows, after SCCM agent installed:
    c:\windows\sysWOW64\ccm\logs\Smstslog\smsts.log
  • After Task Sequence has finished running
    c:\windows\system32\ccm\logs\smsts.log
  • After Task Sequence has finished running(x64)
    c:\windows\sysWOW64\ccm\logs\smsts.log

Information is also logged as SCCM client events, which can be viewed by running the SCCM report:
Last 1000 messages for a specific computer (Errors, warnings and information)

As a general rule, the SMSTS.log provides more detail, however the SCCM client events are easier to read, and, for simple issues, can lead you to the root cause very quickly.

PXE boot issues
In order to resolve PXE boot issues, there are two main log files we are interested in:

  • Pxecontrol.log — which is located in the installation logs directory (eg C:\Program Files (x86)\Microsoft Configuration Manager\Logs\pxecontrol.log)
  • Smspxe.log — which is located in MP logs directory (eg C:\Program Files (x86)\SMS_CCM\Logs\smspxe.log)

If this is the first time you’ve setup a PXE service point, I recommend you check pxecontrol.log, there should be lines similar to the following:

1:
2:
3:
4:
5:
6:
address to server list 192.168.00.117  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.248 2009 Cen. Australia Standard Time><thread=772 (0x304)>
adding address to server list 127.00.00.01  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.250 2009 Cen. Australia Standard Time><thread=772 (0x304)>
Sending availiability packet to: 192.168.0.117~  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.252 2009 Cen. Australia Standard Time><thread=772 (0x304)>
Sent 274 bytes to 192.168.000.117:4011~  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.253 2009 Cen. Australia Standard Time><thread=772 (0x304)>
PXE test request succeeded.~  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.355 2009 Cen. Australia Standard Time><thread=772 (0x304)>
Successfully performed availability check against local computer.~  $$<SMS_PXE_SERVICE_POINT><Fri Jul 31 07:54:45.357 2009 Cen. Australia Standard Time><thread=772 (0x304)>

If you see otherwise, then, WDS or the PXE service point is not correctly installed.  Without going into too much detail in this area, as a catch-all fix:

  • Uninstall the pxe service point
  • Uninstall WDS
  • Reboot
  • Install WDS, but DO NOT configure
  • Install the pxe service point
  • Re-check the pxecontrol.log

Another very common error is to see the following when trying to PXE boot:

1:
2:
PXE-T01: The specified file was not found
PXE-E3B:TFTP error -- File not found

This error is caused because you are missing files from your \remoteinstall\smsboot\x86

or x64 directory and is generally caused by one of two things:

1
The x64 boot image has not been added to the PXE service point.
“But I’m only deploying an x86  boot image and OS,” I hear you say.  It doesn’t matter.  If the machine is x64 architecture (which all today’s new machines are), the boot ROM requested will be x64. This in no way effects your ability to use an x86 boot image; this boot ROM process is completely independent.The solution is to add the x64 image to your PXE DP and update. You will then see the directory \remoteinstall\smsboot\x64 populated with files, and your good to go.

2
Even after you update your PXE DP, the files still don’t show up.
This is a common issue.  When updating the DP, the WIM file is mounted (under C:\windows\temp), all your modifications injected (such as drivers, custom backgrounds etc) and then packed back up into the boot wim pushed to the DP.  At the same time, the boot ROM files were interested in are extracted to C:\Windows\temp\Pxebootfiles before being copied to \remoteinstall\smsboot\x86or x64.Sometimes the C:\Windows\temp\Pxebootfiles directory has something funky happen to it and doesn’t clean itself up correctly.  So the difficult fix is — Delete the directory and re-distribute the package. (The directory is hidden, so make sure you set the option in Explorer so you can see it).  You can also have a look at pxecontrol.log to see the extraction process and/or the error occurring.

On some computers you might PXE boot, proceed to see a screen which indicates that the PC is talking with SCCM, followed by a line which indicates a boot ROM called abortpxe has been used.  This indicates one of two things:

1
This computer has already been built via PXE.
If you want to run this advertisement again, you must go into the console, right click on the computer record and select clear pxe advertisement
2
There is no advertisement for this machines mac address or SMSBIOS GUID in the database.
This can be confirmed by viewing the smspxe.log.  In this case, you should ensure that
a. The computer record has the correct MAC address
b. The computer record is in a collection which has the task sequence advertised to it
c. The task sequence advertisement is available to PXE boot (a property of the advert)

Software Update issues on reference build
While creating the reference build, the target machine must not be a member of a domain (and therefore must only be in a workgroup).  Because of this, the machine cannot use AD to lookup SCCM server location details and software updates will fail (after a 20 minute wait).

To work around this, in your reference build TS, navigate to the step setup windows and configmgr, and in the installation properties add

1:
SMSSLP=<fqdnOfSCCMServer> SMSMP=<fqdnOfSCCMServer>

This will allow the client to locate the software update point and download the appropriate updates. (Note: this assumes you have installed the Server Locator Point role on your server).

In the case that there are a large number of updates to be downloaded, you may also find that this task fails. This is caused by an issue documented in this TechNet blog entry about error 0x80244010.  Due to this issue, I recommend you create a number of software update tasks (I use 3), each with continue on error checked.  This will get around this issue, but will not cause any significant delay even if this issue does not occur.

Drivers
The deployment guys have a fantastic blog post on how to handle drivers in this TechNet Driver Management blog entry.

Boot image drivers
SCCM boot images are customised windows PE 2.x images used to boot the computer and contact the SCCM server. There are a couple of basic rules when working with boot images:

1
SCCM boot images only require network and local disk access (as they need to grab data from the SCCM server and apply it to the local disk) so these are the only drivers that ever need to be added to a boot image. (adding additional drivers will only bloat the image, slowing down your installs).
2
SCCM boot images are based on Windows PE 2.x, which is based on Vista.
You must add Vista drivers to your boot images only.  Even if you’re deploying on XP, it doesn’t matter, the boot environment is completely separate to your final OS.

The way I find out if I need to add additional boot wim drivers is to simply boot any new machines into a OSD TS, boot, press F8 to get a command prompt, then run

1:
ipconfig

If there is no ip address (we don’t have NIC drivers and they need to be added), then run

1:
diskpart | list disk

If there are no disks listed, then we need to add mass storage drivers to the boot WIM.

Windows XP 07B stop issues
If you’re building Windows XP or 2003, these operating systems do not allow dynamic injection of mass-storage drivers. So, you have a few options:

  • Move to Windows 7 — which after 6 months of betas/RCs and now running RTM – I’m willing to say is brilliant.  …or…
  • Change the disk controller mode from AHCI or RAID to IDE in the BIOS (quick, but not recommended for a long term solution).  …or…
  • Use the appropriate AHCI mass storage drivers:
    a. Import the drivers into SCCM, using categories etc. (see the deployment guys blog post on
    best practices for this)
    b.  Add a task to the task sequence: Apply driver package
    c.  Select the appropriate driver package
    d.  Check the box: Select the mass storage driver within the package.…..
    e.  Select the appropriate driver.
    f.  Add a condition via a TS variable <model> or WMI Query (again, covered in the deployment guys post)

Task Sequence Variables
Task sequence variables are really what give task sequences a bucketload of power, as you can have one TS which accounts for all the variations in your environment.

One of the most common questions we get is:
How do I know what TS Variables are available?
Well, there is a list in this article:  Operating System Deployment Task Sequence Variables, or you could read the documentation (Toolkit Reference.doc from the MDT 2008 documentation), or search through the script which gathers the variables (ZTIGather.vbs), or dump them all out using another useful script from the deployment guys (See Logging All the Configuration Manager Task Sequence Variables).

The advantage of dumping them all is that the output actually has meaning, so you can see what variable has what value — as opposed to just looking at a bunch of variables that might not mean much to you without values assigned to them.

In addition to the built in variables, you can add custom variables to computer objects or to entire collections.

SCCM Client Version
If you are using SCCM 2007 SP1, there is a hotfix, KB955955 available here, which you should apply, as it removes a delay between tasks, which, for long task sequences can significantly reduce build time.  The article also includes instructions on how to implement the hotfix during your bare-metal builds.

Categories: SCCM / SMS, VMWare Tags:

Removing hidden devices after a P2V

August 30th, 2011 No comments

After  P2Vs, you are often (in fact almost always) left with hidden devices in computer management – which relate to old hardware that no longer lives with your machine.

 

Getting rid of this is advised – to keep yourmachine as tidy as possible, and will also eliminte some of the error message often seen when re-using IPs for NICs that previously existed on your Server.

 

Simple to do:

Open a command prompt your Windows VM (Start –> Run –> cmd).
set devmgr_show_nonpresent_devices=1
Open device manager:
devmgmt.msc
In the device management console (View –> Show Hidden Devices).
Now simply r0ght-click each of these ‘hidden’ devices and select uninstall.
You’ll probably get prompted to reboot.
job done
Categories: VMWare Tags:

Licensing part 2

August 4th, 2011 No comments

So, we all saw the massive impact of the initial vSphere 5 announcement – all that anyone cared about is licensing. have a look at the VMCommunity and you’ll see thousands of posts complaining about it.

Well VMware – being the company they are, have listened to their customers and come up with a far neater, and more lenient licensing model.

The big changes:
Increased vRAM entitlements for all vSphere editions, including the doubling of the entitlements for vSphere Enterprise and Enterprise Plus.
Capped the amount of vRAM we count in any given VM, so that no VM, not even the “monster” 1TB vRAM VM, would cost more than one vSphere Enterprise Plus license.
An adjusted our model to be much more flexible around transient workloads and short-term spikes that are typical in environments such as test & dev.

Here is a comparison of the licensing entitlements:

vSphere edition Previous vRAM entitlement New vRAM entitlement
vSphere Enterprise+ 48 GB 96 GB
vSphere Enterprise 32 GB 64GB
vSphere Standard 24 GB 32 GB
vSphere Essentials+ 24 GB 32 GB
vSphere Essentials 24 GB 32 GB
Free vSphere Hypervisor 8 GB 32 GB²

To be honest – these are huge changes – I am almost astonished that the Free Hypervisor goes up to 32GB, and am hugely impressed by the allocated entitlements on other licensing versions.

For more info o nthe updates see :http://www.vmware.com/products/vsphere/overview.html

To get an idea of how your will be impacted by the licensing – VMware have created a Powercli script – available here:

http://www.vmware.com/products/datacenter-virtualization/vsphere/upgrade-center/vsphere-license-validator-script.html

Al Renouf over at Virtu-Al.net has written a very easy to use PowerCli script that’ll generate a nice pretty html report to show you how you will be affected.

Running a report, using the revised model has taken me from being 80% of the way through my entitlement (serious Oh $h!t moment – seeing as we are adding another 30% to our environment in upcoming months), to a very realistic 41% – therefore totally nullifying the impact of the license upgrade for me.

So here I stand:

Pooled vRam Capacity: 24576 GB
Number of VMs Powered On: 1623
Current vRam usage: 10065 GB
Percent vRam usage: 41%
Number of VMs if all were Powered on: 1692
vRam usage if all VMs were Powered on: 10525 GB
Percent vRam usage if all VMs were Powered on: 43%

Happy days . . .

BRAVO VMWARE – GOOD WORK YET AGAIN!

Categories: VMWare Tags:

vSphere 5 – the licensing bug . . .

July 15th, 2011 No comments

So I have been rather quiet this week – which is strange, given that vSphere 5 has been announced(of course the worst kept secret ever)
Much like everyone else though, I have been very surprised by the licensing statements and not in the least bit surprised by the backlash.

Absolutely, I 100% agree that VMware may well have opened the door here for other Hypervisors – though not in all cases.
There are some major restrictions in this licensing design.
Firstly, 8GB of ram on the free version? Hmm, not great really – that’s not enough capacity to test drive anything in any lab environment? We all know that pretty much any server you purchase anywhere (even for small businesses) has at least 8GB of Ram in it. So if I am considering consolidating, my 4/5 server environment, I can not even have a free license for a length of time that can create a replica of my environment (ye sI am sure there will still be free trials etc, but these are limited time and so on)

Next, we are deep into a project, for desktop visualization – we have been looking at some pretty clever tools (FusionIO / Atlantis ILIO and so on) – but this new licensing change makes ESXi as the hypervisor VERY unappealing. Our desktops typically run low on CPU, but due to the number of VMs we create, consume a fair amount of memory. The Dell 910s we have bought have been very appealing as hardware for this, as we can cram a bunch of Ram in them and the CPUs are sufficient, but as the new license only allocates 48GB for each of our CPU licenses, it appears that this no longer works.

To save myself panicking too much, I decided to look into the current licensing in my environment, and that when we move(if we move to vSphere 5) and was horrified to learn that we currently have room for about 100% capacity expansion – without putting any clusters at risk(nice position to be in) – but once the license format changes, we can only use up 50% of that capacity? Yes, I know this means that I have less chance of over committing clusters and that I will finally be able to justify N+2 (or even N + 3) clusters as our licensing won;t allow us to go any further, but I must admit I am really disappointed with the way in which this has come forward.

I can appreciate that VMware have spent a lot of time / money developing the product and that when this all started, a 12 to 1 consolidation ration was considered acceptable. I realise we now consolidate at 40 / 50 to 1 and don;t have any issues and that this is largely to do with progress in CPU. So I know that form VMware’s point of view, licensing per socket becomes less and less appealing as CPUs get more cores, mores threads and so, but much like every other blog post I have read, I really think they are doing this too early and opening the door to the competition.

It takes huge balls to do this – they are taking a huge risk (I am sure they know) VMware have the best product (FACT) – but they are exposing themselves to losing the business from small companies that will have reduced consolidation ratios, SMEs – that simply can’t afford to upgrade and re-license environments that are probably running at memory limits and also large companies that have time to review and revise licensing (especially in line with products like Hyper-V being licensed under enterprise agreements etc)

I guess that going forward, those HP Blades that can have a single blade with 1TB of RAM won’t be very appealing as ESX hosts and scaling out – more, lower spec ESX hosts will be the way forward – so expect bigger clusters and lower consolidation ratios (not all bad really as it means ESX maintenance has impact on fewer hosts) – but of course again this means increased costs. More network Points, More Power points, more rack space and so on and so forth.

In short – I don’t like it :-(

It is going to be interesting to see which way this goes – I’ll grab some popcorn so long.

Categories: News, VMWare Tags:

Powershell – Converting multiple return values to single strings for reports

June 24th, 2011 No comments

Sometimes, you’re writing a little Powercli / Powershell code to generate a report and the repotr you generate retuns multiple values for some lines.

for example, you want a report showing each ESX host in your environment’s mapped VLANs and Datastores – or you’d like to interrogate some servers and return their DNSServers – as single objects.

[string]::Join is your friend here.

for example:

Get-VirtualPortGroup -VMHost $vmhost | %{$_.VlanId}
2598
2599
553
552
638
637
104
119
2470
2460
2951
2465
19
17
50
633
634
635
636

Hmm – this has returned a nice list – but I don;t want a new line for each VLAN.

so let’s join that into a comma sepated string?

[string]::Join(',',(Get-VirtualPortGroup -VMHost $vmhost | %{$_.VlanId}))
2598,2599,553,552,638,637,104,119,2470,2460,2951,2465,19,17,50,633,634,635,636

Ahh – much better!

so now I can generate my original report to find VLANs and Datastores mapped to hosts in my cluster

get-cluster $cluster | Get-VMHost | Select Name,
    @{N="VLAN";E={[string]::Join(',',(Get-VirtualPortGroup -VMHost $_ | %{$_.VlanId}))}},
    @{N="Datastore";E={[string]::Join(',',(Get-Datastore -VMHost $_ | %{$_.Name}))}}
Name                                              VLAN                                              Datastore
----                                              ----                                              ---------
LABESX8.get-virtual.info                         3410,3415,3430,3435,3425,3420,0,0,2640           LABSTG112L055,LABSTG112L062,LABSTG112L012..
labesx17.get-virtual.info                         3410,3415,2640,3425,3435,3430,3420,0,0,0         LABSTG112L055,LABSTG112L062,LABSTG112L099..
labesx18.get-virtual.info                         3410,3415,3430,3435,3425,3420,0,0,2640           LABSTG112L055,LABSTG112L062,LABSTG112L099..
labesx21.get-virtual.info                         3410,3415,2640,3435,3430,3425,3420,0,0           LABSTG112L055,LABSTG919119,LABSTGHA919L116_FI,..
labesx40.get-virtual.info                         3410,3415,2640,3435,3430,3425,3420,0,0           LABSTG112L055,LABSTG112L062,LABSTG112L099..
labesx25.get-virtual.info                         3410,3415,2640,3435,3430,3420,3425,0,0           LABSTG112L055,LABSTG919119,LABSTGHA919L116_FI,..

the magic lies here:

[string]::Join(',',(

What this is saying is joing the response from the following queery – into 1 string . .seperated by ‘,’

job done – pretty reports here we come!

Categories: Powershell, VMWare Tags: