When processing config options, we now treat these strings as
'1' and '0' so that they can be used as booleans. (Previously,
'false' would evaluate to true by perl string rules.)

Be sure to added the other side of the tunnel to the topomap, when the
tunnel spans aggregates, so that the host/route calculators on the
client do the right thing.

... seems useful enough that we ought to just do it by default.

Works fine on our server because the hostname is set right and the
path works out fine. Might work less well on servers configured
differently.

correct.

Have sdcollectd log the IP address associated with the incoming packet when
it can't map it to a node id.

when a specific node is provided, since the type of the virtnode is
not always exactly what the user asked for, cause of how we map
virtnode types.

Since the pcpg-i2 nodes are so very flaky, lets try something that
does not require them to rebooted or imaged!

The key change is that on these remote nodes, we do not bridge the
physical control interface to the VM control interfaces. There is no
point since there are no routable IPs we can use, nor is there a
192.168 network that would be useful.

However, we still want to give the VMs their 192.168 address and we
still want multiple VMs on the same host to talk to each other, and we
we still want the VMs to be able to access the outside world with NAT.
So we still create the xenbr0 bridge, and give it the router address
(192.168.0.1). Any traffic heading out will be NAT's as normal, and
you can ssh into the VM using the physical host IP and the per VM
sshd port number.

This allows users to select the specific node type of their VMs,
We need to revisit this type stuff.

It is possible for the CM daemon to grab the lock for a moment,
so lets not fail. Rare case.