[ovirt-devel] Intro

[ilya musayev]

Itamar,

Thanks for the explanation.

Regards
ilya
On 3/5/15 2:22 PM, Itamar Heim wrote:
> On 03/05/2015 08:10 AM, ilya musayev wrote:
>> ++ devel at 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 at ovirt.org
>>>>>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>