(2) I would also like to understand how resources are
deprovisioned. What happens when a provisioned resource's allocated
time has lapsed? Are there any plans for an implementation of an
official deprovisioning process (e.g.,
VCL::Module::Provisioning::unload( ))?
Deprovisioning already happens and is handled by reclaim.pm. The
process depends on whether or not a user logged into the computer,
which can be determined by the value of request.laststate.
If a user logged in, the computer needs to be completely reloaded.
You'll know this if request.laststate = "inuse". If reclaim.pm
detects this, it inserts a reload request for the computer into the
database and exits.
If reclaim.pm sees that request.laststate is not "inuse", it means
the user never logged in and it's safe to attempt to sanitize the
computer without reloading it. reclaim.pm will call the OS module's
sanitize() subroutine. If successful, the computer state is set to
available and can be used for another reservation. If sanitize()
fails, reclaim.pm inserts a reload request into the database and exits.
Hope this helps,
Andy
Andy,
I would like to revisit this discussion. I believe I understand how
this is applicable when physical resources are being provisioned. Does
the same hold true for virtual resources? It seems that once a VM is
provisioned through the vmware or esx modules, that it would persist
indefinitely either via reloading or sanitization for as long as it's
host system is up and running, waiting for another user to "claim" it.
I haven't observed a case where a provisioned virtual resource's
lifecycle actually comes to an end.
Toks
Toks
