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 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.
Re: The New KVM Provisioning module
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 wrote: -
To: vcl-dev@incubator.apache.org
From: Aaron Peeler
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 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.
Re: The New KVM Provisioning module
Xianqing, Sounds great. Yes. Attach the work to the jira issue - the prov module and the kvm host setup script. Look forward to seeing it. thanks, Aaron On Fri, Jul 29, 2011 at 4:30 PM, Xianqing Yu 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 wrote: - > > To: vcl-dev@incubator.apache.org > From: Aaron Peeler > 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 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.
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 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 wrote: ----- > > To: vcl-dev@incubator.apache.org > From: Aaron Peeler > 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 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 every
Re: The New KVM Provisioning module
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 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 wrote: - To: vcl-dev@incubator.apache.org From: Aaron Peeler 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 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&#
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 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 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
Re: The New KVM Provisioning module
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 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 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&
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 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 > 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
Re: The New KVM Provisioning module
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 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 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
Re: The New KVM Provisioning module
$self->data->get_image_os_install_type() should do it. On Wed, Aug 3, 2011 at 12:47 PM, Xianqing Yu 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 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 >> 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/libvi
Re: The New KVM Provisioning module
Hi David and Andy, I finish the new version of KVM provision module for VCL 2.2.1. I upload the kvm.pm code to VCL JIRE. Please take a look at my code and let me know what do you feel about it. The link is, https://issues.apache.org/jira/browse/VCL-339 Generally, the new version of KVM module contain these features, 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. An setup script can help the users to setup KVM host much easier. The attachment named kvmsetup is the script. I tested it on Fedora 9. Basically, user need to install Fedora 9 (or use XCAT to install Fedora 9 on blade automatically) and run the script as the root user. 3. Users don't have to use qemu-ifup and mac script. "qemu-ifup" is not needed because of using lib-virt and "mac" is now included in kvm.pm. So kvm.pm is the only file you need to add to VCL Management Machine. 4. Both "-flat.vmdk" and "img" image format are supported. So now both KVM image and VMware ESXi image (flat.vmdk) can be provisioned on KVM host. 5. Misc code updated. Thanks, Xianqing -Original Message- From: Andy Kurth Sent: Wednesday, August 03, 2011 02:14 PM To: vcl-dev@incubator.apache.org Subject: Re: The New KVM Provisioning module $self->data->get_image_os_install_type() should do it. On Wed, Aug 3, 2011 at 12:47 PM, Xianqing Yu 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 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 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 ma
Re: The New KVM Provisioning module
Hi VCL community, Sorry for the typo in previous email. I finish the new version of KVM provision module for VCL 2.2.1. I upload the kvm.pm code to VCL JIRE. Please take a look at my code and let me know what do you feel about it. The link is, https://issues.apache.org/jira/browse/VCL-339 Generally, the new version of KVM module contain these features, 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. An setup script can help the users to setup KVM host much easier. The attachment named kvmsetup is the script. I tested it on Fedora 9. Basically, user need to install Fedora 9 (or use XCAT to install Fedora 9 on blade automatically) and run the script as the root user. 3. Users don't have to use qemu-ifup and mac script. "qemu-ifup" is not needed because of using lib-virt and "mac" is now included in kvm.pm. So kvm.pm is the only file you need to add to VCL Management Machine. 4. Both "-flat.vmdk" and "img" image format are supported. So now both KVM image and VMware ESXi image (flat.vmdk) can be provisioned on KVM host. 5. Misc code updated. Thanks, Xianqing -Original Message- From: Andy Kurth Sent: Wednesday, August 03, 2011 02:14 PM To: vcl-dev@incubator.apache.org Subject: Re: The New KVM Provisioning module $self->data->get_image_os_install_type() should do it. On Wed, Aug 3, 2011 at 12:47 PM, Xianqing Yu 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 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 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 t
Re: The New KVM Provisioning module
This is great. I'll try to have some more useful comments soon. :) Thanks Xianqing. Aaron On Thu, Aug 4, 2011 at 11:11 AM, Xianqing Yu wrote: > Hi VCL community, > > Sorry for the typo in previous email. > > I finish the new version of KVM provision module for VCL 2.2.1. I upload the > kvm.pm code to VCL JIRE. Please take a look at my code and let me know what > do you feel about it. The link is, > > https://issues.apache.org/jira/browse/VCL-339 > > Generally, the new version of KVM module contain these features, > > 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. An setup script can help the users to setup KVM host much easier. The > attachment named kvmsetup is the script. I tested it on Fedora 9. Basically, > user need to install Fedora 9 (or use XCAT to install Fedora 9 on blade > automatically) and run the script as the root user. > > 3. Users don't have to use qemu-ifup and mac script. "qemu-ifup" is not > needed because of using lib-virt and "mac" is now included in kvm.pm. So > kvm.pm is the only file you need to add to VCL Management Machine. > > 4. Both "-flat.vmdk" and "img" image format are supported. So now both KVM > image and VMware ESXi image (flat.vmdk) can be provisioned on KVM host. > > 5. Misc code updated. > > > Thanks, > > Xianqing > -----Original Message- From: Andy Kurth > Sent: Wednesday, August 03, 2011 02:14 PM > To: vcl-dev@incubator.apache.org > Subject: Re: The New KVM Provisioning module > > $self->data->get_image_os_install_type() should do it. > > On Wed, Aug 3, 2011 at 12:47 PM, Xianqing Yu > 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 >> 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 >>> wrote: >>>> >>>> Thanks for your suggestion. >>>> >>>> I have a question about define the
Re: The New KVM Provisioning module
Xianqing, I've started reviewing the code and have a couple of questions. Please take this as constructive, I'm excited to get the kvm development started, but would like take a lot of the lessons we've learned from some of the previous provisioning modules to get libvirt prov module on the right path. In your load routine it looks like your having to copy the img and vmdk files before starting the vm, was this intended or could it have been something leftover from another template. This will be very slow before vcld would get to the point of starting a vm, some those files can be very large. With the vmdk's under VMware/VMware.pm we run in non-persistent mode and for image captures started using snapshots in the development code. I'm pretty sure you can do something similar with kvm. Do you know of or have you tested another method in running vms a sort of non-persistent mode under kvm? Copying a large .vmdk or .img file on each provisioning request will not work very well in the long-term. By chance did you have time to look at the lib/VCL/Module/Provisioning/VMware/VMware.pm framework? Ideally we'd like to build a similar framework for libvirt. Thanks, Aaron On Thu, Aug 4, 2011 at 1:34 PM, Aaron Peeler wrote: > This is great. I'll try to have some more useful comments soon. :) > Thanks Xianqing. > > Aaron > > On Thu, Aug 4, 2011 at 11:11 AM, Xianqing Yu wrote: >> Hi VCL community, >> >> Sorry for the typo in previous email. >> >> I finish the new version of KVM provision module for VCL 2.2.1. I upload the >> kvm.pm code to VCL JIRE. Please take a look at my code and let me know what >> do you feel about it. The link is, >> >> https://issues.apache.org/jira/browse/VCL-339 >> >> Generally, the new version of KVM module contain these features, >> >> 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. An setup script can help the users to setup KVM host much easier. The >> attachment named kvmsetup is the script. I tested it on Fedora 9. Basically, >> user need to install Fedora 9 (or use XCAT to install Fedora 9 on blade >> automatically) and run the script as the root user. >> >> 3. Users don't have to use qemu-ifup and mac script. "qemu-ifup" is not >> needed because of using lib-virt and "mac" is now included in kvm.pm. So >> kvm.pm is the only file you need to add to VCL Management Machine. >> >> 4. Both "-flat.vmdk" and "img" image format are supported. So now both KVM >> image and VMware ESXi image (flat.vmdk) can be provisioned on KVM host. >> >> 5. Misc code updated. >> >> >> Thanks, >> >> Xianqing >> -Original Message- From: Andy Kurth >> Sent: Wednesday, August 03, 2011 02:14 PM >> To: vcl-dev@incubator.apache.org >> Subject: Re: The New KVM Provisioning module >> >> $self->data->get_image_os_install_type() should do it. >> >> On Wed, Aug 3, 2011 at 12:47 PM, Xianqing Yu >> 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 >>> 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 >>>&
Re: The New KVM Provisioning module
Aaron, Libvirt currently don't have support for non-persistent disk. I sent email to libvirt mail list to ask, and according to Eric Blake said, he is working on that now, and it may be included in libvirt 0.9.5. I also take a look at qemu-kvm API. It support non-persistent disk. I can use command "qemu-kvm -snapshot.." to make it work. For now, I think we have to choose, either use libvirt without non-persistent disk support, or use qemu-kvm API. 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: Wednesday, August 10, 2011 04:01 PM To: vcl-dev@incubator.apache.org Subject: Re: The New KVM Provisioning module Xianqing, I've started reviewing the code and have a couple of questions. Please take this as constructive, I'm excited to get the kvm development started, but would like take a lot of the lessons we've learned from some of the previous provisioning modules to get libvirt prov module on the right path. In your load routine it looks like your having to copy the img and vmdk files before starting the vm, was this intended or could it have been something leftover from another template. This will be very slow before vcld would get to the point of starting a vm, some those files can be very large. With the vmdk's under VMware/VMware.pm we run in non-persistent mode and for image captures started using snapshots in the development code. I'm pretty sure you can do something similar with kvm. Do you know of or have you tested another method in running vms a sort of non-persistent mode under kvm? Copying a large .vmdk or .img file on each provisioning request will not work very well in the long-term. By chance did you have time to look at the lib/VCL/Module/Provisioning/VMware/VMware.pm framework? Ideally we'd like to build a similar framework for libvirt. Thanks, Aaron On Thu, Aug 4, 2011 at 1:34 PM, Aaron Peeler wrote: This is great. I'll try to have some more useful comments soon. :) Thanks Xianqing. Aaron On Thu, Aug 4, 2011 at 11:11 AM, Xianqing Yu wrote: Hi VCL community, Sorry for the typo in previous email. I finish the new version of KVM provision module for VCL 2.2.1. I upload the kvm.pm code to VCL JIRE. Please take a look at my code and let me know what do you feel about it. The link is, https://issues.apache.org/jira/browse/VCL-339 Generally, the new version of KVM module contain these features, 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. An setup script can help the users to setup KVM host much easier. The attachment named kvmsetup is the script. I tested it on Fedora 9. Basically, user need to install Fedora 9 (or use XCAT to install Fedora 9 on blade automatically) and run the script as the root user. 3. Users don't have to use qemu-ifup and mac script. "qemu-ifup" is not needed because of using lib-virt and "mac" is now included in kvm.pm. So kvm.pm is the only file you need to add to VCL Management Machine. 4. Both "-flat.vmdk" and "img" image format are supported. So now both KVM image and VMware ESXi image (flat.vmdk) can be provisioned on KVM host. 5. Misc code updated. Thanks, Xianqing -Original Message- From: Andy Kurth Sent: Wednesday, August 03, 2011 02:14 PM To: vcl-dev@incubator.apache.org Subject: Re: The New KVM Provisioning module $self->data->get_image_os_install_type() should do it. On Wed, Aug 3, 2011 at 12:47 PM, Xianqing Yu 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 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 i
Re: The New KVM Provisioning module
Hi Xianqing, Right I think the snapshot method might be the best way to go. It would allow a quick way to clone with doing a full copy. Aaron On Mon, Aug 15, 2011 at 5:02 PM, Xianqing Yu wrote: > Aaron, > > Libvirt currently don't have support for non-persistent disk. I sent email > to libvirt mail list to ask, and according to Eric Blake said, he is working > on that now, and it may be included in libvirt 0.9.5. > > I also take a look at qemu-kvm API. It support non-persistent disk. I can > use command "qemu-kvm -snapshot.." to make it work. > > For now, I think we have to choose, either use libvirt without > non-persistent disk support, or use qemu-kvm API. > > 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: Wednesday, August 10, 2011 04:01 PM > To: vcl-dev@incubator.apache.org > Subject: Re: The New KVM Provisioning module > > Xianqing, > > I've started reviewing the code and have a couple of questions. Please > take this as constructive, I'm excited to get the kvm development > started, but would like take a lot of the lessons we've learned from > some of the previous provisioning modules to get libvirt prov module > on the right path. > > In your load routine it looks like your having to copy the img and > vmdk files before starting the vm, was this intended or could it have > been something leftover from another template. This will be very slow > before vcld would get to the point of starting a vm, some those files > can be very large. > > With the vmdk's under VMware/VMware.pm we run in non-persistent mode > and for image captures started using snapshots in the development > code. I'm pretty sure you can do something similar with kvm. > > Do you know of or have you tested another method in running vms a sort > of non-persistent mode under kvm? Copying a large .vmdk or .img file > on each provisioning request will not work very well in the long-term. > > By chance did you have time to look at the > lib/VCL/Module/Provisioning/VMware/VMware.pm framework? > Ideally we'd like to build a similar framework for libvirt. > > Thanks, > Aaron > > > > On Thu, Aug 4, 2011 at 1:34 PM, Aaron Peeler wrote: >> >> This is great. I'll try to have some more useful comments soon. :) >> Thanks Xianqing. >> >> Aaron >> >> On Thu, Aug 4, 2011 at 11:11 AM, Xianqing Yu >> wrote: >>> >>> Hi VCL community, >>> >>> Sorry for the typo in previous email. >>> >>> I finish the new version of KVM provision module for VCL 2.2.1. I upload >>> the >>> kvm.pm code to VCL JIRE. Please take a look at my code and let me know >>> what >>> do you feel about it. The link is, >>> >>> https://issues.apache.org/jira/browse/VCL-339 >>> >>> Generally, the new version of KVM module contain these features, >>> >>> 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. An setup script can help the users to setup KVM host much easier. The >>> attachment named kvmsetup is the script. I tested it on Fedora 9. >>> Basically, >>> user need to install Fedora 9 (or use XCAT to install Fedora 9 on blade >>> automatically) and run the script as the root user. >>> >>> 3. Users don't have to use qemu-ifup and mac script. "qemu-ifup" is not >>> needed because of using lib-virt and "mac" is now included in kvm.pm. So >>> kvm.pm is the only file you need to add to VCL Management Machine. >>> >>> 4. Both "-flat.vmdk" and "img" image format are supported. So now both >>> KVM >>> image and VMware ESXi image (flat.vmdk) can be provisioned on KVM host. >>> >>> 5. Misc code updated. >>> >>> >>> Thanks, >>> >>> Xianqing >>> -Original Message- From: Andy Kurth >>> Sent: Wednesday, August 03, 2011 02:14 PM >>> To: vcl-dev@incubator.apache.org >>> Subject: Re: The New KVM Provisioning module >>> >>
Re: The New KVM Provisioning module
Aaron, Right, but this is only for KVM API, in qemu-kvm description, it said "-snapshot write to temporary files instead of disk image files". Right now, Libvirt don't support that. If we using libvirt API in kvm provisioning module, we couldn't make non-persistent disk work until libvirt getting updated in next version to include this. So for now, if we want to use non-persistent disk, we have to use KVM API directly (without libvirt) in our provisioning module. So do you means that we should use KVM API instead of libvirt API for now? Following is email message between Eric and me, FYI. On 08/15/2011 02:57 PM, Xianqing Yu wrote: So, if I understand correctly, non-persistent disk is not there yet. But it may release with next version of libvirt, right? Correct. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org On 08/15/2011 02:01 PM, Xianqing Yu wrote: Hi Libvirt team, I am trying to create a new domain from XML file by using libvirt. I want this new domain using non-persistent disk as its disk. Non-persistent disk means that when the domain is running, all the modification would not be written to disk file. So next time, when you boot VM from the same disk file, you would have a fresh disk. I check the website but I could not find anything about this. I wonder if libvirt support this function. Yep, I'm working on it, and hope to have it in 0.9.5. See my RFC here: https://www.redhat.com/archives/libvir-list/2011-August/msg00552.html You will basically call out: ... ... FYI, if I use KVM, I can use command "qemu-kvm -snapshot" to boot a VM on non-persistent disk. Unfortunately, that makes for a non-migrateable VM - so I'm working on something a bit more robust that stands a chance of creating a transient yet migrateable domain. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org 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 16, 2011 10:31 AM To: Xianqing Yu Cc: vcl-dev@incubator.apache.org Subject: Re: The New KVM Provisioning module Hi Xianqing, Right I think the snapshot method might be the best way to go. It would allow a quick way to clone with doing a full copy. Aaron On Mon, Aug 15, 2011 at 5:02 PM, Xianqing Yu wrote: Aaron, Libvirt currently don't have support for non-persistent disk. I sent email to libvirt mail list to ask, and according to Eric Blake said, he is working on that now, and it may be included in libvirt 0.9.5. I also take a look at qemu-kvm API. It support non-persistent disk. I can use command "qemu-kvm -snapshot.." to make it work. For now, I think we have to choose, either use libvirt without non-persistent disk support, or use qemu-kvm API. 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: Wednesday, August 10, 2011 04:01 PM To: vcl-dev@incubator.apache.org Subject: Re: The New KVM Provisioning module Xianqing, I've started reviewing the code and have a couple of questions. Please take this as constructive, I'm excited to get the kvm development started, but would like take a lot of the lessons we've learned from some of the previous provisioning modules to get libvirt prov module on the right path. In your load routine it looks like your having to copy the img and vmdk files before starting the vm, was this intended or could it have been something leftover from another template. This will be very slow before vcld would get to the point of starting a vm, some those files can be very large. With the vmdk's under VMware/VMware.pm we run in non-persistent mode and for image captures started using snapshots in the development code. I'm pretty sure you can do something similar with kvm. Do you know of or have you tested another method in running vms a sort of non-persistent mode under kvm? Copying a large .vmdk or .img file on each provisioning request will not work very well in the long-term. By chance did you have time to look at the lib/VCL/Module/Provisioning/VMware/VMware.pm framework? Ideally we'd like to build a similar framework for libvirt. Thanks, Aaron On Thu, Aug 4, 2011 at 1:34 PM, Aaron Peeler wrote: This is great. I'll try to have some more useful comments soon. :) Thanks Xianqing. Aaron On Thu, Aug 4, 2011 at 11:11 AM, Xianqing Yu wrote: Hi VCL community, Sorry for the typo in previous email. I finish the new version of KVM provision module for VCL 2.2.1. I upload the kvm.pm code to VCL JIRE. Please take a look at
Re: The New KVM Provisioning module
I suggest we use both for now, until it's fully supported in libvirt API. Use qemu-img to create a qcow2 snapshot for non-imaging reservations. Then use virsh for the rest of the process. Once libvirt supports it, then we upgrade that portion. We'll have to decide if we want to try to also use vmdk files formats on kvm. It's a nice feature but not sure if it is a requirement for using vmdk's on kvm hosts. Also there is a virsh snapshot-create which appears to work only on qcow2 based files. I've not successfully created a snapshot that I can boot yet, but it might be another option. Aaron On Tue, Aug 16, 2011 at 12:20 PM, Xianqing Yu wrote: > Aaron, > > Right, but this is only for KVM API, in qemu-kvm description, it said > "-snapshot write to temporary files instead of disk image files". > Right now, Libvirt don't support that. If we using libvirt API in kvm > provisioning module, we couldn't make non-persistent disk work until libvirt > getting updated in next version to include this. > > So for now, if we want to use non-persistent disk, we have to use KVM API > directly (without libvirt) in our provisioning module. > > So do you means that we should use KVM API instead of libvirt API for now? > > Following is email message between Eric and me, FYI. > > > On 08/15/2011 02:57 PM, Xianqing Yu wrote: >> >> So, if I understand correctly, non-persistent disk is not there yet. But >> it may release with next version of libvirt, right? > > Correct. > > -- > Eric Blake ebl...@redhat.com +1-801-349-2682 > Libvirt virtualization library http://libvirt.org > > > On 08/15/2011 02:01 PM, Xianqing Yu wrote: >> >> Hi Libvirt team, >> >> I am trying to create a new domain from XML file by using libvirt. I >> want this new domain using non-persistent disk as its disk. >> Non-persistent disk means that when the domain is running, all the >> modification would not be written to disk file. So next time, when you >> boot VM from the same disk file, you would have a fresh disk. I check >> the website but I could not find anything about this. I wonder if >> libvirt support this function. > > Yep, I'm working on it, and hope to have it in 0.9.5. See my RFC here: > > https://www.redhat.com/archives/libvir-list/2011-August/msg00552.html > > You will basically call out: > > > > ... > > > ... > >> FYI, if I use KVM, I can use command "qemu-kvm -snapshot" to boot a VM >> on non-persistent disk. > > Unfortunately, that makes for a non-migrateable VM - so I'm working on > something a bit more robust that stands a chance of creating a transient > yet migrateable domain. > > -- > Eric Blake ebl...@redhat.com +1-801-349-2682 > Libvirt virtualization library http://libvirt.org > > > 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 16, 2011 10:31 AM > To: Xianqing Yu > Cc: vcl-dev@incubator.apache.org > Subject: Re: The New KVM Provisioning module > > Hi Xianqing, > > Right I think the snapshot method might be the best way to go. It > would allow a quick way to clone with doing a full copy. > Aaron > > On Mon, Aug 15, 2011 at 5:02 PM, Xianqing Yu > wrote: >> >> Aaron, >> >> Libvirt currently don't have support for non-persistent disk. I sent email >> to libvirt mail list to ask, and according to Eric Blake said, he is >> working >> on that now, and it may be included in libvirt 0.9.5. >> >> I also take a look at qemu-kvm API. It support non-persistent disk. I can >> use command "qemu-kvm -snapshot.." to make it work. >> >> For now, I think we have to choose, either use libvirt without >> non-persistent disk support, or use qemu-kvm API. >> >> 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: Wednesday, August 10, 2011 04:01 PM >> To: vcl-dev@incubator.apache.org >> Subject: Re: The New KVM Provisioning module >> >> Xianqing, >> >> I've started reviewing the code and have a couple of questions. Please >> take this as constructive, I'm excited to get the kvm development >> started, but w
Re: The New KVM Provisioning module
OK. Let's use both APIs. I have to clarify one thing. Although qemu-kvm use -snapshot option. But it is not the snapshot you are thinking about. You don't have to create any snapshot for the images. I only need to add this option to command line. For example, if I want one VM boot on the image A and don't modify anything on the image A, I just simply send this command "qemu-kvm -m 512 imagefile -snapshot -net, network configuartion". So it is actually the same as non-persistent disk option in VMware, and I think that the name "snapshot" is very easy to misunderstand here. About the vmdk on KVM, I think it is an option. The users need to define installtype in VCL database. If it is vmware, KVM module would consider the image file is vmdk type 4. If it is kvm, KVM module would use img instead. So users can decide what they want to use. And by supporting vmdk file, all current vmdk image running on the VMware ESX can be used directly on KVM host without any effort. I think it could be very nice feature in future. 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 16, 2011 01:39 PM To: vcl-dev@incubator.apache.org Subject: Re: The New KVM Provisioning module I suggest we use both for now, until it's fully supported in libvirt API. Use qemu-img to create a qcow2 snapshot for non-imaging reservations. Then use virsh for the rest of the process. Once libvirt supports it, then we upgrade that portion. We'll have to decide if we want to try to also use vmdk files formats on kvm. It's a nice feature but not sure if it is a requirement for using vmdk's on kvm hosts. Also there is a virsh snapshot-create which appears to work only on qcow2 based files. I've not successfully created a snapshot that I can boot yet, but it might be another option. Aaron On Tue, Aug 16, 2011 at 12:20 PM, Xianqing Yu wrote: Aaron, Right, but this is only for KVM API, in qemu-kvm description, it said "-snapshot write to temporary files instead of disk image files". Right now, Libvirt don't support that. If we using libvirt API in kvm provisioning module, we couldn't make non-persistent disk work until libvirt getting updated in next version to include this. So for now, if we want to use non-persistent disk, we have to use KVM API directly (without libvirt) in our provisioning module. So do you means that we should use KVM API instead of libvirt API for now? Following is email message between Eric and me, FYI. On 08/15/2011 02:57 PM, Xianqing Yu wrote: So, if I understand correctly, non-persistent disk is not there yet. But it may release with next version of libvirt, right? Correct. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org On 08/15/2011 02:01 PM, Xianqing Yu wrote: Hi Libvirt team, I am trying to create a new domain from XML file by using libvirt. I want this new domain using non-persistent disk as its disk. Non-persistent disk means that when the domain is running, all the modification would not be written to disk file. So next time, when you boot VM from the same disk file, you would have a fresh disk. I check the website but I could not find anything about this. I wonder if libvirt support this function. Yep, I'm working on it, and hope to have it in 0.9.5. See my RFC here: https://www.redhat.com/archives/libvir-list/2011-August/msg00552.html You will basically call out: ... ... FYI, if I use KVM, I can use command "qemu-kvm -snapshot" to boot a VM on non-persistent disk. Unfortunately, that makes for a non-migrateable VM - so I'm working on something a bit more robust that stands a chance of creating a transient yet migrateable domain. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org 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 16, 2011 10:31 AM To: Xianqing Yu Cc: vcl-dev@incubator.apache.org Subject: Re: The New KVM Provisioning module Hi Xianqing, Right I think the snapshot method might be the best way to go. It would allow a quick way to clone with doing a full copy. Aaron On Mon, Aug 15, 2011 at 5:02 PM, Xianqing Yu wrote: Aaron, Libvirt currently don't have support for non-persistent disk. I sent email to libvirt mail list to ask, and according to Eric Blake said, he is working on that now, and it may be included in libvirt 0.9.5. I also take a look at qemu-kvm API. It support non-persistent disk. I can use command "qemu-kvm -snapshot.." t
Re: The New KVM Provisioning module
I was looking at qemu-img command on the snapshots. I've found qemu-kvm command, it wasn't in my default PATH. Looking at the manpage. So is libvirt virt-install command actually calling qemu-kvm ? I noticed some of the same options, but not the snapshot option. Right, vmdk on kvm is definitely an option and is useful. Just might be limited and for using full kvm features like being able to merge qcow's, etc. They might have to be converted on the fly or during an automated import. - This can be a later feature though and is nothing that has to be address now. Aaron On Tue, Aug 16, 2011 at 3:01 PM, Xianqing Yu wrote: > OK. Let's use both APIs. > > I have to clarify one thing. Although qemu-kvm use -snapshot option. But it > is not the snapshot you are thinking about. You don't have to create any > snapshot for the images. I only need to add this option to command line. For > example, if I want one VM boot on the image A and don't modify anything on > the image A, I just simply send this command "qemu-kvm -m 512 imagefile > -snapshot -net, network configuartion". So it is actually the same as > non-persistent disk option in VMware, and I think that the name "snapshot" > is very easy to misunderstand here. > > About the vmdk on KVM, I think it is an option. The users need to define > installtype in VCL database. If it is vmware, KVM module would consider the > image file is vmdk type 4. If it is kvm, KVM module would use img instead. > So users can decide what they want to use. And by supporting vmdk file, all > current vmdk image running on the VMware ESX can be used directly on KVM > host without any effort. I think it could be very nice feature in future. > > 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 16, 2011 01:39 PM > To: vcl-dev@incubator.apache.org > Subject: Re: The New KVM Provisioning module > > I suggest we use both for now, until it's fully supported in libvirt API. > > Use qemu-img to create a qcow2 snapshot for non-imaging reservations. > Then use virsh for the rest of the process. > > Once libvirt supports it, then we upgrade that portion. > > We'll have to decide if we want to try to also use vmdk files formats > on kvm. It's a nice feature but not sure if it is a requirement for > using vmdk's on kvm hosts. > > Also there is a virsh snapshot-create which appears to work only on > qcow2 based files. I've not successfully created a snapshot that I can > boot yet, but it might be another option. > > Aaron > > On Tue, Aug 16, 2011 at 12:20 PM, Xianqing Yu > wrote: >> >> Aaron, >> >> Right, but this is only for KVM API, in qemu-kvm description, it said >> "-snapshot write to temporary files instead of disk image files". >> Right now, Libvirt don't support that. If we using libvirt API in kvm >> provisioning module, we couldn't make non-persistent disk work until >> libvirt >> getting updated in next version to include this. >> >> So for now, if we want to use non-persistent disk, we have to use KVM API >> directly (without libvirt) in our provisioning module. >> >> So do you means that we should use KVM API instead of libvirt API for now? >> >> Following is email message between Eric and me, FYI. >> >> >> On 08/15/2011 02:57 PM, Xianqing Yu wrote: >>> >>> So, if I understand correctly, non-persistent disk is not there yet. But >>> it may release with next version of libvirt, right? >> >> Correct. >> >> -- >> Eric Blake ebl...@redhat.com +1-801-349-2682 >> Libvirt virtualization library http://libvirt.org >> >> >> On 08/15/2011 02:01 PM, Xianqing Yu wrote: >>> >>> Hi Libvirt team, >>> >>> I am trying to create a new domain from XML file by using libvirt. I >>> want this new domain using non-persistent disk as its disk. >>> Non-persistent disk means that when the domain is running, all the >>> modification would not be written to disk file. So next time, when you >>> boot VM from the same disk file, you would have a fresh disk. I check >>> the website but I could not find anything about this. I wonder if >>> libvirt support this function. >> >> Yep, I'm working on it, and hope to have it in 0.9.5. See my RFC here: >> >> https://www.redhat.com/archives/libvir-list/2011-August/msg00552.html >>
Re: The New KVM Provisioning module
Nevermind. I answer my own question. virt-install is using qemu-kvm under the covers. Aaron On Tue, Aug 16, 2011 at 3:32 PM, Aaron Peeler wrote: > I was looking at qemu-img command on the snapshots. > > I've found qemu-kvm command, it wasn't in my default PATH. Looking at > the manpage. > > So is libvirt virt-install command actually calling qemu-kvm ? I > noticed some of the same options, but not the snapshot option. > > Right, vmdk on kvm is definitely an option and is useful. Just might > be limited and for using full kvm features like being able to merge > qcow's, etc. They might have to be converted on the fly or during an > automated import. - This can be a later feature though and is nothing > that has to be address now. > > Aaron > > > On Tue, Aug 16, 2011 at 3:01 PM, Xianqing Yu wrote: >> OK. Let's use both APIs. >> >> I have to clarify one thing. Although qemu-kvm use -snapshot option. But it >> is not the snapshot you are thinking about. You don't have to create any >> snapshot for the images. I only need to add this option to command line. For >> example, if I want one VM boot on the image A and don't modify anything on >> the image A, I just simply send this command "qemu-kvm -m 512 imagefile >> -snapshot -net, network configuartion". So it is actually the same as >> non-persistent disk option in VMware, and I think that the name "snapshot" >> is very easy to misunderstand here. >> >> About the vmdk on KVM, I think it is an option. The users need to define >> installtype in VCL database. If it is vmware, KVM module would consider the >> image file is vmdk type 4. If it is kvm, KVM module would use img instead. >> So users can decide what they want to use. And by supporting vmdk file, all >> current vmdk image running on the VMware ESX can be used directly on KVM >> host without any effort. I think it could be very nice feature in future. >> >> 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 16, 2011 01:39 PM >> To: vcl-dev@incubator.apache.org >> Subject: Re: The New KVM Provisioning module >> >> I suggest we use both for now, until it's fully supported in libvirt API. >> >> Use qemu-img to create a qcow2 snapshot for non-imaging reservations. >> Then use virsh for the rest of the process. >> >> Once libvirt supports it, then we upgrade that portion. >> >> We'll have to decide if we want to try to also use vmdk files formats >> on kvm. It's a nice feature but not sure if it is a requirement for >> using vmdk's on kvm hosts. >> >> Also there is a virsh snapshot-create which appears to work only on >> qcow2 based files. I've not successfully created a snapshot that I can >> boot yet, but it might be another option. >> >> Aaron >> >> On Tue, Aug 16, 2011 at 12:20 PM, Xianqing Yu >> wrote: >>> >>> Aaron, >>> >>> Right, but this is only for KVM API, in qemu-kvm description, it said >>> "-snapshot write to temporary files instead of disk image files". >>> Right now, Libvirt don't support that. If we using libvirt API in kvm >>> provisioning module, we couldn't make non-persistent disk work until >>> libvirt >>> getting updated in next version to include this. >>> >>> So for now, if we want to use non-persistent disk, we have to use KVM API >>> directly (without libvirt) in our provisioning module. >>> >>> So do you means that we should use KVM API instead of libvirt API for now? >>> >>> Following is email message between Eric and me, FYI. >>> >>> >>> On 08/15/2011 02:57 PM, Xianqing Yu wrote: >>>> >>>> So, if I understand correctly, non-persistent disk is not there yet. But >>>> it may release with next version of libvirt, right? >>> >>> Correct. >>> >>> -- >>> Eric Blake ebl...@redhat.com +1-801-349-2682 >>> Libvirt virtualization library http://libvirt.org >>> >>> >>> On 08/15/2011 02:01 PM, Xianqing Yu wrote: >>>> >>>> Hi Libvirt team, >>>> >>>> I am trying to create a new domain from XML file by using libvirt. I >>>> want this new domain using non-persistent disk
