Archive | technical

VMware Fusion, VM Power states, and you

Or, better living through manually editing what should damn well be a toggle box in a GUI

One of the things that I have to do at ${dayjob} is build distributable VMs. And my preferred way of doing this is by using the VMware OVF Tool to convert/sanitize the guest ‘machine’ configuration and produce a clean copy of whatever I build. Today I noticed that VMs which I’ve exported to OVF format and then reimported into VMware Fusion could no longer be soft-powered down; nothing but the virtual equivalent of slamming the power button or unplugging a machine.


But upon digging a little further into that description of default power states, I found the following:

Virtual machines created in other VMware products might default to hard power options.
These commands act on the virtual machine the way the power and reset buttons work
on a physical computer’s power supply.

Well. There’s the problem. But how do we fix it? The doc says that in VMware Fusion we can hold alt while clicking on the Virtual Machine menu option, but that’s just kicking the can down the road.

It turns out that Darren Woollard has already mostly solved this particular problem1. It looks like a few flags need to be added to the VMX file (don’t panic if you’ve never edited one of these things. It’s just a big long ini file with some goofy looking keys. Here’s the Party Line about editing a VMX file, straight from the horses mouth).

Here’s what needs to be added to the VMX file of imported generic OVAs for Soft Power Operations to work on your newly minted Virtual Machine instance:

powerType.powerOff = "soft"
powerType.powerOn = "soft"
powerType.suspend = "soft"
powerType.reset = "soft"

Save your VMX file, and if necessary restart your VMware product (Fusion, Workstation, Player, whatever). You should now see the safer Soft Power options instead of the big hammer of Force Shut Down, etc.

  1. I’d like this to work on import, without a user having to edit anything. I’m investigating using VMware Studio to cut new releases, but I’ve got no data behind that plan yet. 

Software trends that puzzle me: today, it’s ‘one-line installations’

Maybe my UNIX neckbeard is showing, but the trend of one-line installations confuses me. I guess it’s not fundamentally different than installing whatever random packages you found from some no-name repository, and no admin should be installing things blindly (packaged or otherwise). But it just seems like such an invitation to disaster because if you follow these methods to the letter then you’re executing unread scripts live across the wire. It seems like the sort of thing a developer would whip up for convenience, but I see a ton of admins embracing them now that the trend is loose in the wild.

How about some examples? With pictures!


Here’s an example from Docker, which maybe I’m interested in using for a project at $DAYJOB:

curl | sh -x


OK, so that’s a thing… at least it’s going run that shell in debug mode so you will see what it’s doing.

Ruby Version Manager

Here’s how RVM suggests you install it:

\curl -L | bash


Another instance of “Grab this straight across the wire, and dump it directly into a shell! Do not pass go! Do not bother running this through any sort of sanity check!” I do like that this at least uses the slash in front of curl to make sure you’re not inheriting any aliases when you run it. I guess that that’s considerate of the maintainers?


Over in OS X land, Homebrew also has a one-line installation:

ruby -e "$(curl -fsSL"


I like this one! “Run this curl mess in a subshell, and then feed that into Ruby. Install away!”

What’s the big deal, guy? Just runs them scripts and shuts up.


Inner monologue, you’re a jerk. None of this is a big deal. But these things bug the hell out of me. For starters, I don’t know which irks me more about all of these methods: the use of UNIX-style non-descriptive short flags instead of GNU-style descriptive long flags1, or the fact that there’s no immediately visible validation in these pipelines.

The docs for these tools always say you’re welcome (encouraged!) to download the installation scripts and read them for yourself (which I do — they’re actually very well written and they usually accommodate a lot of the sanity checks and edge cases well) but I know that there’s many, many admins and developers who don’t.

And that’s horrifying.

And it seems like part of a broader trend towards super-dickery2. Along similar lines but without falling victim to the one-line installation trend,RBenv is just sort of dickish (in a short pants, school-boy kind of way) about wanting to know what your shell is doing3.

So what?

YOU GUYS, I can’t run this stuff as-is at $DAYJOB. For any one of these examples I’m going to have to fetch that installation script and save it locally. Then I’m going to have to inspect it and work out what remote resources that script is running. Then I have to figure out how to shove these tools into packages because we version EVERYTHING through packages at $DAYJOB. Science forbid these tools make naive assumptions about their target environment (Hey RVM, storing everything in my home directory is a problem if that home directory is a space-constrained network share; let’s not even talk about I/O if there’s network congestion or disk contention on the remote filer…).

And if there’s any releases/changes/improvements made to these one-line installation scripts between when I ran them in my development environments and when someone (WHO ~~DOESN’T LISTEN~~ IS ILLITERATE) runs them in my production environments then I’ll never see them until/unless I use the one-line method (which then silently introduces the dread environment drift). Put another way, one-line installations make installing the same version of a tool across multiple environments just a little bit trickier.

But I guess that the biggest concern I have is “why did someone think this would be OK?”

  1. GNU-style long flags & options are probably my favorite contribution from the whole of old man Stallman’s GNU project. They’re fantastic when editing/reviewing old shell scripts since they save me/you/everyone we know the hassle of looking up an array of arcane short flags. 
  2. I think of super-dickery as being the act of being an asshole without provocation, based solely on the assumption that the other party is not as smart as you think you are; I am guilty of this more often than not. Also, you know, Superman is a dick. 
  3. I like a good tongue-in-cheek README and I like a strong editorial voice, but this README actually comes across as slightly derisive if you’re trying to take admin-fu seriously. I think that the line “Skip this section unless you must know what every line in your shell profile is doing” is needlessly dismissive, and that’s pants. YMMV, caveat lector, etc.