From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Libvirt and Network
Date: Thu, 14 Apr 2016 11:09:20 +0100
Message-ID: <1460628560.2617.100.camel@ipfire.org>
In-Reply-To: <1460484157-648-1-git-send-email-jonatan.schlag@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============6580852540341602996=="
List-Id: <development.lists.ipfire.org>

--===============6580852540341602996==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

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,=C2=A0
> 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 befo=
re
> the libvirt addon could be merged into IPFire.=C2=A0
> 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.
>=20
> I chatted=C2=A0=C2=A0a 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.=C2=A0=
=C2=A0The
> devices can communicate with all computers in the subnet and with other VM's
> on the same network card.=C2=A0=C2=A0The only problem that they can not com=
municate with
> the host. This was a big problem, but after a little bit research, it was e=
asy
> to solve.=C2=A0
> The patch=C2=A0=C2=A0did the necessary changes. As said the macvtap devices=
 can
> communicate with other macvatp devices at the same nic. So=C2=A0=C2=A0I sim=
ple 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=C2=A0=C2=A0macvtap device. The=
 network work
> perfect, I tested this and can not find any problems.=C2=A0
> Now the libvirt can create the macvtap devices, with endpoint greenic0 and =
the
> VMs can communicate with the subnet and the host (with green0).=C2=A0
> 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.
>=20
> One negative aspect the mac address of=C2=A0=C2=A0green0 changes with every=
 reboot (It
> is possible to make the mac address persistent. )
>=20
> I think the solution with the macvtap device is better, but I like to hear
> your opinions.=C2=A0
> I also would like to ship the init script with libvirt but I would not enab=
le
> 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.
>=20
> For more Information about macvtap see:
> https://seravo.fi/2012/virtualized-bridged-networking-with-macvtap
> http://140.120.15.179/Presentation/20150203/
>=20
> I used both sites to understand macvtap devices.
> Now i like to hear your comments :-)
>=20
> Regards Jonatan
>=20
> PS: Some Benchmarks with virtualized 10 Gbit NICs:
>=20
> Real Computer -> IPfire =3D 14,4 Gbits (this value is a little bit confusin=
g)
> Real Computer -> Vm on IPfire =3D 4,7 Gbits
> Vm on IPfire -> Real Computer =3D 2,45 Gbit
> Vm on IPfire -> IPfire=C2=A0=C2=A0=3D 2,56 Gbit Gbits=C2=A0
> IPFire -> Real Computer =3D 16 Gbits (this value is a little bit confusing)
> IPFire -> Vm on IPfire =3D 4,31 Gbit
>=20
> for Home user with normal Gbit Nics this should be more then enough :-)

--===============6580852540341602996==
Content-Type: application/pgp-signature
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="signature.asc"
MIME-Version: 1.0

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjIKCmlRSWNCQUFC
Q2dBR0JRSlhEMnhRQUFvSkVJQjU4UDl2a0FrSGxKUVAvMXFrZis3TjZWdlNaR0dvRUU3Nitvc2QK
RzU1VUlXZWVtN09TMmQ5M3JiK0pVaHZackJ4Z0J0NFovVDhMSExVd0hSZythSUxPSUdFWGpNc2dV
SngvYTZ4UgpDNWVyQk03eVlqODgrRlZMY0dWMzdsZFlXNWZZOFcxajZkeE1UcC9hcVhhMmExcFhs
QlcyVEVOcTAxSFhMa3dMCjEwOTd3c0pOOTVGSTFIVHJXdEJCQnEvdlFmbnpxRkJyYStKZWdTZndV
bGRBTDFCOEZJbDdzeXhWK1pMMm5kZFQKN0NmbGZqcTduYm9nU3VlWlA0Y3R2YVpQQ08rVy9zT3pa
dkp2cUJLMGhoWnpsTStxSUlvdFl3SW44MGRFZHVZdAoyV3IzY253c0NUTzRvTTlOeFdpVHgzYlBh
S2V0TWRWY0NzZVNlWXBUUkdTd25vcEM3SEovaFoxTHhuWndFRGp1ClJPYnBRTTd6aUxWOEFJb0F3
N3VlN3hReHQvbmxiQjFNTHVqNU5ZbGJIbmU5SzczUHdZcittY3hrczF2VVA0NksKQlJkUHljZnc0
ZFlBUS9BL1FXK2d3M0Jqc3hTNGJScXFSRTFZcEkrQ29Ea2JjMWVsVDBlaUpsS095YUtycHBHMQpO
YlV5eHQ3WjlFTngzbXIxeHVENGNmVGIyS2EvMjFVc21jQlptNExRRnVEcEw4T1VCWjltVlM4MWto
TDNRQUtaCnAvSkEvN1B3T01QYTYvQkdRRGFFZ0VyelVxSHJzL1Q4RVFlOVdRV1dsOEMzWVAzaDNs
M0gzZHE4enJ1RTEyaG4KclRuUWhoVGtuUHc3cXJHeWhXLzRueVd5ekVRRzM4MDI4b2dyUXNuV2lR
dVlVQUFldUhMQXVQTkVPbVRQZnFwWgpjc285RGh6OWQ2S1VZS3BWY3U0Mwo9bTB1OAotLS0tLUVO
RCBQR1AgU0lHTkFUVVJFLS0tLS0K

--===============6580852540341602996==--