$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.
>>
>
>

Reply via email to