Using Chrome - Version 127.0.6533.120 (Official Build) (arm64)

Just tried to inspect the element and before I got to it the data was visible again.... Will post again if I find anything concrete

Just did it again - and this time inspected the source of the cell and the data isn't in the DOM at all -

<td data-v-29257205="" data-title="IP Address" data-testid="sortable-cell-8-5" align="left" class="col-harvester-ip-address"><div data-v-29257205="" row-key="c323fd6e-7845-40a6-bff1-9912ad116012"></div></td>

then it appears... most weird

I'm guessing this is updated form a socket

craig@Craigs-Mac-Studio ~ % kubectl get VirtualMachineInstance -A --watch
NAMESPACE             NAME                AGE     PHASE     IP                NODENAME   READY
harvester-public      web1-clone          6d      Running   192.168.100.206   n4         True
web-engine-services   dns                 3h26m   Running                     n5         True
web-engine-services   gitlab              28h     Running   192.168.100.53    n4         True
web-engine-services   nfs                 77m     Running                     n5         True
web-engine-services   runner-01           4h48m   Running   192.168.100.137   n5         True

usually one or two show empty...

between 2 and 4 are often empty

just realised this showing a log rather than the "now" if you leave it running -

web-engine-services   nfs                 15m     Running                        n5         True
web-engine-services   nfs                 16m     Running      192.168.100.122   n5         True
web-engine-services   minio               47h     Running      192.168.100.200   n5         True
web-engine-services   zabbix              46h     Running                        n4         True
web-engine-services   zabbix              46h     Running      192.168.100.131   n4         True

Its strange - you can see above that one query the info is there, the next it's not. These VM's are always accessible otherwise as far as I can tell.

Would you please open a GitHub issue; add all the info you mentioned in this post.

I think there is a chance this is because of how our network is laid out - so before I raise this I'm going to move the interfaces around such that harvesters network is segregated better from the tenants - excuse the scribbles, but this is what we have now - with the router running DHCP for several networks, the layer 3 switch has a VLAN IP pool defined for the storage and is the only 10G part of the net

Planning to move the SPF+ 10G switch up to its own route from the router with the 122 network assigned, then the 100 network remains heading via the GB switch as a Tennant network that we can NAT to the outside - will test that first and if the problem persists I'll get it on github

Done - https://github.com/harvester/harvester/issues/6406