NetApp VSC Performance

This is related to the 4.2.2 version.  Essentially, the JVM that is installed for the NetApp VSC, defaults to the following:

  1. Initial Heap Size : 64MB
  2. Max Heap Size: 1024MB
What does this mean?  It means that if you deploy a VM w/ 8GB of RAM to install VSC on, it will only EVER use 1GB of RAM.  The VSC (4.2.2) also tends to have performance issues when dealing w/ larger environments.  There is an article somewhere, but I can't find it for the life of me right now.  Anyway to fix this issue, you need to modify the wrapper.conf file.

This is typically in the installation directory of C:\Program Files\NetApp\Virtual Storage Console\wrapper\wrapper.conf

The lines you need to modify are:

# Initial Java Heap Size (in MB)

# Maximum Java Heap Size (in MB)

Now you 'can' up the heap to 4GB max if you think it needs it, but I'd recommend looking @ "Active Memory" stats of the VM this VSC runs on to make sure it 'actually' needs that much.  I found in my environment (2000+ VM's), I didn't need to go above this number since it never breached more than 3.5GB.  Since it was staying steady around 3GB, I decided to change the initial heap to 3GB so it wouldn't have to keep building it up on startup.

Later version of VSC 'might' not have this same issue, but you can this same logic if it does.

Extra Note:
You may need to apply this to the NetApp SnapManager Service as well, that is located in:
C:\Program Files\NetApp\Virtual Storage Console\smvi\server\etc\wrapper.conf

vCenter Client for Mac/Linux!? No, not completely, but a most useful tool.

I was lucky enough to play w/ some early builds that Steve put together and now it's finally a 1.0 product.  I highly recommend downloading and playing with it in the very least.  It is a free download.

The one bug that I remember reporting, that doesn't appear to have been fixed yet though is that the client doesn't understand folders in the hosts & clusters view.  So if you have clusters/hosts in folders, it will not enumerate those in the client.  So it's rather useless to me currently, but should work fine for most people.

You can read more about it here:

Download here:

vSphere NFS Connection Status Alarm Auto-Remediation

One minor annoyance I had when moving to a new company was a load of alerts that were simply noise.  Not to anyone's fault, but simply poor default VMware implementation.

VMware comes packaged w/ an alert to notify when a storage path is down.  The problem is that, that's all it does.  So say you have the SNMP traps generated from that to create a ticket.  Great, now you have a ticket, but little did you know that the problem fixed itself via some failover method.

So now you have a ticket, you were woken up in the middle of the night for something that was benign.  Wouldn't it be great if another SNMP trap were sent that said "Hey, I'm ok now, close out the ticket"?

The assumption is that the SNMP trap collector, like HP's BSM/SiteScope tool, were smart enough to associate a trap to the same alarm.  Which, in my case, it does.  So here is how I redesigned an NFS alarm to send trap stating a problem and then having that alarm send a trap designating everything is ok.

Some interesting results from the Project VRC State of VDI/SBC Survey

I can't publish all the results, but they will be available here on March 24th, 2015.

Here are two that I found rather interesting that I can publish early:

XenDesktop seems to be the incumbent VDI solution for the survey respondents.  I knew that Citrix had been around a long time, but still rather surprised that it's still trumping VMware's Horizon View.  I probably shouldn't be though as Citrix has always advertised their solution very well and feature functionality always seems to be ahead of View.  Although, seeing XenDesktop in practice on vSphere infrastructure doesn't give me the warm and fuzzy's especially leading into the next question.
How updates are installed/updated/managed responses doesn't really surprise me, but it does bother me.  Manually updating images seems so archaic and I'm quite frankly surprised that VMware hasn't made updating Parent VM's a more automated process.  Being that the respondents were also Citrix heavy, I feel this bodes poorly for their product on the automated operations front as well.

The only way I've hypothesized to update parent VM's in a somewhat automated process is to:

  1. power-up the parent VM 
  2. query SCCM for the related VM 
  3. wait for a 'success' of applicable 'some time window' updates.  
  4. Power off VM
  5. Snapshot it
  6. Delete old snapshots (based on some time window and count)
  7. WinRM call powerCLI cmdlets on View Brokers to then associate pool to new snapshot.

I think if I remember correctly, doing that last step was not possible or somewhat very difficult because the cmdlets didn't have this capability.  Something to look into again I suppose.  I also have thoughts on using WinRM in a 'cloud' fashion against View Brokers.  I'm working on an article that I'll publish later w/ my thoughts and practical application of this thought.

Counts of VM's running specific OS types

This was a fun little exercise for me in getting a count of VM's per OS type spawned off by a question in the vmware communities board.  The result would look something like this:

It's quite simple and probably could be written a bit more efficiently, but ran sufficiently fast enough for me.

$TotalVMs = Get-View -ViewType VirtualMachine -Property Name,'Summary.Config.GuestFullName'
$OSFilters = $TotalVMs | select -ExpandProperty summary | select -expandproperty config | select -unique guestfullname | sort

$MyCustomReport = New-Object PSObject
Foreach ($OSFilter in $OSFilters)
     {$MyCustomReport | Add-Member -Name $OSFilter.GuestFullName -MemberType NoteProperty -Value ($totalvms | select -expandproperty summary | select -expandproperty config | where {$_.GuestFullName -eq $OSFilter.guestfullname}).count}
$MyCustomReport | Add-member -Name Total -MemberType NoteProperty -Value $TotalVMs.Count