Re: reaching the guest from the host through network

[Laine Stump <laine redhat com>]

On 02/08/2013 01:26 PM, Lucas Meneghel Rodrigues wrote:
> On 02/08/2013 03:43 PM, Zeeshan Ali (Khattak) wrote:
>> On Fri, Feb 8, 2013 at 7:29 PM, Lucas Meneghel Rodrigues
>> <lmr redhat com> wrote:
>>> On 02/08/2013 12:36 PM, Emmanuel Touzery wrote:
>>>>
>>>> looking at this:
>>>> https://bugzilla.gnome.org/show_bug.cgi?id=677688
>>>>
>>>> it seems that at least for now my best bet would be using virt-manager
>>>> which is more powerful than gnome-boxes. I'll try that now.
>>>
>>>
>>> Bridging requires root access, something that boxes can't provide
>>> you right
>>> now, since it can only access the unprivileged qemu session.

Well, to be exact, qemu is *always* unprivileged. It's libvirt that must
be running privileged in order to do full network setup.

Recent libvirt has an addition that causes an unprivileged libvirt given
an <interface type='bridge'> configuration to tell the (also
unprivileged) qemu it creates to use the new qemu "suid network helper"
to create a tap device and connect it to an existing bridge. This is
about 1/10th of the capabilities possible from a privileged libvirt, but
it may be sufficient in some cases (in particular, if a bridge has
already been setup on the host).


>>> Since
>>> virt-manager can access the privileged qemu session, it also has
>>> access to
>>> the libvirt bridge, and it will all work fine.

With qemu's suid network helper, boxes could also have access to "the
bridge created by libvirt". This isn't exactly the same as
"libvirt-created virtual networks" (it's really just a happy coincidence
that "virbr0" usually happens to be libvirt's "default" network), and in
particular, since that bridge is behind NAT rules, you will only get
incoming connections from the host itself, not from anywhere beyond, and
you won't be able to use libvirt's "hook" functions to setup port
forwarding rules for incoming connections from beyond the host (without
becoming root, that is).

>>>
>>> Note that using wifi and having a working bridge is perfectly
>>> possible, a
>>> wifi interface is very much like an ethernet interface for bridging
>>> purposes.
>>
>> Thats what I thought too but seems libvirt guys do not agree:
>
> I guess then I'm lucky, since I own 2 thinkpads where this works
> perfectly well then :)

I'm guessing that you don't have your wifi directly attached to the
bridge, but are relying on some combination of IP routing and proxy arp?
(Or possibly your wifi card and AP both allow multiple MAC addresses on
the same connection).

Unfortunately, something as hit and miss as this can't be put into
libvirt. If someone comes up with a relatively non-intrusive 100%
reliable on all platforms way to give guests "L2 bridged" access to the
physical network, I would seriously love to make a new libvirt network
type that supports it.

>
>> <zeenix>
>> http://wiki.libvirt.org/page/Networking#Bridged_networking_.28aka_.22shared_physical_device.22.29
>> <zeenix> " Unfortunately, wireless interfaces cannot be attached to a
>> Linux host bridge"
>> <zeenix> is that really true?
>> <zeenix> i clearly remember doing that with success
>> <zeenix> that doc seem a bit outdated. Talks of disabling network
>> manager for fedora 12
>> <danpb> that is still accurate - you can't use bridges with wifi in
>> general, because most wifi cards will refuse to send packets with
>> different MAC addrs
>> <danpb> and of course traffic from VMs will have different mac addrs