(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


Reply via email to