I checked the instructions, I confirmed it was set to vhost0 and had a mac adress (the upgrade did all that I guess).

I host an nfs share on this that UD connects too - hence I notice is same offline.

Ping say not reachable.

Re network settings, no bonding, no bridging - as per the instruction to keep using macvlan on this version (I have unifi USG and want to keep all that management working).

 

 

 

Im still struggling with this.

It was all fine before the upgrade to 6.12.4.

unrad server cant ping 192.168.1.185 (shinobi vm) and the shinobi VM cant ping the unraid server (on 192.168.1.7).

Every other device can ping shinobi, just not the unraid server.

There is no active FW on this VM - nothing has changed except the unraid OS, with changes to the networking as such as per notes :  

  a - Settings > Network Settings > eth0 > Enable Bridging = No
  b - Settings > Docker > Host access to custom networks = Enabled (was on already)
  c - Settings > Docker > custom network on interface eth0 (i.e. make sure eth0 is configured for the custom network, not eth1)

As I use a UD nfs connection and a user script every 5 mons to rsync off the latest cctv files, this is a few days behind now. 

stragely, my other VM - the home assistant VM can be pinged from unraid console.

Further to this, I noticed in home assistant, the APC UPS power usage is not there.  Logs saif timeout error.  I checked the history and this also started when I update unraid to 6.12.4.  Something in the network config has broken VM's talking to the unraid host.

 

I am not going to roll back just for this, but I would like some help if anyone knows aht in the network config caused this.

 

The changes for the macvlan etc were noted in my first post above.

 

These devices are all on the same lan so not a FW issue.

 

Is it something to do with the required changes in the intructions to set enable bridging to no ?

 

 

 

 

 

  

Spent too much time on these issues and no one has anything to help on this issue.

I will just buy another wifi power monitor plug and connected the UPS into that. $15 bucks to sort this.

For the VM running Shinobi CCTV - I will just increase its disk size and increase the stored videos to match what was being pulled to the unraid share. 

As with many things, when something breaks you learn a newer, better way of doing things.  

I have now added a virtio share in the VM xml, and that is mounted at start on the VM, and I have rsync command running in cron on the VM.

So instead of unraid using an nfs to 'pull' the data, I now have it 'pushed' from the VM instead.

A better way of doing this I think.

A new power monitor is coming to solve the UPS comms to home assistant. 

Edited October 20, 20232 yr by vw-kombi

I have the exact same issue.

Translation from the German subforum 

 

Quote

A Windows VM with the standard Virtio network model and vhost0 as network is running.

Everything in the same subnet on a Fritzbox. No VLAN, no separate network segments or other fun stuff, actually a pretty simple config.

 

All my computers can access the shares and the server.

The server can access or ping all computers

The VM has Internet access and can ping all devices in the network and access them.

BUT

The VM and the server do not see each other at all. Neither the VM can ping the server nor the server can ping the VM. Needless to say, the VM cannot access the shares.

 

Only when I set up a public bridge with br0 again (as is currently the case) (while also retaining the network settings of the Win VM) do I have all the effects from above AND the server and VM can see each other and the VM can access the server's shares.

In this respect, I have only changed

-set up bridging on eth0

-changed the network connection of the VM in the VM settings from vhost0 to br0.

 

As soon as I deactivate bridging and change the network connection to vhost0, only the VM and the server are can't communicate, all other devices can communicate with the VM and the Server.

 

I also updated the virtio drivers to 240 out of desperation - no change

I deleted the network connection in the WIN VM and set it up again from scratch - no change

 

Does anyone have any idea what the problem is here? It can't be that under vhost0 all devices in the network can communicate with each other but not the VM and the server on which it is running.

 

nasng-diagnostics-20231231-0022.zip

Edited December 30, 20232 yr by HardwareHarry
diag added

I got no bites in my posts re this issue so maybe it is by design, but if so, a bad design that breaks stuff.

You put more detail into it so hopefully you get some bites.

 

i would love to get the ups integration from ha working again and free up a power monitor.  

@vw-kombi

I "think" I got it solved, thanks to @alturismo

 

Can you share a screen of your routing table ind the network settings? 

Also a screenshot of your complete Docker Settings

No worries - here is the info - but please - its New Years Eeve - you dont have to reply any time soon - I have been living with the issue for motnhs.

 

 

 

 

 

New years eve is currently noon in my timezone (12:40 CET) and i have three little kids (1/1/3) so I'm babysitting and messing around with my server 🙂

 

You have the same issue I had: vhost0 is missing in the routing table. I show you my config and my issues and how I solved it:

 

The Network settings should be:

- Network, Bridging off

- Network, bonding off (optional, if not really needed ...)

- Docker, host access on

- Docker, macvlan

- VM, vhost0

 

 

AND thet here is the kicker:

 

This was my routing table without vhost0 in it....like yours

After

- enabling docker Services AND

-Setting IP Custom Network to my standard Ip settings in the Docker Setting:

- 

 

Vhost0 showed up in the routing table:

 

Right after that I restarted the VM and everything is working as expected

 

 

I personally think this is a dseign flaw in the current network settings.

Edited December 31, 20232 yr by HardwareHarry

Ah - Its 10:20 mPM here for me and I am not that wide awak - off to bed now.

I compared all you said and it seems I have it all there same except the VM Manager settings Default Network source - mine is virbr0 - I assume therefore I stop VM, then change that to vhost0, then restart........

 

I will try that tomorrow and report back.

Fun and games on new years day with this.

stopped vm's

stopped the VM manager

Changed 'default network source' to vhost0

 apply and done.

started VM Manager

clicked on VMS tan - messge saying Libvirt Service failed to start.

checked logs - logs state :

 

Jan  1 10:20:45 Tower emhttpd: shcmd (4854631): /usr/local/sbin/mount_image '/mnt/cache/system/libvirt/libvirt.img' /etc/libvirt 1
Jan  1 10:20:45 Tower root: '/mnt/cache/system/libvirt/libvirt.img' is in-use, cannot mount

 

As its the first of the month, I have a parity check running - so cant really restart unless I kill that chck (which I am leaning toards now).

 

So, I did the reboot.

routing table still the same however.

I tried just adding it manually also - but it would not add (maybe array needs to be stopped for that.

 

My settings are I believe the same as yours :

 

 

I dont have dhcp on the below which should not matter (all my dockers are hardcoded with IP addresses) :

 

 

 

Maybe unrelated, but I have an unresposive GUI and ssh also does not want to work now.  Was a pretty stable system before this.

Everythng is working, dockers, shares etc, I can ping it, but browser just sits there and eventually throws a 500 Internal Server Error when I try to access console, and ssh sits there.

I will give it today cos I am a bit fed up with it and will connect a monitor tomorrow for some diagnostics.

I emded it powering it off and on, parity check, then about 30m later, the same thing starts happening.

I will NOT birng up the VM Manager this time and see what that does ?

I noticed I did not have host access turned on in my docker settings.  That was for unraid to access docker containers I thought - and nothing to do with VM's accessing host - once I alsoe set that on, then the routing table matches yours.

 

I have no ideas if the stability issues relate to this work or something else random.

 

For now, I have shutdown all docker containers except emby and cloudflare tunnels, and shutdown the VM engine.  Another parity check is running so I will leave that for a day, and then start bringing up the other stuff bit by bit.

All seems good and stable again - and the issue is indeed fixed and I can ping both ways.

Clincher was I suspect allowing host access in docker setup as well as the rest in your post (that is ambiguous - as I wanted to allow VM access to host)

I marked your post as the solution - I am sure others will stumble over this.

Thanks for your help

The unraid upgrade to 6.12.8 fixed the home assistant container to unraid host.  It was not working since .4, .6, but now magically the home assistant APC sensors came back to life!!!!!  

On 3/3/2024 at 11:54 PM, vw-kombi said:

The unraid upgrade to 6.12.8 fixed the home assistant container to unraid host.  It was not working since .4, .6, but now magically the home assistant APC sensors came back to life!!!!!  

 

Well - that was short lived.

My unraid system locked up again - and after a reboot, this can not longer connect again from the home assistant docker container to the APCUPSD running on the unraid host

For everyone still searching...Had the same issue, allow access to custom networks enabled but still no ping. The solution for me was:

 

Remove offending routing rule in console:

ip route del 192.168.1.98 dev br0

 

Add new route rule to the shim network (custom network that is bridged with local unraid adapter:

 ip route add 192.168.1.98 dev shim-br0

The result needs to be: