Archives For January 2011

What I like the most of PowerCLI is the power that gives you, instead of relaying on a GUI every second you just issue a couple of commands and everything gets done. Of course thin provisioning is no exception to this and following is the way to convert from thin to thick a VM hard disk and vice versa.

The first task is to get the type of the hard disks. You can use the vSphere Client to check the format of the disk, just edit the VM setting and go the the hard disk as shown in the screenshot below.

However using the vSphere Client is slow since you can only check one VM at a time, fortunately for us PowerCLI can offer a clean and elegant way to retrieve type for every disk of every virtual machine.

Next we are going to convert from thin to thick the hard disk of the debian-vm1 virtual machine. To do so we are going to use the cmdlet Set-HardDisk.

Now that the disk is converted, how can we revert it using only PowerCLI? The way to do it is to move the disk to another datastore and convert it during the process.

The cmdlet to use is again Set-HardDisk with the -Datastore and -StorageFormat options. Take into account that these options can only be used if you are connected to the vCenter Server, you can’t do this when directly connected to the ESX(i) server.

Any other methods to execute the same operation are always welcome so please comment :-)

Juanma.

Today I was performing a test in the vSphere cluster I have in my laptop and when I tried to connect to the vCenter Server with PowerCLI I got the following error.

C:\Users\juanma
[vSphere PowerCLI] % get-vc vcenter.mlab.local -user Administrator -Password vmwarerules!
Connect-VIServer : 24/01/2011 12:58:33    Connect-VIServer        Could not connect using the requested protocol.   
At line:1 char:7
+ get-vc <<<<  vcenter.mlab.local -user Administrator -Password J3d1kn1gh/
 + CategoryInfo          : ObjectNotFound: (:) [Connect-VIServer], ViServerConnectionException
 + FullyQualifiedErrorId : Client20_ConnectivityServiceImpl_Reconnect_ProtocolError,VMware.VimAutomation.ViCore.Cmdlets.Commands.ConnectVIServer

C:\Users\juanma
[vSphere PowerCLI] %

My first thought after that was to check network connectivity and the firewall configuration of the vCenter Server but everything was OK. Then after a quick search in the VMware Communities I found the solution in this post.

The problem was the proxy server configuration of PowerCLI, I’m used to do everything directly from the vCenter desktop, where I have installed PowerCLI and the vSphere Client, but this time I tried to connect directly from my laptop and since I was connected to the corporate network PowerCLI was trying to connect through the proxy server. Following is how I fixed this thanks to the above VMTN post.

First retrieve the PowerCLI proxy configuration with the Get-PowerCLIConfiguration cmdlet.

C:\Users\juanma
[vSphere PowerCLI] % Get-PowerCLIConfiguration

Proxy Policy    Default Server
                Mode          
------------    ---------------
UseSystemProxy  Multiple       

C:\Users\juanma
[vSphere PowerCLI] %

As you can see Proxy Policy is set to UseSystemProxy. To set this value to NoProxy use the cmdlet Set-PowerCLIConfiguration.

C:\Users\juanma
[vSphere PowerCLI] % Set-PowerCLIConfiguration -ProxyPolicy NoProxy

Perform operation?
Performing operation 'Update vSphere PowerCLI configuration.'?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y

Proxy Policy    Default Server
                Mode          
------------    ---------------
NoProxy         Multiple       

C:\Users\juanma
[vSphere PowerCLI] %

Now try to reconnect to the vCenter Server and everything should go without errors.

C:\Users\juanma
[vSphere PowerCLI] % get-vc vcenter.mlab.local -user Administrator -Password vmwarerules!
WARNING: There were one or more problems with the server certificate:

* The X509 chain could not be built up to the root certificate.

* The certificate's CN name does not match the passed value.

Name                                           Port                                        User                                        
----                                           ----                                        ----                                        
vcenter.mlab.local                             443                                         Administrator                                

C:\Users\juanma
[vSphere PowerCLI] %

Juanma.

Long time since my last post about HP Integrity Virtual Machines, well you know I’ve been very occupied with vSphere and Linux but that doesn’t mean that I completely eliminate HP-UX from my life, on the contrary… HP-UX ROCKS! :-D

This is just a quick post on how to map a specific port of virtual switch to a specific VLAN. First retrieve the configuration of the vswitch.

[root@hpvmhost] ~ # hpvmnet -S devlan12
Name     Number State   Mode      NamePPA  MAC Address    IP Address
======== ====== ======= ========= ======== ============== ===============
devlan12      3 Up      Shared    lan4     0x000cfc0046b9 10.1.1.99    

[Port Configuration Details]
Port    Port         Port     Untagged Number of    Active VM
Number  State        Adaptor  VLANID   Reserved VMs
======= ============ ======== ======== ============ ============
1       Active       lan      none     1            oradev01
2       Active       lan      none     1            oradev02
3       Active       lan      none     1            oradev03
4       Active       lan      none     1            oradev04
5       Active       lan      none     1            nfstest01
6       Active       lan      none     1            linuxvm1
7       Active       lan      none     1            linuxvm2 

[root@hpvmhost] ~ #

We are going to map the port 5 to the VLAN 120 in order to isolate the traffic of that NFS server from the other virtual machines that aren’t on the same VLAN. Again the command to use is hpmvnet.

[root@hpvmhost] ~ # hpvmnet -S devlan12 -u portid:5:vlanid:120

If you display again the HPVM network configuration for the devlan12 vswitch the change will appear under the Untagged VLANID column.

[root@hpvmhost] ~ # hpvmnet -S devlan12
Name     Number State   Mode      NamePPA  MAC Address    IP Address
======== ====== ======= ========= ======== ============== ===============
devlan12      3 Up      Shared    lan4     0x000cfc0046b9 10.1.1.99    

[Port Configuration Details]
Port    Port         Port     Untagged Number of    Active VM
Number  State        Adaptor  VLANID   Reserved VMs
======= ============ ======== ======== ============ ============
1       Active       lan      none     1            oradev01
2       Active       lan      none     1            oradev02
3       Active       lan      none     1            oradev03
4       Active       lan      none     1            oradev04
5       Active       lan      120      1            nfstest01
6       Active       lan      none     1            linuxvm1
7       Active       lan      none     1            linuxvm2 

[root@hpvmhost] ~ #

Juanma.

This is the fourth and last part of this series of posts about Virtual Connect, the first three were:

In this final post I will discuss Server Profiles, what are they and how to create. As in the rest of the series I’m using Virtual Connect 3.10.

So, what is a Server Profile? We can define a Virtual Connect server profile as a logical grouping of attributes related to server connectivity that can be assigned to a server blade. You can see it as the connectivity personality of the server.

The server profile includes:

  • MAC address.
  • Preboot Execution Environment (PXE) enablement.
  • Network connection setting for each NIC port and WWN.
  • SAN fabric connection.
  • SAN boot paramenter setting for each Fibre Channel HBA port.

Once the server profile is created you can apply it to any server within the VC Domain. There is a maximum of 64 fully populated VC Server Profiles in a VC Domain.

As we saw in the network and storage posts the VCM can be configured so that blade servers use their factory-default MACs/WWNs and serial numbers or Virtual Connect provided and administered ranges of MACs and WWNs. These MACs and WWNs will override the default MAC and WWN values when a server profile is applied to the server and appear to preboot environments and host operating systems as the hardware addresses.

When a server profile is assigned to a Device Bay the Virtual Connect Manager securely connects to the blade in the bay and configures the NIC ports with profile provided MAC addresses and PXE settings and the FC HBA ports with the appropriate WWNs and SAN boot settings. Additionally the VCM automatically connects the server to the specified networks and SAN fabrics.

This server profile can then be copied or reassigned to another server as needed without interrupting the server connectivity to the network and SAN.

Once a blade server has been assigned a server profile and as long as it remains in the same device it does not require further VC Manager configuration during server or enclosure power cycle. They boot and access the network and fabric as long as soon as the server and interconnect modules are ready. If a server is inserted into a device bay that has already been assigned a server profile VCM automatically updates the configuration of that server before it is allowed to power on and connect to the network.

If a blade server is moved from a Virtual Connect managed enclosure to a non VC managed one all the ports automatically returns to their original factory values and settings in order to prevent duplicate MAC and WWNs within the datacenter because a blade server redeployment.

In addition to the above information the following points must be considered when working with server profiles:

  • Blade server and card firmware revision must be at a revision that supports Virtual Connect profile assignment.
  • Before creating the first server profile select whether to use Virtual Connect administered MAC and WWN ranges or the local factory default values.
  • After an enclosure is imported into a VC Domain the blades will remain isolated from networks and SAN fabrics until a server profile is assigned.
  • When Virtual Connect administered MACs and/or WWNs or when changing Fibre Channel boot parameters the servers must be powered off in order to receive or relinquish a server profile.
  • Fibre Channel SAN connections will display in the profile server screen only if the VC-FC module in the enclosure managed by Virtual Connect. If there is no VC-FC module the FC option wouldn’t appear in the server profile screen until a module has been added.
  • Some server profile SAN boor settings, like the controller boot order, are applied only after the server has been booted with the final mezzanine card configuration.
  • If PXE or SAN boot settings are made outside of Virtual Connect, the settings defined by the server profile will be restored after the blade server completes the next boot cycle.

If you have worked in the past with the 2.x Virtual Connect Manager revisions I’m sure that you will remember the Server Profile Wizard. That wizard has been removed from the  3.x revisions of VCM.

To start the server profile creation you have now to go to the Virtual Connect Home and in the Server area click on Define Server Profile.

In the Define Server Profile screen first enter the name of the profile, ESX01 in the example, and choose if you want to use factory default MAC and WWN or the VC-predefined.

Then move to Ethernet Network Connections. Here you can select the networks to assign to the ports, the port speed between AUTO, PREFERRED and CUSTOM and the PXE settings (ENABLED, DISABLED or USE-BIOS). By default there are only two connections created, to add more connections just right-click the area and choose Add connection.

In Network Name if you choose Multiple Networks a new icon will appear that will allow you to edit this connection type. Click and a new section will show up, this section allows to select the Shared Uplink Set and the networks. There is also a checkbox to set if you want to force the same VLAN mappings as the Shared Uplink Set to the different networks.

The next area is the FC SAN Connections. Assign the modules in the bays to the correspondent fabric and set the port speed.

Also in this section you can define the SAN boot parameters, click on the checkbox, the page will dim and a pop-up will appear.There you can configure each FC connection as PRIMARY, SECONDARY, DISABLED or USE-BIOS and set the Target Port Name and the LUN.

Finally we can assign the profile to a server bay.

Click Apply and the new server profile will be done. You can always edit the existent server profiles from the Server Profiles screen in the VC administration interface.

And this is the end. This series is done, if you have follow the correct steps outlined in the four posts you will have a fully operation Virtual Connect Domain. Of course there are a some topics I’d like to write about like iSCSI, FlexFabric and the VCM command line but I believe it’s better to do it in their own dedicated posts, stay tuned :-)

Juanma.

Welcome to the third post of the Virtual Connect series!

The first two posts were about initial VC Domain creation and the Network setup. In this one I’ll explain the storage configuration of the Domain using the Fibre Channel Setup Wizard.

Please take into account that iSCSI is supported with Virtual Connect since the version 3.10 of Virtual Connect Manager and only with the Flex-10 and FlexFabric modules. However I’m going to leave iSCSI configuration for a future post, since I didn’t have many opportunities to try it with VC, and write only about Fibre Channel.

Before we start with the wizard and all the setup task is important to explain the Virtual Connect storage fundamentals.

The first concept to understand are the several key Fibre Channel port types. There a three basic FC ports:

  • N_Port (Node Port) – An N_Port  is a port within a node that provides Fibre Channel attachment like an HBA port. VC-FC module uplink ports are N_ports.
  • F_Port (Fabric Port) – This a port on a FC switch connected to an N_port and addressable by it. These are commonly used in Edge or Core switches. The VC-FC module’s downlink ports are F_ports in order to allow the HBAs to login into them.
  • E_Port (Expansion Port) – These are switch ports used for switch-to-switch connections known as Inter Switch Link or ISL.

Additionally there are two other ports, however these ports are not typically seen in Virtual Connect environments.

  • NL_Port (Node Loop Port) – An N_port capable of Arbitrated Loop function.
  • FL_Port (Fabric Loop Port) – An F_port capable of Arbitrated Loop function.

The next key concept to understand in N_Port ID Virtualization or NPIV. It’s a T11 FC standard than can be defined as a Fibre Channel facility that allows to assign multiple N_Port_IDs to a single N_Port, this is a physical N_port having multiple port WWNs. Of course the VC-FC module must be connected to a Fibre Channel switch that supports NPIV.

And how manages Virtual Connect all this port stuff? I believe that an image is worth a thousand words, so first I will show with the below diagrams illustrate how FC ports and SAN are managed with and without Virtual Connect.

As it can be seen the SAN switches, like the Cisco MDS 9124e,  that can be used in any blade enclosure including the HP ones are part of the SAN Fabric, that means the enclosure itself is part of the Fabric. These switches are connected to the SAN Core via E_ports or ISL.

In this configuration the SAN boundary has been moved out of the enclosure. The VC-FC module includes an HBA Aggregator which is an NPIV device. It passes, transparently, the signals from multiple HBAs to a single switch port.

Here it is how the whole process would go:

  1. VC-FC module uplink port issue a Login Request, an FLOGI to the SAN and advertize itself as NPIV capable port.
  2. Upon receiving an ACCept from the Fabric it would begin to process server requests.
  3. Server HBAs would begin normal Fabric login process with the WWNs.
  4. VC-FC module would translate FLOGI requests into an FDISC requests since a single N_Port can only receive one FLOGI request.
  5. SAN switch would reply with an ACCept and provide HBAs with Fabric addresses.
  6. The ACCept frames would reach uninterrupted the HBAs.
  7. From then on all the traffic will be carried over the sane link for all HBA connections.

Now the the basic concepts are explained and, hopefully clear, it’s time to configure the storage.

We are going to use the Fibre Channel Setup Wizard to:

  • Identify the World Wide Names (WWNs) to be used by the servers.
  • Define the available SAN fabrics.

You can launch the wizard either from the Tools menu in the Virtual Connect page or right after finishing the Network Setup Wizard. From the welcome screen click Next and move into the World Wide Name (WWN) Settings page.

In this first page you can specify if you want to use the WWN settings that comes with the Fiber Channel HBA card or if the HP Virtual Connect supplied WWN settings.

Virtual Connect will assign both a port WWN and a node WWN to a Fibre Channel port, the node WWN will always be the same as the port WWN incremented by one.

There is key advantage when configuring Virtual Connect to assign the WWNs and is that, since it maintains a consistent storage identity, it allows blades to be replaced in case of failure without affecting the external SAN.

In the wizard select Virtual Connect assigned WWNs and click Next to move into the Assigned WWNs screen.

This screen is very similar to the MAC address range selection screen we saw in the previous post. Here you have to choose between an user defined WWNs range and an HP defined one. You must ensure that the selected range is unique within the environment.

Next we are going to define the Fabric, first you’ll be presented with a screen asking if you want to define the fabric.

After that we have to enter the Fabric name, assign the uplink ports and configure the speed.

After applying the configuration the wizard will move to the next screen where it will ask if you want to create more Fabric, for the example purposes I decided to create a another one named fabric_prod2.

When you are done with the second fabric finish the wizard and the storage setup will be done. You can review and modify the configuration from the Virtual Connect main interface.

The next post will be the last of the series and I will discuss about Virtual Connect Server Profiles. As always any feedback would be welcome :-)

Juanma.