Well . .some free training . . and no . . not VCDX or anything too exciting, but VMware have at least provided some online training / eBooks to help all those people who will soon need to transition to ESXi, from ESX (ESX of course will be end of lifed soon)
On VMware.com blogs:
Great news for all VMware customers: the VMware Education Services team has just made available a new, FREE elearning course dedicated to ESXi , “Transition to ESXi Essentials”. The course is a self-paced three-hour online training that provides the knowledge necessary to make fundamental design decisions to successfully add VMware ESXi to a vSphere environment and to take advantage of all of the new features included in ESXi 4.1. The training is ideal for system administrators, consultants and engineers responsible for managing and supporting a vSphere environment.
Setting up the test environment
In order to get this whole build tested, we need a repeatable and accessible Lab environment.
If you are unfortunate enough to not have an ESX lab environment that you can play on, you could build a workstation and emulate your production environment right on your desktop using VMware workstation.
Tools that we’ll require (so need to download if you do not have them already) are as follows:
· Installation guide http://www.vmware.com/support/developer/windowstoolkit/wintk40/doc/viwin_install.pdf
· Download : http://www.vmware.com/download/download.do?downloadGroup=sdkwin41u1 (you’ll need a free logon)
You favourite script editor
· I use PowerGui : http://www.powergui.org/index.jspa – but you can use anything you like
A VMware ESXi Server, or VMware workstation to run tests on, along with a copy of the ESXi Installable media
· https://www.vmware.com/tryvmware – you can get trials of both from here
Copies of the various tools we’ll be testing
· UDA (Ultimate Deployment Appliance) – http://www.ultimatedeployment.org/download.html
· EDA (ESX Deployment appliance) – http://virtuall.eu/downloads/
· VMware’s own ‘Auto Deploy’ – http://labs.vmware.com/flings/vmware-auto-deploy
· SD / USB duplication – WinImage – http://www.winimage.com/download.htm
· V-PXEServer – http://www.epic.ca/lab/V-PXEServer.zip
· Manual installation – Just the Install ISO above
Assuming that not everyone has spare hardware at their disposal, I guess it would be useful to create VMs to act as ESXi hardware on which to test our installations.
If you’re using VMWare workstation as your lab – Full guide at: http://www.vladan.fr/how-to-install-esxi-4-1-inside-of-vmware-workstation-7-1/
If you are using an ESX(i) host to run your test ESXi VMs on, follow the guide at : http://www.vcritical.com/2009/05/vmware-esx-4-can-even-virtualize-itself/
For each appliance based deployment method, we’ll create a new VM – these will be detailed as we test each appliance
‘Upgrading’ from VMWare ESX 4.0 to ESXi 4.1(u1) – with as few button clicks as possible.
Anyone reading the official docs from VMware at : http://www.vmware.com/products/vsphere/esxi-and-esx/upgrade.html#c177045 is likely to be annoyed and frustrated at the lack of actual information as to how to manage the ‘upgrade’ (migration) from ESX to ESXi.
There is no direct way to upgrade directly as the 2 products are effectively 2 different operating systems that behave in exactly the same way. (well not really, but they are installed totally differently and are managed slightly differently)
Anyway, we have about 80 ESX hosts to migrate to ESXi, so I decided to find the easiest method to do so.
A scour of the web found several great resources. – and some valuable information. It seems that nobody has yet delivered a full ‘upgrade’ solution, but several people have provided automated deployments of the core installation and several other people have created configuration scripts for the newly installed ESX. So I have decided to add an additional ‘information gathering’ step, then ‘borrow’ some of the work done elsewhere and put together an ‘upgrade’ solution.
Scratching my head, I have been working on a simpler way to manage the deployment / upgrade.
The way I see it, the ‘upgrade’ needs 3 parts:
1) Capture configuration from the existing ESX host that we will be replacing (we may need to interpret and reformat it for our new ESXi Host
2) Deploy new ESXi instance on the hardware
3) Deploy captured config to our new ESXi host.
Whilst I realise that this probably will not be enough to make it a full ‘upgrade’ the idea is to get as much done as quickly as possible.
Coming up will be several posts, documenting comparisons of 5 methods of deployment, as well as some PowerCli code and a look into Host Profiles for easing this process.
On the off chance that one of the vendors that do ‘migration’ tools feel like offering me a free license to trial their tool and write up a process doc, I may even be inclined to review that for people with $$$ – but it is important that it is noted that I promise no allegiance to any tools, as would like this review to be fair and open to all. The end product of the series should provide a decision as to my preferred FREE method for doing the migration.
At the end of the series, I’ll create a comparison table comparing the various products, as a springboard for anyone who’ll soon be in the same situation as me.
For environments where there are only 2 or 3 ESX hosts, I’d consider building a solution like this going overboard, so I will make the assumption that readers of the series are people who have large numbers of hosts to upgrade and therefore will be wanting to work on ESX / ESXi rather than VMware workstation. As such, I will endeavour to get all tools working on ESXi and will highlight tweaks required (several of the tools I have tested so far were created on VMware workstation and therefore do not import directly to ESX hosts)
Products that I will be including in my review for the deployment include:
4. SD / USB duplication
5. Manual installation (I will include this as a benchmark – remember ESXi requires very few clicks as is to get running, so manual may still be the way to go)
I will go through the options for the deployment of ESXi, before doing the capture and deploy steps above (I need a deployment workframe to work on, so it makes sense in this case)
All tests for now will be run in my isolated lab, with the convenient luxury of the deployment servers being located on the same subnets etc as the Hosts I’ll be deploying to, but once I have selected a solution and start the migration of 80 ESX hosts to ESXi, I will of course post details of any further tweaks required for deployment.
Today’s Script of the day is not one of my own, but one I have used a few times in the past few weeks – and I figured I should post here as a reminder for when I next need it.
Written by the scripting wizard LucD, it is a tool that basicall ymonitors and displays VM logs . . almost as they happen.
A great and very effective script for troubleshooting realtime VM issues.
As a special holiday gift to VMware vExperts, VMware Certified Professionals and VMware Certified Instructors, Veeam is offering FREE two-socket licenses of their products for non-production use.
Just register here to receive the Veeam products of your choice for evaluation, demonstration and training purposes. You can choose one or both:
Veeam Backup & Replication v5 with vPower
Veeam ONE Solution
— Veeam Monitor Plus (with Veeam Reporter)
— Veeam Business View
Info below copied from : http://www.vm-help.com
By default SSH is not enabled on ESXi – though every time you log a call with VMWare, the first thing that they do (of course) is ask you to enable it?
To enable SSH, do the following:
1) At the console of the ESXi host, press ALT-F1 to access the console window.
2) Enter unsupported in the console and then press Enter. You will not see the text you type in.
3) If you typed in unsupported correctly, you will see the Tech Support Mode warning and a password prompt. Enter the password for the root login.
4) You should then see the prompt of ~ #. Edit the file inetd.conf (enter the command vi /etc/inetd.conf).
5) Find the lines that begins with #ssh and remove the #. Then save the file. If you’re new to using vi, then move the cursor down to #ssh line and then press the Insert key. Move the cursor over one space and then hit backspace to delete the #. Then press ESC and type in :wq to save the file and exit vi. If you make a mistake, you can press the ESC key and then type it :q! to quit vi without saving the file. Note: there are two lines for SSH with ESXi 4.0 now – one for regular IP and the other for IPv6. You should
6) Once you’ve closed the vi editor, you can either restart the host or restart the inetd process. To restart inetd run ps | grep inetd to determine the process ID for the inetd process. The output of the command will be something like 1299 1299 busybox inetd, and the process ID is 1299. Then run kill -HUP <process_id> (kill -HUP 1299 in this example) and you’ll then be able to access the host via SSH.
Tip – with some applications like WinSCP, the default encryption cipher used is AES. If you change that to Blowfish you will likely see significantly faster transfers.
Changing the port for SSH
To change the port for SSH, edit the file /etc/services and change the SSH port listed in the file. Save the file and repeat step 6 above.
The steps are the same as with SSH, but you’ll remove the # from the 2 telnet entries in /etc/inetd.conf. Enabling telnet is not recommended if security is a concern.
Enable SSH access for a non-root account
Use the following process to enable SSH access for a non-root account
1) Access SSH or the console with a root account.
2) Create a new account with the command useradd <account_name> -M -d/ . This will set the home directory to / instead of requiring a /home directory.
3) Use the command passwd <account_name> to set the password for your new login.
4) Edit the passwd file with vi /etc/passwd. For the entry for your new account, change the /bin/sh part to /bin/ash. Save the file and exit. See the example for the test1 user below.
nfsnobody:x:65534:65534:Anonymous NFS User:/:/sbin/nologin
You should now be able to connect with SSH using this new account.
Disable SSH access for the root account
If you have created non-root accounts for SSH access you can also disable root access via SSH. Edit the /etc/inetd.conf file using the initial process on this page and add the option -w after the -i option. The line in inetd.conf will appear similar to the below.
ssh stream tcp nowait root /sbin/dropbearmulti dropbear ++min=0,swap,group=shell -i -w -K60
One you have made the change, save the file and run the kill -HUP command to restart the inetd process. You will now be able to login with a non-root account, but will get access denied if you use a root account. Once you have established a SSH session with your non-root account you can issue the command su – to switch to the root account.
How often do you need to duplicate the port group config from one ESX host to another – easy if you can use Host Profiles . . but maybe you are not licensed for it?
I found a great (FREE . . the best type) tool for this:
The author is Flores Eken from ITQ Consultancy in the Netherlands. He is a VMware SDK programmer. He wrote this application in C# based on the new ESX3.x /VC2.x SDK, but it works in ESX 4
you can download it at :