Rule out problems with your old firefox profile by creating a new firefox profile dedicated to non internet stuff. We should always use a dedicated profile for internal only websites such as your firewall webpage, XenOrchestra, freeNAS, and so on.

firefox -no-remote -new-instance -createprofile intranet
firefox -no-remote -new-instance -P intranet

Rule out problems with your old firefox profile by creating a new firefox profile dedicated to non internet stuff. We should always use a dedicated profile for internal only websites such as your firewall webpage, XenOrchestra, freeNAS, and so on.

firefox -no-remote -new-instance -createprofile intranet
firefox -no-remote -new-instance -P intranet

I had similar problems in 8. Even though I had static leases set in DHCP, oftentimes services come up before the IP address has been obtained. The physical console and SSH worked, but not XOA nor XCP center.

Set a static IP address and reboot.

If that does not work, repeat the installation and set a static IP at install.
Make sure your IP address has not changed and look at the lease time. Is it only leased out for a few minutes?

Here is where we discussed it for version 8:
Broken Host Consoles in fresh xcp-ng 8 installation. VM consoles work.

@moradin
i am not sure exactly what you are saying in your last post and would very much appreciate it if you could expound on it with the simplicity of your previous posts Also, have you found 8.1 to be better at matching up VIFs when moved to a completely different host? I believed the vLan ID number would be the primary method of mapping, but apparently it is not.

@pdonias @julien-f What is the default behavior or a normal XAPI VM import when it comes to VIF mapping? Could you point to documentation, please? We are getting hung up on this.

@DreDay yes, statically leased DHCP addresses that used to work on spinning platters of rust no longer work on Solid State Drives.

However, setting static IP address did not work to fix it. Had to reinstall, setting a static IP at re-installation time.

We have seven virtual lans and each of course has a unique vLan number.

Two XCP-ng hosts that are not in the same pool, but have the same vLans.

Each virtual machine has multiple vLans.

When migrating a VM from one pool to another pool, the network interfaces become messed up and always fails unless all of the virtual NICs are disabled in the VM.

Since each virtual NIC on each VM has a unique numeric vLan number, is there a way to tell the systems to prioritize the matching algorithm based on numeric vLan id?

@borzel i had tried that but found grep did not work like i am used. egrep worked better, but still not like how i am used to..

 egrep -R '(10\.40\.|192\.168\.)'  /etc

Anybody have an idea of what to do to get our consoles back?

@olivierlambert Would the ”dom0 userland process/tools that must be improved” actually mean functionality that does not actually require Dom0? Wondering if dom0less Xen would speed things up.

@olivierlambert
The /var/lib/xcp/state.db is basically a single line of xml with a half-million characters.
The old egrep or sed or vi searching did not seem to narrow things down likely they normally do. Used xmllint to put the db in a pretty format with line breaks and indentation. Then vi to edit. Of course, as soon as i start xapi, those changes are lost. I assume there must be a massive speedup in lookups when all on a single line.

[23:59 xen-B xcp]# pushd /var/lib/xcp/
[23:59 xen-B xcp]# systemctl stop xapi
[23:59 xen-B xcp]# cp state.db ./state-YYYYMMDD-HHMM.db
[23:59 xen-B xcp]# egrep  '(192.168.2.141)' ./state.db | wc
      1   11757  454034
[23:59 xen-B xcp]# echo " :( 1 line with over 11,000 words :(" 
[23:59 xen-B xcp]# xmllint --format state.db >> state.xmllint--pretty.db
[23:59 xen-B xcp]# egrep  '(192.168.2.141)' ./state.db | wc
     10     193   13526
[23:59 xen-B xcp]# echo "i can deal with 193 words :) and edited with vi" 
[23:59 xen-B xcp]# mv state.xmllint--pretty.db ./state.db
[23:59 xen-B xcp]# systemctl start xapi

xe console-list indicates the the proper IP addresses:

[23:59 xen-B xcp]# xe console-list  vm-name-label=Control\ domain\ on\ host:\ xen-B

uuid ( RO)             : d5039d1a-64ad-c8a9-a309-51e568ba2926
          vm-uuid ( RO): 1593da28-8e85-4252-878e-778eb414c549
    vm-name-label ( RO): Control domain on host: xen-B
         protocol ( RO): VT100
         location ( RO): https://192.168.10.192/console?ref=OpaqueRef:7be93ca1-76cf-4649-8276-74891eac0a06


uuid ( RO)             : 7bcf725e-ae83-cf6f-7997-7dd63469929f
          vm-uuid ( RO): 1593da28-8e85-4252-878e-778eb414c549
    vm-name-label ( RO): Control domain on host: xen-B
         protocol ( RO): RFB
         location ( RO): https://192.168.10.192/console?ref=OpaqueRef:1361b935-2d25-4929-9b27-4b0483cbb0f7


[00:00 xen-B xcp]# ip a show dev xenbr0 | egrep inet
    inet 192.168.10.192/16 brd 192.168.255.255 scope global dynamic xenbr0

But there is still a blank host console in both XOA and xcp center. Suppose those OpaqueRefs have to be fixed up as well. EFI starting crashing on this r720, so having many other severe issues to deal with.

@olivierlambert Is there a github issue for this? Does the xcp-ng or xen project have something in mind?