Re: [ovirt-devel] Intro

On 03/05/2015 08:10 AM, ilya musayev wrote: > ++ devel(a)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 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 >>>>>>>> Devel(a)ovirt.org >>>>>>>> http://lists.ovirt.org/mailman/listinfo/devel >>>>>>> >>>>>> >>>>> >>>> >>> >> >