Monday, January 28, 2013

Pivot3 VDI Appliance for VMware View and Pivot3 Certification

I have already written a blog post on this earlier. Since accidentally I created a separate page for it, the post is not visible on the Home Screen. 


To see my post on Pivot3 vSTAC VDI appliance, VMWare View and Pivot3 vSTAC VDI Certification, please go to this link:


http://amitabh-vworld.blogspot.com/p/pivot3-vstac-vdi-professional.html

Monday, January 21, 2013

Internet Accessible High Performance vSphere Home Lab Part II

Having created a home lab and trying to remotely connect to that, I was quite happy to see it's fast performance which I never received in VMware Workstation based lab. But sooner I realized I cannot access the VM's remote console (Right click the VM-> "Open Console") through this web client. 

On further researching, I found out TCP Port: 903 is responsible for this job. Since we are using a PAT (Port Address Translation) like service through "Dynamic Update Client" of http://www.no-ip.com it is essential that we need to make a similar entry for this port in our wifi router (refer to Step.10 in previous blog post on the same title). 

I also developed greed of accessing my vSphere Home Lab through vSphere Client itself remotely. And for that TCP Port 443 needs to be exempted. So, I made another entry for port 443. Now your Wifi Router console screen ("Advance Settings") should show like this:


 Now when I try to access the console of any VM by doing right click to the VM and choosing "Open Console" from vSphere Web Console, I can open it.

Also I tried to access my vSphere Home Lab Remotely through vSphere Client, I have no issues. Good thing is that the speed is so good that I don't feel I am accessing a Remote Lab at all. And unlike VMware Workstation based labs, this is blazing-fast and no latency at all (without even using SSD!)



Now you can play with your Home Lab Remotely through vSphere Web Client  as well as vSphere Client. 

I shall wait to hear your feedback if you have implemented this. I will be interested to know whether you have gained easy access and faster performance from your Home Lab or not. Feel free to contact me via the blog or write to me: Amitabh.Dey@Gmail.Com 

Internet Accessible High Performance vSphere Home Lab

There has been enough talk on vSphere Home Lab based on VMware Workstation. I have tried doing that. It's great, but with slow performance and still acceptable when you access the lab directly sitting at the machine itself. But what about a lab which I want to access from anywhere in the world and without any slow performance? This solution is not at all a suitable one.

Hereby I will give you a complete idea (step by step) to create a High Performance (Yes it is possible!) Home Lab accessible remotely. And I assure you there will be no mouse lagging or latency issue.

No further talks, straight to building the lab now...

So what you need to build this lab...

Pre-requisites: 

1. A decent hardware. My suggestion: Go for a desktop PC with Intel i7 3Ghz, at least 16GB RAM, one 2TB SATA HDD dedicated for this purpose. These is cheap commodity now-a-days. If you can get a SSD of at least 250GB that's great, you will get terrific performance! But if you can't, still okay. I assume you have a decent broadband line with wifi, everyone has now-a-days. Connect your Desktop PC to the Wifi Router through a Ethernet cable. Let's assume the Wifi Router IP is: 192.168.0.1

If you have an existing PC matching similar configuration that's great. You will now ask: "But do I have to wipe out my existing Windows/Linux and any other applications?" No, you don't need to. That's why I asked for a spare HDD (call it as HDD2) of 2TB. I assume your Windows OS and other applications are sitting on HDD1. We will keep them intact, we are not going to touch them. 

So, what next?

Ans: Make use of ESXi USB Installation. Take a 4GB USB stick. Keep it exclusively to store your ESXi installation.

Step1. ESXi installation on bare metal machine with the help of USB:

Boot your PC through ESXi DVD Installer CD. Alternatively if you have another (2nd USB stick of at least 4GB) USB stick and the .ISO file of ESXi downloaded from VMware site, you can make the 2nd USB stick bootable drive with the help of a free tool called "UNetbootin". 

Download it from http://unetbootin.sourceforge.net/ by clicking on downloading for Windows (I will cover Windows here, you can choose Linux as well depending on your current OS)

Click on the "Diskimage" radio button and select "ISO". Click on "..." button and select the ESXi installer ISO from the location wherever you kept it.

Make sure the type is: "USB" and on the Drive choose the Drive letter of USB Stick 2. Click on "OK". This will make the 2nd USB stick as bootable ISO. Or else you will need to download the ISO and burn it to a DVD and boot from that DVD.

Go through the ESXi installation process and install ESXi on the 1st USB stick. This way you are using your PC's hardware more like in a bare metal server but you are not touching the existing Windows OS with applications. You can always go back to your Windows by NOT booting from the 1st USB stick. So, now you have installed your 1st ESXi on your home lab.

Go ahead and configure the ESXi with a management port with:

IP address: 192.168.0.100 | Subnet: 255.255.255.0 (should be at per with what your Wifi router provides to it DHCP clients) | Default Gateway: 192.168.0.1 (IP of the Wifi Router)

Step2. Configure the 1st ESXi by connecting to it so that it can host a nested ESXi by editing the required files. There are other blogs if you want to know what are the changes required to do in the 1st ESXi (or Base ESXi)  so that it can host nested ESXi.

Step3: Open vSphere Web Client on another machine/laptop and connect to the newly installed ESXi (IP: 192.168.0.100). Create a Datastore of 2TB from the spare HDD you kept aside for this home lab. I assume the drive is connected in the drive bay in the PC and ESXi Host can access this disk. Give this Datastore a name, say: TOSHIBA

Step3: Create a VM and install ESXi on that. Give it 4GB vRAM and 2x2=4vCPUs. This will be your 2nd ESXi and it is nested on top of 1st or the Base ESXi. Give it a Management IP of 192.168.0.101 | Subnet: 255.255.255.0 | Default Gateway: 192.168.0.1 (IP of the Wifi Router)

Step4: Create another VM of 4GB vRAM, 2x2=4vCPUs (for better performance. You can reduce the configuration gauging the performance), 20GB Thin Provisioned Disk. Install Windows Server 2008 R2 64Bit. Install the required Service Pack and Windows Patches.

Step5: Give it IP of 192.168.0.110 | Subnet: 255.255.255.0 | Default Gateway: 192.168.0.1 (IP of the Wifi Router)

Step6: Install vCenter Server on this with SSO. And also install the vSphere Web Client Server. I assume you keep the default port setting for http and https which are 9090 and 9443 respectively.

Step7: Check if you can access the vCenter through Web Client from your laptop by going to this web url: https://192.168.0.110:9443/vsphere-client/ If yes, you are almost there! Login with the required credentials. Create your sample Data Center and you both the ESXi Hosts on this virtual Data Center.

Now you have a Nested ESXi Home Lab which is fast, simple and agile too. But how do I access it from Internet? (Your next question)

For this you need a Public IP. Public IP is expensive to get one from the ISP. So, how we do go about it?

We will use a great free stuff for this purpose called "No-IP DUC (Dynamic Update Client)"

Step8: Go to http://www.noip.com/downloads.php?page=win from your vCenter Server. Click on "Download" button and install it on the vCenter Server. It will install the "Dynamic Update Client" from No-IP on your vCenter Server. Now you need to go the no-ip.com site and register for a free dynamic DNS by providing your email and choosing a password and activate it. It will provide you a FREE PUBLIC IP.

Step9: Go to vCenter and login to DUC client by the email address and password you used in Step8.

To make you understand, the DUC client sitting on your vCenter Server will do kinda NAT operation from Public IP to Private IP whenever you try to access the vCenter from outside.

But hold on! You still will not be able to access your machine from outside unless you specify the exemption rule with the vCenter Internal IP and Port number on your Wifi Router. Because any traffic coming down to vCenter from web has to go through the Wifi Router first. So, for example you are trying to access vCenter by RDP from Web, your Wifi should not block Port 3389 (RDP Port) traffic coming to the vCenter Server (to Internal IP which is 192.168.0.110).

So how do we do it?

Step10: Login to your Wifi Router and go to the Advanced Option. It depends on which router you are using. I am using a DLINK router and it shows me a screen like this:





















Put the settings exactly the way I have put it in the screen. In case the input part is not clearly visible in the picture, let me post a zoomed picture for better visiblity.














Once the setting is done, click on "Save Settings". It will ask you to reboot the router. 

Step11: Restart the Wifi Router.

Step12: Go to any other PC/laptop's (NOT any mobile device!) browser and give this url:

https://<Your Public IP You Received from No-IP>:9443/vsphere-client/ and hit Enter. You should see the vSphere Web Client Login Screen like this:



















Step13: Login with your vCenter Administrator ID and Password and you will see a screen like this:



















Keep playing with your vSphere Home Lab remotely from anywhere as long as you have an internet connection as Adobe Flash enabled Browser. Remember you will NOT be able to connect to this Home Lab from iPAD or Android Tablets since they don't support Adobe Flash. 

For that you need a separate server (or appliance) to be installed, called as "VCMA Server". But with the DUC Client in picture it may be slightly difficult to install the DUC client in the VCMA since it is an appliance until now. I have not tried the DUC Linux Client yet and also not sure whether it will be able to get installed in any VMware appliance. It should be, since the appliance is nothing but SUSE or some other Linux variant on the OS level. That makes a room for another blog post...

Happy playing around with your Home Lab REMOTELY :-)

Saturday, January 19, 2013

vCloud Director Components


People often ask me what is vCloud Director (VCD) and how vCloud works? While I was learning and working on vCloud although I found it to be an extremely wonderful and scalable product but sadly presented in a very complicated manner, something which is hard to digest for the beginners.

In this blog post, I have made an attempt to explain the concepts of vCloud and it's components in a much simpler manner.

Q: At the outset, what is vCloud?

Ans: vCloud is a Iaas type Cloud powered by a set of tools from VMware by which you can create:

  1. Your on-premise Infrastructure -As-A-Service (or Iaas) Private Cloud. Example of a private vCloud will be something like a company say, GE (General Electric) which has decided to build it's own Private Cloud and in turn all the department or COEs or Business Units of GE become it's customers ( or "Tenants" in Cloud term).

  1. Or you can build Amazon or Rackspace like "Public Cloud" built with the help of vCloud too. The greatest example of Public vCloud would be probably Vmware's Public Cloud itself where it extends the Public vCloud facility with the help of different partners across the globe. e.g: CSC, Singtel, HCL, Colt, AT&T etc.

  1. Now you may ask, what about Hybrid Cloud? Can I make a Hybrid Cloud through VCD? Well, that's possible too! (with the help of a vCloud component called "vCloud Connector").

Here I am not going to define what is Cloud and how Cloud works. I assume you know it already. If not, I encourage you to go for Cloud Foundation self-study courses like "EXIN Cloud Computing Certification" or Rackspace's "RackU Certification". and if you need more information on that feel free to drop me a line.

Next question, what are the different components of vCloud?

Ans:

         A) VMWare vSphere (version 5.1 : I will go with the latest version of vSphere)  comprising of:

  1. ESXi Servers or Physical Hosts which will provide the required compute resources like CPU, Memory and Network (Network Ports and Connectivity at the base vSphere layer)
  1. vCenter Server: Acting as a VMM tool or Management console for the ESXi and hold other components or virtual appliances.
  1. Storage: Depending upon your infrastructure, it may be Fiber Channel or FCOE or iSCSI SAN or NFS. Storage is presented to the Cloud layer to the tenants through vSphere and vCloud software. We will talk about this later.
  1. Network: This consists of your Standard Virtual Switches, Distributed Virtual Switches and any Cisco Nexus 1000V switch if you have. Only the port-groups or ports are presented to the vCloud layer. We have another tool/software for advanced networking requirements like Router, NAT device, Firewall called "vShield Edge"

(N.B: I can include vShield Endpoint and vShield Edge here, but I will not do so to keep simplicity to the readers. Although they stay at the vSphere layer, for ease of understanding I have kept them aside from vSphere Layer)

vSphere suite will provide the basic vSphere Virtualization layer absolutely must for any Cloud setup. This layer decouples physical resources like memory, CPU, Network, Storage etc. from the underlying Hardware layer. This is also the layer where one creates resource pools which is again an aggregation of the physical resources from different physical hosts. These resource pools will later be shared between Tenants, Organization VDCs and vApps . (If you wonder what these terms are, I would say don't try to burn your head in these now. We will talk about them eventually)

B) vCloud Director Software: 

This will provide the Cloud Layer (upper layer which sits on top of vSphere Layer). It will help us with the creation of different core Cloud components like Provider and Organization vDCs, vApps etc. For now you can imagine a vCloud as a group of servers sharing a common database. Every vCloud Director Servers runs a set of services which is called as "vCloud Director Cell". These group of vCloud Servers will eventually connect to multiple vCenter or a single vCenter Server (depending on the complexity of your VCD setup) .

A vCloud Direct Server is nothing but a RHEL6 VM or can be a Physical Machine  and vCloud component is installed on top it. I will talk about the installation and configuration later in details.

Note: a single vCloud Director Server can be mapped to only one cell and single database whereas a single database is shared between the multiple VCD Servers to maintain common information for the vCloud Cells in a VCD group)

vCloud Director will also provide us with a Web Portal or Web Console through which Cloud Administrators will connect to it and configure further.

vCloud Director also puts the "vCloud Agent" software in every ESXi that it connected through the vCenter Server.

There is also another NFS Server that vCloud Director connects to which will store the common configuration for all the vCloud Servers in a multi-vCloud Director Cluster Setup.

Apart from this vCloud Director connects to LDAP services (like Microsoft Active Directory or Open-source's OpenLDAP), SMTP too.

  1. vShield Manager  (and vShield Edge) : This is a virtual appliance (downloaded from Vmware site) which provides the network services to the Cloud Layer. Note one vCenter Server can connect to only one vShield Manager and also a vShield Edge.



Diagram1. (Courtesy: Vmware Corp.)

As you can see in this picture, a vCloud Director Cluster (bordered in dotted lines, Green color area) consists of multiple  vCloud Director Servers. Each vCloud Director Server (showed in Blue Line Box) consists of a vCloud instance what is called "vCloud Cell". All these servers in turn are connected to one single vCloud Director Database to store common cell information.

Now look at this Diagram2. below: (Diagram2. is in fact the extension of Diagram1.)

Diagram2. (Courtesy: VMWare Corp.)

Here what it explains is that the group of vCloud Director Servers are connected to a bunch of vCenter Servers on the vSphere layer which in turn are connected to their respective ESXi Host Servers. Like every vCloud Director, vCenter has it's own Database which you install and configure when you are setting up your vCenter Server during vSphere Installation/Configuration (or you connect to an embedded DB in case of say vCenter Appliance).  Also, as I have mentioned previously every vCenter Server also connects to vShield Manager. vShield Manager holds a very important role in the vCloud Family and no wonder it deserves a separate blog post exclusively.

Until this point what we saw is that our Cloud or what we call vCloud in VMWare World :) is ready to be deployed. You immediately come up with a question: But what about charging the customers? Is it done by vCloud itself?

NO! For that we have something called "Vmware Chargeback Manager". Yes, by now you figured out that it is another appliance which can be downloaded and installed .  Chargeback Manager will create the usage reports, do billing etc.

Did we miss something else too or we are good to go?

Well, there's another optional component named "vCloud Connector" which will enable your Private On-Premise Cloud to be connected to other Public Clouds (at this moment those have to be vClouds as well, if I am not wrong) making it a Hybrid Cloud. Think about a situation, you have set up a Private Cloud in your company and set up the workloads. Eventually it needs growth and you find it a cheaper and easier to move workloads to a Public vCloud provided by any of the vCloud Partners of Vmware or vice versa. There comes VCD Connector to your rescue.  See the diagram below.


Diagram3 (Courtesy: Vmware's Official Blog)






I hope by now we have a basic idea about the different building blocks of VCD. To sum it up let's refer to this architecture diagram:













Now that we have some basic idea about VCD, we will go further in-depth in the coming posts, Stay Tuned...