available computers

[Dmitri Chebotarov <dc...@gmu.edu>]

Hi, All  

I found that sometimes there is a 'disconnect' between information in SQL database and actual state of 'available' computers.

If VCL has a bunch of availabe computers preloaded with an image and I then update that image (new image revision), computers are not automatically reloaded with newer image revision.  
New reservation will have new image revision, but those available computer will still have older image revision and it would be reloaded only if a user makes reservation.  
At that time it will take longer to load (ie. ~10min vs <1min for preloaded available computer).  

Also in cases when I need to reboot ESXi hosts, all the VMs are not loaded automatically. In this case database lists those VMs as available, but they are off-line.  

I would like to share the small tool (a .pl script), which syncs available computers with actual state of computers (VMs).

I've used peaces of code from utils.php to write it. The script creates reload requests for all available computers using the current image and latest image revision.
VCLD then caries out requests and reloads computers which are either have older image revision or cannot be contacted via SSH (ie. after ESXi reboot).  

I plan to run the script weekly via cron on vcld server to make sure all is in sync, as well as after image updates.  
I've tested it and it works fine. .pl is attached.

(I have hardcoded $managementnodeid value in reloadComputer(). Yours could be different)

Thanks. ​
--
Dmitri Chebotarov
Virtual Computing Lab Systems Engineer, TSD - Ent Servers & Messaging
223 Aquia Building, Ffx, MSN: 1B5
Phone: (703) 993-6175
Fax: (703) 993-3404

Re: available computers

[Aaron Peeler <fa...@ncsu.edu>]

Cool. Nice script.

Do you have an account under Jira?
https://issues.apache.org/jira/browse/VCL

If so would recommend to create a jira issue for 2.4 release to add
this in. This way we can make sure to add that in.

Also it may be worth looking at a script called healthcheck.pl in
<pathtovcl>/vcl/bin.

I think healthcheck.pl does not work too well in 2.2.1 - had some
issues with the data structure object.

The healthcheck.pl in the repo for the 2.3 is pretty stable, it
doesn't initiate a reload, but checks the state of the machine,
current image in db vs actual image loaded and updates the database
accordingly. So maybe, we could combine yours and healthcheck.

Aaron


On Thu, Apr 12, 2012 at 12:04 PM, Dmitri Chebotarov <dc...@gmu.edu> wrote:
> Hi, All
>
> I found that sometimes there is a 'disconnect' between information in SQL
> database and actual state of 'available' computers.
>
> If VCL has a bunch of availabe computers preloaded with an image and I then
> update that image (new image revision), computers are not automatically
> reloaded with newer image revision.
> New reservation will have new image revision, but those available computer
> will still have older image revision and it would be reloaded only if a user
> makes reservation.
> At that time it will take longer to load (ie. ~10min vs <1min for preloaded
> available computer).
>
> Also in cases when I need to reboot ESXi hosts, all the VMs are not loaded
> automatically. In this case database lists those VMs as available, but they
> are off-line.
>
> I would like to share the small tool (a .pl script), which syncs available
> computers with actual state of computers (VMs).
>
> I've used peaces of code from utils.php to write it. The script creates
> reload requests for all available computers using the current image and
> latest image revision.
> VCLD then caries out requests and reloads computers which are either have
> older image revision or cannot be contacted via SSH (ie. after ESXi
> reboot).
>
> I plan to run the script weekly via cron on vcld server to make sure all is
> in sync, as well as after image updates.
> I've tested it and it works fine. .pl is attached.
>
> (I have hardcoded $managementnodeid value in reloadComputer(). Yours could
> be different)
>
> Thanks.
> --
> Dmitri Chebotarov
> Virtual Computing Lab Systems Engineer, TSD - Ent Servers & Messaging
> 223 Aquia Building, Ffx, MSN: 1B5
> Phone: (703) 993-6175
> Fax: (703) 993-3404
>



-- 
Aaron Peeler
Program Manager
Virtual Computing Lab
NC State University

All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.