Home / server / Questions / 3661
Accepted
Chopper3
Asked: 2009-05-04 11:35:17 +0800 CST

VMWare: ESX or 3i? Do I need the COS?

  • 772

We have lots of regular ESX 3.5 hosts but I'm about to take delivery of a bunch of Xeon 55xx based servers and think it's time to question whether to use 3i in the future. It would save me buying local boot disk pairs and most of the patches are to the COS rather than the kernel. We use vCenter so don't need SSH access. So my question is do I really need the COS? What do you need the COS for? Thanks.

virtualization vmware-esxi vmware-esx

5 Answers

  1. Best Answer

    You mean the service console? If you've got vCenter then you don't need it. It's as simple as that. I'm using the VI Client with a single ESXi host, I've enabled ssh access but I'm not using it. Occasionally will use the RCLI but the GUI does most of what we need.

    • 2

  2. You can easily enable hidden console on 3i (prior to update 2):

    1. On the VMware ESXi host, press ALT-F1.
2. Print **unsupported** (text will not be visible), you enter the Tech Support Mode, and you will be prompted for a password. Enter a password for the user root.
3. You should see command prompt ~ #.
4. Open the file inetd.conf using vi /etc/inetd.conf
5. Find the line, starting with #ssh and remove the #character.
6. Press ESC and type: wq, to save your changes and exit back into the console.
7. Restart the management services using the command `/sbin /services.sh restart`.
8. Now you can connect to SSH, using any ssh-client (eg, Putty).

    Starting with the VMware ESXi Update 2, this method of enabling SSH access is not working, servises.sh no longer restarts the daemon inet.d, which is supposed to enable SSH. To restart, do the following:

     * Type ps | grep inetd
   The result will be something like 1299 1299 busybox inetd. 
   Process ID for inetd - 1299.
 * Now enter the kill-HUP process_id, where process_id in this case 1299.

    After that SSH should work.

    • 2

  3. We still haven't made the jump to ESXi because we're not ready to move to CIM-based management yet. We still use the COS-hosted WBEM agents. We'll revisit this with the vSphere 4 implementation.

    • 1

  4. Some vendors use the service console (COS) to optimize storage attach options such as iSCSI Timeouts, NFS block size, etc., specific to certain storage controllers. Check with the vendor you are using for more details.

    • 1

  5. Perhaps the better question is why you would need the service console. I can only think of two main reasons you would need the cos. Either to install third party software, or to officially kill a hung VM. Personally, I support both ESX and ESXi, and I have grown to prefer ESXi especially at patch time! As for SSH access if it weren't for my *nix coworkers I would turn it off. I can do almost anything through the SDK using either the rCLI or the PowerCLI. VMware has also made it very clear that the goal is to remove the service console. Why invest time/energy maintaining a tombstoned feature?

    In reality though it's all taste. If you want to save some money not buying boot disks. Perhaps decreasing your vulnerability footprint, etc, etc... Go for it! I don't believe ESXi has a real downside. It's just not for everyone... Some shops currently rely on the cos, and there is nothing wrong with that, but it is not required!

    • 1