One common question that comes up around EVO:RAIL is where all those pre-defined settings in the appliance UI come from, where are they stored and how can you modify them? In case you haven’t seen the EVO:RAIL UI (and if you haven’t what stone have you been living under! 🙂 ) The “Configuration” front-end and engine of EVO:RAIL is a service (vmware-marvin) that runs inside the vCenter Server Appliance which initially comes up on node01 of the first appliance itself:

As you can see from the single page there are actually quite a number of settings gathered before the configuration is initialized, built, configured and finalized. These include:

• ESXi host naming convention and vCenter FQDN
• vSphere ESXi host networking (IP Ranges/Subnet Mask/Default Gateway/VLAN IDs) for vMotion, Virtual SAN and ESXi hosts
• Virtual Machine Network (VLAN ID and associated network names)
• Passwords (for ESXi and vCenter) and optional Active Directory configuration
• Global Settings such as: Time Zone, NTP, DNS, Syslog/Log Insight IP, Proxy Server settings including hostname, port, username and password

 

Where do these settings come from? Well, they are held in a JSON file on the vCenter Server Appliance that runs on the EVO:RAIL in the following directory:

/usr /lib /vmware-marvin /marvind /webapps /ROOT /WEB-INF /classes/

The file is called default-config-static.json

There is a sample JSON file in our User Guide appendix – for ease of use I’ve reproduced it at the end of this blog post.

The reason the file is named “static” is that it uses a static IP configuration for all components that require an IP address. When you order an EVO:RAIL, you could supply the VLAN/IP/hostname data to a Qualified EVO:RAIL Partner (QEP) for customization at the factory. Then, when it arrives onsite, you would just plumb it into the network and click the “Just Go!” button. Personally, I always check “Customize Me!” unless I know I’m just repeating the same process over and over again for validating purposes. For example I’m working a lot in the HOL where I repeatedly build the same EVO:RAIL appliance for testing purposes.

Incidentally, if you do click “Just Go!”, then all you will be prompted is to set the ESXi hosts and vCenter Server passwords. From here you can change the default password that is held in the JSON file to something that suits your needs.

So what if the settings in the JSON file don’t suit your needs, and you want to change them without endlessly retyping? Perhaps you would like to send an EVO:RAIL out to a remote location, and send the person who’s plugging it in for the first time, settings that are valid for their location. Simple – send them a custom JSON file with the correct values…

When confronted by the EVO:RAIL Welcome screen they would use “Customize Me!” and then click the link to “UPLOAD CONFIGURATION FILE”:

EVO:RAIL will then inspect and validate the JSON file to check it for errors – so if there are bum entries in it you will receive a warning. (Note that EVO:RAIL does not validate the syntax of the JSON file, so syntax errors will prevent the file from being read.)

For instance in the example below I deliberately created a JSON with insufficient IP addresses in the pool for the Virtual SAN pool of IP addresses, as well you can see there is a bum IP range from the JSON file:

Note: 10.20.x.y and 10.10.x.y are not invalid IP ranges.

If no errors are found in the JSON file, then it should pass with flying colors – and lead you to the Build Appliance button.

One thing you’ll notice about my ranges is that they begin x.y.z.101 to x.y.z.116 to include 16 IP addresses even though I only need 4 IP addresses for the 4 servers in my EVO:RAIL appliance. That’s deliberate on my part – so if I ever need to add an additional EVO:RAIL appliance, it can simply be detected on the network and added. To add an appliance all I need to supply is the ESXi and vCenter passwords in the tiny workflow. By creating a pool of IP addresses in the JSON file, it is very easy to add more EVO:RAIL appliances. When a new appliance becomes present on the network, the EVO:RAIL Management UI will discover it, and allow the administrator to add it to the existing cluster.

And if there are free IP addresses in the pool, all that’s required is the passwords. These are indicated by the green ticks in the Add New EVO:RAIL appliance UI.

If the network pool of IP address is not big enough or depleated – you get blue (i) information badges, and you’ll need to specify additional bundles of IP ranges to add the appliance. This is mildly taxing, and I think its just neater to specify the full range of IP (16) for each type of pool upfront. It’s just a slicker experience.

If the pool is depleted of IP addresses because the range was set too small its not the end of the world – it just means you need to fill in more IP data before you can add the EVO:RAIL appliance. In the example below where the IP pool was kept deliberately small (just 4-IPs) there’s a blue (i) info alert to indicate the operator needs to add more IP addresses before continuing.

Takeaway:

• You can use JSON files to automate and customize the build out of EVO:RAIL without the need to manually type IP configurations (not that it takes much time to do that!)
• The EVO:RAIL Configuration engine validates your IP setting
• It’s nice to have a pool of IP addresses large enough to make adding a second appliance a trivial process.
• However, there are limits – the incorrect IP address, or bad VLAN values could still pass a validation test by the operator inputting incorrect settings or by the person who creates the JSON file. After all, EVO:RAIL has no idea if you have mistyped the default gateway IP address…
• Finally, it is possible to leave the password field in the JSON file blank – which means no password is ever stored in clear-text and the person doing the configuration file would have to type in a valid password.

 

Click here to see a sample JSON file:

{
    "network": {
        "dhcp": false,
        "hosts": {
            "management": {
                "pools": [{
                    "minIp": "192.168.10.1",
                    "maxIp": "192.168.10.4"
                }],
                "netmask": "255.255.255.0",
                "gateway": "192.168.10.254"
            },
            "vsan": {
                "pools": [{
                    "minIp": "192.168.30.1",
                    "maxIp": "192.168.30.4"
                }],
                "netmask": "255.255.255.0",
                "vlanId": 30
            },
            "vm": [{
                "name": "VM Network A",
                "vlanId": 110
            }, {
                "name": "VM Network B",
                "vlanId": 120
            }],
            "vmotion": {
                "pools": [{
                    "minIp": "192.168.20.1",
                    "maxIp": "192.168.20.4"
                }],
                "netmask": "255.255.255.0",
                "vlanId": 20
            }
        },
        "vcenter": {
            "ip": "192.168.10.200"
        }
    },
    "hostnames": {
        "hosts": {
            "prefix": "host",
            "separator": "",
            "iterator": "NUMERIC_NN"
        },
        "tld": "localdomain.local",
        "vcenter": "vcserver"
    },
    "passwords": {
        "esxiPassword": "",
        "esxiPasswordConfirm": "",
        "vcPassword": "",
        "vcPasswordConfirm": "",
        "activeDirectoryDomain": "",
        "activeDirectoryUsername": "",
        "activeDirectoryPassword": "",
        "activeDirectoryPasswordConfirm": ""
    },
    "global": {
        "logging": "LOGINSIGHT",
        "timezone": "UTC",
        "loginsightServer": "192.168.10.201",
        "loginsightHostname": "loginsight",
        "ntpServerCSV": "",
        "syslogServerCSV": "",
        "dnsServerCSV": "",
        "proxyServer": "",
        "proxyPort": "",
        "proxyUsername": "",
        "proxyPassword": ""
    }
}