VM can't access CIF shares on host

[aglyons]

I had the issue of duplicate IP's on my network and happened across another post that seemed to sort things out. But it introduced a new issue that I haven't been able to figure out.

 

I figured out my error after re-reading the post @murkus wrote. I had the custom network for the eth0 still enabled in the docker config.

 

That solved the duplicate IP, different MAC issue!

 

BUT! I seem to have now run into another problem. HAOS VM is using the vhost0 network and it is accessible on the network. But there was an error in HAOS about a failed mounted network storage volume that is located on the host system.

 

[853.7504591] CIFS: VFS: Error connecting to socket. Aborting operation.
[853.7518201] CIFS: VFS: cifs mount failed w/return code = -115

 

After pulling my hair out I determined that while everyone on the network can access the HAOS website, and HAOS can ping and mount shares on other systems, HAOS can't ping or mount anything on the host system and the host system can't ping the VM.

 

HOST (UnRaid): 192.168.200.88

HAOS VM: 192.168.200.87

 

Can't ping VM from HOST

root@KNOXX:~# ping 192.168.200.87
PING 192.168.200.87 (192.168.200.87) 56(84) bytes of data.
From 192.168.200.88 icmp_seq=1 Destination Host Unreachable
From 192.168.200.88 icmp_seq=2 Destination Host Unreachable
From 192.168.200.88 icmp_seq=3 Destination Host Unreachable
From 192.168.200.88 icmp_seq=4 Destination Host Unreachable
From 192.168.200.88 icmp_seq=5 Destination Host Unreachable
From 192.168.200.88 icmp_seq=6 Destination Host Unreachable
From 192.168.200.88 icmp_seq=7 Destination Host Unreachable
^C
--- 192.168.200.87 ping statistics ---
8 packets transmitted, 0 received, +7 errors, 100% packet loss, time 7195ms
pipe 4
root@KNOXX:~# 

 

Can't ping HOST from VM

 

Host UnRaid routing table

root@KNOXX:~# ip route
default via 192.168.200.1 dev eth0 metric 1 
default via 192.168.202.1 dev eth0.2 metric 2 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown 
192.168.200.0/24 dev eth0 proto kernel scope link src 192.168.200.88 metric 1 
192.168.200.0/24 dev br1 proto kernel scope link src 192.168.200.253 metric 1 linkdown 
192.168.202.0/24 dev vhost0.2 proto kernel scope link src 192.168.202.2 
192.168.202.0/24 dev eth0.2 proto kernel scope link src 192.168.202.2 metric 1 
root@KNOXX:~# 

 

HAOS VM routing table

# ip route
default via 192.168.200.1 dev enp1s0 proto static metric 100
172.30.32.O/23 dev hassio proto kernel scope link src 172.30.32.1
172.30.232.0/23 dev docker0 proto kernel scope link src 172.30.232.1
192.168.2OO.0/24 dev enp1s0 proto kernel scope link src 192.168.2OO.87 metric 100

 

 

Any thoughts??

[aglyons]

BUMP

 

This has to be an issue with UR as I can map SMB drives in HAOS on other systems on the network. It's just connecting to the host IP address or hostname that does not work.

 

Also, the duplicate HOST IP is on the network again with a different MAC. I suspect that this is the main culprit. I believe the HAOS VM, because it goes through the MACVTAP, it believes that eth0.2 'IS' the system I am trying to connect to. Since there are no shares there (it's a bridge after all) it fails.

 

I've cleaned up a bunch of things that were not being used, mainly extra NICs that were in the system that I chose not to use. There is only one physical NIC in the system now and it has no bridging or bonding set. I do have a VLAN configured on it and that is being used for most of my Docker containers.

 

 

 

 

 

Docker config

 

 

Now from what I gather, because I have a VLAN set, the system is creating a VHOST for it, eth0.2 as well as etho. It is the MAC for eth0.2 that is causing the duplicated HOST IP on the network

 

root@KNOXX:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/ipip 0.0.0.0 brd 0.0.0.0
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 3c:8c:f8:ee:59:84 brd ff:ff:ff:ff:ff:ff
    inet 192.168.200.88/24 metric 1 scope global eth0
       valid_lft forever preferred_lft forever
5: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 3c:8c:f8:ee:59:84 brd ff:ff:ff:ff:ff:ff
    inet 192.168.202.2/24 metric 1 scope global eth0.2
       valid_lft forever preferred_lft forever
6: vhost0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 500
    link/ether 02:65:43:f8:ad:c4 brd ff:ff:ff:ff:ff:ff
7: [email protected]: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 500
    link/ether 02:65:43:f8:ad:c4 brd ff:ff:ff:ff:ff:ff
    inet 192.168.202.2/24 scope global vhost0.2
       valid_lft forever preferred_lft forever
8: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default 
    link/ether 02:42:b4:d2:d6:aa brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
10: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:ca:33:2d brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever
11: macvtap0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 500
    link/ether 52:54:00:94:77:76 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::5054:ff:fe94:7776/64 scope link 
       valid_lft forever preferred_lft forever
root@KNOXX:~# 

 

But I am lost as to why the MAC address for both eth0.2@eth0 and [email protected], which is reported in UR as having the IP 192.168.202.2, shows up on the network as having the IP 192.168.200.88 ?!?!?

 

 

 

Also, I am curious as to why the MACVTAP is IPV6 only? I have IPV6 disabled in UR and across my network. It's also disabled in HAOS. Does this matter in this instance or is that strictly for internal purposes and one of the reasons the MACVTAP approach works as it does?

 

[murkus]

I believe I wrote something about that in my thread. You have 2 parameters that can have 4 value combinations, while the combination where both are enabled leads to create vhost0@eth...

to avoid vhost0@eth0 to use the same IP as eth0 (will be alarmed by arpwatch, pfSense, TrueNAS, etc.): do no NOT enable BOTH of IPv4 custom network on interface eth0 (optional) (default is ON) and Host access to custom networks (default is OFF)

 

Have you tried to enable one and disable the other?

From what I am reading I believe you use HAOS in a VM, not in a container on unraid. The two above parameters should not have an impact on VMs, only on Docker containers, but I am no expert.

The VM Manager settings use different mechanisms (br0 or virbr0) to ensure communication between host and guest VMs (maybe you check out the "Default network source:" in the VM Manager settings, this is the help text copied from the UI:

Select the name of the network you wish to use as default for your VMs. You can choose between 'bridges' created under network settings or 'libvirt' created with virsh command in the terminal. The bridge 'virbr0' and the associated virtual network 'default' are created by libvirt.
Both utilizes NAT (network address translation) and act as a DHCP server to hand out IP addresses to virtual machines directly. More optional selections are present for bridges under network settings or for libvirt networks with the virsh command in the terminal.

If your are unsure, choose 'virbr0' as the recommended Unraid default.

NOTE: You can also specify a network source on a per-VM basis.

IMPORTANT: Neither Libvirt nor Unraid automatically brings up an interface that is assigned to a Libvirt network. Before you use a Libvirt network, please go to Settings -> Network Settings and, if necessary, manually set the associated interface to up.)