[virt-tools-list] virt-manager only adecuate for IPv4 networks?

Fri Oct 3 11:02:06 UTC 2014

On 2014-10-03 11:09, Daniel P. Berrange wrote:
> On Fri, Oct 03, 2014 at 06:59:56AM -0300, Hugo Osvaldo Barrera wrote:
> > On 2014-10-03 10:39, Daniel P. Berrange wrote:
> > > On Fri, Oct 03, 2014 at 06:28:44AM -0300, Hugo Osvaldo Barrera wrote:
> > > > I've been trying to set up a simple VM with network (Internet) connectivity on
> > > > my laptop.
> > > > 
> > > > I've come across series of issues, after which I'm starting to believe that
> > > > virt-manager is oriented towards IPv4-only networks, since non of it's options
> > > > work with IPv6: NAT has (luckily/finally) obsoleted by IPv6 and bridging does
> > > > not work on wireless networks.
> > > > 
> > > > I've seen some guides here and there were users configured their machines as
> > > > routers, with radvd, manual routing, etc. That's a bit of a pain because:
> > > > 
> > > >  * It requires a not-so-short series of steps which I must redo every time I
> > > >    connect to a different network (since I'll have different IP addresses,
> > > >    different routes, etc).
> > > >  * The whole point of virt-manager is to make this "user friendly", and not so
> > > >    complicated.
> > > > 
> > > > Am I missing something? Are there any plans to address this in future? Is there
> > > > something I can do to work around this?
> > > 
> > > Given the lack of NAT for IPv6 what behaviour would you suggest
> > > virt manager attempt to do for IPv6 ?  If there are suggestions
> > > we're listening, but I've not heard any satisfactory suggestions
> > > for a "just works" setup with IPv6 that's on a par with what we
> > > are able todo with IPv4 NAT.
> > > 
> > > Regards,
> > > Daniel
> > > -- 
> > > |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> > > |: http://libvirt.org              -o-             http://virt-manager.org :|
> > > |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> > > |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
> > 
> > IMO, the real problem is that wireless clients can't have two MACs (and hence,
> > can't bridge). But I don't see that changing in future.
> > 
> > I think what would work aroundn this issue is:
> > 
> >  * Grab a second IP address on the host machine on the same subnet. eg: my
> >  machine gets it's IP via RA. It's quite possible to simply grab a second IP on
> >  the same subnet that RA is advertising.
> >  * Set up something like radvd on the virtual network that's set up for the
> >  guest. Give it that same IP, and forward any DNS that were picked up via RA.
> >  * Forward all traffic to this second IP to the guest machine.
> > 
> > This doesn't seem to conflict with any standard (AFAIK), and should work fine
> > on roaming clients (eg: laptops). I think the only scenario where this may not
> > work is were static IPs are used and there's no RA present.
> 
> So this would require virt-manager or libvirt to be actively monitoring
> for change of IP addresses and then reconfigure radvd with the new address
> info. It also sounds like it would only work with a single guest, or require
> the host to acquire an extra IP address per guest. So this isn't exactly
> straightforward compared to our current NAT setup.
> 

Or it could determine those IP addresses when starting up the VM. I don't think
there's a strong need to constantly monitor it (though it might help keep
networking alive when roaming).

Of course you need an additional IP for every guest, but that's always the case
(unless you have nasty hacks like NAT in IPv4, but luckily we've gotten rid of
that!).

> For a while I've thought it would be nice to have a Proxy-ARP setup for
> IPv4, basically that's IPv4 level bridging instead of ethernet level
> bridging. There does seem to be a similar-ish concept for IPv6 called
> proxy NDP, but from what I can see that still requires manual routing
> table setup for each address.
> 
>   http://www.ipsidixit.net/2010/03/24/239/
> 

I kept saying RA, but RA is just one type of packet defined by NDP, your
suggestion is pretty good.

I guess forwarding NDP traffic to the guest would allow it to have an IP
address, and DNS configuration (via RA), so I like where you're going.

The only thing that would need to be done is have the kernel forward traffic
from wlan0 (or the desired interface) to the VM's virtual interface.

My initial proposal was not as clean as this is: you don't need 1mac per IP
(which is what I had in mind to being with), and having libvirt/virt-manager
work as a proper router (instead of a bridge, as I was thinking) is a pretty
good idea.

Of course, I think the most important detail regarding this on virt-manager, is
if the network configuration can be handled behind the curtains (eg: without
forcing the user to deal with iptables and such).

> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Cheers,

-- 
Hugo Osvaldo Barrera
A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/virt-tools-list/attachments/20141003/298926e2/attachment.sig>