You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@vcl.apache.org by Michael Jinks <mj...@uchicago.edu> on 2012/11/14 23:12:17 UTC
Throttling VM startups within VCL?
Hi List.
I'd like to introduce (or increase, if it's already there) a delay
between VM startups during block allocations and image reloads. Can
someone point me to the right spot in the code to look for that logic?
We're still on 2.2.1.
Thanks,
--Michael
--
Michael Jinks :: mjinks@uchicago.edu
University of Chicago IT Services
Re: Throttling VM startups within VCL?
Posted by Josh Thompson <jo...@ncsu.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael,
Yes, that's much clearer.
For block allocations, the start times are staggered by 1 minute. You can
increase that in XMLRPCprocessBlockTime in xmlrpcWrappers.php. Change the
"60" in
$stagExtra = $reqToAlloc * 60;
to whatever you want. The units for "60" are seconds.
Reloading via the Computer Utilities part of the site has no staggering. You
could add staggering in submitReloadComputers in computers.php by adding a
"$stagstart" variable to the 2nd foreach loop that gets incremented by some
amount during each iteration of the loop. Then, pass that variable instead of
$startstamp when calling simpleAddRequest.
Staggering normal reservations that happen to be concurrent would require a
fair amount more logic, but you'd be modifying isAvailable and addRequest in
utils.php.
Josh
On Thursday, November 15, 2012 1:08:58 PM Michael Jinks wrote:
> Yeah, sorry that was unclear.
>
> There are two workflows that can cause a batch of VM reloads: block
> allocations, and the interface under Manage -> Computers -> Computer
> Utilities. I get the sense that whenever VCL deploys VM's, it has some
> kind of logic to keep from firing them up all at once, but I don't know
> what that logic looks like or if it's the same logic in all situations
> (e.g. block allocations, reloads through the admin UI, or several users
> coincidentally reserving VM's at the same time).
>
> We're having boot storm issues, and we're trying to address them in a
> number of ways (improving our storage performance, adjusting our VM
> images to be less thrashy on boot, looking into deploying 2.3, etc.) but
> as a short-term improvement of the problem I'd like to try spreading out
> VM start intervals, and I thought it would save me some detective work if
> I asked here how that's controlled in the stock code.
>
> Does that make more sense?
>
> Thanks,
> -m
>
> On Thu, Nov 15, 2012 at 01:14:37PM -0500, Josh Thompson wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Michael,
> >
> > Can you clarify what you are asking? I would consider the VM startup to
> > be
> > part of the image reload.
> >
> > Thanks,
> > Josh
> >
> > On Wednesday, November 14, 2012 4:12:17 PM Michael Jinks wrote:
> > > Hi List.
> > >
> > > I'd like to introduce (or increase, if it's already there) a delay
> > > between VM startups during block allocations and image reloads. Can
> > > someone point me to the right spot in the code to look for that logic?
> > >
> > > We're still on 2.2.1.
> > >
> > > Thanks,
> > > --Michael
> >
> > - --
> > - -------------------------------
> > 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)
> >
> > iEYEARECAAYFAlClMQ0ACgkQV/LQcNdtPQNpjwCfZitm2gh3foFuHtBkFTtZSwUy
> > iekAn3J/WdqJvLYbhGsbkJdHVm4LXOev
> > =I8Qt
> > -----END PGP SIGNATURE-----
- --
- -------------------------------
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)
iEYEARECAAYFAlClSWkACgkQV/LQcNdtPQNtQwCfTGsIs9WdThvydw68m8W1IrnS
96MAniZFPwV8CuUOqm9R+xz5r97f+b0H
=B1Qs
-----END PGP SIGNATURE-----
Re: Throttling VM startups within VCL?
Posted by Michael Jinks <mj...@uchicago.edu>.
Yeah, sorry that was unclear.
There are two workflows that can cause a batch of VM reloads: block
allocations, and the interface under Manage -> Computers -> Computer
Utilities. I get the sense that whenever VCL deploys VM's, it has some
kind of logic to keep from firing them up all at once, but I don't know
what that logic looks like or if it's the same logic in all situations
(e.g. block allocations, reloads through the admin UI, or several users
coincidentally reserving VM's at the same time).
We're having boot storm issues, and we're trying to address them in a
number of ways (improving our storage performance, adjusting our VM
images to be less thrashy on boot, looking into deploying 2.3, etc.) but
as a short-term improvement of the problem I'd like to try spreading out
VM start intervals, and I thought it would save me some detective work if
I asked here how that's controlled in the stock code.
Does that make more sense?
Thanks,
-m
On Thu, Nov 15, 2012 at 01:14:37PM -0500, Josh Thompson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael,
>
> Can you clarify what you are asking? I would consider the VM startup to be
> part of the image reload.
>
> Thanks,
> Josh
>
> On Wednesday, November 14, 2012 4:12:17 PM Michael Jinks wrote:
> > Hi List.
> >
> > I'd like to introduce (or increase, if it's already there) a delay
> > between VM startups during block allocations and image reloads. Can
> > someone point me to the right spot in the code to look for that logic?
> >
> > We're still on 2.2.1.
> >
> > Thanks,
> > --Michael
> - --
> - -------------------------------
> 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)
>
> iEYEARECAAYFAlClMQ0ACgkQV/LQcNdtPQNpjwCfZitm2gh3foFuHtBkFTtZSwUy
> iekAn3J/WdqJvLYbhGsbkJdHVm4LXOev
> =I8Qt
> -----END PGP SIGNATURE-----
>
--
Michael Jinks :: mjinks@uchicago.edu :: 773-469-9688
University of Chicago IT Services
Re: Throttling VM startups within VCL?
Posted by Josh Thompson <jo...@ncsu.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael,
Can you clarify what you are asking? I would consider the VM startup to be
part of the image reload.
Thanks,
Josh
On Wednesday, November 14, 2012 4:12:17 PM Michael Jinks wrote:
> Hi List.
>
> I'd like to introduce (or increase, if it's already there) a delay
> between VM startups during block allocations and image reloads. Can
> someone point me to the right spot in the code to look for that logic?
>
> We're still on 2.2.1.
>
> Thanks,
> --Michael
- --
- -------------------------------
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)
iEYEARECAAYFAlClMQ0ACgkQV/LQcNdtPQNpjwCfZitm2gh3foFuHtBkFTtZSwUy
iekAn3J/WdqJvLYbhGsbkJdHVm4LXOev
=I8Qt
-----END PGP SIGNATURE-----