Re: Libvirt and Network

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 4249 bytes --]

Hi,

apologies for the delay.

I am not entirely sure about this. You are saying this works which is good :)
But I do not see any advantage/disadvantage over the bridge approach (except not
requiring dnsmasq).

I would have loved to see it solved like this:

* An extra zone for the virtual machines (e.g. vm0)
* All machines go into that (and only into that)
* It gets an own subnet
* Access to all the other zones can be configured with the usual firewall GUI

I am not sure if the last bullet point is possible with the macvtap approach.

The MAC address on green must be persistent.

Can you maybe elaborate more about all this? What should convince me to like
this approach more than the other one?

And of course this must be solved cleaner than this is right now...

Best,
-Michael

On Tue, 2016-04-12 at 20:02 +0200, Jonatan Schlag wrote:
> Hi, 
> first, this patch is only a base for discussion . It should not merged!
> The Libvirt networking is the last big problem, which we have to solve before
> the libvirt addon could be merged into IPFire. 
> My first solution was to create a virtual network (libvirt do this fine) but
> there are several problems.
> 1. Libvirt needs a patches version of dnmasq, this could cause trouble
> 2. Libvirt insert IPTables rules, which could also cause trouble
> 3. We have an extra subnet which is difficult to filter with normal firewall
> rules.
> 
> I chatted  a little bit with Michael Tremer and Marcel Lorenz and both give me
> maybe not aware the right direction and ideas and so I found an another
> solution which is 100 times more elegant than the extra subnets.
> This solution is based on macvtap devices. Libvirt is able to create these
> devices and this works fine. The endpoint is a real network card and the
> macvtap get a normal IP from the subnet in which the network card is.  The
> devices can communicate with all computers in the subnet and with other VM's
> on the same network card.  The only problem that they can not communicate with
> the host. This was a big problem, but after a little bit research, it was easy
> to solve. 
> The patch  did the necessary changes. As said the macvtap devices can
> communicate with other macvatp devices at the same nic. So  I simple created a
> macvtap devices in bridge mode and named it green0, the real network card is
> renamed to greenic0. The script is called before the network startup so IP
> addresses and routes are added to the green0  macvtap device. The network work
> perfect, I tested this and can not find any problems. 
> Now the libvirt can create the macvtap devices, with endpoint greenic0 and the
> VMs can communicate with the subnet and the host (with green0). 
> So what are the benefits?
> 1. Libvirt doesn't need a patched version of dnmasq.
> 2. No firewalls rules are inserted.
> 3. The machines are in the same subnet of the nic, they could be treated as
> normal real computers which are attached to a switch.
> 
> One negative aspect the mac address of  green0 changes with every reboot (It
> is possible to make the mac address persistent. )
> 
> I think the solution with the macvtap device is better, but I like to hear
> your opinions. 
> I also would like to ship the init script with libvirt but I would not enable
> it by default. The user should be able to decide which network card (the
> orange one is also possible) he wants to use for libvirt.
> 
> For more Information about macvtap see:
> https://seravo.fi/2012/virtualized-bridged-networking-with-macvtap
> http://140.120.15.179/Presentation/20150203/
> 
> I used both sites to understand macvtap devices.
> Now i like to hear your comments :-)
> 
> Regards Jonatan
> 
> PS: Some Benchmarks with virtualized 10 Gbit NICs:
> 
> Real Computer -> IPfire = 14,4 Gbits (this value is a little bit confusing)
> Real Computer -> Vm on IPfire = 4,7 Gbits
> Vm on IPfire -> Real Computer = 2,45 Gbit
> Vm on IPfire -> IPfire  = 2,56 Gbit Gbits 
> IPFire -> Real Computer = 16 Gbits (this value is a little bit confusing)
> IPFire -> Vm on IPfire = 4,31 Gbit
> 
> for Home user with normal Gbit Nics this should be more then enough :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]