There are video on the web which show you how to setup the Nexus 1000V in 8 mins video, which is greatly reliable. You can refer to the link here to find out more. Further that, you will no longer require to register and redeem the license as tough as previously does. Once you setup the Nexus 1000V, it will automatically come with the license applied which valid for 60 days, and you can enjoy your sweet time to wait for the final license key and re-apply it. Since the Nexus 1000V come with the http web base, I am not sure why Cisco had not consider to allow us to apply the license key file via the web rather than the messy process of transferring the license file into the nexus 1000v with certain CLI command. To simplify this, will definitely help the administrator to speed up the work.

There are 3 option of installing the VEM, which via VCLI, ESX console or VMware update manager. My setup today are without internet connection, therefore I went for both vcli and SSH protocol and I found that the easiest way are using vCLI. You can download the vCLI from here which is free via VMware official website. A lot of users are not adopting to Nexus 1000V today, but if you ask whether there are a need for it, my answer will be yes. For the users who had been virtualized their environment for years may realized the challenges been faced on the normal vswitch or dvswitch, and Nexus 1000V will greatly address all the challenges we have on the virtual environment.

We also tested the active standby architecture for Nexus 1000V in the VMware environment and it greatly fail over as it promised. Not too much hassle require to configure this, just as simple as 10 mins job follow the video here. Personally I will be glad to see more improvement from Cisco to further enhance and simplify the installation process and configuration which will greatly bring more value to the customer for planning and implementation moving forward.

1. First, you press Alt + f1 then type “unsupported” and press enter.
2. You will see the prompt for password after this. Key in the root password you had previously configure, and you will be able to log in to the service console.
3. Follow by that, do a vi /etc/xinetd.conf and look for #ssh. Remove the # and save the file after this.
4. Go to /sbin, and run this command ./services.sh restart
5. Noted: If you still having problem with SSH access, please restart and it should be work.

You will have your SSH enable now. Have fun.

Latest updated 12/08/2010:
Using Tech Support Mode in ESXi 4.1

Basically setting up a brand new Windows 2003 machine is pretty simple but setup a new Virtual Machine took me 2 days. The most important is my VM template is go missing. The quick solution is search for VM template and register (add to inventory) again.

SSH into my ESX server using putty and search for VM template file with extension “.vmtx”.

[root@malaysiavmesx01 vmfs]# find /vmfs -name *.vmtx
/vmfs/volumes/465eeddb-89b75750-a52d-011aa0289d15/W2K3STD/W2K3STD.vmtx
/vmfs/volumes/465eeda7-2a63d436-724b-011aa0289d15/RHEL5/RHEL5.vmtx

How to register a VM template using CLI:
[root@malaysiavmesx01 vmfs]# /usr/bin/vmware-cmd -s register

In my case, I will register my VM template as example below:
[root@malaysiavmesx01 vmfs]# /usr/bin/vmware-cmd -s register /vmfs/volumes/465eeddb-89b75750-a52d-011aa0289d15/W2K3STD/W2K3STD.vmtx
[root@malaysiavmesx01 vmfs]# /usr/bin/vmware-cmd -s register /vmfs/volumes/465eeda7-2a63d436-724b-011aa0289d15/RHEL5/RHEL5.vmtx

Probably you can check previous article “How to re-register a VM once it had been removed from ESX” posted by Craig for register a VM template using Virtual Center and browse through the data store.

The lesson tell me I MUST backup SQL database and VM template keep in the database.

According to US-CERT, the attack appears to rely on stolen SSH keys to gain access to a system. It then uses a local kernel exploit to gain root access, whereupon it installs the “phalanx2″ rootkit, derived from the older “phalanx” rootkit.

Since the ESX server is running on Linux kernel, I will strongly recommend we should keep an eye on the ESX host to ensure this is not impacted. That could become a serious impact to the virtualization.

For more information, please view from this link

http://www.informationweek.com/news/software/linux/showArticle.jhtml?articleID=210201115

Installation – ESX 3.5i had advantages as the entire process is fast and simple. ESX 3.5 require more interaction as it looks similiar to Linux installation. I know the ESX 3.5 can be script and customize by using the ks.cfg which I had done previously for mass deployment. For comparison 1 to 1, ESX 3.5i is much more easier and faster.

Configuration – Basically I dun really find much different as I do manage this machine with my virtual center. The only different is the Linux connection and command no longer usable on ESX 3.5i. By the way, I read some artical to tweak around to make the SSH work on the 3.5i, but I will prefer to proceed with powershell or CLI if I do need to use command prompt.

Perfomance – ESX 3.5i had better through put. In my test, I created 3 VM which 2 of them running on Windows 2003 SP2 with 4GB memory and 4Vcpu, plus additional 1 VM with SUSE Linux. I did the same on ESX 3.5 too. The respond on the ESX 3.5i is much smooth and not lacking, as ESX 3.5 you will see some lacking from the console open on Virtual center.  Follow by file copy test, the VM on ESX 3.5i is slightly faster than ESX 3.5. just less than a minute faster which I tried to copy some file with 20GB. Beside these points, I had not found anything different.

Manage ability – ESX 3.5 will still be the best, as there are none of the software vendor will guarantee bugless on their products. If the ESX 3.5 having some technical issue, it can be easily troubleshoot and anlayze from the Linux command which is more familiar with. ESX 3.5i still have a gap to be close up as is still new to most users yet.

Here is all my finding and I will post more in the future for any new finding

The following article try to give better understanding about latest VMware ESX 3.5 authentication login using AD.

Use esxcfg-auth command – VMware ESX Server Network Management Utility

Login to VMware ESX host using SSH as root

Ping ad.malaysiavm.com to make sure you can reach AD server.

The esxcfg‐auth command includes options for configuring interoperability with several authentication providers. This note focuses on the options that are relevant to Active Directory:
esxcfg‐auth [ [ ‐‐enablead | ‐‐disablead ] [ ‐‐addomain= ] [‐‐addc= ]

Type man esxcfg-auth for more information.

–disableab
Reverts the changes required to authenticate the user against Active Directory.

–enablead
Sets up the Console OS to authenticate the user against an Active Directory server. addomain and addc are required with this option.

–addomain
Sets the domain against which the user is to be authenticated when authenticating against an Active Directory server.

–addc
Sets the domain controller against which the user’s password should be checked.

# esxcfg-auth –enablead –addomain=AD.MALAYSIAVM.COM –addc=dc01.ad.malaysiavm.com

This enables Active Directory based user authentication in the ad.malaysiavm.com domain
with the domain controller dc01.ad.malaysiavm.com.

Basically the system will generate /etc/krb5.conf file as example below:

[domain_realm]
ad.malaysiavm.com = AD.MALAYSIAVM.COM
.ad.malaysiavm.com = AD.MALAYSIAVM.COM

[libdefaults]
default_realm = AD.MALAYSIAVM.COM

[realms]
AD.MALAYSIAVM.COM = {
admin_server = dc01.ad.malaysiavm.com:464
default_domain = AD.MALAYSIAVM.COM
kdc = dc01.ad.malaysiavm.com:88

Basically the different between ESX 2.x and 3.x is in PAM configuration, make sure you have correct PAM configuration as example below:

/etc/pam.d/vmware-authd
auth required pam_stack.so service=system-auth
account required pam_stack.so service=system-auth

/etc/pam.d/system-auth
account sufficient /lib/security/$ISA/pam_krb5.so
account required /lib/security/$ISA/pam_unix.so

auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass
auth required /lib/security/$ISA/pam_deny.so

password required /lib/security/$ISA/pam_cracklib.so retry=3
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow
password sufficient /lib/security/$ISA/pam_krb5.so use_authtok
password required /lib/security/$ISA/pam_deny.so

session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
session sufficient /lib/security/$ISA/pam_krb5.so

According to previous article from VMware, you’re require /var/kerberos/krb5kdc/kdc.conf which it’s worked without this file on VMware ESX 3.5 update 2.

Create a user on the VMware ESX Server system with permissions to use the service console or SSH. To create a user, use the Linux command useradd.

# /usr/sbin/useradd user1

Note: please make sure you have user1 in your AD or create any other AD account.

Open a new SSH session(I used putty) and login with username: user1 and AD password. If you have any problem with AD authentication logon, please refer to /var/log/message.

In case you need to access to VMware ESX host directly, you’re require to define user test1 in permission tab under VI.

Done! Congratulation! You should be able to login to ESX server using Active Directory authentication.

Related Post:

• SLES 9 Authentication Login Using Active Directory
• SLES 10 Authentication Login Using Active Directory
• ESX Server Integration with Active Directory

Here is what I did to reconfigure my ESX host and re-join it back to the HA and DRS cluster in my production farm.

Disable the HA and DRS features from the cluster, and totally remove the ESX host from the inventory on Virtual Center server. Follow by that, I SSH in to the ESX host with su -, then I path to the /etc/init.d and look for the services mgmt-VMware status command

It show the services is running. Then I issue the command services mgmt-vmware restart. This will take couple of minutes to get the service fully restarted. At the same time I had actually Remote log on to 1 of the VM to ensure no impact on the VM guest which sit on the ESX host. The result is perfectly work without any downtime on the VM guests, and should credit to the ability from VMware technology.

Once the services restarted, you can easily add host to the virtual center and reconfigure the HA and DRS cluster mode again. The ESX host is back to normal now and work perfectly as usual.