What are your steps when you start the imaging process?

You have to do the following:
- make the reservation/request
- wait for connect button
- click connect button
- connect to the machine
- then you can hit the create image button to start the imaging process.

If your in the reserved state as reported in the log file below - the process is polling the node looking for the user to connect. Once connected then it proceeds to the inuse state.

This is actually a user interface bug. We're assuming users will actually login to the remote node and install something - but in your case if your just testing I can see going straight to the image creation mode. Created JIRA issue VCL-84.

Under normal operation you don't need to clean on the computerloadlog. Since your developing and likely having to break things, it's going to behave a little bit different.


--On February 6, 2009 3:12:16 PM -0500 Andrew Brown <brow...@gmail.com> wrote:

So we have things mostly working except for one detail: When we check out
a computer for capture through "update image", all that goes fine. But
when we go and hit "create" to actually capture the image, vcld hangs
with the log messages that Brian posted, repeating.

If we go in and remove the database entry in the computerloadlog table,
the capture goes through; however, there seems to be a process that
lingers and keeps trying to ssh to the machine even when our capture is
proceeding. It gives us log entries like this:
for connection by administrator on test_vm, attempt 4
SSH command on test_vm: netstat -an
14:56:58|31467|93:93|reserved|utils.pm:run_ssh_command(6748)|$?: 0,
signal: 0, core dump: 0, exit status: 0
14:56:58|31467|93:93|reserved|utils.pm:run_ssh_command(6799)|SSH command
executed on test_vm: netstat -an, returning (0, output)
SSH command on test_vm: who
14:56:58|31467|93:93|reserved|utils.pm:run_ssh_command(6748)|$?: 0,
signal: 0, core dump: 0, exit status: 0
and output: admin pts/0 Feb 6 15:59 (
14:56:58|31467|93:93|reserved|utils.pm:run_ssh_command(6799)|SSH command
executed on test_vm: who, returning (0, output)
(the pid being different from the one that is going into our capture

This may be unrelated, I don't know. But we need to fix it so we don't
need to manually delete the computerloadlog entry each time, as well as
fix it so this second process... goes away or something.


On Fri, Feb 6, 2009 at 1:23 PM, Aaron Peeler <aaron_pee...@ncsu.edu>

Actually it's computerloadlog

The computerloadlog table has three purposes.
It also has two dependent tables computerloadflow and computerloadstate

1) Provides information to the user about what state user request is in,
where it's at in loading, performing post install tasks, adding user
acct, etc. This information is seen on the current reservations page by
the user clicking on the pending link. This link opens a ajax based
window and will provided the state the load is in. At some point during
your load routine - you'll want to add these type of calls in the
appropriate places.

insertloadlog($reservation_id, $computer_id, "startload",
"$computer_node_name $image_name");

But this isn't required to get a provision module functional. It's a nice
feature, so the user can be aware of what's going on. We'll put together
information on how to best use the insertloadlog.

2) If a new|reload request is started and the computer state is reload or
reloading. The forked request process will use that table to determine
what to do. Either take over, fail, or let the current owning process

3) It is also used in vcld to prevent duplicate or competing processes.

It gets cleaned out on a per-reservation basis. When a reservations goes
into the inuse state and when a reservation is removed from the db.

In your case, since your just testing your module, just manually empty
the computerloadlog table as needed.


--On February 6, 2009 11:20:47 AM -0500 Brian Bouterse
<bmbou...@ncsu.edu> wrote:

 What is the purpose of the loadlog table?  Currently the ESX
module doesn't update any information in the loadlog table, and the
provisioning works fine.  We're working on the capture() portions now,
and when we go through the web interface to have it "capture" our
reservation, vcld warns saying:

| 25052|72:72|image| ---- WARNING ----
| 25052|72:72|image| 2009-02-06
| 11:19:56|25052|72:72|image|vcld:main(272)|reservation 72 is already
| being processed 25052|72:72|image| ( 0) utils.pm, notify (line: 683)
| 25052|72:72|image| (-1) vcld, main (line: 272)

Is this normal for the "image update" process?


Brian Bouterse
Secure Open Systems Initiative


Reply via email to