Re: VirtualBox provisioning and capture.

2011-02-03 Thread Aaron Peeler

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 Kurthandy_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



Re: VirtualBox provisioning and capture.

2011-02-03 Thread David Hutchins
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 Kurthandy_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




Re: VirtualBox provisioning and capture.

2011-02-03 Thread Aaron Peeler

No problem - I understand getting pulled into other tasks.

Thanks for the additional info on the plans, those sound good. We can 
also help the design to line up with some useful general error checking 
in the VMware/* modules. Also we are interested in taking advantage of 
several features of vbox.


I've committed the vbox.pm module and the changes to vcl.sql file into 
the repository - anyone who wants to play with it can pull it from 
there. The two changes in the sql file where to add vbox to the module 
and provisioning tables - which will be needed for it to work.


I tagged it with the jira issue - 
https://issues.apache.org/jira/browse/VCL-417


Aaron


On 2/3/11 10:00 AM, David Hutchins wrote:

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 Peeleraaron_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 Kurthandy_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





--

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



Re: VirtualBox provisioning and capture.

2010-12-10 Thread Aaron Peeler

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



VirtualBox provisioning and capture.

2010-12-09 Thread David Hutchins
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.