$self->data->get_image_os_install_type() should do it.
On Wed, Aug 3, 2011 at 12:47 PM, Xianqing Yu <yu267155...@hotmail.com> wrote: > A quick question, do you know any function call can get OSinstalltype > content for the target image? > > Thanks, > > Xianqing Yu > > ------ > Graduate Research Assistant, Cyber Defense Lab > Department of Computer Science > North Carolina State University, Raleigh, NC > E-mail: x...@ncsu.edu > > -----Original Message----- From: Andy Kurth > Sent: Wednesday, August 03, 2011 09:38 AM > To: vcl-dev@incubator.apache.org > Subject: Re: The New KVM Provisioning module > > I agree that entries should be added to OSinstalltype. I wouldn't > include the 'kvm' hypervisor name in the name since the same type may > be used by multiple hypervisors. The 'vmware' entry can probably be > renamed to 'vmdk' and then used by both VMware and KVM. An entry can > be added named something like 'img' or 'vm-img'. > > On Tue, Aug 2, 2011 at 5:00 PM, Xianqing Yu <yu267155...@hotmail.com> wrote: >> >> I think it is possible to handle both types: vmdk and img. I believe that >> in >> my kvm provisioning code, the code need some conditions to decide if image >> file is vmdk file or img file. For example, We can add "kvm-img" and >> "kvm-vmware" into OSinstalltype table. If one image's OS module point to >> "kvm-img" as OSinstalltype, then the code should consider the image as >> "img" >> image file, and vice verse. >> >> Thanks, >> >> Xianqing Yu >> >> ------ >> Graduate Research Assistant, Cyber Defense Lab >> Department of Computer Science >> North Carolina State University, Raleigh, NC >> E-mail: x...@ncsu.edu >> -----Original Message----- From: Aaron Peeler >> Sent: Tuesday, August 02, 2011 02:39 PM >> To: vcl-dev@incubator.apache.org >> Subject: Re: The New KVM Provisioning module >> >> The imagename is related to the OS table. It's also dependent on the >> the OS.moduleid, OS.installtype and the computer.provisioningid. We >> might need to add new entries for this module, which isn't a problem. >> Just need to decide on how to name it. >> >> Ideally I would like to see the libvirt/kvm module handle both types - >> vmdk and img. >> >> Aaron >> >> >> On Mon, Aug 1, 2011 at 11:13 AM, Xianqing Yu <yu267155...@hotmail.com> >> wrote: >>> >>> Thanks for your suggestion. >>> >>> I have a question about define the image name and capture function. >>> Currently my kvm module can support vmware esxi image format (.vmdk and >>> flat.vmdk, so I can easily support existing flat.vmdk images by KVM). But >>> I >>> also want it to support other image formats, such as .img. >>> >>> I think we may need to define the name format both in VCL database and >>> KVM >>> module. Let's said there is an image named CentOS5, >>> >>> In VMDK format, >>> In VCL database, it should be esx-CentOS5-v0, >>> In image library, it should be files, esx-CentOS5-v0.vmdk and >>> esx-CentOS5-v0-flat.vmdk. >>> >>> My question is that what its name should be when the image file is img >>> format? My final goal is that make KVM module can support flat.vmdk and >>> img >>> file at the same time. Is that possible to do that? Or I should give one >>> of >>> them up? >>> >>> Thanks, >>> >>> Xianqing Yu >>> >>> ------ >>> Graduate Research Assistant, Cyber Defense Lab >>> Department of Computer Science >>> North Carolina State University, Raleigh, NC >>> E-mail: x...@ncsu.edu >>> -----Original Message----- From: Andy Kurth >>> Sent: Monday, August 01, 2011 09:02 AM >>> To: vcl-dev@incubator.apache.org >>> Subject: Re: The New KVM Provisioning module >>> >>> 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. >>> >>> >> >> >> >> -- >> 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. >> > >