Here is part of the log. Seems like the allocation was successful but I'm a bit concerned with the vcld:REAPER line which seems to be when I deleted the allocation. Thank You
|29259|blockrequest| : "allocated" => 6, |29259|blockrequest| : "status" => "success", |29259|blockrequest| : "unallocated" => 0 |29259|blockrequest| : } 2013-12-06 16:31:42|29259|blockrequest|blockrequest.pm:process(208)|success blockTimes id 32 processed and allocated 6 nodes |29259|blockrequest| status= success 2013-12-06 16:31:43|29259|blockrequest|utils.pm:mail(1266)|SUCCESS -- Sending mail To: root@localhost, VCL Block allocation results for table is empty test 2013-12-06 16:31:47|22472|vcld:main(167)|lastcheckin time updated for management node 1: 2013-12-06 16:31:47 2013-12-06 16:31:52|22472|vcld:main(167)|lastcheckin time updated for management node 1: 2013-12-06 16:31:52 2013-12-06 16:31:53|29259|blockrequest|blockrequest.pm:process(345)|Removed processing flag on blockrequest_id 7 2013-12-06 16:31:53|22472|vcld:REAPER(721)|VCL process exited for reservation <unknown>, PID: 29259, signal: CHLD David DeMizio *Academic Systems Coordinator* Office of Information Technology New College of Florida Phone: 941-487-4222 | Fax: 941-487-4356 www.ncf.edu On Fri, Dec 6, 2013 at 4:28 PM, David DeMizio <[email protected]> wrote: > Hello, > > I noticed when I delete a block allocation that the data is not removed > from the request table and reservation table, is this normal? Will it > eventually remove it? it removes it from blocktimes table but not from > the tables mentioned above. Thank You. > > > > > > > On Wed, Dec 4, 2013 at 9:09 AM, David DeMizio <[email protected]> wrote: > >> Thank You Josh, Great explanation! I'll keep this in mind when creating >> block allocations but hopefully it won't be an issue once I start adding >> more VMs to the environment. Thanks again. >> >> David DeMizio >> *Academic Systems Coordinator* >> Office of Information Technology >> New College of Florida >> Phone: 941-487-4222 | Fax: 941-487-4356 >> www.ncf.edu >> >> >> On Wed, Dec 4, 2013 at 8:54 AM, Josh Thompson <[email protected]>wrote: >> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> David, >>> >>> When a block allocation time slot is processed, reload reservations are >>> created for each computer that is allocated so that they will be loaded >>> and >>> ready by the start time of the allocation time slot. The start time for >>> the >>> reload reservations is a little complex, but they basically have >>> staggered >>> start times 1 minute apart such that the last start time is 10 minutes >>> before >>> the start of the allocated time slot plus the estimated load time for the >>> image. >>> >>> So, you have computers allocated until 8:45 from the first block >>> allocation. >>> Then, there is an estimated load time for the Windows image - let's use 5 >>> minutes for that - plus an additional 10 minutes [1]. That gives the >>> following start times for the reload reservations for the 2nd block >>> allocation: 8:42, 8:43, 8:44, 8:45. >>> >>> So, 3 of those would not be able to get allocated due to the overlap >>> with the >>> 1st block allocation. >>> >>> For changes to a block allocation, if I remember correctly, it >>> deallocates all >>> of the computers and reallocates them all again. >>> >>> Josh >>> >>> [1] The additional 10 minutes is a fudge factor to handle storage >>> possibly >>> being slower than normal due to several concurrent image loads. >>> >>> On Wednesday, December 04, 2013 8:24:31 AM David DeMizio wrote: >>> > Hello, >>> > >>> > I'm testing block allocations at the moment so I set up two schedules: >>> > >>> > 1) has 5 seats from 8:15 - 8:45 - Linux image >>> > 2) has 4 seats from 9:00 - 9:30 - Windows image >>> > >>> > I have 6 computers total. I received the error below after I modified >>> the >>> > group that could create the reservation on the block allocation. Why >>> am I >>> > getting unable to allocate machines when the start time of Windows >>> image is >>> > 9:00 a.m? Also, when making changes to the allocation does it attempt >>> to >>> > reload the machines? I would think that as long as I don't change the >>> image >>> > to load that it would leave the machines untouched. Thank You >>> > >>> > |20610|blockrequest| ---- CRITICAL ---- >>> > |20610|blockrequest| 2013-12-04 >>> > >>> > 08:14:05|20610|blockrequest|blockrequest.pm:process(245)|Problem >>> > processing block allocation >>> > >>> > |20610|blockrequest| Block id = 4 >>> > |20610|blockrequest| Block name = test2 >>> > |20610|blockrequest| Block start time = 2013-12-04 09:00:00 >>> > |20610|blockrequest| Block end time = 2013-12-04 09:30:00 >>> > |20610|blockrequest| Environment name = Windows 7 64Bit >>> > |20610|blockrequest| Allocated = 1 >>> > |20610|blockrequest| Block requested = 4 >>> > |20610|blockrequest| xmlrpc warn msg = unable to allocate any machines >>> > |20610|blockrequest| ( 0) blockrequest.pm, process (line: 245) >>> > |20610|blockrequest| (-1) vcld, make_new_child (line: 571) >>> > |20610|blockrequest| (-2) vcld, main (line: 451) >>> - -- >>> - ------------------------------- >>> Josh Thompson >>> VCL Developer >>> North Carolina State University >>> >>> my GPG/PGP key can be found at pgp.mit.edu >>> >>> 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. >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2.0.19 (GNU/Linux) >>> >>> iEYEARECAAYFAlKfNCMACgkQV/LQcNdtPQN+CQCeLYzUFJBHyzMjlZf9eRcEDdyf >>> RfgAn0fK4F095n2rUF4U8yZaBXCPtJS0 >>> =9tvL >>> -----END PGP SIGNATURE----- >>> >>> >> >
