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:
2009-02-06 
14:56:57|31467|93:93|reserved|utils.pm:check_connection(1828)|checking
for connection by administrator on test_vm, attempt 4
2009-02-06 
14:56:57|31467|93:93|reserved|utils.pm:run_ssh_command(6729)|executing
SSH command on test_vm: netstat -an
2009-02-06 14:56:58|31467|93:93|reserved|utils.pm:run_ssh_command(6748)|$?:
0, signal: 0, core dump: 0, exit status: 0
2009-02-06 14:56:58|31467|93:93|reserved|utils.pm:run_ssh_command(6799)|SSH
command executed on test_vm: netstat -an, returning (0, output)
2009-02-06 
14:56:58|31467|93:93|reserved|utils.pm:run_ssh_command(6729)|executing
SSH command on test_vm: who
2009-02-06 14:56:58|31467|93:93|reserved|utils.pm:run_ssh_command(6748)|$?:
0, signal: 0, core dump: 0, exit status: 0
2009-02-06 
14:56:58|31467|93:93|reserved|utils.pm:run_ssh_command(6796)|run_ssh_command
output: admin pts/0 Feb 6 15:59 (152.14.244.35)
2009-02-06 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
routine)

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.

-Andrew

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

> 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 complete.
>
> 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.
>
> Aaron
>
>
>
> --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 provisioning
>> 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?
>>
>> Best,
>> Brian
>>
>> Brian Bouterse
>> Secure Open Systems Initiative
>> 919.698.8796
>>
>>
>>
>>
>>
>
>

Reply via email to