WWT Datacenter Services Team Blog

Our Team's Ramblings about Server, Desktop, and Application Virtualization, Cloud Computing, and other fun stuff.

Configuring iSCSI Boot on a FlexPod

1 Comment Posted by on December 29, 2011

I was recently at a customers site at was doing an implementation of a Flexpod.  The client wanted to do iSCSI booting of their ESXi 5.0 servers, as there was no local storage, nor was the environment capable of Fiber Channel.  This experience was quite an interesting one as we originally were unable to get the iSCSI booting to work correctly.

What i experienced was an error during the install process of ESXi 5.0.  We were able to see the NetApp LUN correctly during the installer, however when the installer hit 90%, we got the following error;  “Expecting 2 bootbanks, found 0”.  Doing an Alt-F12 during the install and watching the logs more closely today, at ~90% the installer claims that there is no IP address and begins to look for DHCP, in addition claiming it can no longer see the disk.  The odd thing is during the configuration of the Service Profile and the iSCSI NIC, at no time did we choose DHCP, we choose Pooled.  Since there is no DHCP Server in that subnet it doesn’t pickup an address and thus loses connectivity to the LUN.

The installer would then error out and the only option was to reboot.  However, the odd part is that ESXi would actually boot from the iSCSI LUN, however it was an incomplete install, as none of the settings specified during setup were taken, and the VMware Tools ISOs are not available to any VMs on the host, in fact they don’t appear to be loaded on the host.

To make a long story short, we called Cisco TAC, and we were told “Currently, there are NO UCS blades that are officially supported to work for iSCSI Boot with ESXi 5.0, the latest version to be supported is ESXi 4.1″.  We tried ESX 4.1, it works perfectly.  I also had spoken with another colleague who was going through the same issues, and they stated they had fixed it, however as it turns out it was a “lucky fix”.  So something changed with the ESXi installer from 4.1 to 5.0, and the way it was handling the NICs.

When i returned on site after the Christmas break, we tried the “lucky fix” with no success.  We then looked into the ESXi Installer logs a lot closer, trying to figure out what exactly was going on.  What we saw, this time by looking closer and trying to decrypt the sometimes vague messages, it appeared to be resetting the first NIC and looking for a management IP, NOT the iSCSI IP.  We then looked at the Service Profile configuration, more specifically the “vNIC/vHBA Placement Policy”.  We had set a specific placement policy so that certain NICs would always be the same, ie. vmnic1,2, etc.  In that placement policy we had the HBA of the server, followed by the iSCSI Overlay vNIC then the rest of the normal vNICs.  We then moved the Overlay vNIC to the bottom of the order and re-ran the installer, it worked perfectly this time.  Watching the logs this time, it was still resetting that first NIC and looking for DHCP, however this time the Overlay vNIC wasn’t the first one, so the iSCSI adapter was maintaining its’ IP and thus connectivity to the disk.  We were able to repeat this fix on every other server.

So while there still is an issue Cisco & VMware need to work out, and if it’s a firmware fix or simply a procedural how-to is yet to be determined.

In the meantime I’ve created a “How-to” of my own.  This document covers the iSCSI Configuration portion of a Flexpod install, it deals with the UCS portion as well as the Netapp.  It does take some assumptions that you know how to navigate the GUIs.  I did use Filerview for this doc, however the premise is the same if using System Manager or the CLI.

FlexPod iSCSI Boot-Fixed

Cisco, ESXi, iSCSI, Netapp, VMware, WWT , , , , ,

Backpack as a Service (BaaS)…

4 Comments Posted by on September 2, 2011

If you’re in the IT industry you’ve more than likely attended some of the numerous vendor conferences such as VMworld, Cisco Live, etc. One common theme amongst these events, besides the great learning opportunity, seems to be backpacks being given out to all the attendees. While they are a great use during the show to carry all the gathered information and other swag you may pick up, what I’ve found is that when I get home, the backpack is usually just put in the basement and there it sits amongst all the others I’ve collected over the years.

Well, I just got back from VMworld and having gone through my normal routine of pulling all the collected information out, I made that trip downstairs to put the newly obtained backpack with the rest.

Seeing the pile, I began to think… 

Wouldn’t it be awesome to get these things to someone in need? Perhaps a child whose parents couldn’t afford to buy them a school backpack? What if I could also throw in some school supplies…Perhaps some pencils, paper, etc? Another thought was to get them to a homeless shelter where the less fortunate could use them to put their things in…stash them with a few toiletries to help get them through another day?

So… I’ve made the decision to do just that! 

In the coming week I will be placing calls to shelters and schools to see where the need fits most. Since we’re already a few weeks into the new school year, it’s very possible schools will have all they need in which I’m certain, a backpack full of toiletries would come to great use for our homeless community.

If the above interests you, and you too have an ever-growing collection of backpacks, I’d challenge you to donate yours. In fact, I’d be happy to take it off your hands to add it to the donation collection, to fill it with needed items and donate it to someone in need. If you’d like to include a small donation or even pre-packed with school supplies/toiletries, I’ll make sure it goes to good use and that everything makes its way to a child or individual needing a little help in their lives.

Over the coming weeks, I’ll make a promise to update this blog with my findings as I contact shelters and schools. I’ll also include ship to information along with the chosen path for donation (School vs. Homeless) so that if you’re interested, and choose to prepack it with supplies, you will know what cause it is going to. Of course lots of updates, pictures, etc of everything coming together will also come with the updates.

VMworld had close to 20,000 attendees and if just a fraction of the attendees donated their bags, I’m certain the impact would be felt all around us.

If you have any thoughts and suggestions feel free to leave a comment below. I hope that you stay tuned in and can help with this cause.

-Chris

WWT , , ,

Cisco UCS PTS vs 1000v

6 Comments Posted by on March 1, 2011

I’ve had a couple great conversations the last projects I’ve been involved in where I’ve been asked, “Do you recommend PTS with Cisco UCS or the 1000v?”  This is a great question because in a sense, they both do the same thing.  In this post I hope to cover the differences and why someone may choose one over the other.

Like most things in IT, I’m going to start out with a big it DEPENDS.  Time really needs to be analyzed in each environment to ultimately determine what works best.  I’ve seen both implemented out there and both work very well.  I won’t say one is better than the other if that’s what you’re looking for ;)   It is your job to be informed and then decide!

Some background…

If you’re not familiar with PTS or how to get it up and running, I suggest a good post by a fellow member of my team here.  Jason walks you through actual implementation and discusses what PTS is.   The 1000v has been around for a while with lots of great discussions of its use.  I wrote a deployment guide not too long ago here that walks through the actual implementation.  Both are easy to get up and running without much pain.

It’s important to note that both solutions operate on the principle of VN-Link.  It’s VN-Link that passes network control and insight back to the network admins for virtual machines.  As our virtual domain grows, this capability becomes a necessity.  If you’re not yet using VN-Link within your environment, I suspect you’re already considering it or looking into how it can be implemented within your environment.  A great description of VN-Link can be found here by Joe Onisick; another great member of the WWT Datacenter team!

On with the differences…

I like things as simple as possible so hopefully with the below chart, you’ll be able to easily get a grasp of things.  It should be noted that where the 1000v has a lot more features then I show here, those features would not be applicable within the UCS stack.

So which do you choose???

As mentioned earlier it’s really going to depend what works best for you and your environment.  To call out a couple things…

UCS PTS

  • We can manage and see all VM’s and port-profiles right from UCS Manager.  If you’re not familiar with the configuration of the 1000v, management can be a bit easier.  This also becomes useful for quickly seeing all your VM’s and to see which port profile (network) they are connected to from a nice GUI.
  • UCS PTS is FREE!  It’s included in the cost of UCS, so right out of the box you can have this functionality.
  • The currently max supported virtual machines per ESX host with PTS is 54.  Note: Remember this when factoring in HA in your VMware environment if you’re utilizing memory dense servers.
  • All virtual machine traffic is processed by the 6100’s even when two virtual machines reside on the same ESX host.  Those Affinity rules you have specified to allow optimal networking traffic just went out the door.  Keep in mind it’s sub-micro seconds for 6100s to switch traffic so this may not matter in your environment

1000v

  • One obvious thing should be the enhanced security control mechanisms provided by the 1000v.
  • Management of the 1000v should be very familiar to the Networking Administration team.  Favorite CLI commands are mostly supported and current scripts can easily be integrated. Note: Scripts can also be used against the UCS stack it’ll just take some rework to get them to be compatible.
  • The currently max supported virtual machines per ESX host with 1000v is 216.
  • Virtual machine traffic is switched locally on the ESX host
  • There are licensing costs associated with the 1000v.  As of this writing it’s based on physical processor count.

Some final thoughts…

As you can see, there are very subtle differences between the PTS and 1000v when applied within the UCS stack.  Unless you need granular security control, I don’t see a whole lot of reason why not to use PTS unless you’re planning on really running a lot of VMs per ESX host.

That’s it from my side.  If you don’t run into the above points, I’d say you really need to take a strong look at PTS within your environment.

Cisco, Nexus, VMware, WWT , , , ,

Installing a XenDesktop 5 Proof of Concept

11 Comments Posted by on February 18, 2011

In case you haven’t heard, Citrix has released the newest version of their VDI offering, XenDesktop 5. If you’ve worked with the previous versions of XenDesktop, then you also probably already know that getting it up and running is no picnic and can be very complicated. Citrix has heard your cries and has designed XD5 to compete with VMware View in simplicity to get up and running and get you connecting to virtual desktops for proving out the capability set.

Before we run through a basic proof-of-concept install, let’s talk about some of the key differences between XD4 and XD5.  There are some significant terminology changes from previous releases of XD (this is Citrix, so no surprise, right?!):

  • What was known as Farms are now called Sites.  Citrix would like you to think of a site as a deployment of XenDesktop in a single geographical location.
  • A catalog is a collection of user desktops managed as a single entity. Catalogs specify virtual machines (VMs) or physical computers that host user desktops, the Active Directory computer accounts assigned to those VMs or computers, and, in some cases, the master VM that is copied to create the user desktops.
  • Desktop groups and the virtual desktops they contain can be configured more flexibly. A single desktop group can contain desktops from a number of catalogs rather than being limited, as in earlier versions, to a single hypervisor pool. Also, a single desktop group can be published to users so that a single user may access multiple desktops in the group, and a single desktop may be assigned for use by multiple users. Desktops can also be assigned to client machines, rather than users, if required.
  • A host is the infrastructure on which desktops are hosted, which comprises of hypervisors (resource pools or clusters), storage etc.

There are also some very substantial architectural differences in XD5. These include:

  • No IMA data store. XenDesktop 5 no longer uses the IMA data store as the central database in which to store configuration information. Instead, a Microsoft SQL Server database is used as the data store for both configuration and session information. This means:
    • Database requirements are different: Microsoft Access and Oracle are no longer supported databases.
    • Terminal Services is no longer required on servers running the controller.
    • There is no longer a dedicated zone master. In previous XenDesktop versions, there was a zone master/data collector responsible for user connection requests and communication with hypervisors. In XenDesktop 5, this function is distributed evenly across all controllers in the site.
    • Due to reliance on Microsoft SQL Server, to ensure failover should the database become unavailable, you must use either SQL clustering or mirroring, or deploy the database as a virtual machine and use your hypervisor’s high availability features instead.
  • Registry-based discovery. Desktops will now locate XD controllers through a registry-based mechanism. An Active Directory Organizational Unit is no longer required, although you can still use Active Directory-based registration. Active Directory is still needed in a XenDesktop deployment for authentication and authorization, therefore machines need to be domain-joined regardless of whether you use registry-based discovery or not.
  • SDKs. XenDesktop 5 provides a new PowerShell SDK which allows you to perform the same tasks as you would with the Desktop Studio console. You can also perform tasks with the SDK that you cannot do with the console, such as assigning an IP address to a desktop, rather than a user name. Desktop Studio is built upon the PowerShell SDK; you can display the PowerShell in use in the console. Note that the new PowerShell SDK is not compatible with the SDK associated with previous XenDesktop releases.

No IMA? No AD OU required for registration of the DDC? No terminal services? Pretty crazy, right? Yes, it is but Citrix is definitely going in the right direction on simplifying the installation and configuration of XD.  Certainly lots of things have changed.   As humans we are creatures of habit, but these changes by Citrix are intended to make the lives of us consultants, architects, and Citrix administrators easier.  With that said, it’s important to know that now the logged-on user’s rights are what you are using to authenticate to the XD5 database, to your back-end virtualization, and to AD.  Because of this, make sure the user that you install XD5 as and the user that connects to your back-end virtualization has the appropriate privileges to access everything XD5 needs to touch.

Also, for the DDC, Windows Server 2008, Standard or Enterprise Edition, with Service Pack 2 installed (32- and 64-bit) Windows Server 2008 R2, Standard or Enterprise Edition (64-bit only) are the only supported OSs. Windows Server 2003 in any edition is no longer supported.

OK, with the semantics out of the way, let’s get started on a basic install of XD5.

First, let’s go to Citrix’s website (http://www.citrix.com), then to Downloads and get the appropriate software for XD5. In this version, we are using the Express edition.

Once you’ve downloaded the XD5 ISO, put it in a place where it will be accessible to your back-end virtualization. For our purposes, we are using vSphere as our virtualization solution.

For the master desktop, I used Windows 7 Professional 32-bit, although XP 32 and 64-bit are supported, as well as Vista 32 and 64-bit. Aero is not supported for Vista or 7. Install all updates and make any customizations to the desktop that you require. .NET 3.5 and Visual C++ will be automatically installed if not already when installing the Virtual Desktop Agent (VDA).

Spin up a Windows Server 2008 or 2008 R2 VM as our DDC (from what I’ve read, DDC seems to have been dropped by Citrix, with “controller” being the favored term now). Install all necessary Windows updates, assign it a static IP address, and join it to a domain. Although, most prerequisites can be installed with the XenDesktop install itself, it is advised that you manually add the .NET 3.5 feature before the XD5 install (if installing Web Interface on the same box). You could potentially have some funky things happen if you don’t. IIS, which is required by Web Interface, is installed with .NET 3.5.

We’ll handle the install of the VDA on our master desktop first. Open a console to your VM and connect to the XD5 ISO and let’s get started.

If the autorun doesn’t go, just go to Computer and start it manually.

Click Install Virtual Desktop Agent (VDA).

Click Quick Deploy. You would choose Advanced Install for a production environment.

You may get a notice similar to the one above. Click Yes to continue. XD5 will disable the WDDM driver for you.

Next, is the Summary Screen. Pretty self-explanatory. Click Install to begin.

Be patient as the VDA and its prereqs install.

Notice Restart machine (required to complete install) is checked. Make sure that it is, and then click close. Your VM will restart. After it comes back up, you can shut it down. It’s ready to go.

With our master desktop out of the way, let’s get going on our XD5 controller (DDC). Console to your 2008 or 2008R2 VM and connect it to the XD5 ISO. As before, if autorun doesn’t work, start the installation manually.

Click Install XenDesktop.

That brings us to Citrix’s Licensing Agreement. Please read over it and put a check in the box if you agree with the terms. Click Next.

This is where we select what components to install. You must select and install all components on the same server for quick deploy to function.  Most of these components would be separated out on their own servers for a production install.

You may get the above message if you either have Windows Firewall turned off or if you have a third-party firewall installed. In this case, Windows Firewall has been turned off and there is no third-party firewall so we need not worry about this message. Click Next.

We get the Summary screen to see what exactly is being installed. Click Install to begin.

The install will begin. It will take a while for all the components to install, so please be patient.

After all components have been installed successfully, we can begin to configure our XD environment. Check the box to Configure XenDesktop after closing. (Note: If you have neglected to join your XD controller to a domain before the install, this box will not be able to be checked).

The Citrix Desktop Studio will open for you automatically. This is where we will begin to configure the environment. Click Quick deploy to begin.

Enter the name for your Site. Remember, Citrix would like for you to think of a Site as a geographical location but you can choose any name you’d like.

Select your hosting virtualization platform. Since we’re using vSphere, we’ll need provide the http or https address of our vCenter Server. Don’t forget to add the /sdk behind the address. Provide the necessary credentials to your vCenter Server. When done with all of that, click Next.

(Note: in our PoC environment, we are not using https access to our vCenter Server. To allow http access, you will have to modify the proxy.xml file on the vCenter Server. To do this, logon to your vCenter Server as an administrator. Go to this path: C:\Users\All Users\VMware\VMware VirtualCenter/ to find the proxy.xml file. Make a copy of the file in case you make a mistake. Edit it with Notepad or something similar. It can be difficult to read, so to get a clearer picture of the contents, you can open it in a web browser then make edits as you find the correct places with your text editor. You want to change two places: the / namespace and the /sdk namespace. We need to change them from >httpsWithRedirect< to >httpAndHttps<. I’ll highlight them in the screenshot below:


What we are changing is the access mode. To make it even easier to find, look at the red circles. The / namespace is listed after <e id= “0”>. The /sdk namespace is listed after <e id= “5”>. Also note, I’ve already changed these to read httpAndHttps.

This is similar to what you had to do in XD4 to allow http access but with XD5 you actually have to change this in both of these places. If you don’t, your VMs will delete themselves after provisioning.)

It may take more than a few seconds to contact your hosting, FYI.

When you get connected, we get to select the cluster and storage for the deployment. Click Browse to select your cluster.

Select your cluster and then click OK.

Now, select the storage you want your VMs to be able to be stored on. Lastly, select the network for your VMs. Click Next.

We now get to use the master desktop we create earlier. Select the master image and click Next.

Select the number of VMs you wish to create. Customize the number of vCPUs and RAM if needed. Browse to an Active Directory Organizational Unit in which to create the computer accounts (Hint: Go to your AD Users & Groups and do this ahead of time). Click OK and then Next.

Click Add and select the users and/or groups that will be able to access the VMs. Click Next.

Here we have the summary of everything we have just configured. Review your selections and click Back to make changes. If everything looks good, click Finish.

Sit back and relax because this will take a while depending upon the number of datastores you selected earlier (I’ll explain in just a bit). In the meantime, we’ll take a look at what vCenter is doing while we wait.

In just five minutes time, we have a lot going on for just 3 VMs we are creating. Let’s take a look at what’s going on with one of our datastores.

Here, we’re looking at the VM files for one of our virtual desktops XD5WIN7-01 (highlighted in yellow). Highlighted in blue, is our identity disk. Highlighted in green is our vswap. Highlighted in purple is our delta file. You’ll notice that our identity disk is just about 16MB. Our vswap is just about 1GB. Our delta file is about 144MB. This particular VM has been up and running for about 8 days. Take note that there are no apps added into the image, just Windows updates.

When complete, you’ll see the above. All in all, to create 3 virtual desktops, it took about 30 minutes. What actually is happening during this time is the copying of the replica (of your master VM) to the datastores that your site has access to. That is the explanation on why it takes so long. Once the initial cloning is complete, VMs spin up rapidly. I tested spinning up 100 desktops and they were ready to go in 5 minutes.

So, what next? Let’s configure admin access to our catalog.

Click on Administrators in the left hand pane.

Select the user or group to grant admin rights. Browse if necessary to select it. Next, select the appropriate level of privileges for the user or group. Don’t forget to enable the group before clicking Next.

Next, you get a summary page displaying what we just configured. If all looks good, click Finish. Now, let’s create a desktop group.

In the left hand pane of Citrix Desktop Studio, click Assignments. In the right-hand pane, click Create Desktop Group. Add the amount of machines you want to assign to the group based on how many you originally added to the catalog. You can always add more machines to the catalog and assign them to this group or subsequent groups you create. Click Next.

Select the users or groups that will have access to the VMs in the new desktop group. Assign the number of desktops per user. Click Next.

On the screen, the administrators you assigned to the catalog will be pre-filled for you here as administrators that can manage this desktop group. Click Next.

Here is your Summary page. Pick a display name for your users to see when they connect to a desktop. Choose a name for the desktop group. Click Finish. Now that we’ve gotten all the configuration out of the way, let’s connect to a desktop!

If you don’t know the name of your Web Interface site, check it by going to the left-hand pane of CDS, expand Access, and click XenApp Web Sites. You may also be wondering what is the difference between XenApp Web Sites and XenApp Web Services?  Well, allow me to digress. Here’s the skinny: XenApp Web Sites will provide users a URL to a website where, once authenticated, users will have access to their online resources using a Citrix client. With XenApp Web Services, you can use the Citrix online plug-in in conjunction with the Web Interface to integrate resources with users’ desktops. Users access applications, virtual desktops, and online content by clicking icons on their desktop or the Start menu, or by clicking in the notification area of their computer desktop. OK, let’s get back on track. In the top middle pane, you’ll see the name for your internal site. So, fire up a browser and let’s connect.

You may be prompted to install the Citrix Web Client. Follow the on-screen instructions to do so. You may also have to install an ActiveX add-on if you’re using Internet Explorer.

Eventually, you’ll be able to authenticate. Log on with the appropriate credentials the click Log On.

Click on the appropriate desktop (the reason two are shown here is because another group was created before I created the screenshots for this blog).

Nice! We’re connecting to one of our virtual desktops.

You will get a dialogue box asking about HDX file access. Select the appropriate level of access you wish to grant. HDX allows certain multimedia tasks to be processed by the users’ Windows device to reduce server and network load.

That’s it! You have the XenDesktop welcome screen here, which you can select not to show again. You can also choose to stop it from ever showing up via a custom GPO, by registry key, or by simply removing the shortcut for it in the Startup folder for All Users.

OK, let’s recap. In this process, we have accomplished the following:

  • Downloaded XD5 software from Citrix
  • Spun up a Windows 7 VM, patched it, and customized it for use as our master image

o   Patched it via Window Update

o   Customized it via our specifications

o   Installed the Citrix Virtual Desktop Agent (VDA) to enable its use as our master image

  • Spun up a Windows 2008 R2 VM, patched it, installed .NET 3.5 (which installs IIS as part of it) for our XD controller (DDC)

o   Patched it via Windows Update

o   Installed .NET 3.5 feature, which installs IIS (required for Web Interface)

o   Installed XenDesktop 5 and all roles needed for a PoC

o   Configured our site, connected to vCenter, and began creating desktops

o   Configured administrative access to our catalog

o   Created a desktop group

o   Connected via internal Web Interface to our virtual desktop

Next Steps…

Well, in lieu of creating a more production-ready type of XD environment, you could start with creating vSphere permissions for XenDesktop 5. There is an excellent blog out about this already from Jarian Gibson (http://jariangibson.com/2010/12/21/using-xendesktop-5-with-vmware/) where he talks about drilling down XD5 permissions with vCenter roles.

As you can see, there are still a lot of steps in the process but Citrix has clearly designed XD5 to be easier and quicker to get up and running than its predecessors.

Citrix, Proof of Concept (PoC), vSphere, WWT, XenDesktop , , , ,

Configuring Pass-Through Switching (PTS) within UCS using the Virtual Interface Card (VIC)

5 Comments Posted by on February 14, 2011

PTS is a Cisco UCS feature that allows management of the virtual network and configuration of virtual ports to be handled within UCS manager. This feature does not require a license and is available at no additional cost for any blade using the VIC/Palo card. PTS does not require Hypervisor Bypass/Direct-Path I/O but can be used in conjunction with it, although there are current limitations such as no vMotion. PTS utilizes a Cisco software switching element within the hypervisor much like a Nexus 1000v VEM, all management/supervisor capabilities are handled within UCSM on the Fabric Interconnects. PTS provides a 1-to-1 mapping between a virtual machines NIC, vNIC, and a Virtual Interface (VIF) on the VIC card. This allows for VM level granularity for network monitoring and control while maintaining the single point of management UCSM provides.

Requirements:

  • ESX/ESXi 4.1 installed on all blades that will be participating
  • Cisco VIC in each blade that will be participating
  • Virtual Center Server
  • VMware Enterprise Plus licensing (required for vDS usage)

Recommended:

  • VMware Update Manager (VUM)
  • Latest Nexus 1000v packages downloaded to VUM repository and a baseline created in VUM that contains the appropriate updates/patches for your ESX build number
  • Current 1000v bundle downloaded from Cisco if VUM is not available

Note: If VUM is not used the VEM will need to be manually installed per host.

Installation steps:

  • Create a Dynamic vNIC policy within UCSM (LAN tab)
    • Provide a name
    • Select the number of ports (typically the default of 54 which is the max)
    • Select VMware for the port type
  • Create a template or service profile for each host that will participate using the dynamic vNIC policy. Alternatively the policy can be applied to an existing service profile or updating template.
  • Apply the profile to the blades that will act as VMware hosts that contain the VIC

Note: We recommend the service profile be configured to pass 4 vEth ports. Two to be attached to a standard vSwitch and used for all VMkernel ports in use and two will be used as uplinks to the vDS, these will carry VM Guest data traffic.

Note: UCSM allows for many different methods to complete the next steps.  This just happens to be the method we used last.  The latest release of UCSM has a wizard to assist with this process also.

  • Connect and authenticate UCSM and vCenter server
    • From the VM tab within UCSM click on the “Export vCenter Extension” save the file to a location accessible by both systems (typically your desktop.) This is an XML file that contains all the information which is used to authenticate UCSM with vCenter and allow API calls.
    • Import the file as a vCenter server plugin through the vSphere client. You will need to right-click on white space below all other plugins and select Register Plugin.
  • Setup vCenter connection information in UCSM
    • From the VM tab within UCSM click on the “Configure vCenter” link
    • Provide a descriptive name (We suggest it matches the vCenter name for ease of use)
    • Provide the hostname or IP of the vCenter server (IP is recommended for statically assigned vCenter server IPs, if you choose DNS hostname ensure name resolution is configured in UCSM)
    • Next, skip the folder settings and next again.
    • Click Add on the Datacenter screen
    • Provide a descriptive name (We suggest it matches the vCenter Datacenter name for ease of use)
    • Add a folder, this will contain your DVS, Next
    • Add the DVS, this is what is pushed into vCenter
    • Ok, Finish, then Finish again.

Note: If the DVS is not created in vCenter now, one of the steps above did not properly complete or there are communication issues between the vCenter server and UCSM.

  • Add hosts to the DVS created
    • From the networks view in vCenter right-click the DVS and click add host.
    • Select the NICs that are defined for VM data/DVS traffic.

Note: The hosts uplinks will fail to connect and show a “Port blocked by admin” state if the dynamic vNIC policy is not in place.  The dynamic vNIC policy allows UCSM to automatically create VIC interfaces on the fly as VMs are added.  It also allows UCSM to create the management interfaces required for communication between UCSM and the VEM (similar to Control/Packet on a 1000v.)

Note: At this point VUM (if in use) will install the VEM.  If the VUM automated install fails, or if VUM is not in use the VEM must be manually installed as follows: 

  • Upload the proper VEM from the Cisco 1000v bundle (downloaded from Cisco) to a VMFS datastore that all of the hosts have access to. 
  • Login to the ESX/ESXi console (you may have to enable “Local Tech Support” for ESXi 4.1) and change to the datastore referenced earlier.
  • Run “esxupdate -b cross_cisco-vem-v121-4.0.4.1.3.1.0-x.x.x.vib update” ensuring that you are using the correct version VEM.
  • From the UCSM VM tab create any port-profiles required for the virtual machines assigning any appropriate network settings.

Make sure to read the readme.txt file in the bundle to match the version of VEM to use with the ESX/ESXi version and build number deployed.

  • Create Port Profiles
    • From the VM tab within UCSM right-click on “Port Profiles” in the left hand tree and create a new one.
    • Provide a descriptive name (Will not be visible in vCenter)
    • Choose which VLANs will be available.
  • Create Port Profile Clients
    • From the VM tab within UCSM right click on a Port Profiles you have created and choose “Create Profile Client”
    • Provide a descriptive name (Will be visible in vCenter)
    • Choose the Datacenter, Folder, and DVS you want it presented to.

Note: These profile clients are pushed to vCenter as port-groups and will be selectable within the VM NIC settings.

And the last step is to assign VMs to the DVS port-groups as required in vCenter.  See, it wasn’t that bad right? 

Cisco, ESX, ESXi, vCenter, VMware, vSphere, WWT , , , ,

Nexus 1000v Install via GUI

8 Comments Posted by on January 21, 2011

Deploying Cisco’s Nexus 1000v has gotten easier and easier as software updates have been released for it.  I remember when the 1000v first came out and the difficulties people had (including myself!).  One thing for sure is Cisco listens to their customers and partners, and works hard to correct pains as they can as quickly as they can.

I recently was working with a customer who wanted a detailed step-by-step guide on how to deploy the 1000v without the use of all the various Cisco docs.  The idea was a one-stop shop with screenshots outlining the install process.

I had not seen this before out and about so figured I’d share it with the public.  Before someone goes there, the below is not taken from their environment and all screenshots are from within WWT’s own lab environment.

There are a couple ways to perform the install based on your comfort level.  For this post, I’ll be utilizing the GUI method as it’s the simplest and quickest way to get up and running.  This wizard based install will guide you through performing base configurations and getting the 1000v talking to vCenter.  Once complete, you’ll be able to immediately start configuring port-profiles for VM use!

Let’s get started…

First, you need to understand the 1000v is installed by importing an OVF template.  To begin, head on over to Cisco and download the 1000v – Note you’ll need a CCO login to download it.  If you have not purchased licenses for the 1000v, good news!  There is a fully functioning 60 day trial so you can get it up and running to play with in your environment to see how it functions and works.   For this post, I’ll be using version 4.0(4)SV1(3b).

Once you have the file downloaded, let’s unzip and place it somewhere we can access it.  Now in, vCenter we’ll begin the process.

Note, the below is going to get very step-by-step as I had mentioned earlier, so if you’re comfortable deploying OVF template VM’s you can go ahead and skip ahead to the 1000v GUI install :)

We’ll begin by deploying an OVF Template.  This is done within vCenter.

Browse to the folder where you uncompressed the downloaded file.  You’re looking for the following file. -> ~\Nexus1000v.4.0.4.SV1.3b\Nexus1000v.4.0.4.SV1.3b\VSM\Install\nexus-1000v.4.0.4.SV1.3b.ova.

Once found, let’s click Next to continue.

The next screen should confirm that you’ll be installing the Nexus 1000v along with provide some version information.  Click Next to continue.

Standard ULA agreement.  If you agree, click Accept then Next to continue.

Remember, the 1000v is a virtual machine, so we’ll have to give it a name.  As you can see, I’ve appended an A.  The 1000v can be configured in two ways (HA and Standalone).  We’ll be installing a second 1000v later to create an HA pair so appending the A makes it easy to denote in vCenter which is which. Here is also where you can place the virtual machine into a specific folder if you so choose.  Once the name has been entered click Next to continue.

For the rest of this post I will refer to the first 1000v as “Node-A” and the second as “Node-B”

Since we’re utilizing the GUI for this 1000v deployment, you’ll want to ensure the Nexus 1000v Installer is chosen for the Configuration screen.  Click Next to continue.

Choose what datastore you’d like the 1000v to reside on and then click Next to continue.

The next screen we’ll supply some basic configuration items.  There will be more later don’t worry.  Each field here is required so ensure all items are filled out before clicking Next.

Confirm all information is correct and click Finish to begin the install.

Pretty easy huh?  Remember, since we’ll be configuring the 1000v in HA mode, we’ll need a second VM.  Simply walk through the above process again with the exception of a couple steps.

I’ve appended a B on the second 1000v.

Because this will be the second set of the HA pair, we won’t need to do much configuration of it (i.e. IP address, Subnet, Gateway, etc) so just choose Manually Configure Nexus 1000v and click Next to continue.

The rest of the process will be similar to the steps followed for when deploying the Node-A.  Finish going through the wizard and once complete we’ll continue.

Alright, so now what you should see in vCenter is two new virtual machines for the 1000v.  Let’s take a quick look at the properties of Node-A.

As you can see the OVF template deployment preset and built out the VM as required.  Nothing more should be required here.  We’ll want to of course make sure that the attached NICs are connected to a vSwitch port-group that will allow connectivity to the supplied IP address when building Node-A.

Let’s start Node-A and jump into the virtual machine console.

Once the virtual machine has completely booted up, you should see a login prompt.    What I would do at this point is simply ping that IP address from your local machine to ensure you have connectivity.  If you do not, go back and make sure your vnic to port-group mappings are correct.  Once confirmed, let’s open a browser and continue down the configuration process.

Open your browser and point to the IP address of Node-A.  Click on the link to launch the installer application.  A java based configuration GUI should appear.  It is this wizard where we’ll supply further configuration information and link the 1000v to vCenter.

Supply the password specified during the initial deployment and click Next to continue.

Here is where vCenter specific information must be supplied.  Enter in the IP address and Administrator account information to connect to vCenter.  It should be noted that this account is only utilized for the initial link and not required after the wizard is complete.

The 1000v has the capability to manage multiple clusters within a data center.  If you want to have the capability to manage all ESX hosts in a given data center, you should choose the highest level.  Click Next to continue.

Choose Node-A since that is what we’re configuring and now there are some items to discuss.

If you remember when we looked at the 1000v virtual machine properties, we saw three NICs.  Each NIC is utilized to carry traffic for a very specific function.

  • Control – This NIC is utilized to communicate with the VEM’s which reside on each ESX host.  VEM’s should be thought of as line cards in a catalyst switch.  They are dumb and hold no configuration capabilities.
  • Management – Should be obvious but this is where we connect to configure and manage the 1000v.
  • Packet – This is used for specific protocols such as CDP, LACP, and IGMP.

In earlier releases of the 1000v, it was generally recommended to provide a separate VLAN for each of these functions.  Cisco now states, all can reside on the same VLAN without problems however often times, customers will have a dedicated Management VLAN so running the Control and Packet interfaces over the same Management VLAN would not be allowed.  Depending on your environment we can choose the Default, which places all NICs on the same VLAN or port-group, or we can choose the Advanced option and manually specify what NIC connects to what port-group.  If a specific port-group does not yet exist, you can also create it here.

For this example, I have chosen the Default install method.  If this were to be in production, it would be my general recommendation to separate these functions out thus having a separate VLAN for Management and then one dedicated to Control and Packet.  Some will say Control and Packet should reside on separate VLANs however I have not seen any issues or problems keeping them on the same VLAN.

Here we’re configuring some additional information.  I’ve called out a few that we’ll want to pay attention to.

  • Switch Name – Since we’re configuring two switches here to be utilized in an HA pair I’ve taken the names we used when deploying the VM’s and dropped the appended A and B.
  • Domain ID – You can basically use anything you want here.  Domain ID’s are used to denote a logical grouping of devices which the HA pair will manage.  If later you were to deploy a new pair of 1000v’s, a different domain ID would be utilized.  Make note of what domain ID you use here as we’ll be utilizing it later on.
  • SVS Datacenter Name – Make sure the correct vCenter Datacenter name is displayed here.

When all info is supplied, click Next to continue.

Review all the settings and click Next to continue.

The configuration process should now commence and if you’re still consoled into Node-A, you’ll see it reboot a couple times as configurations are applied.

When the process completes, you should get this screen.  I’m not going to let this process join any hosts to the 1000v but you could do that if you wanted to here.  I’ve chosen No and clicked Finish to close out the wizard.

At this point, we now have one node of the HA pair deployed.  If we were not installing an HA pair, configuration of uplinks and port-groups could begin so ESX hosts can be joined to the 1000v.

Let’s take a look at vCenter and see what changed.  Going to the Networking screen we can see the new dVS created.

We’re almost done with the initial configuration.  The next couple things will go quickly.  We now need to tell Node-A he’s going to be in an HA pair since the default setup is to create a standalone switch.  Let’s console Node-A and set it up.

Note – It’s important that Node-B remain powered off during this process.  If you find Node-A rebooting on you without notice, check to ensure Node-B is powered off.

First let’s look at the redundancy status.  This will show you what mode (Standalone or HA) the switch is running in.  In the console issue the following command:

>WWTLab_1000v#show system redundancy status

We can see the current Redundancy role is standalone.

Let’s change that to HA by issuing the following.  We’ll save the config and then reload the switch to make the changes take affect.

>WWTLab_1000v#system redundancy role primary

>WWTLab_1000v#copy run start

>WWTLab_1000v#reload

After the switch has rebooted, log back in and check the redundancy status again.

>WWTLab_1000v#show system redundancy status

We should now show the Redundancy role as being Primary.  Great, now we have the first node in the HA pair.

We can’t have an HA pair without a secondary Node so let’s configure Node-B real quick.  Remember when we initially deployed Node-B we didn’t do any IP configuration or anything else right?  Let’s start Node-B and jump in the console to configure it.

Enter the same password you used for Node-A here.

This will be the secondary Node so type secondary.

Confirm that you’re wanting to change the role by typing Yes.

Remember that Domain ID thing?  Type in the same Domain ID as you used when configuring Node-A.

The switch will now go through an automated configuration process.  It is during this process where the cluster or HA pair is formed.  Node-B should reboot automatically to apply settings.

Let’s login to Node-B and take a look at the redundancy status.  First you’ll notice the (standby) trailing the switch name.  This tells you right away the HA pair was formed.  We can also see this by running the following command.

>WWTLab_1000v(standby)#show system redundancy status

Let’s jump back on Node-A and look at the redundancy status.  Notice it now shows the other supervisor (sup-2) and as being in Standby.

>WWTLab_1000v#show system redundancy status

Basic configuration of the 1000v HA pair is now complete including the linking to vCenter.  Quick and painless huh?!

Uplink Configurations…

For the next phase of the install we’re going to create one Uplink profile to be used to carry traffic outside of the 1000v.  This is used to carry VM traffic, IP storage, etc.  It should be noted that multiple uplinks can be specified to segregate traffic and is typically the case in a production environment.  In this example, I’m just creating one that will carry all traffic.  We’ll want to create this uplink prior to joining ESX hosts to the 1000v as we’ll later see it’ll ease the configuration of things.

Let’s start by SSH to the 1000v.  Since we have an HA pair, get in a habit of just SSH to the specified IP address.  You’ll be automatically connected to the active node.  As configuration changes occur, they are automatically replicated to the secondary node.

To create the Uplink Port-Profile, we’ll use the following.

>WWTLab_1000v#config t

>WWTLab_1000v(config)#port-profile type ethernet Uplink

>WWTLab_1000v(config-port-prof)# vmware port-group

>WWTLab_1000v(config-port-prof)# switchport mode trunk

>WWTLab_1000v(config-port-prof)# switchport trunk allowed vlan 70

>WWTLab_1000v(config-port-prof)# channel-group auto mode on mac-pinning

>WWTLab_1000v(config-port-prof)# system-vlan 70

>WWTLab_1000v(config-port-prof)# no shut

>WWTLab_1000v(config-port-prof)# state enabled

>WWTLab_1000v(config-port-prof)# copy run start

A couple things to call out in the above.

  • The type Ethernet denotes that we will be attaching physical NICs to this profile and to thus carry traffic north of the 1000v.
  • The channel-group auto mode on mac-pinning is to be utilized when attaching multiple NICs to the uplink.  There are posts out there going into detail on what this specifically does but quickly, this will tie a VM to one leg of the uplink in order to not create a loop.  It should be considered a must have and be utilized on all uplinks when multiple NICs are to be attached.
  • The system-vlan command is utilized for an interesting use.  Again, lots of posts out there on what exactly this should be used for but simply put, if the 1000v will be the only switch used in the virtual environment (i.e. no standard virtual switches) and/or traffic such as ESX management and IP storage routed through it, system VLANs should be specified for those VLANs carrying the following traffic:
    • ESX Management
    • IP based storage
    • Control and Packet

Alright, now that we have the Uplink setup, let’s join an ESX host to the 1000v…

Back in vCenter, lets go to the Networking configuration section.

Click on the Summary tab and click on Add Host.

As you can see, I’ve chosen an ESX host and a corresponding vmnic.  Make sure to choose the corresponding DVUplink port group.  You should see “Uplink” from when we created it earlier.

Click Next to continue.

Click Finish to join the host.

When complete and if successful, you should now see the host under the Hosts tab.  Continue the above process until all needed ESX hosts are joined successfully.

Conclusion…

If you’re still with me at this point, congratulations.  Cisco’s Nexus 1000v has been deployed in an HA pair, an Uplink to carry traffic has been specified, and we’ve joined an ESX host to the 1000v so we can start utilizing it.

With the addition of the GUI wizard and OVF Template import, deployment of the 1000v has been immensely simplified.  Gone are the days of manually configuring VM’s and installing the 1000v from an ISO.  Also, simplified is the connection process between vCenter and the 1000v.  All great enhancements to an already great product!

What’s to do next? Well, the creation of additional port-profiles to attach virtual machines or vmkernels would be a good place to head.  Once that is complete, you can then begin the migration of current virtual machines over to the 1000v along with vmkernels if you so choose.

Cisco, Nexus, VMware, vSphere, WWT , , , ,

My VCDX Journey

6 Comments Posted by on January 16, 2011

I’ve been tracking the VCDX for over a year now.  I am scheduled to defend my design at Partner Exchange 2011.  This will be my second attempt at the defense as my first attempt was at VMworld 2010 and I obviously did not pass.  I have not talked much about my first defense; mostly because publicly admitting I failed at something was not high on my to-do’s list.

VMworld 2010 was communicated as the last allowed attempt at the VCDX3 so when I received notice that I had not passed, I had a whole range of emotions from being angry to extremely disappointed in myself.  At the time, it was the first time I had failed at something in my career.  I remember having immediate thoughts that I would not attempt the VCDX again and as time went on, those thoughts turned into how I would change my design and what I would do differently if there were another chance.

When VMware announced there would be another chance to become a VCDX3 at PEX 2011, I’m not going to lie, I was a little excited.  You see I had thought I would be starting over from scratch going through the Enterprise Admin and Design exams all over again.  I think it was this news of one last chance at PEX that pushed me over the edge and so I began putting those design changes down on to paper.

Instead of making changes to my first design, I thought it would be best to start from scratch.  Trying to figure out what was wrong or what I missed wasn’t healthy for me nor was a good use of time, so it was out with the old and in with the new.  The process was more difficult the second round as I attempted to cover every little thing ensuring nothing was left out and that all things were covered.  As most have already communicated, the application is down right nasty and probably the most difficult part of the process (aside from standing in front of the panel).  I spent countless hours on it and attempted to apply whatever lessons I learned from the first attempt to it.  I used every bit of time allowed and submitted all required documents to VMware the day everything was due as I ferociously made fine tune adjustments.

On to the dreaded waiting game!

It seemed as though the waiting for this round was much longer than I had remembered the first time.  All documents were turned in right before Thanksgiving and it was only very recent that results were communicated.  As time went on I didn’t let things worry me too much as I hadn’t seen anyone tweet about getting their results (thank goodness for Twitter!).   Finally the day came when I got that email I had been waiting for.  I had done it a second time and was accepted to defend my design!

Some final thoughts…

As we get closer and closer to PEX 2011, I’m beginning to block out time to prepare.  I won’t go into every little detail I’m doing as it has been so well communicated by others and honestly, was not my purpose for this article.  It is funny though, I find myself reading all those same articles even though I read them 6 or so months ago!

Pass or fail, making it to the defense, let alone twice, has been a great success in my eyes.  My first attempt I looked at myself as a complete failure.  Stepping back and looking at that long road to the defense has shown me it was not a complete failure.  The actual process taught me so much about how to be a better Architect, how to better communicate and articulate myself, and I think most importantly, taught me a lot about myself personally.  I have also met a lot of great people through the process.  Individuals who like me have gone through the process and have both passed and failed.

So this second round when I walk out of that room, pass or fail, I know I’ll succeed in my eyes (at least a little bit) ;) One thing is for sure; Thursday, February 10th at about 3:00 I’ll be a better Architect…

 

VCDX, VMware, WWT ,

UCS Host Firmware Packages

5 Comments Posted by on January 12, 2011

I haven’t seen a lot of details surrounding the Host Firmware Packages within UCS and wanted to go through their use and setup.

First some background…

The UCS itself from a firmware management perspective is quite possibly the simplest set of hardware devices to update that I’ve utilized to date.  From one centralized management point you can upgrade and manage firmware within the entire UCS cluster – Fabric Interconnects, Physical Servers, Server Components, etc.  With new firmware comes new features, device support, etc. so having this centralized management is a HUGE benefit!

Like most things within the UCS stack, there are a number of policies that can be defined and applied to physical servers to accomplish things.  Sean McGee has a great post discussing all the items which can be controlled through UCS policies here.  I want to concentrate on just one of them here as we’re discussing firmware management – Hence the “Host Firmware Packages”.

Why do we need a Host Firmware Package and what’s it use?

Part of any firmware update within the UCS should also include the creation of a Host Firmware Package.  This package allows us to create a policy which ensures a specified firmware revision is applied to physical servers and their components.  It is typically created after the major components (Fabric Interconnects, UCSM, IOM’s, etc.) have all been updated and should correspond to the updated firmware version.  We’re capable of managing firmware on the following components residing in a physical server:

  • Network Adapters
  • Server BIOS
  • Board Controller
  • Fibre Channel Adapters
  • HBA ROM Packages
  • Storage Controllers

It should be noted that the above components cannot be updated without the use of a defined Host Firmware Package hence the importance of ensuring a corresponding package are defined each time a firmware update is done.

Lets Build One…

With UCSM 1.4, the creation of these packages became extremely easy to create (not that they were difficult before however the choosing of hardware was a little cryptic).  Below are the steps required to create a Host Firmware Package in UCSM 1.4.

We’ll start by navigating to where Host Firmware Packages are created under the Policies section of UCSM.

By right clicking on “Host Firmware Package” you’ll see an option to create a new package.  A new window will appear to walk you through the package creation process.

As seen in the above screenshot, there are six tabs where specific firmware packages can be chosen.

Walking through each tab, you’ll want to select the hardware you’re wanting to update making sure the firmware version is properly selected as well.

Note, because I choose the M81KR card under the first tab, I have not chosen any Fibre Channel Adapters.

Once your satisfied with all your selections, click OK and it will save and create the package as seen below.  Notice how you can quickly and easily go back in to change the firmware version if needed meaning you don’t have to recreate the package every time you update firmware.

Now that we have a Host Firmware Package created we have one last step to complete the process.  Within the Service Profile, there is a specific place to specify a Host Firmware Package to be applied to an associated server.  Below is where this is accomplished within a Service Profile.

Modifying an existing Service Profile, the specifying of Host Firmware Package is done under the Server Assignment section as seen below.  Simply choose the package we created above for Host firmware package and you’re complete.

Now when the blade server boots that has this profile associated with it, the new firmware will be automatically applied and the corresponding components updated.  Couldn’t be any easier!!!

Remember, this should be the standard practice whenever updating firmware within the UCS.  Components should always match the running version of the components north of the blades (i.e. Fabric Interconnects, UCSM, IOM’s, etc.).

Cisco ,

Windows 2003 and Cisco UCS

2 Comments Posted by on October 1, 2010

This past week I was deploying Windows 2003 Server 64bit onto a few blades within a Cisco UCS chassis and ran into a couple minor driver issues.  The main item I want to focus on with this post is that the required drivers to detect the local disk controllers within the Cisco blades are not included within Windows 2003 Server so installation can be problematic without the proper preparation.  I will be posting a second article on installing drivers for the Menlo adapter as it too proved challenging especially from an HBA level requiring some additional Microsoft hotfixes.  Something to call out right from the beginning is that the Palo adapter is NOT supported when utilizing Windows 2003 64bit version so if that’s what you’re looking to utilize, you better get some Menlo adapters! :)  I think as we see more of UCS being deployed it’s evident that the infrastructure is to not only be utilized for virtualization specific services.  Organizations obviously see the power and simplicity in what UCS has to offer and are looking beyond virtualization to serve specific IT needs (i.e Windows, Linux, etc).

On with getting Windows 2003 Server installed…

So to get around the lack of native support for the storage controllers, you basically have two options to get Windows installed – Pressing F6 during the install boot process to specify third party drivers or, slipstream the required drivers into the Windows media so hardware can be detected and installed automatically.  The first option I thought would be easiest as it had been a while since I had done any slipstreaming with Windows.  I went out to Cisco’s site to grab the UCS drivers which can be found here -Note: A valid Cisco login will be required.  Make sure to grab the drivers and not the utilities ISO.  The most recent version at the time of this writing was “ucs-b2xx-drivers-1.3.1e.iso”.

After downloading the driver ISO file, I extracted the drivers required for the specific blade I was installing onto.  The drivers are nicely organized within the ISO so you should be able to find them very easy.  To determine what storage controller is installed into your blade, you can always check the Inventory tab with in UCS Manager.

Cisco conveniently provides a floppy disk image included in the corresponding driver folder which is the required media type by Windows during this third party driver install.  Easy enough I thought…I quickly attached the floppy disk image within Virtual Media in UCS Manager, back in the KVM console I continue for the third party driver install and Windows fails to find the hardware.  After reconfirming I had the correct driver selected and ensuring media is mapped within Virtual Media, and it continuing to fail I decide to go down the slipstreaming route.

For those of you not familiar with slipstreaming, it is essentially a way to imbed third party drivers, security patches, service packs, etc. into Windows install media so that during the installation of the OS, the items added get automatically installed.  It does take a little prep work but I found this was the best (and the only for my situation) way to get Windows to successfully detect the storage controller within the blade.  One thing that is also great about this process is you can provide all the drivers (not just the storage controller) so after Windows is installed ALL components will be detected and have the proper driver installed.  So on with the slipstreaming process I used…

  1. To start out, you’ll need your Windows install media.  I had an ISO but the physical media will work as well.
  2. Go here to download and install nLite.  nLite is a great free utility that allows the modification of OS install media to allow things such as slipstreaming.  It also has a lot of other great feature sets that I would encourage you to explore.
  3. Once installed, launch nLite and click “Next” at the Welcome screen.
  4. Browse to your install media – If you have an ISO you’ll need to mount it.
  5. nLite will ask where to save the install files for modification.  Click OK and then browse to a location with enough disk space (1.2GB for Windows 2003).  If needed, you can create a new folder during this process.
  6. Once the folder is specified nLite will begin to copy the install files to the specified folder.
  7. When the copy finishes click OK to continue.  Notice how nLite detects the OS version.
  8. Click Next to continue at the next screen asking to import presets.
  9. At this screen this is where we’ll tell nLite we want to integrate additional drivers into Windows.  Make sure you select “Bootable ISO” so when finished we can use the ISO within Virtual Media to install Windows.
  10. It is in this next step where we will specify what drivers to integrate into Windows.  Click “Insert” and you’ll have two options – Single driver or Multiple drivers.  For this example we’ll just be integrating a single driver but you CAN do multiples if wanted such as HBA and NIC drivers, etc.  In my case I was using the 1040E LSI storage controller.  It’s important to choose TXT mode driver install over PNP otherwise Windows will not automatically detect and install the driver during the initial install process.
  11. When all drivers have been chosen, click Next to continue.
  12. Click “Yes” to begin the slipstreaming process of the drivers into the Windows install files.
  13. When finished processing, click Next to continue.
  14. The final step is to create the ISO.  Input a name you’d like as the Label and then click on “Make ISO” to indicate where you would like the ISO saved to and to start the ISO creation process.
  15. The process is complete when nLite indicates the ISO has been created successfully.

If you’ve made it this far the last step of the process is to mount the ISO you just created within Virtual Media in UCS Manager and boot the blade.  If done correctly, Windows 2003 should automatically detect the storage controller and proceed with the install.

I hope the above helps when there is a requirement for Windows within your UCS environment.  Any issues or questions feel free to leave some comments and I’ll be happy to help!  As mentioned in the beginning, I’ll be posting a second post on how to get the Menlo adapter up and running.

Cisco, WWT , ,

Stateless Desktops?

1 Comment Posted by on August 31, 2010

Sitting here in the VMworld keynote, I’m finally allowed to discuss a pet project our team has been working on for VMware around stateless desktops with View 4.5.    The Reference Architecture brief is released now, and the “full” reference architecture with full detail around the architecture will be out in the next month or so.

Stateless desktops are all about the use of local host-based solid-state drives, coupled with a consistent operating system image, to allow enhanced performance, linear scalability, and a reduction in cost.    It is important to realize that the OS, Application, and User data must be compartmentalized in order to use this design.   However, in our opinion this is the key to being able to use VDI in a truly flexible way.    It is how we design VDI.     Personally, I think the model will open many eyes to why NOT to use persistent images.   It simply isn’t efficient.   The costs show it!

What is really interesting about this design is many of the issues that require intense storage design to address simply vanish.   Boot storms, antivirus scans, login storms, worrying about the IOPS; all are at the least mitigated and at best are no more.    A foundation of simplicity perhaps?  For a highly scalable and manageable architecture, a level of simplicity is a requirement.   You can build two hosts or thousands, and this design can scale without much of a difference in the cost per user for core compute, software, storage, etc.

Last – and perhaps a bit of a teaser for the upcoming full RA – this type of design becomes a local SSD capacity discussion today.  It is the Achilles heal of the design, however easily mitigated today with multiple SSD’s.   With ever larger and faster SSD’s coming out in the market very soon, I don’t think this is a real limiting factor.   The scaling per-host is now potentially NOT about memory or CPU, which is a drastic change in what everyone typically discusses.   We are seeing the VM-per-core limited primarily based on how many we can smash on the drives, and especially with a host with 12 cores it gets quite interesting.

Storage, View (VDI), VMware, WWT

← Older posts

Follow

Get every new post delivered to your Inbox.