I’ve used this process multiple times to create quick Docker host VMs running on VMware Workstation in my home lab. It is important to note that although I’m using VMware Workstation, the type 2 hypervisor you use here is fairly unimportant. You could just as well use VirtualBox, or Fusion for this purpose.
Create a new Virtual Machine for your Docker host using your type 2 hypervisor software (Workstation in my case).
Give the VM following hardware/spec:
OS – Linux/uBuntu 64bit
1 or 2 vCPUs
512 MB RAM
2 x vNICs (1st is set to the default NAT option and the 2nd should be set to Host-only)
Here is my VM’s setup:
Attach the uBuntu ISO and start the VM up.
Install a standard uBuntu OS using the text based installer, and just be sure to also install OpenSSH server when prompted for features to install. After the install completes, reboot, login with your user account you created during install, run ‘ifconfig’ to check the assigned IP address, and then use your favourite SSH client to connect to that IP. Using a PuTTy session will just make copy/pasting commands into your uBuntu VM easier.
Now you’ll install docker – the package includes both the docker server and client.
Run the commands above in sequence, and after the apt-get install docker-engine at the end, run ‘sudo service docker status’ to check that docker is running. You should see it listed as Active (running)
● docker.service – Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2016-07-06 21:20:39 BST; 2h 0min ago
Run a quick ‘docker info’ command to ensure that you get information back from Docker and that everything looks OK.
I had a storage outage to deal with recently, and after the datastores on this storage were taken down, a vCenter Server Appliance VM on the storage got some corrupted files and would not boot. Upon start up, I was greeted with this message:
The error message reads:
fsck failed. Please repair manually and reboot. The root
file system is currently mounted read-only. To remount it
After trying the mount command using the maintenance mode bash shell, I restarted and found that the appliance still did not boot properly. I found a thread on the VMware community forums where someone had the same issue and was able to run e2fsck to fix the disk issues. I tried this and found it fixed a whole heap of disk errors on the /dev/sda3 mount, but on restart I noticed more issues on the /dev/sdb2 mount, so I ran the e2fsck command again for this path, and was able to finally reboot the appliance successfully. The commands I ran to resolve were essentially:
mount -n -o remount,rw /
e2fsck -y /dev/sda3
e2fsck -y /dev/sdb2
CTRL-D to reboot after fixing the errors using e2fsck
I’ve recently been updating firmware on some development and testing storage and found that the HP P2000 storage array firmware update TS251R004 and above enable the HP P2000 G3 FC enable T10 compliance for the hardware.
To quote VMware’s documentation on their VAAI implementation specific to T10 compliance:
The second required component can be referred to as a VAAI plug-in specific to the VAAI filter. It implements vendor-specific VAAI functions such as ATS, XCOPY and WRITE_SAME. There were different implementations of the VAAI block primitives in vSphere 4.1, but all of the primitives in vSphere 5.0 have been ratified by T10, so any array that is T10 compliant should be able to use VAAI.
This means that you no longer need to be running the HP P2000 VAAI plugin software directly on ESXi hosts. In fact, HP recommend you uninstall and remove the plugin software before you upgrade the firmware on these arrays, otherwise you could suffer from performance degradation and possible loss of access to datastores.
My process was to first of all login to all hosts and check for the presence of the VAAI plugin.
SSH into host as root, run find / -name hp_vaaip_p2000
Ensure that nothing comes up with the find command, if it does (you see something like this output: /usr/lib/vmware/vmkmod/hp_vaaip_p2000), then you should use this HP document to ensure it is removed correctly: https://h20566.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=4118559&docId=mmr_kc-0123414&docLocale=en_US – this will involve some setting changes, and removing claim rules as well as removal of the HP P2000 VAAI VIB itself.
After verifying nothing came up, check other hosts, and once happy all hosts are clear of the plugin, upgrade the firmware for the P2000 system.
Ideally reboot ESXi hosts after the firmware update and ensure access to datastores is still there. Check the hardware acceleration status of datastores – they should show up as “Supported”.
I recently did a presentation at the South West VMUG on VMware vSphere community (free) health check options. In my presentation I covered some of the options available out there at the moment such as:
vCheck (vSphere plugins)
vGhetto health check script
Miscellaneous PowerCLI / PowerShell options
The second half of my presentation I dived into a live PowerCLI and PowerShell demo where I demonstrated some PowerCLI basics to get any kind of information out of your vSphere environment using some of the core cmdlets. I demonstrated use of the core PowerCLI cmdlets used for retrieving VM, Host and Datastore information, how to use the pipeline in PowerShell, and taking a look at all properties on any PS object using the Get-Member cmdlet on the pipeline.
After covering these basics, I took a blank vCheck plugin template, and showed how easy it is to create your own custom plugins for vCheck should you find that the existing plugins don’t cover everything you need.
I’ve got a link to download the slides for the presentation below, and hopefully I’ll be able to find a recording of the PowerCLI / PowerShell live demo I did to attach to this post as a follow up.
If you’re based in the South West of the UK, be sure to check out and attend the next SW VMUG meeting!
A change I noticed right away between vSphere 5.5 and vSphere 6.0 is the introduction of a default limiter when it comes to performing database queries for performance metrics.
When querying vCenter 6.0 for performance data, there is a system in place by default that limits the number of entities that are included in a database query. As performance charts in the vSphere Web and C# client depend on this performance data, you may sometimes see an error when attempting to view overview or advanced charts because of this change.
In my case, I am using some custom code to query performance metrics using vSphere APIs and noticed the issue right away, as I was trying to gather a large amount of data.
VMware state that the reason for the change is to protect the vCenter database from receiving intensive or large queries.
If you wish to work around this, or remove the limit, you’ll need to introduce a new key/value pair advanced setting in the advanced settings area for your vCenter server instance. The key should be named “config.vpxd.stats.maxQueryMetrics” (without the quotes) and should have a value set of -1 to disable the limit. This could also be set to a value of 100 for example to limit the entities included in a database query to 100.
A further edit should be made to the web.xml file, however in my case I was not concerned with the limit affecting the client, as I was using the API, and making the first change seemed to do the trick for me.
I’ve not had a lot of luck in the past with updating my VMware Fusion installs. Since version 5.x and upwards through to 6.x I’ve always had some annoying bugs or issues crop up when updating Fusion on my work machine. Whether these be relating to functionality I am used to changing, or bugs that interfere with my use of the software, there has always been something that goes wrong when I update.
So here is some general advice for when a new update for Fusion appears (this is what I now do before updating to the latest and so-called greatest version!)
Wait. Don’t update as soon as the new release is out. I generally wait about a month now. Generally this should be enough time for the Fusion team to correct initial problems with releases and give them time to submit a follow up patch to fix issues.
Keep tabs on the VMware communities forums for Fusion – users will often post issues with new releases here – judging on how much activity appears after a new release, you can generally tell whether its been a bad release or not.
Read the release notes in detail. Does the new release really give you any benefit? Have they patched vulnerabilities, or just simply added more features? What existing issues have been fixed? Make your decision to update based on the release notes. Sometimes a new release might not add any value for the way you use the product, and may add 10 new features. You can almost be sure that at least one of those new features is bound to introduce some sort of bug. (This is the nature of new features being added to any software in general, not just Fusion!)