This title is a bit of a pun on “Ghost in the Machine”, typically used to describe some undocumented hidden magic at the heart of things – think of Arthur C. Clarke’s famous pronouncement!. Of course, there’s no ghost in the EVO:RAIL machine, but there are certainly daemons. By which I mean the services running in the background that make it all happen. In the spirit of demystification I want to explain where they are, what they are, what they do (roughly!) and how to test if they are functioning – and what to do if they’re not!
Note: Quite why Linux calls these things “daemons” and Windows calls such built-in processes “services” has always been a mystery to me. But for the “We only run Windows” folks out there – two things.
A.) No you don’t – Linux is all over the place, you just can’t see it…
B.) daemons = services, services = daemons.
Try to not get too worried by that tautology, it is mere linguistics. Anything else is in the realms of Harry Potter. 🙂
VMware Loudmouth
There are two core daemons with the EVO:RAIL; one is called “Loudmouth” and the other has the original project name of EVO:RAIL – aka “MARVIN”. The Loudmouth service runs on BOTH the EVO:RAIL node and the vCenter Server Appliance. The “Loudmouth” service running on ESXi is installed at the factory using a VIB (Virtual Infrastructure Bundle) file, and in the vCenter Server Appliance using a .RPM file. These are pre-installed at the factory by your preferred Qualified EVO:RAIL Partner. They should start automatically and you shouldn’t have to do anything to it. However, if you did want to validate that VMware Loudmouth had started and was working properly you would:
On The ESXi Host run the command:
/etc/init.d/loudmouth status
On The vCenter Server Appliance run the command:
/etc/init.d/vmware-loudmouth status
You can use the flags “restart”, “stop” and “start” as well.
VMware Loudmouth is an implementation of Zero Network Configuration or ZeroConf (think of it like Apple Bonjour for vCenter/ESXi). It’s primarily used in three areas:
- The initial discovery and configuration of the 1st
- The adding of subsequent EVO:RAIL appliances to add more compute and storage capacity – call it auto-discovery and auto scale-out if you wish!
- Replacement of failed node with a brand new node, typically caused by a motherboard failure, or CPU failure – where wholesale replacing of a node is quicker and easier than replacing individual components.
VMware MARVIN
In contrast the VMware MARVIN daemon only resides on the vCenter Server Appliance. It’s essentially a dedicated Apache Tomcat instance whose sole purpose is to assist the administrator in both configuring the EVO:RAIL appliance for the first time, and also providing the Management UI once the configuration has completed.
Note: This is a screen grab of the EVO:RAIL Management UI as provided by the VMware MARVIN service. The VMware MARVIN service listens on a SSL enabled port number of 7443. For instance to get to the EVO:RAIL UI you would use https://192.168.10.200:7443
As you might suspect, confirming the status of VMware MARVIN means connecting to the vCenter Server Appliance and running the following command:
/etc/init.d/vmware-marvin status
Again there are very few reasons to ever restart this service – and of course a reboot of vCenter would restart it as well. I can give you just one case where I have had to restart it. Occasionally, I like to modify the default JSON file that provides the default IP Pools, Hostnames and so on in the main Configuration pages. The JSON file is located at: /usr /lib /vmware-marvin /marvind /webapps /ROOT /WEB-INF /classes/ and is called default-config-static.json. The file JSON file is read when the vmware-marvin service starts for the first time. So any edits to it require a restart of the service in order for changes be picked up and used.
Conclusion:
EVO:RAIL is magic, but it’s not magic spells that makes it work but daemons. Fortunately, these daemons are good ones that are not your enemy, they’re more like Prof. Dumbledore than Lord Voldermort. They are pre-installed by the QEP at the factory, and you should never have to restart them, or check their status. But you can. Simple. Now, I might just disappear in a puff of my own logic….