cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: Generate single rpm quickly (cloudstack-agent)
Date Sat, 06 Jul 2013 02:37:45 GMT
I don't have a current patch or anything, and I'm not near a PC, but look
in LibvirtComputingResource.java and elsewhere for references to lsmod or
KVM and comment any out. Then go into LibvirtVMDef.java and look at the
strings that build the XML. You will want to start some VMS on your host
manually for reference on what works, then look at that XML and make the
adjustments in that file. Immediately what comes to mind is changing
"domain type=kvm" to "domain type=qemu" and there is an os type somewhere
from hvm to whatever your host supports (type 'virsh capabilities' I think).
On Jul 5, 2013 4:32 PM, "Abhishek Lahiri" <lahirister@gmail.com> wrote:

>
>
> I agree it makes sense to have nested virtualization enabled on the host,
> but can you please share the exact changes that you made to allow qemu ,
> just for testing?
>
> On Jul 5, 2013, at 2:48 PM, Marcus Sorensen <shadowsor@gmail.com> wrote:
>
> > On a side note, I've made the modifications required once to run qemu
> > without the kvm modules, as a test. You have do do several things, not
> > just disable the checks (that are there for a reason, to ensure that
> > everything will work). You'd have to disable several checks, and then
> > edit the XML definitions that cloudstack creates when defining virtual
> > machines. After all that, you end up with unbearably slow vms inside a
> > vm. Unless you don't have access to the hypervisor host (in which case
> > this is the only option), it's far better to just enable nested
> > virtualization on the host and use the kvm modules like you would with
> > a real hardware host.
> >
> > On Fri, Jul 5, 2013 at 3:38 PM, Marcus Sorensen <shadowsor@gmail.com>
> wrote:
> >> You only need to run package.sh when you've tested everything and made
> >> sure it's ready. Then you package the final product. For testing, you
> >> can just edit utilities.py in its installed location on the server.
> >>
> >> You can run the agent in a VM if you're using vmware-fusion or KVM,
> >> you just have to enable the support for vmx on the hypervisor so you
> >> can modprobe the kvm modules, and then set the 'nested' flag on the
> >> module configs. If you don't, I believe the agent will fail to start
> >> anyway, as it does 'lsmod| grep kvm' on startup.
> >>
> >> See devcloud-kvm as an example of running the agent in a vm:
> >> https://cwiki.apache.org/confluence/display/CLOUDSTACK/devcloud-kvm
> >>
> >> On Fri, Jul 5, 2013 at 11:42 AM, Abhishek Lahiri <lahirister@gmail.com>
> wrote:
> >>> Hi,
> >>>
> >>> I am attempting to make a simple change in the
> >>>
> cloudstack/dist/rpmbuild/SOURCES/cloudstack-4.2.0-SNAPSHOT/python/lib/cloudutils/utilities.py
> >>> script , so that the cloudstack-setup-agent script does not throw an
> error
> >>> and exit if it cannot fine /dev/kvm (usage scenario - running
> cloudstack
> >>> inside a running vm). Anyway the change is trivial , but after I make
> the
> >>> change I have to run cloudstack/packaging/centos63/package.sh which
> takes a
> >>> very long time to complete and generate the rpms under
> >>> cloudstack/dist/rpmbuild/RPMS/x86_64. Is there any way I can speed up
> this
> >>> process? I just need to generate the
> >>> cloudstack-agent-4.2.0-SNAPSHOT.el6.x86_64.rpm package everytime I make
> >>> some change to the utilities.py script.  This will save me a lot of
> time.
> >>>
> >>> Thanks
> >>> AL
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message