Thanks Aaron,
That was an issue I was aware of, in my setup I just have all the disk
images in the root of the repository. I had planned to fix that, but never
got around to it, and being caught up in the migration of our finance system
to another product I haven't been able to work on VCL here for a couple
months. There is a light at the end of the tunnel though, and I expect to
get back to this soon. I had seen a JIRA issue with a request for persistent
snapshotting, and had started on that code last time I was working on it.
Since VBox creates a snapshot by default when provisioning, the thought was
to just unregister and move that SS image to a /snapshots directory in the
repository and insert a record into a newly created table on the management
DB with the location, owner, UUID, image that the SS works against, etc.
Then add an extra drop down from the create reservation page that appears
and gets populated if the user selects an image that they have snapshots
against. Of course there would need to be some sort of cleanup processes
that would clear out SS images if unused for some predefined length of time
and such.
Thanks again:
-David
On Thu, Feb 3, 2011 at 9:32 AM, Aaron Peeler <aaron_pee...@ncsu.edu> wrote:
> Hi David,
>
> Sorry it's taken so long to get this tested.
>
> I was able to set it up to work with our current code base without too much
> effort, which is good.
>
> Not sure if it was intended or if I set it up wrong, but I ran into a small
> issue with trying to provision a non-imaging load. Around line 356 when
> adding the storage medium I couldn't get it to work without explicitly
> listing the hdd file.
>
> --medium $image_repository_path/$requestedimagename", "root")
>
> my edit:
> --medium
> $image_repository_path/$requestedimagename/$requestedimagename.vdi", "root")
>
> Overall it works and looks really good and I think we can go ahead and add
> it to the repository. Then it will be easier to maintain it and make any
> improvements. I'll go ahead and add it to the repository today.
>
> Since you have the ICLA on file, you're interested in becoming a committer,
> and have shown that you can add great value to the community, we'll start
> the next phase, which is a voting process with the mentors and current
> committers.
>
> Aaron
>
>
> On 12/15/10 4:31 PM, David Hutchins wrote:
>
>> Thanks for the info, I will make those changes to the module.
>>
>> On Wed, Dec 15, 2010 at 4:23 PM, Andy Kurth<andy_ku...@ncsu.edu> wrote:
>>
>> Thanks for contributing this.
>>>
>>> I took a quick look at it. The utils.pm patch can be avoided by
>>> changing
>>> the call from _getcurrentimage to $self->os->get_current_image_name().
>>> The
>>> OS.pm::get_current_image_name subroutine takes its place and should
>>> return
>>> the same value.
>>>
>>> All calls to utils.pm::_getcurrentimage should really be changed and
>>> this
>>> subroutine should be removed. It contains code that was used before the
>>> OS-specific code was modularized.
>>>
>>> -Andy
>>>
>>>
>>>
>>>
>>> On 12/10/2010 8:34 AM, Aaron Peeler wrote:
>>>
>>> Cool. Look forward to testing it out.
>>>> Thanks
>>>> -Aaron
>>>>
>>>> On 12/9/10 5:26 PM, David Hutchins wrote:
>>>>
>>>> Provisioning and capture are working. The module only supports
>>>>> localdisk
>>>>> mode at the moment, but network storage support should be trivial at
>>>>> this
>>>>> point. If anyone wants to test this, feel free to contact me with
>>>>> questions.
>>>>> The code is currently attached to JIRA issue VCL-417, at
>>>>> https://issues.apache.org/jira/browse/VCL-417 . vcl.pm will have to be
>>>>> patched with the two patches, provisioning patch then capture patch.
>>>>> and
>>>>> utils.pm will need the provided patch.
>>>>>
>>>>>
>>>>>
>>>>
>
> --
>
> Aaron Peeler
> Program Manager
> Virtual Computing Lab
> NC State University
> aaron_pee...@ncsu.edu
> 919-513-4571
>
>
