Getting VitalSource Bookshelf to work with a Virtual Machine

All current VMware class materials are delivered via VitalSource Bookshelf.  It's pretty good for digital book software (still doesn't go much beyond what you can do with a paper book, but that is another article).  If, like me, you run VitalSource on a virtual machine, you may have noticed after a recent upgrade you can't open your books anymore, you just get a grey screen.

After doing some digging, I discovered this is because the new version of the software requires DirectX 10 (yes, for a book).  https://support.vitalsource.com/hc/en-us/sections/200390856-Troubleshooting

The default VMware SVGA driver doesn't support DirectX 10, however the solution is pretty simple, just enable 3D Graphics.

The challenge of teaching with Powerpoint

Generally when I teach a class, I try to tell a story, and use the slides as a background, rather than use the slides to tell a story.  Sometimes, when I'm relatively new to teaching a specific class I will use the slides as more of a crutch than I prefer however.  I also think that using a whiteboard, demoing, and engaging the students in a discussion is more effective than a simple slideshow.  It turns out a lot of people agree with me.  Here is a slideshow explaining why slideshows are not the best way to teach.  My favorite comment is ""Your slideshow by itself should be incomprehensible, because the most important part is what is not on the slides."  If the slides stand completely on their own, then instructors aren't necessary, and the students might as well be reading a book.

Digital slides are the scourge of higher education

Minor bug in vSphere Web Client autofilling the VLAN when creating portgroup.

While adding a new host in my home lab this week, I discovered a minor bug in the web client related to VLANs.  The VLAN dropdown will remember previous VLANs that you used, and try to autofill them.  Generally autofill isn't a problem, you just type a space to indicate you want a shorter version.  However this doesn't work as typing a space isn't an option for a VLAN.  So there is no way to indicate for instance that you want VLAN 30 instead of 300.  After some experimenting, I discovered that you can type in 030 and it will take it, and it'll work correctly.  That is however a workaround and not an ideal fix.  

Configuring Auto Deploy: Changing a host profile and checking compliance

I desperately needed a second host in my lab network, the primary host isn't overloaded in terms of resources, but in working on it I would sometimes have to restart it, which meant shutting down all of my VMs, some of which provided services for my home network (like the firewall to the outside world).  I dug up an old Dell Precision workstation that I haven't used in a while and decided to put it in to service.  I also figured it was time for me to gain some experience with Auto Deploy.
I used a combination of two great blog entries on setting up Auto Deploy as a starting guide.
     vSphere 5 Auto-deploy in 20 steps over at vClouds.nl
     Using vSphere 5 auto-deploy in your home lab from Duncan Epping over at Yellow-bricks.

Those entries got me through most of the setup, but after getting the host to boot up, I decided I wanted to make some changes to the image and the rules.  After adding changes to the ruleset, I had to test compliance to get the rules to update.  I was curious how I could verify the changes, so in my research, I came across a KB for troubleshooting Auto Deploy that pointed me to this page you can access on your autodeploy server

     http://autodeployserver:port/vmw/rdb/

From here I can look at registered hosts as well as the Auto Deploy cache information.  By selecting my host, prior to testing compliance of the rule set, I saw this information:

Notice that the PxeProfile that is cached does not match the new rule listed below it.  To test and repair the rule set, I ran the following commands:

     PowerCLI C:\> $tr = test-deployrulesetcompliance esxi50.starship.local
     PowerCLI C:\Program Files (x86)\VMware\Infrastructure\vSphere PowerCLI> $tr.itemlist
     CurrentItem                                                 ExpectedItem
     -----------                                                 ------------
     ESXi-5.1.0-799733-standard                                  ESXiHA

     PowerCLI C:\> Repair-DeployRuleSetCompliance $tr

At this point, if I go back to the host on the autodeploy page, I now see:

Notice that at this point the PxeProfile matches on the top and the bottom.  At this point when I reboot the host it will load the new image.

Seeing what exactly is in the PxeProfile is a little bit more tricky.  If you look in the cache, you can locate PxeProfile-2, and from there, determine the locate of the imgprofile.xml file location.  If you log in to the Auto Deploy server, in my case the VCVA, and go to /var/lib/rdb/cache and locate the file to view it's contents.

Playing around with Netflow on the vSphere Distributed Switch.

I'll start of this post by saying that I am not a Netflow expert, so I have a pretty steep learning curve here.  As with most things, I learn by finding all the available material I can, and then playing around with it to see if how it works matches my expectations.  I found very little primary documentation on Netflow in the vDS, so I had to do a lot of experimenting.

As of vSphere 5.1, the vDS supports Netflow v10, also known as IPFIX.   A flow consists of packets with the same source and destination ip addresses, ports, and protocol.  There are two flows for every connection, one in each direction. Basic information about the flow is then sent to the collector.  The collector is a third party solution that gathers the flow data and provides useful information to the network administrator.  In the vDS implementation, the information that is provided to the collector is the number of octets and packets.
(more information below the break)

Static vs Dynamic Port binding on the vSphere Distributed switch (vDS)

I've been playing around with port binding this week.  I will save ephemeral port binding for it's own post, as there is a lot more to it.  I'll also save port binding on the ESXi host until a later post, and focus on vCenter port binding.

Static Port binding is the default.  With static port binding a vnic is assigned a port with that vnic is placed in to the portgroup.  As long as the vnic is in the portgroup, it is consuming a port, regardless of whether it is turned on.  By default static portgroups are configured to be elastic so more ports can be added when you run out.  If they are fixed rather than elastic, when you try to add a vnic that exceeds the number of available ports, you will get an error message.

Dynamic port binding functions more like a standard switch.  It has been deprecated in favor of static port binding with elastic growth.  With dynamic port binding, a vnic is not assigned a port until the virtual machine is powered on.  That binding is maintained until the VM shuts down, at that point, the port becomes available again.  The vnic will have a preference for getting the same port when it's powered on, and other vnics will not use that port if they have another option, so it's sort of a "soft" static port binding.  The difference between the two does not become apparent until you use up all of your available ports.  First off, dynamic ports are not elastic, so the number of ports does not grow.  Secondly, as dynamic binding will allow you to assign more vnics to a portgroup than there are ports.  This means that if you consume all your available ports, and power on a VM, it will not get a port, and you will not get a warning.  The only way you will know this occured is that the VM does not communicate, and the connected box under edit settings is unchecked.

If all of the available ports have been used at least once, but some are available due to powered off VMs, then the vnic will get the next available port and "bump off" the vnic that was there before.  When the old vnic tried to connect in the future, it will look for a new port, and not have a preference for the old one, even if it is available.

The biggest reason that staying on the same port matters is gathering port level statistics.  With static binding, vDS port statistics persist across vMotions, reboots, and any other action that does not change portgroups. 

Neat trick for reaching an ESXi host when vmk0 is misconfigured

Last night while reconfiguring my network after my new layer 3 switch, I had to change the IP address of vmk0 on my ESXi host.   I had to change the IP, default gateway, and VLAN all in one go.  Apparently that doesn't actually worked, after making the changes and hitting Save, I could not ping the host with it's new IP address.  I have no local monitor on the host, and for some reason the IPMI console isn't working (that is a later troubleshooting step).

I'm pretty sure I know what's wrong, but how can I get in to the host to find out.  I do have ssh enabled, but of course can't reach vmk0.  So my next thought is how can I reach vmk1 (the iSCSI interface).  When you enable ssh, it's enabled on all interfaces, not just the management interface.  I didn't have any VMs on the storage subnet, but it turns out I can ssh in to my Synology Diskstation.  From there, I was able to ssh in to the iSCSI interface on the ESXi host.  Sure enough, the VLAN change and the default gateway didn't get updated, just the IP address.  After a quick change from the command line I was up and running:

# esxcfg-vswitch -v 30 -p "Management Network" vSwitch0
# esxcfg-route 10.10.30.1

I've used that trick before when I was working as an Escalation Engineer for VMware.  It's a very hand trick and saves a lot of time by not having to hook up a console (or in one customers case, driving 30 miles to the datacenter).  Of course, remote consoles are the better answer, as this trick only works if ssh is already enabled.