Monday, March 14, 2016
VMware has just updated, re-titled, and published "Architecting Microsoft SQL Server on VMware vSphere -- Best Practices Guide."
There looks to be some pretty good information within, so get comfortable and grab the PDF here.
Wednesday, December 9, 2015
If you are configuring vSphere hosts for syslog collection you may be overwhelmed by the amount of data thrown at your collector. By default hostd and vpxa are configured for a logging level of “verbose.”
To view the configuration for all of your vSphere hosts, break out PowerCLI. I’m forever forgetting how to retrieve information from certain cmdlets and include the host name. Here it is for me to find again:
Setting hostd and vpxa logging levels on all hosts to “info” is pretty easy:
Friday, October 30, 2015
Queue DeflationI’m rather red-faced right now. I chimed in with a reply in the VMTN VMware vSphere PowerCLI forum and promptly got schooled.
Which is great; these things should happen.
Where’s the Template?In this thread, VMTN Communities member denjoh44 asked how one would obtain a list of templates along with the name of the vSphere hosts on which they reside.
I haven’t had the need to do this myself, but I wanted to give it a shot. I fired up PowerShell ISE and plugged away:
And it works, which is nice.
I See Your 12 Lines and…It wasn’t long after that I revisited the thread only to find a much more elegant solution posted by Christophe Calvet:
My personality dictates that I should feel silly about my reply. Christophe nailed it with a one-liner. Instead, I’m going to focus on my inexperience with Get-View and do some reading. I'll endeavor to always keep calculated expressions in mind as well.
Time to LearnBrian Graf has a 3-part blog series on Get-View which I’ve seen before and marked for reading in more detail “later.” If you are interested in learning more about Get-View, start here:
- Get-View Part 1: Introduction
- Get-View Part 2: Views and Extension Data
- Get-View Part 3: Performance Impact
Tuesday, October 6, 2015
The Best IntentionsIt was obvious and natural; the Right Thing to do. In preparation for a deployment across all vSphere hosts we took the step of insuring the latest updates. And since we are running vSphere 5.5, this meant Update 3.
There was even some chest-thumping among our small team of generalists as they completed the task within short order. And why not?
That was Short-LivedWithin 2 weeks we were crestfallen. Update 3 introduced a service-impacting defect involving seldom-used (sic) snapshots. KB 2133118 was released to announce "unexpected signal: 11." Consolidate or delete a snapshot and you may suffer a VM outage.
To be honest, I find the KB lacking in details--there are no specifics to indicate contributing factors or degree of impact across customers.
A New Hope?While we haven't been impacted (whew!), I'm happy to see that today brings the release of patch ESXi550-201510401-BG to address this issue.
Fire up Update Manager and start patching! Let us know how it goes, because I'm not sure that we wish to be first on this one.
Thursday, September 24, 2015
I’d like to say that I work with virtualization every day, and in a way I do. Virtually every server in my employer’s environment is virtualized (see what I did there?).
That we are a small team in an SME environment dictates that we are I.T. generalists. That’s not a curse—that’s variety and opportunity alleviating the mundane. It’s also an opportunity to automate the mundane.
For the purposes of user provisioning I wanted to use PowerShell for identity management on a shoestring budget. As with many things, creating is harder than destroying; this provisioning needs a GUI. Pick an OU, pick a user/template, and copy with new details. While that’s how I got to the point of driving a GUI with PowerShell, it’s difficult to effectively convey a company-specific workflow. So I’ll demonstrate with something virtualization-focused.
With a little bit of Googling I found an older option or two along with .NET-based Windows Presentation Foundation (WPF). .NET this plus .NET that sounded appealing with me, so I dug in further.
There are solid posts to be found that give you all that you need. I’m working against some of my musings, so here I share my journey toward the same end result.
At a higher level the process is relatively simple:
- Generate a GUI form in Extensible Application Markup Language (XAML).
- Load the XAML in PowerShell with some minor (automated) transformations.
- Instantiate the WPF form.
- Create variables for working with our GUI elements.
- Define PowerShell event handlers for each GUI element, incorporating our workflow within.
Generating Your GUI’s XAMLTo generate the GUI we need something that will generate XAML that WPF can handle. Anything from Visual Studio 2010 on up will do here. I used Visual Studio 2015 Community since it is full featured with an investment of $0.
Open Visual Studio and create a new project. Choose WPF Application under Visual C# Templates and give it a name. Any name will do—we only want the XAML which this project will generate.
What you will notice is a blank window in the main center pane, labeled MainWindow.xaml. The pane below contains the XAML in which we are interested.
I find it best to turn on the toolbox from the View menu and pin it to the side bar this yields an environment tailored for creating window forms.
Let’s use the toolbox to drag and position a few controls:
- A ComboBox selector for Cluster
- A DataGrid to display VMs within a selected Cluster.
- A Button for launching a selected VM’s console.
- A Label or three for clarity.
With each control use the properties pane and give it a unique name, which we will use later to bind to PowerShell variables. I like to start all label control names with “label_” for easier exclusion from this binding process.
Loading the XAMLAll we need from Visual Studio is the XAML, which we will copy and paste into a PowerShell here-string. The string isn’t perfect for PowerShell processing yet, so we’ll also rework it to take care of these issues and cast as XML:
Instantiating the GUI Form
Next we need to load the PresentationFramework assembly and process our form so that it can be presented:
Creating GUI Variables
We need to be able to work with the controls on form that comprise our GUI, and that means variables that let us get/set values and work with other properties and methods afforded to us by WPF.
We can do this rather handily in PowerShell by invoking Set-Variable for nodes within the XML that comprises our form. The iteration of those nodes will return Label controls as well, which we’ll ignore based on giving them a prefix of “Label_”, which was mentioned earlier:
Defining Event Handlers
WPF will send asynchronous signals (events) to our script when the GUI is acted upon. Examples include when a selection is made, a button is clicked, and when the window is instantiated or destroyed.
Defining event handler functions in our PowerShell lets us dictate our workflow:
- When the window is created, connect to vCenter, get a list of clusters, and populate the cluster ComboBox.
- When a selection is made in the cluster ComboBox, get a list of cluster VMs and populate the details DataGrid.
- When a VM selection is made in the DataGrid, enable the console Button.
- When the console Button is clicked, launch a vSphere Remote Console window.
- When the window is closed, disconnect from vCenter
Final BitsThere’s not much left! Define the vCenter server against which we will operate and display the form:
RevealRun this little puppy and off we go. Pick a cluster from the drop-down to see a list of VMs and click the column headers to if you don’t like it ordered by VM name. Choose a VM and the console button becomes active so long as the VM state is “PoweredOn.”
- My error checking and validations are non-existent--Add some.
- Add another button to perform another task.
- Change what VM properties appear in the DataGrid.
- Do something else and have fun with it!
Full CodeYou can grab the full code from here.
Proper Attribution is Proper
- Stephen Owen’s XAML to GUI
- The Scripting Guys’ I've Got a PowerShell Secret: Adding a GUI to Scripts
Thursday, September 17, 2015
That's not the case for everyone, of course, but it holds true for me. If you know me on a personal or professional level you've heard me say this before. The odd thing is, I enjoy writing. And because of that I tend to focus on this topic.
I have reasons not to write.
It's a silly idea/topic/thoughtThis is a powerful one for me and stops me the most often. It's also the quickest way out. I question myself by nature, so there's no surprise here. I'm still not certain that I'll hit publish on this post!
Suck it up and write anyway.
It's never quite rightOne of the things that I enjoy most in the writings of others is the multitude of ways to say the same thing. The simplicity of some, the eloquence of others. Let's not even talk about grammar, misspellings, etc. Whether I'm writing here or within the corporate walls, I can tell you that I've reworked virtually every paragraph multiple times.
Practice makes perfect? No, but it certainly improves.
Others have already written about thisWhy bother covering a topic that so many others already have? Fear of getting lost among similar technical articles and not managing to stand out.
Not to be glib, but meh--one more can't hurt.
TimeHow do others find the time? I'm up early and put in long days. There is often weekend work. Around it all I must find time for family. There needs to be wind-down time and sleep in there somewhere.
Others do it. There are ways. Give up a little time that's normally spent by myself anyway.
Why have I shared this? Certainly it is therapeutic to a degree and I can refer to it in the future to push me forward.
But that's not my hope.
I want to reach someone else and push them forward. I'm an avid reader of blogs, sometimes churning through dozens a day. I make it part of my daily routine. I thoroughly enjoy reading what others have to say.
If you are like me, I'd like you to write--or write more.
Because I'd like to read what you have to say.