Well that wasn't very useful message. If you can find the cloud-utils jar on your server run
java -cp <PATH>/cloud-utils-4.1.1.jar com.cloud.utils.net.MacAddress That will output what its finding for the mac address. Also run an "ifconfig -a" from the command line. If you won't mind sending the output of "ifconfig -a" that would be helpful to see what's going wrong. Darren On Tue, Oct 22, 2013 at 2:48 PM, Marty Sweet <msweet....@gmail.com> wrote: > Just noticed I didn't include the log: > > http://pastebin.com/wUtCsSAb > > Marty > > > On Tue, Oct 22, 2013 at 10:38 PM, Marty Sweet <msweet....@gmail.com> wrote: > >> Hi Darren, >> >> Maybe I'm getting confused with an issue I had with the Agents around that >> time! >> The error message I got was very cryptic. Having a fresh look at the >> source code: >> >> >> https://github.com/apache/cloudstack/blob/04cdd90a84f4be5ba02778fe0cd352a4b1c39a13/utils/src/org/apache/cloudstack/utils/identity/ManagementServerNode.java >> >> Would suggest that it gets: private static final long s_nodeId = >> MacAddress.getMacAddress().toLong(); and ensures it's <=0 in the check() >> function, which is run by the SystemIntegrityChecker. >> >> Hopefully it is just a MAC Address issue, what would the IntegrityChecker >> be looking for? >> >> Thanks, >> Marty >> >> >> On Tue, Oct 22, 2013 at 10:02 PM, Darren Shepherd < >> darren.s.sheph...@gmail.com> wrote: >> >>> Do you have a specific error from a log? I was not aware that >>> CloudStack would look for interfaces w/ eth*, em*. In the code it >>> just does "ifconfig -a" to list the devices. By creating a bond, the >>> mac address CloudStack finds will probably change then I could imagine >>> something could possibly fail. >>> >>> Darren >>> >>> On Tue, Oct 22, 2013 at 1:39 PM, Marty Sweet <msweet....@gmail.com> >>> wrote: >>> > Hi Guys. >>> > >>> > I am planning on upgrading my 4.1.1 infrastructure to 4.2 over the >>> weekend. >>> > >>> > When testing my 4.1.1 setup I ran across a problem where a TOR switch >>> > failure would cause an outage to the management server. The agents use 2 >>> > NICs for all management traffic using bonds. >>> > When I tried to configure the management server to use a bond0 in simple >>> > active-passive mode (like I use for my agent management network), >>> > cloudstack-management would not start due to 'Integrity Issues', which >>> at >>> > the time I located back to a IntegitryChecker which ensures the >>> interfaces >>> > of eth* em* or some others were taking the IP of management server. >>> > >>> > My question is does this limitation still exist and if so, can it be >>> > overcome by adding bond* to the list of allowed interface names and >>> > compiling the management server from source? >>> > I would love to hear input to this, it seems bizarre to me that it is >>> > difficult to add simple but effective network redundancy to the >>> management >>> > server. >>> > >>> > For scenario basis, this is the basic redundant network setup I have >>> for my >>> > Agents: >>> > 4x KVM Hosts all with 4 NICs - 2 bonds (Private/Public Traffic) >>> > >>> > Example Host: >>> > ------------------Interconnect--------------- >>> > TOR 1 --------- TOR 2 >>> > --------------------- --------------------- >>> > | Management | >>> > | Tagged VLANs | >>> > ---------------------------------------------------- >>> > KVM Cloudstack Hypervisor >>> > ---------------------------------------------------- >>> > | Public Traffic | >>> > | Tagged VLANS | >>> > | LACP Aggregation | >>> > ---------------------------------------------------- >>> > Core Router >>> > ---------------------------------------------------- >>> > >>> > There are also LACP links with STP rules between the TOR switches are >>> the >>> > core device to allow for interconnect failure so the TORs do not become >>> > isolated, but I have excluded that for simplicity. >>> > >>> > >>> > I would have thought it would be easy to create a bond for my management >>> > node and connect the two NICs to both the TOR switches, but that didn't >>> > work in 4.1.1 due to my reasons above. >>> > >>> > Thanks! >>> > Marty >>> >> >>
