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 <aaron_pee...@ncsu.edu> 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 <yu267155...@hotmail.com> 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 <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.








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