On 03/05/2015 08:10 AM, ilya musayev wrote:
++ [email protected] - 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
vdsm (ovirt host agent) will not return from libvirt VMs it did not
start. it will be missing vdsm level metadata for such vm's, etc.
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.
ovirt would be missing important factors of the VM like reserved ram
definition and HA reservation policy which would impair its capabilities.
though that's not relevant due to point above which is vdsm does not
return VMs to engine not started by vdsm.
(and vdsm would be probably missing data for such a VM to add such support).
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.
ovirt/vdsm are not intended to work with "any host out there", rather
mostly for a cluster of hosts managed by ovirt engine.
so not possible/simple.
(unless cloudstack impersonates libvirt, which again, probably the
wrong abstraction level to be feasible).
CloudStack has an agent that talks to libvirt.
yes, but that's consuming it, not faking it.
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.
ovirt should have an issue with such scales as well, but the approach
you want is not the "intuitive" one for cloudstack/ovirt.
i suggest either pursuing adding a cloudstack ovirt driver, or using
ovirt cleanly.
note ovirt is also augmented by ManageIQ (upstream of Red Hat's
CloufForms) for additional features
HTH,
Itamar
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
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________
Devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/devel
