tinc - Mar 2016 - AW: issue with tinc and libvirt / Network is already in use by interface tun0

>> I have tinc up and running on a kvm/libvirt host. libvirt creates a 
>> bridge and assigns ip to this bridge, for instance 192.168.1.1. All 
>> guests have an ip within 192.168.1.0/24. I want to access the guests 
>> in this libvirt network with tinc from the internet via the host.
>[...]
>> and tinc.conf like this
>[...]
>> Interface = tun0
>> 
>> Every thing works fine until I reboot the host.
>> 
>> Then I get the following error from libvirt "Network is already in
>> use by interface tun0" and libvirt does not start the network.
> If libvirt wants to use "tun0" as an interface, then just have
tinc
> use a different name for its interface. Change "Interface = tun0"
to
> something else, or you can leave it out entirely, in
 > which case tinc names its interface the same as the netname you specify
with the -n option.

Nice hint, but it's not this simple. Libvirt complains about the network not
the interface. The interfaces have different names already.
It seems like tinc bind the subnet on startup and libvirt doesn't like it

Regards
Dieter

On Fri, Mar 04, 2016 at 07:46:24PM +0100, shad0wrunner at gmx.de wrote:
> >> I have tinc up and running on a kvm/libvirt host. libvirt creates
a
> >> bridge and assigns ip to this bridge, for instance 192.168.1.1.
All
> >> guests have an ip within 192.168.1.0/24. I want to access the
guests
> >> in this libvirt network with tinc from the internet via the host.
[...]
> > If libvirt wants to use "tun0" as an interface, then just
have tinc
> > use a different name for its interface. Change "Interface =
tun0" to
> > something else [...]
> 
> Nice hint, but it's not this simple. Libvirt complains about the
network not
> the interface. The interfaces have different names already.
> It seems like tinc bind the subnet on startup and libvirt doesn't like
it
Well, if it's about the subnet, then it's up to you to change the
Subnets in the host config files (and change the tinc-up script
accordingly if necessary), or somehow convince libvirt to use a
different range of IP addresses for its bridge interface.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20160304/bebae50b/attachment.sig>

>> 
>> Nice hint, but it's not this simple. Libvirt complains about the 
>> network not the interface. The interfaces have different names already.
>> It seems like tinc bind the subnet on startup and libvirt doesn't 
>> like it
> Well, if it's about the subnet, then it's up to you to change the 
> Subnets in the host config files (and change the tinc-up script
accordingly if necessary), or somehow convince libvirt to use a different
range of IP addresses for its bridge interface.

Sorry, I don't get it. I thought the Subnet parameter is indented for
routing local nets to the remote host.
This way a remote host can access the provided  local nets.

What I have is my host A with vms (ips within 192.168.1.0/24).
My host A has a bridge to the  vm's network. The bridge has the IP
192.168.1.1. Furthor more my host A has a tinc device tun0 with the IP
192.168.2.10.

 My host A has A static internet IP.

I want to connect Host B to Host A via tinc. Host B should be able to access
all VM's within the network  192.168.1.0/24. To get this to work I have to
create on both hosts a hostfile with the name A.conf containing the entries:

Address = XXX.XXX.XXX.XXX
Subnet = 192.168.1.0/24
Subnet = 192.168.2.10/32

right? Or am I wrong?

When I use this entries it works. But only as long as I start libvirt before
tinc.
When I start tinc before libvirt  then I get this error message " Network
is
already in use by interface tuno"

When I remove the entry

Subnet = 192.168.1.0/24

I can't reach the vm's from host B even when I set a route by hand.
It seems like tinc passes only packets on for networks which are listed as
provided networks.