[virt-tools-list] [RFC] enable direct interface selection
Cole Robinson
crobinso at redhat.com
Tue Apr 5 17:14:34 UTC 2011
On 04/05/2011 10:54 AM, Gerhard Stenzel wrote:
> On Tue, 2011-04-05 at 09:58 -0400, Cole Robinson wrote:
>> I'm having difficulty decoding this. What is the functional difference
>> between these two modes? Can both modes talk to network, host, and
>> host
>> VMs? The bridge caveat that both devices be in bridge mode, if that
>> isn't the case, can packets not be delivered, or are they just
>> delivered
>> sub-optimally?
>
> In vepa mode all packets are sent to the external switch. Normally, a
> switch will not send a packet back to the same port where it came from.
> So, a guest using a direct interface in vepa mode can not talk to
> another guest or the host using the same interface.
> If they need to talk to each other, the switch must support "hair pin"
> mode where the switch sends the packet back to the same port. For
> example, a linux based switch can be configured for "hair pin" mode.
>
> In bridge mode, guests using the same interface will be able to talk
> directly, that is the packets will not be send to the external switch.
> To talk to the host, the host interface will need to be reconfigured in
> the following way:
>
> sudo ip link add link eth0 type macvlan mode bridge
> sudo ifconfig eth0 0.0.0.0
> sudo ifconfig macvlan0 192.168.0.3 netmask 255.255.255.0 up
>
> I hope this clarifies more than it confuses.
>
Thanks, that helps. I would recommend clarifying these drawbacks in the
libvirt documentation.
Unfortunately these are the caveats that scare me from a UI perspective.
We want to prevent users shooting themselves in the foot, as much as
possible. Having an option in the UI like 'Eth0 (direct)' certainly
doesn't sound like an option that prevents VM communication with the
host machine. And the fact that it requires zero extra config on the
part of the user is only going to make it seem like a more tempting
option, when for many people this is definitely not what they will want.
There are a few things we can do to prevent its misuse.
1) Some better name in the UI than 'direct'. Unfortunately I can't think
of one. Maybe just use 'via macvtap' or something: doesn't exactly make
for good UI, but I'd rather have bad UI than misleading UI.
2) Don't offer the 'direct' option in the New VM wizard, only allow the
option in the VM details wizard and addhardware wizard. Should be simple
to just add an extra flag to populate_network_models (also
show_manual_bridge is unused and can be removed). If users want to use
vepa at install time, I have no problem telling them to drop into the
'Customize before install' dialog and tweak it there.
3) When the user selects 'direct' mode, we should show a warning. I
think we only need to unhide a warning icon with a tooltip that briefly
explains this may prevent guest to host network communication without
extra configuration.
Integrating 1 and 2 with your virt-manager patch should be sufficient
for now.
Thanks,
Cole
More information about the virt-tools-list
mailing list