Kb117
Emulab FAQ: Testbed Operations: Understanding ImageID's and OSID's and defaults
> Trying to reload pc34 ... > *** /usr/testbed/bin/os_load: > No such imageid RHL71-NEWKERNEL is defined in the DB! > /usr/testbed/bin/os_load -s failed on pc34. Thats not supposed to happen.
This message is because the reload daemon operates from an imageid. You created a new OSID called RHL71-NEWKERNEL, but maybe not an imageid of that name? I'll ramble on and then come back to the problem at hand.
The node_types table specifies two things; a default OSID to boot if the user does not specify one, and a default imageid for the node. The reload daemon uses this default imageid when cleaning up nodes. Of course, the default osid you specify (for users) must (well, *should*) be an osid in the default imageid that the reload daemon is putting on your nodes!
So, an imageid is comprised of one or more osids. At Utah, the default image id includes both the freebsd and linux slices, and yours should too so that users can pick either of the defaults and not have to worry about reloading the nodes when the experiment is created; better to have that done already by the reload daemon. There can be a one to many mapping of an osid to imageids that contain it, but that can lead to confusion. Still, its allowed, and useful. For example, the default imageid contains both freebsd and linux. Another imageid contains just one or the other, which is useful for users who mess up their nodes and want to reload *just* the partition they care about (have selected in ns file).
Okay, so how do we track what is loaded on a node and what slice to boot? When os_load sets up the load for a node, it also modifies the "partitions" table for that node. The partitions table holds what osid is getting dropped on which slice. So, for the combined image the partitions table will get FBSD in slice 1 and RHL in slice 2. Which slice is booted comes from the imageid; in our combined image we set it so FreeBSD boots instead of linux whenever the node is free. When the node is allocated to an experiment, that gets switched to whatever the user specified, or the default osid I mentioned above if none was specified.
When the experiment is set up, a check is made to see if the osid the user selected for a node is loaded on the node. It does this by checking the partitions table. If the OSID is on the node, great! If the user selected a generic osid (RHL-STD instead of RHL71-STD), the user is simply saying he wants any version of RHL, and if there is an RHL71 on the node, great!
Okay, so what if the OSID is not listed in the partitions table? Then we need to load an image. The trick is to find an imageid that has the requested OSID in it, and since we allow a one to many mapping, we need a way to decide. Thats what the osidtoimageid DB table does. When you create a new imageid in the web interface, you can optionally set up these mappings (or by hand later). Basically, for a particular node type (pc600, pc850), specify what imageid to load when a user wants RHL71-STD. This table forces you to have a unique mapping of course since there won't be any way to resolve conflicts in the experiment setup path. So, in our table:
+--------------------------------+--------+--------------------------------+ | osid | type | imageid | +--------------------------------+--------+--------------------------------+ | RHL71-STD | pc600 | UTAHPC-LINUX71 | | RHL71-STD | pc850 | UTAHPC-LINUX71 | | FBSD45-STD | pc850 | FBSD45-STD | | FBSD45-STD | pc600 | FBSD45-STD |
Which says that when a user has requested RHL71-STD on a pc600, and that osid is not loaded already (in the partitions table), set up an os_load using the imageid UTAHPC-LINUX71. As you can see, osids and imageids can have the same name, or not have the same name. Does not really matter. :-)
Okay, so now we load the UTAHPC-LINUX71 imageid on a node. In the imageid it says what gets loaded on each slice (and thus what goes into the partitions table), and what slice to boot after its loaded (def_boot_osid in the nodes table). This is where frisbee gets started and the node is auto loaded during experiment creation. The user can also os_load it by hand later (say if he screwed up the node).
Of course, none of this has much to do with the problem at hand! In this case, you have tripped over a poor design decision (my decision actually). The imageid table holds the pid (project id) under which the imageid was created. In the case of RHL71-NEWKERNEL, it was created in the mtcp2 project. The pid was intended to enforce per-project protection of images, but is also a pain in the ass since we have not been consistent in storing the pid alongside the imageid (there is more to this, but I won't bother to bore you with 2 more paragraphs!). Anyway, the reload daemon looks for the imageid in the emulab-ops pid, and since you created it in the mtcp2 pid, it cannot find it. So, after all this text, all you need to is:
update images set pid='emulab-ops' where imageid='mctcp2-RHL71-NEWKERNEL';
Note that "mctcp2" will remain in the imageid tag, but that won't really matter; I combine the pid and imagename to form a globally unique id.
As for imagename and image id (and this applies to osname and osid in the os_info table). Originally, osids and imageids were globally unique, so all we had was an imagename and osname slot. Well, after a long while it became clear that this was bad, and that they had to be per-project unique instead. So I added the id slots which gives us globally unique names within the system, but still allows for different projects to use the same imagename. When that change was made, all the related fields in the DB where shifted to hold ids instead of names, but since we already had globally unique names, I left imagename=imageid (and osname=osid) for the set of images (and osids) that existed at that time. All this does is explain why you sometimes see them equal and other times don't. The key thing is that imagename is what the user selected, and imageid is the globally unique id we give it inside. Utilities like os_load can handle either pid,imagename or imageid on the command line (with appropriate option). Confusing? I'll say!
> Changing the pid didn't fix it. I added a debug line to > os_load to see what options it was getting passed, and found that > it is using the -m option to load an image based on > the ID, and it is using the ID RHL71-NEWKERNEL. From > what you've said I guessed that it is getting this > value from the nodes_types table (or at least I thought it was).
os_load with no args except nodeid(s) will look in the node_types table to get the default *imageid* for node.
> How did the nodes types table get set to this value? Did someone have to > set it to that?
Yep, we (or you!) set that when we create a default image for a node. We probably did it initially for you.
> In the entry in the nodes_types table to mctcp2-RHL71-NEWKERNEL, expecting > that would make the reload daemon use the correct imageid, but it was > still using RHL71-NEWKERNEL. I now guessed the imagename and imageid > needed to be the same.
No, just consistent. Whatever is in the imageid slot in the images table has to be what you put in any slot called "imageid" in the rest of the DB. The imagename is just fluff for the users. Sounds like your DB changes had the desired effect.
> About our default imageid for both redhat and freebsd using > the same image. I've enclosed a discussion we > had with Mike Hibler. Experiments created with RHL-STD, > which were supposed to use a multiboot image were always > loading FBSD-STD.
I remember that discussion. My view is that there are two sets of images. The default which includes both, and a set of per-slice images which get loaded explicitly by the user. This last has the intended consequence of making sure the node boots what the user wants.
Mike was attempting to solve the problem a different way (not having to setup per-slice images). I tend to disagree, but the benefit is less work when creating new images.
> For the RHL selections they all resolved to the > RHL71-NEWKERNEL image, as expected. Although, I > still don't see how/where RHL-STD is mapped to > anything.
An undocumented convention handles this one. This actually requires some work since it can lead to problems. A "generic" osid is one in which the version slot is left null. When os_setup sets up the node, if it see the user wanted a generic osid, it looks on the disk to see if there is an already loaded osid that has an actual version (7.1) and a matching OS field (linux). It picks that. We should have done this with another mapping table, but I was lazy at the time I did it. The downside is that if someone loads an old version (say, 6.2), the next person can get that old version if the disk is not cleaned by the reload daemon before it is next allocated. The reload policy is a whole nutter letter to write!
> The strange thing is of the above osid selections only > the FBSD45-STD osid did not work, os_load returned: Invalid > osid.
Remember, os_load is a "primitive" that loads imageids not osids! os_setup handles mapping osids to imageids. You need to specify the imagename (with optional pid so it can be found), or with -m using the internal name.