Hi Xianqing, Sounds great. I'd like to help with this too. I like the idea about making it generic. Since libvirt supports a few different things, I think a very generic libvirt.pm module inheriting from Provisioning.pm makes sense: Package: VCL::Module::Provisioning::libvirt File: /usr/local/vcl/lib/VCL/Module/Provisioning/libvirt.pm
I'd create a Provisioning/libvirt subdirectory, and create .pm files for each libvirt/VCL supported product: Package: VCL::Module::Provisioning::libvirt::KVM File: /usr/local/vcl/lib/VCL/Module/Provisioning/libvirt/KVM.pm I agree to use the VMware module as an example though there will be a difference in how your Perl package path is constructed and where the files reside. The main VMware.pm file should reside 1 directory higher, directly under Provisioning. When the new VMware.pm module was created, the older vmware.pm module already resided in this location. We couldn't remove it at that time so I put VMware.pm a directory lower to keep them straight. There is a lot of code in the VMware.pm module that could be reused by other modules. I tried to break up the subroutines as much as possible so that each one performs a single function. Many of them are not VMware-specific and could be moved up into Provisioning.pm so that the code can be reused by libvirt.pm and other provisioning modules. Submitting your code via Jira is the best way to get started. We already have issue VCL-339 for this. Please be sure to submit your code as an attached file to the issue, not copied/pasted to the description. Also, 1 suggestion for anyone working on code. Make sure you are developing using a checked-out copy of trunk from Subversion and perform a 'svn update' regularly. Don't work off of the code in the VCL 2.2.1 release because it is changing frequently. It will also be very easy to commit your code to trunk this way. Thanks, Andy On Fri, Jul 29, 2011 at 4:30 PM, Xianqing Yu <xia...@us.ibm.com> wrote: > Aaron, > > Thank your interesting. > > I looked at the vmware Provisioning module code, and try to learn and reuse > some code from that. Because there are some many functions in VMware.pm, I > probably start with some basic functions, and make it work first. > > About structure, I has several functions inside my kvm.pm, including, > initialize, load, capture, node_status and get_image_size. I already finish > most of them except for capture function. So basically, kvm module will do > very similar thing as VMware.pm. And it generates a XML file to define the VM > (like VMX file in VMware) and creates VM on KVM by sending ssh command "virsh > create vm.xml". I have a script which can install necessary packages and set > up proper network configuration on the host. So I can use that with xCAT to > create kickstart image for KVM host. I also can use the script to configure > existing Fedora machine. > > I can have my script and kvm provisioning code ready within three days, so > you guys can take a look. So should I publish it on the JIRE? > > Thanks, > > Xianqing Yu > > WSTI Intern > xia...@us.ibm.com > > -----Aaron Peeler <fapee...@ncsu.edu> wrote: ----- > > To: vcl-dev@incubator.apache.org > From: Aaron Peeler <fapee...@ncsu.edu> > Date: 07/29/2011 08:58AM > Subject: Re: The New KVM Provisioning module > > Hi Xianqing, > > This is great. I'd like to work with you this module. > > What are your thoughts on the structure? > > Have you looked at the work Andy did on the VMware Prov module: > /..../lib/VCL/Module/Provisioning/VMware > > > Aaron > > > > On Tue, Jul 26, 2011 at 11:18 PM, Xianqing Yu <xia...@us.ibm.com> wrote: > > > > > > > > Hi VCL community, > > > > I am developing KVM Provisioning Module for VCL system, which is based on > > my previous version of KVM Provisioning Module. You can find out my > > previous KVM module's information from here, > > https://issues.apache.org/jira/browse/VCL-339 > > > > Currently, I am trying to make this module's code as generic as possible. > > And I will including these features inside this new version of module. > > 1. The module will use libvirt API to manipulate the VM on KVM hosts. The > > main reason behind this is that libvirt is widely used API, many people > in > > the community talked about this before, and libvirt support for different > > hypervisors, such as KVM, Xen, Qemu, etc.. It would be easier to port > this > > module to support other hypervisor in future. > > 2. A setup scripted will be developed to help the users to setup host > much > > easier. > > 3. A document descripts how to install this module. > > > > Welcome everyone to join the discussion with me if you are interesting > > about. Such as, is there any new features you expect to see in this > module? > > Do you have any suggestion about this module? Or you have any questions > > about this module? Please let me know. > > > > Thanks, > > > > Xianqing Yu > > WSTI Intern > > xia...@us.ibm.com > > > > -- > Aaron Peeler > Program Manager > Virtual Computing Lab > NC State University > > All electronic mail messages in connection with State business which > are sent to or received by this account are subject to the NC Public > Records Law and may be disclosed to third parties.