The rationale here is we don't want to extend trust from the old
machine, which we do by giving them root access on the new server. By
giving root access to the *old* server, we don't give it access to
anything it already has (or will have, in the case of the ganeti
nodes).

this is starting to look like a thing ansible should be doing

we could have also used the new swap UUID and edited the fstab, but
that would have required more steps:

 1. mount the filesystem
 2. edit fstab
 3. unmount

... and another thing to redo after the last resync.

By enforcing a UUID from the start, we don't need to edit the fstab at
all. I can't think of a compelling reson why reusing the UUID might be
a problem.

A glossary doesn't belong in the tutorial, which expects the user to
know nothing of the service. That belonds in the Howto section, where
we expect to learn a little more about the service before doing things.

I added that TODO based on a misunderstanding of the function of the
private network between the Ganeti nodes. It's not there to provide a
private network between *instances*, but really just the nodes, for
DRBD and Ganeti traffic.

So it makes no sense to allocate private IPs to the instances in that context.

We remove the `gnt-node list` command because it's included in the other.

The rationale is that this part is more rarely used and definitely
more complex than a Howto.