Here is what the channel-group modes mean:
Ports can form an EtherChannel when they are in different channel modes as long as the modes are compatible. For example:
A port in desirable mode can form an EtherChannel successfully with another port that is in desirable or auto mode.
A port in auto mode can form an EtherChannel with another port in desirable mode.
A port in auto mode cannot form an EtherChannel with another port that is also in auto mode, since neither port will initiate negotiation.
A port in on mode can form a channel only with a port in on mode, because ports in on mode do not exchange PAgP packets.
A port in off mode will not form a channel with any port.
Normally, if the other end does not support PaGP, then you want to use the on value.
You mentioned shutting down the channel-group - did you do that as part of troubleshooting once you realized the loss of server connectivity, or did you do that as the 1st step. If you did that 1st, then that is why the server connectivity was lost as shutting down the logical shutdown all phy interfaces.
Yes, I would remove your servers from vlan 1 since it is the default vlan, and more importantly if that is also your mgmt vlan. In the 1st case (default) there are security issues, in the 2nd (mgmt) too much end-station traffic can overwhelm the switch processing due to how the cat switches operate with regards to the native vlan.
It is possible to crate a mgmt vlan, and I would create one whose vlan is 1, unless there are switches that cannot change the mgmt vlan. In addition you do not have to have an msfc (routed) interface on the mgmt vlan. This can address your concern about doing maintenance via tftp that you do not want to have routed throughout the layer 3 environment. Just dedicate some ports for end-station access on the mgmt vlan, one for syslogging, one for AAA, and another for net mgmt (tftp, snmp, etc.) By not having an msfc or any other routed interface that vlan is not seen by stations in other vlans.
Let me know if this is of any help.
