Bare Metal Management With Razor (2/N)

Having set up our Razor environment, it's now time to put it through its paces. The first order of business is to get a VM or two up and registered with the system.

Start by creating two VMs, making the following configuration tweaks:

1. Configure them to use the natnet1 NAT network.
2. Enable network boot, and put it first in boot order.
3. Give one VM 1G of RAM and another 4G of RAM.

Power on the 1G VM and watch its console. It should PXE boot off of the Razor/Dnsmasq infrastructure and eventually come up at a login prompt; default creds are root/thincrust.

We haven't installed an OS yet, so what is the VM running? It's running the Razor Microkernel, "a small, in-memory Linux kernel that is used by the Razor Server for dynamic, real-time discovery and inventory of the nodes that the Razor Server is managing". It's entirely ephemeral, no disk needed. And, better yet, the docs on how to modify the kernel for your own needs are pretty good. So if you want to, say, include tools for updating system firmware, or running tests/benchmarks, or anything of that nature, its not terribly hard to do.

Alright, on with the show! On the Razor server, do:

gem install razor-client

and then run razor nodes to see what's in inventory:

[root@razor log]# razor nodes
From http://localhost:8150/api/collections/nodes:

+-------+-------------------+--------+--------+----------------+
| name  | dhcp_mac          | tags   | policy | metadata count |
+-------+-------------------+--------+--------+----------------+
| node1 | 08:00:27:0c:fd:f4 | (none) | ---    | 0              |
+-------+-------------------+--------+--------+----------------+
...

There you have it... there is no step three. Alright Razor, tell me about node1:

[root@razor log]# razor nodes node1
From http://localhost:8150/api/collections/nodes/node1:

          name: node1
      dhcp_mac: 08:00:27:0c:fd:f4
         state:
                  installed: false
        policy: ---
  last_checkin: 2019-06-05T10:09:34-07:00
      metadata: ---
          tags: (none)
...

So far, so good. What sort of "facts" does the server know about the node?

[root@razor log]# razor nodes node1 facts
From http://localhost:8150/api/collections/nodes/node1:

          network_enp0s3: 192.168.15.0
              network_lo: 127.0.0.0
           system_uptime:
                            seconds: 731
                              hours: 0
                               days: 0
                             uptime: 0:12 hours
...

The server has recorded the system configuration and some other relevant items, like IP address and uptime. Now power up the 4G VM; it should do the same thing.

At this point we've achieved our first goal, which was to find a way to quickly boot up a bare metal system and allow us to do some poking around prior to making decision about OS installation. And now, a little digression.

I first got interested in bare metal management a bazillion years ago when I was working for a system integrator. We had to be able to build, inventory, and test racks of servers as efficiently as possible. Having that sort of capability is useful not only for system integrators, but anyone who has to deal with hardware at scale. As a by-product of its operation, Razor persists a bunch of readily-accessible information about hardware configuration:

[root@razor ~]# su - postgres
Last login: Fri Jun  7 10:17:54 PDT 2019 on pts/0
-bash-4.2$ psql -c 'select name, hw_info, facts from nodes' razor_prd postgres
 name  |  hw_info                                                                                         | facts
 node2 | {fact_boot_type=pcbios,mac=08-00-27-43-84-1d,serial=0,uuid=55c8c240-9c29-43cc-ab69-c55720067fa4} | {"network_enp0s3":"192.168.15.0", ...
 node1 | {fact_boot_type=pcbios,mac=08-00-27-0c-fd-f4,serial=0,uuid=f3b91803-383d-43a7-bb76-97f995cd4118} | {"network_enp0s3":"192.168.15.0", ...
(2 rows)

facts contains a JSON blob with a bunch of useful information like MAC addresses, serial numbers, disk devices, etc., suitable for post-processing/transmission to a system of record.

And we'll leave it at that for now. Next time we'll pick up with the second objective, doing some automated OS installs.