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@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.