On Mon, May 12, 2014 at 06:14:40PM +0200, John Smith wrote:
On Mon, May 12, 2014 at 5:39 PM, Dan Kenigsberg <danken@redhat.com> wrote:
A big limitation of the macvtap approach is that it would let you connect only a single VM to your WiFi. Is that fine by you?
I wasnt aware of that limitation. No, a single VM limitation would not be sufficient. I was assuming you could simply do something like this :
ip link add link wlp2s0 name macvtap0 type macvtap ip link add link wlp2s0 name macvtap1 type macvtap ip link add link wlp2s0 name macvtap2 type macvtap
And then assign individual 'interfaces' macvtap0, macvtap1 and macvtap2 to different VM's. Apparently it doesnt work that way.
Maybe it does - please try or wait for someone in the know (such as mst) to explain. 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.
Yes, defining a libvirt network requires using
virsh net-define <xmlfile>
(you may need to pass the not-so-secret vdsm@ovirt/shibboleth password to tinker with libvirt, which is better done on non-production setup)
virsh net-dumpxml <net-name>
could show you what's already defined, but I don't expect you to have interesting networks as of yet.
Thanks, ill start fooling around with virsh net-define and virsh net-dumpxml then.
It may not be easy, but I'd be grateful if you report here on what you will have accomplished.
No problem. Although after having read your last message, I think I may be better off using (and start with looking at) your NAT-based network / vdsm-hook-extnet approach.
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. Dan.