On 09/15/2014 06:17 PM, Daniel Helgenberger wrote:
On 15.09.2014 15:23, Itamar Heim wrote:
> On 09/15/2014 04:10 PM, Daniel Helgenberger wrote:
>> Hello Livnat,
>> On 15.09.2014 14:46, Livnat Peer wrote:
>>> On 09/15/2014 03:15 PM, Daniel Helgenberger wrote:
>>>> +1 for the iso uploader,
>>>> +1 for hostusb in UI
>>>> +1 EL 7 (on the roadmap anyway?)
>>>> With hostusb some more host-dev virtualization could be added. Top of my
>>>> list is:
>>>> - SR-IOV
>>>> - NPV
>>>> - VFIO
>>>> These things could be handled on cluster level - hypervisors need to
>>>> have the same hardware configuration anyway.
>>>> Also, I think its time to add official support for OpenVswitch?
>>> Are you looking for a specific functionality that is available via
>>> OpenVswitch (=OVS)?
>>> also we have the Neutron integration where we use OVS.
>> I think its sufficient to say OVS is a 'real' modern switch while plain
>> ol' linux bridge is not (so much any more). Of curse, maybe implementing
>> other things like macvtap and / or SR-IOV achieves just the same thing
>> (at least for me, as I then mange vlans/trunks and QoS, Spanning Tree
>> ect. on my switches).
>> I know you can point on OpenStack integration because you get those
>> features for 'free' (see Ceph). But what about users like me who do not
>> wish / can / should implement the whole OpenStack but rather want to run
>> 'plain' oVirt?
> that's why we added in 3.5 a standalone, pre-configured, neutron virtual
> appliance so you won't need "all of openstack"?
Witch is certainly nice to have. But this is not the point. IMHO storage
and networking are core functions for a virtualization platform. And
such a platform will need to reflect the the progress made in general
and in particular by the hypervisor monitor (libvirt).
I am no developer and can hardly estimate the coding effort and do not
want you to redo already working things. But at least in case of Ceph
there is the API from libvirt, this is true for all the other things I
mentioned, in my naive view they are all variations of the hostusb hook.
Certainly I can deploy OVS myself and manage it from CLI, witch is what
I do now.
But in the end, I would very much like to do this via one integrated
GUI, this is why I deploy oVirt (witch I see as a open source
counterpart to EXi. Esp. the concept of one engine for management - but
not critical for running my VMs.)
Please allow me a 'heretic' question, will oVirt make itself obsoleted
in the future because all of the core functionality is moved to an
external provider? Is it better for my use case (small/medium business
and not in the telco sector) to deploy OpenStack in the first place and
not to use oVirt at all? ATM OpenStack seems to me like the literal
sledgehammer to crack a nut.
well, we are trying things out, seeing what works, what makes sense,
what does not, etc.
yes, ceph is supported by libvirt. the cinder-ceph approach will use
that libvirt functionality. but the "meta data" actions (create disk,
etc.) will be done via engine-cinder-ceph, rather than engine-vdsm-ceph.
for both cinder and neutron, the nice thing about them is a very large
ecosystem of 3rd party implementations which are easy to leverage due to
no, it doesn't mean all features will be done only through neutron or
cinder, but some functionality make more sense there than doing
everything natively. just like doing bare metal provisioning and some
guest provisioning makes more sense through an external provider (we
pushed a foreman integration, someone can contribute another flavor).
Same for advanced scheduling - we added integration via optaplanner for
>> I think this might not be a desirable way to add / modernize features as
>> it creates a huge overhead (at least in my use case, medium business. I
>> did this once for Glance 'just' to get a way to more easily handle
>> import / export of image files, now I need to implement Neutron 'just'
>> to get OVS?).
>> Don't get me wrong - OpenStack integration is a wonderful thing witch
>> leaves room for expansion - later on.
>>>> On 12.09.2014 14:23, Itamar Heim wrote:
>>>>> With oVirt 3.5 nearing GA, time to ask for "what do you want to
>>>>> oVirt 3.6"?
>>>>> Users mailing list