I’m using my rPI headless. Meaning no monitor, mouse and keyboard. Just an ethernet connection. And that is great, but then you need to have ssh access.. and by default that is not running. There are some small steps to have ssh running on boot, these are the steps (assumption is that your network has a DHCP service running)
insert SD card into your Windows / MacOS / Linux system
create a file named ‘ssh’ on the root partition.
Insert the SD card into the rPI
boot the rPI
check your DHCP service log for a new created IP lease
SSH to the IP found in the previous step Default username: pi, password: raspberry
A year ago, after following a few sessions at the dutch VMATechcon I decided to dive into the world of Ansible. With a background in industrial automation (programming PLCs) I have a soft spot for writing code. I saw the benefits of declarative languages, and decided to dive into Ansible. But where to start. And what should I use it for.
I’m working on a small VM which provides DHCP,DNS,TFTP,FTP,HTTP and NTP services so I can easily (PXE) boot nested ESXi hosts on VMware workstation and my homelab. All running in docker containers on Photon OS. For maintenance (and learning) I decided to use Ansible for building, running these containers.
One of the issues I had, was that I had to maintain the VM and the software installed on it… I’m quite proficient with Linux, but it can still be a challenge. And keeping installations logs update about how to install software… yeah…. that is an issue. A embraced the solutions docker, git and ansible are giving me. (And vagrant, when using VMware workstation).
Using docker to run the services, using ansible to automate workflows and using git to keep track of changes and store my code in my github repositories. With this approach I can easily rebuild the VM when it breaks down. And I see the VM more as a processing entity, then a virtual computer that needs to be maintained.
The Ansible container
browsing the internet I found this blog post about running ansible inside a docker container and using it interactively on the docker host. This gave me the possibility to have ‘portable’ ansible installation, without any ties to the VM OS. In my opinion it is great. With adding some small bash scripts so I don’t need to write something like ‘docker run -rm -it …..’ everytime, I have an ideal solution. The original code for the container is based on alpine:3.7 and python 2. Everytime I build the docker image I received a warning that python 2 is outdated…. so I (finaly) updated the dockerfile using alpine:3.11 as the base image and using python 3. You can find my code here on github, and the docker image here on dockerhub.
How to use
simple. There are 2 ways to use it.
clone git repository
pull image from dockerhub
Option 1, clone git repository
I’ve created a small installation script to make things easier. It will run docker build to build the ansible image and it will copy the scripts under ./scripts/ to /usr/local/bin/ And your all set… well almost
Option 2, pull image from dockerhub
Instead of building the image, you can pull it from dockerhub into your local docker environment. The scripts assume that the docker image is tagged like ansible:2.9.0, but when you pull it from dockerhub, the name is brtlvrs/ansible-helper:v.0.3. So you need to retag them (or edit the scripts).
docker image tag brtlvrs/ansible-helper:v.0.3 ansible:2.9.0
docker image tag ansible:2.9.0 ansible:latest
The wrapper scripts are stored in the image, in the folder /2installOnHost To copy them out of the image do the following
docker create -n test ansible:2.9.0
docker cp test:/2InstallOnHost/ah* /usr/local/bin/
chmod +x /usr/local/bin/ah*
docker rm test
This will create a docker container named test, using the imported image ansible:2.9.0. Then copies the files from inside the container to the /usr/local/bin/ and sets the executable bit on these files. Finally it removes the created docker container. Now you should be able to run ah or ah-playbook.
Both scripts will mount the folowing volumes into the container
needed to access localhost via ssh (ansible)
needed to access localhost via ssh (ansible)
Mountpoint is the default location inside the container.
Making the ansible logs persistent.
To make it work you need to do the following:
install docker-py on the docker host ( if you want ansible to be able to control docker)
add the ~/.ssh/id_rsa.pub content to ~/.ssh/authorized_keys file, so you don’t need to store the user password into the ansible inventory file.
An now it should work. Type ‘ah’ and you’ll enter a temporary docker container running ansible. Type ah-playbook and you’ll execute the command ansible-playbook inside a temporary docker container. Have fun.
Recently I discovered you can change the default ESXi DCUI screen. This feature is already present for a long time…. just check one of my favorite blog sites (virtualGhetto) for this item here. Yes he blogged about it in 2010….. I know
Why would you want to change it
Your Company wants a warning shown on the DCUI
Security, don’t show hostname, ip etc…
showing off ASCI-ART – just for fun
For me, it was point 3…. I run on my laptop VMware Workstation and am sometimes in need of spinning up nested ESXi with different kind of versions. For this reason I build a provisioning VM, so I can network boot empty VMs and choose from an iPXE menu the ESXi version I want to work with. (maybe some interesting stuff for a blog serie) And this setup wasn’t finished with a custom DCUI screen.
How does it work
Until version ESXi 7.0 there is a text file /etc/vmware/welcome, which you can edit. When it is succesfully edited, the DCUI wil show the result. My screen shows: VMware product and version, license, Memory, IP, SSL Thumbprint and ASCI-ART 🙂
You can also edit the logonbanner, shown when you access the host via SSH. And the support info
Until ESXi 7 ?
Yes, until… well almost. Until version 7.x you just could simply edit the file /etc/vmware/welcome. But it isn’t there anymore. But there is a different way. Called CLI. You can edit the welcome message with esxcli and powercli. Information is found in the VMware knowledge base kb2046347. And this works for a lot off ESXi versions. I’ve tested it succesfully from 5.5 to 7.0.
Well, you can show your creative side. Some guidelines I found are:
Especially number 3 is a killer. A lot of text editors will replace a certain amount of spaces with a TAB character… and this will mess up your screen.
The syntax is easy, just
esxcli system welcomemsg set -m 'your welcome'
And that is what is shown in the kb article. But how do you create a complete screen. Well, there are some undocumented parameters you can use. The article by William Lam (see above) shows some of them. But I haven’t find a site with all of them. With those parameters you create in a text editor your screen…. like this one
For a customer I’m migrating their legacy vSphere 5.5 environment to vSphere 6.5 U3. The migration is from a windows vCenter to the VCSA. First, we tried to use the GUI and stumbled over an issue.
The GUI, is of course a nice, friendly way to do this process. But when we got at the stage to select the size of the VCSA, we only had the ‘xlarge’ option. And well… that was a bit too much. Because we were aiming at the ‘small’ size.
So we did some searching on the internet and found out that we were not alone. Although it was an encouraging thought, we still didn’t find what we were looking for. Most of the threads and blog posts pointed to database size, log size etc.. And yes, they need to be checked. We had a vcenter database table of 7 million records, the size of the database was 80 GB. After some cleaning up and shrinking the database it was only a few GB. But al this effort, didn’t persuade the GUI to give us the desired ‘small’ size option.
Hoping that the validation in the GUI was different than when using the CLI, we decided to migrate using the vcsa-deploy CLI method.
Yes, it involves creating a json file. But the .iso file for the vcsa contains several template files, for several migration scenarios. We used on of the templates, customized it to our needs (setting the size to ‘small’. And after some trial and error we finally got it working.
If you want to read more about the CLI way of migration, check the vmware docs here.
vcsa-deploy creates for every run a new log folder . When we checked the logs we found out that vcsa-deploy was content with the ‘small’ size option we configured in the json file.
Why not 6.7 U3, well due to dependencies 6.5 U3 is at the moment the most current version we can run. Although this post is about migrating to 6.5 U3, it could also work for 6.7 U3, but no guarantees. The gist of this all is, if the GUI doesn’t work, try doing it the CLI way.
I know, it is not the most interesting subject to blog about. VMware gives you the opportunity for your My VMware account to use MFA. And I would advise to use MFA.
Well, depending on the situation, your my vmworld account can have access to different company accounts. Giving you, depending on roles and permissions, the ability to create support requests, download software, access licenses etc… And that is great. But it is a risk when your account gets hacked. That is where MFA can help. It is an extra line of defense.
MFA stands for, multi factor authentication. And when MFA is enabled,a person needs to present multiple pieces of evidence to authenticate (see https://en.wikipedia.org/wiki/Multi-factor_authentication ) Most of the times these pieces are a password and a token, generated by a authentication app or device. So, when you would know my password, you still can’t use my ‘my vmware’ account because I’ve enabled MFA. And the token is generated on my phone, which I have with me, and is locked.
Use a strong password. Strong doesn’t mean a lot off difficult characters, although there are some rules you have to follow. Study has shown that also the length of your password is a big key in having a strong password.
Enable MFA. Check this VMware KB on how to enable MFA for your My VMware account.
I already blogged about my VCAP deploy experience.( you can find it here ) And as stated…. I passed !!!… Sadly VMware doesn’t let you know the mistakes you made in the exam. But in the end…. this is what counts !!!
Next step ??
Well… to do the VCAP design exam. To be honest, I don’t look forward to it, because theory questions are not my strong suit. My strategy is going to study, visit VMware Empower europe 2019, do the VCAP design exam @ Empower (it is part of the conference) so I get a direction of what the exam looks like…. and maybe pass it on the first try.
Maybe you think, we’ll how hard can it be ?? Yes, that was the same question I had. And to be honest… it is not that hard. But there are some quarks or gotchas. In this post I’ll explain the route I took for patching a vCenter HA setup.
Why don’t you use the VAMI ?
VAMI stands for ‘ Virtual Appliance Management Infrastructure ‘. It can be accessed via port 5480 like https://<FQDN VMware appliance>:5480 . The VAMI of a vCenter Appliance (VCSA) has an update section, which you can use to patch the VCSA. This is a nice and easy way for patching the VCSA, but when you have vCenter configured as vCenter HA then this option won’t work. (I know from experience….) After trying (and failing) I thought, why not read the manual…. VMware has a nice article about patching a vCenter in HA and you can find it here. I still use the VAMI, but not for patching but for making a backup.
Yesterday I did the VMware VCAP-DCV 2018 Deploy experience. I dreaded to do the exam because the VMware DCV landscape is a fast landscape. I do have enough experience and expertise, but to know all the tiny details…. To be honest , there was a little fear for failure…. Especially because I heard that you really need all the time (3,5 hours)…. and that the performance of the virtual environment is bad …. And no access to VMware pubs/Docs/KBs and blog sites…. Do I really have it in me to pass this exam ??
But, eventhough I don’t now the score yet ( that could take up to 6 weeks or so)…. I’m quite confident that I passed it. Why ? Well… the situations you need to solve are for me common troubleshoot scenarios in a vSphere environment. Yes some questions are tricky… but hey… of course they are, you want to prove that you have advanced knowledge in this area.. I even enjoyed taking the exam. It just felt as a normal day at the office…
Yes I do have some critical comments. It is true, the lab enviroment (same experience as a VMware HOL enviroment), performs poorly. Not sure if it is because the internet connection, the hardware, or just the exam enviroment. But…. it was a while back that I used a 17″ monitor…. (i mean years…. prehistoric period)… but yesterday… yes …. really…. my exam enviroment had a 17″monitor…. Which is challenging. As you maybe know… the HOL enviroment has a book area where the questions and explanations are shown (right side on the screen)….. I had to switch often between this area and the console area. With a normal monitor, you can keep them side by side… And the performance…. selecting text with the mouse, click delays up to 10 seconds …. which is really annoying, and not helpful for someone who is nervous.
So I have to wait a few weeks for the result. And even if I failed, I still think that in hindsight I should have taken this exam earlier. If you have day to day hands on experience with a vSphere datacenter virtualization environment for more then a year, then I my advise would be to consider this exam. Your experience should be like, implementations , troubleshooting, and day-2 operations of a vSphere datacenter environment. Get some experience with the VMware HOL environment to get used to the lab environment. It is also a great place to practice with certain functionalities without destroying your own production … euh…. test environment. You can find VMware HOL here.
So fingers crossed (f0r me) and good luck when you want to certify your advance experience with a vSphere environment.