Turbonomic: Network keeps dying when using static IP...

Deployed a new Turbonomic OVA 5.8.3 for some testing.  Logged into appliance via console, ran 'ipsetup' as instructed w/ 'static' selected.  VM stayed online for about 5 min. before dying.

Assuming DHCP is not an option, you simply need to change the 'bootpromo' entry from 'static' to 'none'  in the /etc/sysconfig/network-scripts/ifcfg-eth0 configuration file.

At some point it was likely that Turbonomic upgraded their OS instance, but failed to take into account a change in the OS' option 'static' being no longer a valid value and has been replaced w/ 'none'.  Seems to affect newer versions of linux OS'.  This will likely be fixed sooner rather than later.

Powershell: How to get REST API data in JSON format rather than XML using invoke-restmethod

I was exploring a REST API interface for an internal tool being built.  Being that I'm so accustomed to powershell, I wanted to explore how I could get data from it.  The Invoke-RestMethod is perfect for this, but I was having issues getting data back in straight json format.  Data kept coming back in ugly as hell xml format by default.

The short answer was that I need to make a hash table to pass to the -Header parameter of the invoke-method cmdlet.  Basically, it looks like this:

$Headers = @{"Accept" = "application/json"}
Invoke-RestMethod -URI "https://myrestapi/endpoint" -Method:Get -Headers $Headers 

Once I did this, I received the data back in json format and powershell automatically captures it as a system.array object.  Making it immensely easier to work with rather than the xml return.  See below pictures as examples of the difference.
Json returned data.

xml returned data
As you can see, the return I received when in json looks like any other object return from something like powercli whereas the xml return is this ridiculous mess.  Not all Rest API endpoints work in the same fashion.  Some will return json by default, but listing the "Accept" = "application/json" in your request header doesn't seem to hurt those that don't unless you want a different type of return.

VMware: ESXi 6 503 Service Unavailable endpoint: [N7Vmacore4Http16LocalServiceSpecE:0x1f098b08] _serverNamespace = / _isRedirect = false _port = 8309)

Basically I enabled SR-IOV on the only two pNIC's I had in my ESXi host in my lab.  This doesn't necessarily cause a connectivity problem, but the ESXi management agents did not like this at all.  Meaning I could connect to my hosts, as evident in the error message, but the agents basically broke once SR-IOV was enabled on the only two physical uplinks I had.

Unfortunately, the only workaround I've found is to:

  • "Reset System Configuration" from DCUI
    • This basically bring ESXi back to default install config.  root password is blanked out, etc. etc.
  • Re-Deploy the host. 
For my testing though, I can enable on one of the physical uplinks and work w/ that just fine, just not both in my case.  The other aspect that I didn't realize is that the CNA cards I was using lose their Fiber Channel connectvity as well.

SR-IOV effectively changed my CNA cards to NIC adapters only.

ESXi 6.0 Build 5050593
Dell FX2 - FC630 - Qlogic 57810 adapters

Chrome: On MacOS downloads .OVA files as OVF's.

I must not download OVA's all that often.  When I do though, Chrome decides that "nah" you should name that into OVF.  Seems to be a long standing bug w/ Chrome and MacOS.  Not really a huge problem until a you try to import the OVA w/ the file extension of OVF.

Error when trying to import:
Basically the error returned when trying to import an OVA w/ OVF file extension:
"Failed to open OVF descriptor"

Workaround 1:
Stop using Chrome...Haha, just kidding.
On macOS, you simply have to enable "Show all filename extensions" in Finder.

    • You'll usually find this icon in your dock.  Probably the most under-stated/used icon in your dock.

Once done, Chrome will download OVA's as is and not change it to OVF like a proper browser.  Honestly, if Chrome does it for OVA's it "might" do it for other file extensions as well.  Firefox and Safari don't have this problem, so if you use either of those, Bravo!

Workaround 2:
Uncheck the "Ask to save each file before downloading" box in Chrome's Advanced Settings.  This bypasses Chrome's macOS finder integration which seems to be the root of the problem.

Reference bug:

PowerCLI/Powershell: vCenter Slack Bot

An OVF from Opvizor that gets deployed to any VMware environment for powercli slack integration.  Very simple deployment model.  
Current Model:
  1. Appliance can currently only target one vCenter and one slack bot.
  2. Permissions are granted via account designated in OVF config. 
    • (read only recommended for obvious reasons)
    • all commands requested via slack bot run in context of this account.
  3. Multiple appliances/vCenters can target one slack bot. 
    • (Ref.1 of two appliances/vcenter targeting one slack bot)
  4. Appliances can also be assigned to individually different slack bots. 
    • (Ref.2 of two different slack bots)
  5. Both models can be achieved by simply doubling up OVF deployments.  One that targets a singular bot, while the other targets a default/catch-all bot.
  6. Utilizes powerclicore so, there are limitations to what powercli cmdlets can be utilized and same limits that powershellcore may have too.


Neat Tidbit:
  1. Not yet in "Help", but there is a little neat 'alias' function.
    • @yourbotname alias badvms=posh get-view -ViewType VirtualMachine -Filter @{'RunTime.ConnectionState'='disconnected|inaccessible|invalid|orphaned'} | select name
    • @yourbotname badvms
  2. This will run your PowerCLI/Powershell line of code by simply passing your alias. (ref.3)