GitLab

Hopefully, my last schema change related to images. If relocatable is not
set then an image must be loaded at the lba_low offset. If set, then the
image can be loaded at other offsets. Currently, all FBSD images are
relocatable courtesy of the relocation mechanism in imagezip (which can
fix up otherwise absolute offsets in an image). Sadly, Linux images are
not relocatable due to absolute block numbers in the grub partition
bootblock that we require. Ryan "taught" imagezip to relocate these, but
I need to find his changes.

The old way worked...sorta. When we deleted the old partition and then
recreated it with gpart, it would create the new one at the end of the
disk, not likely where the old partition was previously.

In elabinelab setup the combo:

   mkextrafs -s 2 ... /usr/testbed
   mkextrafs -s 4 ... /q

resulted in slice 2 getting created at the end of the disk (where slice 4
would normally be) and then slice 4 getting created in the only remaining
available space (where slice 2 would normally be). Very confusing to my
Monday morning brain...

Tracking this in the DB will eliminate the need to run imageinfo
from tmcd.

These are computed by imagedump for .ndz images. The plan is to
pass this info on to clients via tmcc so they can know the max disk
size required.

There will shortly be a utility to automatically update these values
when an image is created or updated. Stay tuned.

Is mike being anal here? Yes, yes he is.

This at least avoids a whacky conflict between QEMU-emulated and
FreeBSD-paravirtualized disks that caused disk corruption.

The latter is really important since we create 1024 ifb devices on
a Xen host.

I was basing off the wrong time, the very miscalculation I was hoping
to keep people from making...

Doesn't work unless the control net is eth0. Gotta have enough
interfaces defined to cover where the real cnet is.

Otherwise, an ops node will hang forever shutting down if the boss node
is down.

Don't recall what this rule was supposed to accomplish, but it
doesn't get installed anyway in the singlenet case since the ipfw
modules is not loaded.

We also make sure that all dirs in /var/emulab are really dirs and
not symlinks. Having /var/emulab/vms be a symlink (left over from
a vnode setup) caused vast confusion when trying to use the new
images for vnodes.

Note: you really, really should not image the vhost in an experiment
with vnodes. Prepare in such an environment is destructive and you
won't get a clean image anyway (due to LVM state). Swap the Xen image
in on a node directly and image that.

You do this by setting the nodeos of "xenhost", ala:

    set elabinelab_nodeos("xenhost") XEN44-64-BETA2

    set elabinelab_nodeos("boss") FBSD100-64-STD
    set elabinelab_nodeos("ops") FBSD100-64-STD

Needed for pygrub.

Stick the pid file into /run/sendsigs.omit.d. If xenstored is gone, any
attempt to use "xl" will hang un-killably, at least on Xen 4.4.

Note that this does not help shutdown to single user, which runs a different
"killprocs" script as it enters single-user. That kills all processes with
no omissions (/etc/rc1.d/S30killprocs)! We may want to consider running the
Xen start script following that to at least re-start xenstored (and which
will free up any hung processes).

I was having to hack grub.cfg to make this work anyway since I don't know
how to properly configure /etc/default/grub to use ttyS0 for regular Linux
and hvc0 for Linux under Xen.

This change would mess up the console on Xen 4.1 and Xen 4.3 image too.

we rely on that version of the tools in the code. Need to be
fixed at some point.

experiment.

I've seen about a dozen cases in the last two days of bad rspecs,
but not catching the fact that we cannot get peer ip from the
manifest on the other aggregate.