++ devel@ovirt.org - as i realized it got dropped by mistake.. Itamar, Please see response in-line,
On 3/2/15 2:10 PM, Itamar Heim wrote:
On 03/02/2015 11:22 PM, ilya musayev wrote:
Itamar,
Please see response in-line,
On 3/2/15 10:34 AM, Itamar Heim wrote:
On 03/02/2015 07:59 PM, ilya musayev wrote:
Hi Itamar,
Sorry for delayed response.
We are using Apache CloudStack as a platform that can manage KVM, Xen, VMware and Baremetal hosts/hypervisors.
We would like to tie in oVirt with our KVM infrastructure but we dont want both CloudStack and oVirt to step on each other toes.
We are thinking if there is a way to proxy specific commands from oVirt to CloudStack and not KVM host directly.
wouldn't the "normal" architecture of CloudStack be to have an ovirt driver/plugin, so you'd use cloudstack and it will ask ovirt rest api to launch the VMs on the actual hosts? It would have been "intuitive", but this is a chicken and the egg situation. CloudStack has been deployed long ago, while oVirt is fairly new - in our world.
On a basic level, CloudStack can manage KVM just like oVirt does, however, oVirt is more feature rich, both have their own advantages and disadvantages. Combining both with least amount of complexity and inter-dependency would be the proper solution for us.
1) Specific feature we need oVirt for is historical analysis of VMs stats for resource consumption - i believe oVirt has a separate interface for that.
yes, the data warehouse (and potentially, the reporting server)
2) We need a way to manage load balancing of VMs across the cluster/host and we are thinking this is where we need to integrate oVirt. I guess i'm only considering a fraction of what oVirt has to offer, but for now - this is all we need.
What you are proposing is what Vmware vCenter does right now, it has its own pluses and minuses, we are leaning toward not having another vCenter - as it proves to be rather painful to add and manage yet another dependency stack. We would prefer a parallel independent add-on (oVirt talks to cloudstack to perform specific tasks, but if there are any issues, we can just stop oVirt from communicating) VS in-line dependency (if there are any oVirt issues, we are down, until the issue is resolved).
well, its an different/interesting approach which wouldn't be common probably, but it may work. but ovirt needs to talk to vdsm (host agent), which talks to libvirt.
so theoretical integration points are: 1. ovirt-->cloudstack-->libvirt ? On the high level, without having greater knowledge of oVirt, yes.
Reading data: ovirt --> ovirt-agent Execution: ovirt-->cloudstack-management-->cloudstack-agent-on-kvm (uses libvirt) Only execution needs to be proxied over to cloudstack
this would require implementing most/all of vdsm verbs over cloudstack. I doubt the abstraction level is the same between them.
2. ovirt-->vdsm-->cloudstack-->libvirt
this is possible, as vdsm supports custom hooks, but monitoring would still be direct to libvirt, and the custom hooks don't cover all features anyway.
in oVirt, would it be feasable to run vm load balancing - in passive state. Proposed scenario would be, oVirt identified the VM A needs to move to KVM Host X, this recomendation message is posted to a location (be it message queue we can subscribe to, file, db or some external call), another service listens for oVirt suggestions and executes migration via cloudstack. This seems rather simple and we would not need to rewrite much assuming oVirt can only run in passive state and not actually act upon a task. We would need to lock the ability so it does not mistakenly move the VM around.
(unless cloudstack impersonates libvirt, which again, probably the wrong abstraction level to be feasible).
CloudStack has an agent that talks to libvirt.
so both paths are far from trivial.
may i ask for the size of the deployment you're considering this effort for (number of hosts/vms)?
Depending on the type of environment, lowest would be 100 or so hypervisors and 2000 or so VMs, it goes higher in numbers from then on with many different environments. Cloudstack can handle that without issues.
Thanks, ilya
Feedback is welcome,
Thanks ilya
your path seems less intuitive - which features in ovirt are you trying to leverage?
Any thoughts or pointers on this would be greatly appreciated,
Thanks ilya
On 2/24/15 12:20 PM, Itamar Heim wrote:
On 02/12/2015 06:38 PM, ilya musayev wrote: > Hi oVirt Devel Team, > > Thought i would introduce myself being newbie here, my name is ilya > and > i work for one if the larger IT companies in Bay Area. > > I'm interested in learning more about what oVirt does, > especially from > developers points of view as we may have some integration > initiatives.
we're always happy to help with these - anything more specific on the type of integration you are interested in?
> > I'm also actively involved in Apache CloudStack project as PMC and > Committer. > > Thanks > ilya > _______________________________________________ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel