Installing ESXi 5.5 on VMware Workstation 11

Requirements:

i3 Processor(Virtualiastion Technology enabled from BIOS)or above with minimum 8GB of RAM.

Install VMware worksation 11 .

First step is to register on VMware portal and download vSphere Hypervizor (ESXi) – current version when that article is written  version is ESxi5.5. Once you register and download software VMware will issue serial number for ESXi as this software is available for free with limited number of features – for details check article on VMware web page “VMware vSphere Architectures Compared“.

 

 

 

 

Next>>

Select default settings my case 2 processor 1 core and 4 GB RAM

 

 

 

 

 

 

 

After that download the vsphere from the web link .

 

 

 

Enable SSH

First log into the ESXi console, bring up the logon box by pressing the <F2> button.

VMware vSphere How to enable SSH

At the “Authentication Required” logon window enter your login username and password, then press the <Enter> key to continue.

VMware ESXi 5.1 Enable SSH

From the “System Customization” screen scroll down to “Troubleshooting Options” and press the <Enter> key.

VMware vSphere 5.1 Enable SSH

You’ll now see four options under the “Troubleshooting Mode Options” menu, from here you toggle between enabling and disabling the “ESXi Shell” and/or “SSH”.  By highlighting the relevant option and pressing the <Enter> key you can toggle between enabling and disabling that part particular option.

As you can see from the screenshot below, if the option giving you the option to “Enable” it then that means that the setting is currently disabled.

Enable SSH vSphere

In this example I want to enable SSH on the ESXi 5.x host so I highlight the relevant line and then press the <Enter> key.

Disable SSH vSphere ESXi

 

 

 

Baremetal vs Hypervisor

With the “cloudification” of IT, new terms have appeared across the hosting industry. Some of the most popular terms are bare metal and hypervisors. But what are these? Let’s clarify the bare metal first. To answer simply, a bare-metal server is your traditional dedicated server with a hip new name for the cloud generation! Let’s have a look at what a dedicated/bare-metal server is.

Bare Metal

Bare metal is a single tenant server. This means only you are taking the resources of the server. The server belongs to you and you only. Compared to the cloud model where multiple users (multi-tenancy) reside on the same physical server, the bare-metal server only has one customer on the server.

Multi tenant cloudMulti-tenant server
Single tenant cloudSingle-tenant server

Single tenancy allows you to avoid the noisy neighbor effect, which is described as a user impacting the performance and stability of other users within the same server. With bare metal, since you are the sole user, you will not witness the noisy neighbor effect.

From a financial perspective, the bare-metal server is typically billed per month. This means no surprise on your bill at the end of the month. However, with the “cloudification” of hosting, bare metal is also available in hourly billing, so keep in mind that costs are variable when selecting an hourly usage plan.

Bare metal supports multiple types of operating systems on top of it, including hypervisors. This brings us to our next point – the difference between bare metal and hypervisors.

 

Hypervisors

What is a hypervisor and how does it differ from bare metal? A hypervisor is an operating system that can create virtual machines (VM) within a bare-metal server. Let’s have a look at the representation below to better understand the difference between the two.

Traditional bare-metal serverBare-metal server without hypervisor
Bare metal vs. hypervisorBare-metal server with hypervisor

The first image above represents a traditional bare-metal server. The operating system (CentOS, Debian, Redhat, SUSE, Ubuntu, Windows Server, etc.) is installed directly on the server, and applications are running natively in the operating system. In the second image above, a bare-metal server installed with a hypervisor provides the user with a management suite to create virtual machines on the server. The hypervisor should not run applications natively; rather, its purpose is to virtualize your workloads into separate virtual machines to gain the flexibility and reliability of virtualization.

Multiple hypervisors exist on the market. We have reached a point with virtualization technology where the ecosystem is very mature and all options are very similar, so the choice of a hypervisor relies mainly on the following points: your current familiarity with a vendor, your current infrastructure technologies, your staff certifications and of course, the cost of ownership. Make sure to understand what features you are looking for and which vendor offers the best solution based on your budget and compatibility with your current infrastructure to avoid painful migration and unexpected issues.

As for the bare metal selection, be certain to choose the proper billing method that fits your budget and your needs. If you require on-the-fly resources that will likely be shutdown within hours or weeks, then hourly billing is probably the way to go. However, if you are looking to deploy a steady workload that will run for multiple months, then monthly billing is likely the best choice. As for the hardware itself, leverage the hourly billing of bare metal to test your application on the server of your choice, and run tests for a few days or weeks until you find the right bare metal configuration for your performance requirements.

See server specs and pricing for bare-metal servers.

In the end, there is no single story for the bare-metal server with native workload versus bare metal with a hypervisor and virtualized workloads. Both solutions have their advantages, and nothing would stop a small development firm from leveraging bare metal servers with hypervisors. It simply is a matter of selecting which technology best fits your need, and what you feel most comfortable with. Start with a proof of concept with an hourly bare-metal server (with a hypervisor or running your application natively on the bare metal), and see how your application performs. Evaluate the impact on your infrastructure and service management, and move forward according to your findings and experience. There’s nothing like giving it a spin to get the feel of it!

 

 

 

https://cpamithabh.wordpress.com/