Hi Darren, Thanks for getting back to me. I will set the networking config up again and run the commands you sent me over the next couple of days.
Thanks, Marty On Tue, Oct 22, 2013 at 11:39 PM, Darren Shepherd < darren.s.sheph...@gmail.com> wrote: > 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 > >>> > >> > >> >
