Jump to content


Functional XS7.1 Host Displays Ip Address Not Configured

Started by Ryan Burns , 11 April 2017 - 05:17 AM
6 replies to this topic

Ryan Burns Members

Ryan Burns
  • 1 posts

Posted 11 April 2017 - 05:17 AM

I've a home lab with a pool built on XenServer 6.5 then upgraded to 7.1.

All of my servers at the console screen on XenCenter show the following:


You can connect to this system using one of the following network
IP address not configured


The only issue have have had with the pool is nominating a new master.  I always receive the error:


On SBC01ENC01, Nominating server SBC01ENC01BLD02 as new master...
Server could not be contacted


I did find an issue of the servers not being able to resolve each other but that was corrected by a /etc/resolv.conf entry adding my domain to the search list.


Each server has 4 nics:

San0 10.20.x - routable - Management Interface + SAN

San1 10.21.x - non routable - SAN

Nic2 bonded with Nic3 for guest traffic

Nic3 bonded with Nic2 for guest traffic


each box has just the two ip's


I am really at a loss for what the issue is here...

Gertjan Jongeneel Members

Gertjan Jongeneel
  • 197 posts

Posted 20 April 2017 - 08:32 PM

We see the same problem at a customer's site after removing all bonds. The use of bonds with specific Intel NICs seems to be shaky (servers stop responding after a few days). We removed the bonds and that seems to help. Management and VM network use a single NIC now. After the change, the bug described above ('IP address not configured' within xsconsole). 

dirk dingus Members

dirk dingus
  • 87 posts

Posted 23 April 2017 - 09:08 PM

I'll second that about shaky Intel NICs. After creating bonds with 10-Gigabit X540-AT2 NICs using the ixgbe driver ssh console connectivity is shaky now with delays and stuttering in the console. The "IP address not configured" looks like this same problem found a while back on xenserver.org. However, it is worse, as noted above with the Intel NICs and ssh connectivity problems. This makes you wonder what other problems are going on. I also see this exact issue in XS7.0 so it has been around awhile. I notice that the ixgbe driver now includes VLAN and FCoE components that were not in XS6.5SP1 as shown from ethtool. I also disable loading of the FCoE modules by removing the load from SUPPORTED_DRIVERS="libfc fcoe bnx2fc" in /etc/sysconfig/fcoe. This did not have any effect. Not sure where to go. Still on XS6.5SP1 but I would like to use XS7.1 to get under support.

John M Members

John M
  • 44 posts

Posted 24 April 2017 - 06:13 PM

Did you apply all the 7.1 patches as well?  I was about to post the same problem until I saw this so I'll append.  We have a pool (unfortunately a production environment and not a home lab) which has been upgraded since the early 5.x days.  Last weekend we upgraded from 6.5 to 7.1 and applied all current patches.  It is a 10-host pool, rolling through the upgrade to 7.1 went fine (I use the word "fine" very loosely in regards to upgrading Xenserver) and all the hosts rebooted.  It wasn't until we applied the 4 latest patches, XS71E001, 4, 5, & 6 that rebooting the slaves, 4 of them came back with no management IP found.  Long story short, we had to rebuild the host and get it hardened to a state where no reboots were required.  It will reboot fine while it's standalone, it's not until you join to the pool and need to reboot that it comes back in that state.


We have reproduced the issue with support in a Gotomeeting session however they cannot find a solution.  They are claiming the different number of NIC's in some hosts could be an issue.  We use NIC's 0-7 between storage and network traffic.  Around 3 of the servers have 12 NIC's, however each host is only configured for networks 0-7.  Plus we have never had this issue in the past rebooting slave hosts.  


We now have a host that needs added back, which upon pool join will crash and reboot.  2 of the 4 servers I mentioned earlier that had to be rebuilt, it caused the pool master to crash and reboot.


I mentioned to the support person this was a bug and should be reported and they took no interest in my comment.  Is anyone familiar with bug reporting for Citrx?

dirk dingus Members

dirk dingus
  • 87 posts

Posted 24 April 2017 - 09:12 PM

@John M -- my solution was found in this post. To answer your question though, yes I applied all 4 patches chronologically -- that is 5, 1, 4, 6 in that order. I always do this as that is the date they are released. But all my troubles with the NIC were based on having the mgmt bond in an active-passive mode and it should be in active-active. I hope you get your issue resolved. Maybe you should start a new thread.

Gertjan Jongeneel Members

Gertjan Jongeneel
  • 197 posts

Posted 25 April 2017 - 08:35 AM

We had two NICs configured in an active/active bond for Management (2 x 1 GB, Intel I350) and two NICs in an active/active bond for VM network (2 x 10 GB, Intel X540-AT2). However, the servers were unstable and every morning we had two reset 1-2 servers (out of 8) because they stopped responding completely (black console screen, not able to control VMs). We completely removed the two bonds and now it is more stable. The overall performance, however, is terrible. The performance was far better with XenServer 6.5. We are seriously thinking of downgrading. 

dirk dingus Members

dirk dingus
  • 87 posts

Posted 25 April 2017 - 04:42 PM

I understand how frustrating this can be. I had 2x10GB X540-AT2 act-pas on mgmt and 2x10GB X540-AT2 act-act on VM initially. The first troubleshooting I tried which was helpful was to break the mgmt bond and leave the VM bond intact. This made the system stable again and the VM traffic was unaffected and VMs operated normally. This told me the mgmt bond software had some issues going on. As mentioned in other posts, I created the mgmt bond once again as act-pas. Same thing happened. Then through XenCenter changed the mgmt bond to act-act and everything is stable now, it's crazy! Even in act-pas mode I would not think the mgmt bond would be so erratic. I never did figure out if it is the ovs, NIC, or drivers that are responsible for this. Citrix has been quiet about it.


As far as performance, I can say that XS7.1 is better than XS6.5. This is one of the main reasons I am going through this pain. The export performance is phenomenal. I am seeing a 66% speedup on the exports of all my Linux and Windows VMs. For that I have to give Citrix kudos. I hope you get far enough along to see this speedup. I am still testing day to day operational performance but it looks promising so far. The one grey area for me is the detection of virtualization state by newly imported XS6.5 Windows VMs into XS7.1. There seems to be some confusion in the VMs about this. I also have problems with losing network setups (IPs, static) when installing XenTools in XS7.1. Still testing that. I am afraid to see what happens to a PDC when it loses it's network details....


Good luck!