[ovirt-users] newbee questions

[Dan Kenigsberg]

On Mon, May 12, 2014 at 09:40:20PM +0200, John Smith wrote:
> On Mon, May 12, 2014 at 7:44 PM, Dan Kenigsberg <danken at redhat.com> wrote:
> >
> > or wait for someone in the know (such as mst) to explain.
> >
> Guess ill do that, then.
> 
> 
> >
> > The thing is that afaik
> > http://libvirt.org/formatnetwork.html#examplesDirect creates the macvtap
> > devices for you, and it creates one device per one virtual function.
> >
> Hrm. here the docs talk about 'interface pools', where presumably, you
> can map (combine/bond) multiple physical interfaces to a single
> virtual interface, instead of the other way around: mapping a single
> physical interface to multiple virtual interfaces.
> 
> 
> >
> > NB: Even if it is possible to define a libvirt network with several
> > pre-created macvtaps, you'd need something like vdsm-hook-extnet to
> > convince oVirt to use your network instead of a bridge.
> >
> ... because ovirt is hardwired to work with linux network bridges only
> ? maybe i should just stop fooling around with ovirt altogether, and
> just start work on custom tooling to work with kvm and macvtap
> directly: all of the restrictions appear to be in the ovirt management
> layer and not in the underlying virtualization technologies like kvm
> or macvtap ?

It is unavoidable that any management level in a software stack adds
abstractions and requirements.

If you are planning to run only a couple of VMs on a single laptop,
going to basics and using qemu/libvirt directly, or gnome-boxes, would
make sense.

If you plan to manage a multitude of hosts, then the benefits of oVirt
comes to play.

To your specific point, I am aware of two restrictions. One, of Linux
not supporting bridging wifi. The other is oVirt's reliance on bridges
for VM connectivity. The second restriction is avoidable, but requires
some tinkering. If you decide to try it out, I'd love if you report your
success or challenges on this list.

Dan.