[ovirt-devel] Intro

[ilya musayev]

++ 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
>
>>
>> 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 at ovirt.org
>>>>>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>>>>
>>>>>
>>>>
>>>
>>
>