Reservations and Reloading

[Ryan Johnson <rj...@gwmail.gwu.edu>]

When testing the service I noticed something curious.  If I make a
reservation, the vm files are copied and powered on.  When I end the
reservation, the copied vm files are destroyed and copied again and the vm
is powered on again - the vm is reloaded.  What is strange to me is that
when I create a new reservation, the vm files are destroyed and copied again
and the vm is powered on again.  Why would the vm be reloaded if only to
reload it again on the next reservation for the same image?  Does the
service maybe think that a different image is being requested?

Re: Reservations and Reloading

[Ryan Johnson <rj...@gwmail.gwu.edu>]

esx

On Wed, Mar 24, 2010 at 8:57 AM, Aaron Peeler <aa...@ncsu.edu> wrote:

> The vm or node should be reloaded only if it confirmed as a used image, by
> being in the "inuse" state. If the node was simply reloaded with imageA
> using the reload function in computer utils and then the same node/same
> imageA was reloaded again through new reservation, then there might be a
> bug. Which provisioning module are you using?
>
> Aaron
>
>
>
> On 3/24/10 8:45 AM, Henry E Schaffer wrote:
>
>> Ryan writes:
>>
>>
>>> When testing the service I noticed something curious.  If I make a
>>> reservation, the vm files are copied and powered on.  When I end the
>>> reservation, the copied vm files are destroyed and copied again and the
>>> vm
>>> is powered on again - the vm is reloaded.  What is strange to me is that
>>> when I create a new reservation, the vm files are destroyed and copied
>>> again
>>> and the vm is powered on again.  Why would the vm be reloaded if only to
>>> reload it again on the next reservation for the same image?  Does the
>>> service maybe think that a different image is being requested?
>>>
>>>
>>   If you're describing the vm guest image, then there is a security
>> reason to do this.
>>
>>   The user can be Administrator/root for an image.  We generally do
>> this, although the choice is on an image by image basis.  So the user
>> can do something to affect/harm the image.  Whatever changes are made
>> can't affect the next user of the imaage if it isn't carried over to the
>> next image.  So reloading the image, even if it is the same image,
>> protects the user from whatever went on previously.
>>
>>   This protection removes a lot of possible problems, and is worth the
>> reloading.
>>
>>
>
>
> --
>
> Aaron Peeler
> Program Manager
> Virtual Computing Lab
> NC State University
> aaron_peeler@ncsu.edu
> 919-513-4571
>
>

Re: Reservations and Reloading

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

The vm or node should be reloaded only if it confirmed as a used image, 
by being in the "inuse" state. If the node was simply reloaded with 
imageA using the reload function in computer utils and then the same 
node/same imageA was reloaded again through new reservation, then there 
might be a bug. Which provisioning module are you using?

Aaron


On 3/24/10 8:45 AM, Henry E Schaffer wrote:
> Ryan writes:
>    
>> When testing the service I noticed something curious.  If I make a
>> reservation, the vm files are copied and powered on.  When I end the
>> reservation, the copied vm files are destroyed and copied again and the vm
>> is powered on again - the vm is reloaded.  What is strange to me is that
>> when I create a new reservation, the vm files are destroyed and copied again
>> and the vm is powered on again.  Why would the vm be reloaded if only to
>> reload it again on the next reservation for the same image?  Does the
>> service maybe think that a different image is being requested?
>>      
>    If you're describing the vm guest image, then there is a security
> reason to do this.
>
>    The user can be Administrator/root for an image.  We generally do
> this, although the choice is on an image by image basis.  So the user
> can do something to affect/harm the image.  Whatever changes are made
> can't affect the next user of the imaage if it isn't carried over to the
> next image.  So reloading the image, even if it is the same image,
> protects the user from whatever went on previously.
>
>    This protection removes a lot of possible problems, and is worth the
> reloading.
>    


-- 

Aaron Peeler
Program Manager
Virtual Computing Lab
NC State University
aaron_peeler@ncsu.edu
919-513-4571

Re: Reservations and Reloading

[Henry E Schaffer <he...@unity.ncsu.edu>]

Ryan writes:
> When testing the service I noticed something curious.  If I make a
> reservation, the vm files are copied and powered on.  When I end the
> reservation, the copied vm files are destroyed and copied again and the vm
> is powered on again - the vm is reloaded.  What is strange to me is that
> when I create a new reservation, the vm files are destroyed and copied again
> and the vm is powered on again.  Why would the vm be reloaded if only to
> reload it again on the next reservation for the same image?  Does the
> service maybe think that a different image is being requested?

  If you're describing the vm guest image, then there is a security
reason to do this.

  The user can be Administrator/root for an image.  We generally do
this, although the choice is on an image by image basis.  So the user
can do something to affect/harm the image.  Whatever changes are made
can't affect the next user of the imaage if it isn't carried over to the
next image.  So reloading the image, even if it is the same image,
protects the user from whatever went on previously.

  This protection removes a lot of possible problems, and is worth the
reloading.
-- 
--henry schaffer