CLI

You are currently browsing articles tagged CLI.

A Couple GeekTool Scripts

Monday, January 11, 2010 in Macintosh, UNIX by slowe | 2 comments

I’ve been experimenting with GeekTool, a nifty Mac OS X Preference Pane that allows you to display information on your desktop. This information can be static text, images, or the output of a script. The last option is the most useful one, in my opinion, and that’s where I’ve been putting GeekTool to use for me. This isn’t going to be some long post on how to use GeekTool or why you should install it; rather, I just wanted to share a couple of short scripts that I wrote that you might find useful.

I use Mac OS X’s network location support extensively. I have separate locations for home (where I have a proxy server) and when I’m out and about (where there generally is no proxy server). So it’s important for me to be able to tell, quickly, which location is active. If the wrong location is active, then network connectivity is impaired.

To help, I use this command with GeekTool to display the network location on my desktop:

echo "Location: `networksetup -getcurrentlocation 2>&1 | tail -n 1`"

Note that if you are running as an administrative user on your Mac (which I don’t in order to reduce potential security risks), then the networksetup command I use above will probably behave differently for you. Since I’m not running as an administrative user, networksetup would throw an error at the command line. Thus why I had to redirect STDERR to STDOUT and filter it using tail. Now, a quick F11 to show the desktop and I can immediately see which network location is active.

I also recently added a script to show me what proxy servers are currently active. This is in anticipation of starting my new job at EMC. I don’t know if they have proxy servers on their network, but in the event they do I thought this next command might be handy:

echo "HTTP Proxy: `scutil --proxy | grep HTTP | sort | sed -n '3,3p' | awk '{print $3}'`"

This command displays the HTTP proxy host configured in your network settings. So, again, a quick F11 allows me to see which proxy hosts are configured and active on my Mac.

I actually wrapped several of these commands together into a shell script that you can download here if you’d like. I’m sure there is probably some bash black magic that could produce this output in a more efficient way; feel free to post suggestions for improvement if you have any!

Of course, I also have a few other scripts running with GeekTool—one that displays system information, one that produces IP addresses and Airport (wireless LAN) information, etc.—but these two are probably most useful to me so far.

Tags: , ,

New User’s Guide to Managing Cisco MDS Zones via CLI

Tuesday, October 20, 2009 in Networking, Storage by slowe | 2 comments

Toward the end of August 2009, I posted an article on how to configure Cisco MDS zones via the command-line interface (CLI). This article is a follow-up to that article; in this post, I’ll review some commands that are helpful in managing those zones.

As with the first post, this post probably won’t be very helpful to users who are well-versed with the Cisco MDS family of Fibre Channel switches. Hence, why I’ve tagged it as a “new user’s” post. Similarly, I’m not going into the need for zones, as that is covered amply elsewhere.

First, I find it extremely handy to be able to rename Fibre Channel aliases using the fcalias rename command like this:

switch(config)# fcalias rename <old alias> <new alias> vsan XXX

You can also rename zones:

switch(config)# zone rename <old zone name> <new zone name> vsan XXX

And you can rename zonesets:

switch(config)# zoneset rename <old zoneset name> <new zoneset name> vsan XXX

In my earlier article I talked about the zoneset clone command, but you can also clone aliases and individual zones. I’m not yet convinced of the value of being able to clone an individual alias, and if you are using single initiator/single target zoning I’m not 100% sure how helpful it will be to clone a specific zone. Still, the functionality is there if you need it.

Adding a new alias, zone, or zoneset is similar to modifying an existing alias, zone, or zoneset. For example, to add a new alias to an existing zone, you would use these commands:

switch(config)# zone name existing-zone-name-here vsan XXX
switch(config-zone)# member fcalias new-alias-to-add
switch(config-zone)# exit

Likewise, adding a new zone to an existing zoneset is similar to defining a new zoneset:

switch(config)# zoneset name existing-zoneset-name vsan XXX
switch(config-zoneset)# member new-zone-to-add
switch(config-zoneset)# member another-new-zone
switch(config-zoneset)# exit

Managing zones via the CLI can be a bit daunting; as the number of aliases and zones increases, it becomes more difficult to work with all of them and find only the ones in which you are interested at the moment. Here, using the include keyword can be rather handy. Consider this command:

switch# show zone | include server-name
zone name server-name-storage vsan XXX
  fcalias name server-name vsan XXX
zone name server-name-storage2 vsan XXX
  fcalias name server-name vsan XXX

I’ve marked the matching text in bold, so that you can see that the include keywords acts like a bit like grep. This makes it much easier to filter out only the zones you want or need to see, instead of having to wade through all the currently defined zones. This is not an MDS-specific trick; it’s also applicable in IOS and NX-OS as well. And it works not only with zones, but also with zonesets, FC aliases, etc.

Cisco MDS experts, feel free to post additional suggestions on managing zones via the CLI in the comments below so that all readers can benefit. Thanks for reading!

Tags: , , , ,

New User’s Guide to Configuring VMware ESX Networking via CLI

Tuesday, June 23, 2009 in Gestalt, Networking, PASS, Virtualization by slowe | 12 comments

A lot of the content on this site is oriented toward VMware ESX/ESXi users who have a pretty fair amount of experience. As I was working with some customers today, though, I realized that there really isn’t much content on this site for new users. That’s about to change. As the first in a series of posts, here’s some new user information on creating vSwitches and port groups in VMware ESX using the command-line interface (CLI).

For new users who are seeking a thorough explanation of how VMware ESX networking functions, I’ll recommend a series of articles by Ken Cline titled The Great vSwitch Debate. Ken goes into a great level of detail. Go read that, then you can come back here.

Before I get started it’s important to understand that, for the most part, the information in this article applies only to VMware ESX. VMware ESXi doesn’t have a Linux-based Service Console like VMware ESX, and therefore doesn’t have a readily-accessible CLI from which to run these sorts of commands. There is a remote CLI available, which I’ll discuss in a future post, but for now I’ll focus only on VMware ESX.

The majority of all the networking configuration you will need to perform on VMware ESX boils down to just a couple commands:

  • esxcfg-vswitch: You will use this command to manipulate virtual switches (vSwitches) and port groups.
  • esxcfg-nics: You will use this command to view (and potentially manipulate) the physical network interface cards (NICs) in the VMware ESX host.

Configuring VMware ESX networking boils down to a couple basic tasks:

  1. Creating, configuring, and deleting vSwitches
  2. Creating, configuring, and deleting port groups

I’ll start with creating, configuring, and deleting vSwitches.

Creating, Configuring, and Deleting vSwitches

You’ll primarily use the esxcfg-vswitch command for the majority of these tasks. Unless I specifically indicate otherwise, all the commands, parameters, and arguments are case-sensitive.

To create a vSwitch, use this command:

esxcfg-vswitch -a <vSwitch Name>

To link a physical NIC to a vSwitch—which is necessary in order for the vSwitch to pass traffic onto the physical network or to receive traffic from the physical network—use this command:

esxcfg-vswitch -L <Physical NIC> <vSwitch Name>

In the event you don’t have information on the physical NICs, you can use this command to list the physical NICs:

esxcfg-nics -l (lowercase L)

Conversely, if you need to unlink (remove) a physical NIC from a vSwitch, use this command:

esxcfg-vswitch -U <Physical NIC> <vSwitch Name>

To change the Maximum Transmission Unit (MTU) size on a vSwitch, use this command:

esxcfg-vswitch -m <MTU size> <vSwitch Name>

To delete a vSwitch, use this command:

esxcfg-vswitch -d <vSwitch Name>

Creating, Configuring, and Deleting Port Groups

As with virtual switches, the esxcfg-vswitch is the command you will use to work with port groups. Once again, unless I specifically indicate otherwise, all the commands, parameters, and arguments are case-sensitive.

To create a port group, use this command:

esxcfg-vswitch -A <Port Group Name> <vSwitch Name>

To set the VLAN ID for a port group, use this command:

esxcfg-vswitch -v <VLAN ID> -p <Port Group Name> <vSwitch Name>

To delete a port group, use this command:

esxcfg-vswitch -D <Port Group Name> <vSwitch Name>

To view the current list of vSwitches, port groups, and uplinks, use this command:

esxcfg-vswitch -l (lowercase L)

There are more networking-related tasks that you can perform from the CLI, but for a new user these commands should handle the lion’s share of all the networking configuration. Good luck!

Tags: , , , ,

VMware vSphere vDS, VMkernel Ports, and Jumbo Frames

Thursday, May 21, 2009 in Gestalt, Networking, Storage, Virtualization by slowe | 41 comments

In April 2008, I wrote an article on how to use jumbo frames with VMware ESX and IP-based storage (NFS or iSCSI). It’s been a pretty popular post, ranking right up there with the ever-popular article on VMware ESX, NIC teaming, and VLAN trunks.

Since I started working with VMware vSphere (now officially available as of 5/21/2009), I have been evaluating how to replicate the same sort of setup using ESX/ESXi 4.0. For the most part, the configuration of VMkernel ports to use jumbo frames on ESX/ESXi 4.0 is much the same as with previous versions of ESX and ESXi, with one significant exception: the vNetwork Distributed Switch (vDS, what I’ll call a dvSwitch). After a fair amount of testing, I’m pleased to present some instructions on how to configure VMkernel ports for jumbo frames on a dvSwitch.

How I Tested

The lab configuration for this testing was pretty straightforward:

  • For the physical server hardware, I used a group of HP ProLiant DL385 G2 servers with dual-core AMD Opteron processors and a quad-port PCIe Intel Gigabit Ethernet NIC.
  • All the HP ProLiant DL385 G2 servers were running the GA builds of ESX 4.0, managed by a separate physical server running the GA build of vCenter Server.
  • The ESX servers participated in a DRS/HA cluster and a single dvSwitch. The dvSwitch was configured for 4 uplinks. All other settings on the dvSwitch were left at the defaults.
  • For the physical switch infrastructure, I used a Cisco Catalyst 3560G running Cisco IOS version 12.2(25)SEB4.
  • For the storage system, I used an older NetApp FAS940. The FAS940 was running Data ONTAP 7.2.4.

Keep in mind that these procedures or commands may be different in your environment, so plan accordingly.

Physical Network Configuration

Refer back to my first article on jumbo frames to review the Cisco IOS commands for configuring the physical switch to support jumbo frames. Once the physical switch is ready to support jumbo frames, you can proceed with configuring the virtual environment.

Virtual Network Configuration

The virtual network configuration consists of several steps. First, you must configure the dvSwitch to support jumbo frames by increasing the MTU. Second, you must create a distributed virtual port group (dvPort group) on the dvSwitch. Finally, you must create the VMkernel ports with the correct MTU. Each of these steps is explained in more detail below.

Setting the MTU on the dvSwitch

Setting the MTU on the dvSwitch is pretty straightforward:

  1. In the vSphere Client, navigate to the Networking inventory view (select View > Inventory > Networking from the menu).
  2. Right-click on the dvSwitch and select Edit Settings.
  3. From the Properties tab, select Advanced.
  4. Set the MTU to 9000.
  5. Click OK.

That’s it! Now, if only the rest of the process was this easy…

By the way, this same area is also where you can enable Cisco Discovery Protocol support for the dvSwitch, as I pointed out in this recent article.

Creating the dvPort Group

Like setting the MTU on the dvSwitch, this process is pretty straightforward and easily accomplished using the vSphere Client:

  1. In the vSphere Client, navigate to the Networking inventory view (select View > Inventory > Networking from the menu).
  2. Right-click on the dvSwitch and select New Port Group.
  3. Set the name of the new dvPort group.
  4. Set the number of ports for the new dvPort group.
  5. In the vast majority of instances, you’ll want to set VLAN Type to VLAN and then set the VLAN ID accordingly. (This is the same as setting the VLAN ID for a port group on a vSwitch.)
  6. Click Next.
  7. Click Finish.

See? I told you it was pretty straightforward. Now on to the final step which, unfortunately, won’t be quite so straightforward or easy.

Creating a VMkernel Port With Jumbo Frames

Now things get a bit more interesting. As of the GA code, the vSphere Client UI still does not expose an MTU setting for VMkernel ports, so we are still relegated to using the esxcfg-vswitch command (or the vicfg-vswitch command in the vSphere Management Assistant—or vMA—if you are using ESXi). The wrinkle comes in the fact that we want to create a VMkernel port attached to a dvPort ID, which is a bit more complicated than simply creating a VMkernel port attached to a local vSwitch.

Disclaimer: There may be an easier way than the process I describe here. If there is, please feel free to post it in the comments or shoot me an e-mail.

First, you’ll need to prepare yourself. Open the vSphere Client and navigate to the Hosts and Clusters inventory view. At the same time, open an SSH session to one of the hosts you’ll be configuring, and use “su -” to assume root privileges. (You’re not logging in remotely as root, are you?) If you are using ESXi, then obviously you’d want to open a session to your vMA and be prepared to run the commands there. I’ll assume you’re working with ESX.

This is a two-step process. You’ll need to repeat this process for each VMkernel port that you want to create with jumbo frame support.

Here are the steps to create a jumbo frames-enabled VMkernel port:

  1. Select the host and and go the Configuration tab.
  2. Select Networking and change the view to Distributed Virtual Switch.
  3. Click the Manage Virtual Adapters link.
  4. In the Manage Virtual Adapters dialog box, click the Add link.
  5. Select New Virtual Adapter, then click Next.
  6. Select VMkernel, then click Next.
  7. Select the appropriate port group, then click Next.
  8. Provide the appropriate IP addressing information and click Next when you are finished.
  9. Click Finish. This returns you to the Manage Virtual Adapters dialog box.

From this point on you’ll go the rest of the way from the command line. However, leave the Manage Virtual Adapters dialog box open and the vSphere Client running.

To finish the process from the command line:

  1. Type the following command (that’s a lowercase L) to show the current virtual switching configuration:
    esxcfg-vswitch -l
    At the bottom of the listing you will see the dvPort IDs listed. Make a note of the dvPort ID for the VMkernel port you just created using the vSphere Client. It will be a larger number, like 266 or 139.
  2. Delete the VMkernel port you just created:
    esxcfg-vmknic -d -s <dvSwitch Name> -v <dvPort ID>
  3. Recreate the VMkernel port and attach it to the very same dvPort ID:
    esxcfg-vmknic -a -i <IP addr> -n <Mask> -m 9000 -s <dvSwitch Name> -v <dvPort ID>
  4. Use the esxcfg-vswitch command again to verify that a new VMkernel port has been created and attached to the same dvPort ID as the original VMkernel port.

At this point, you can go back into the vSphere Client and enable the VMkernel port for VMotion or FT logging. I’ve tested jumbo frames using VMotion and everything is fine; I haven’t tested FT logging with jumbo frames as I don’t have FT-compatible CPUs. (Anyone care to donate some?)

As I mentioned in yesterday’s Twitter post, I haven’t conducted any objective performance tests yet, so don’t ask. I can say that NFS feels faster with jumbo frames than without, but that’s purely subjective.

Let me know if you have any questions or if anyone finds a faster or easier way to accomplish this task.

UPDATE: I’ve updated the comments to delete and recreate the VMkernel port per the comments below.

Tags: , , , , , , , , ,

Summary of CDP Articles

Monday, May 18, 2009 in Virtualization by slowe | 10 comments

For all you data storage guys and gals out there, CDP here means “Cisco Discovery Protocol”, not “Continuous Data Protection.” Sorry.

It seems that interest in VMware ESX’s support for CDP is gaining interest and attention; fellow blogger Rich Brambley of VM /ETC recently covered the topic as well.

To help summarize some of the content that I’ve generated around VMware ESX and CDP, here is a list of the articles available on this site:

  • Identifying ESX Server NICs in Blades – Although written for the blade server environment, the information presented in this article on how to use CDP to identify NICs works just as well for rack mount servers.
  • Next-Gen Stuff: Enabling CDP in ESX/ESXi – This article describes how to enable CDP on a standard vSwitch (on both VMware ESX and VMware ESXi) as well as on a vNetwork Distributed Switch (officially abbreviated as vDS but I like to call them a dvSwitch).
  • Viewing CDP Data on VMware ESX – Using the esxcfg-info command will actually show you the CDP data that’s been collected by VMware ESX. This command is different from the command that Rich showed; I think I like Rich’s command (also shared by wharlie in the comments to my article) better.

Enjoy!

Tags: , , , , ,

3010: A MultiStore Primer

Wednesday, April 8, 2009 in Storage, Virtualization by slowe | 16 comments

This session describes NetApp’s MultiStore functionality. MultiStore is the name given to NetApp’s functionality for secure logical partitioning of network and storage resources. The presenters for the session are Roger Weeks, TME with NetApp, and Scott Gelb with Insight Investments.

When using MultiStore, the basic building block is the vFiler. A vFiler is a logical construct within Data ONTAP that contains a lightweight instance of the Data ONTAP multi-protocol server. vFilers provide the ability to securely partition both storage resources and network resources. Storage resources are partitioned at either the FlexVol or Qtree level; it’s recommended to use FlexVols instead of Qtrees. (The presenters did not provide any further information beyond that recommendation. Do any readers have more information?) On the network side, the resources that can be logically partitioned are IP addresses, VLANs, VIFs, and IPspaces (logical routing tables).

Some reasons to use vFilers would include storage consolidation, seamless data migration, simple disaster recovery, or better workload management. MultiStore integrates with SnapMirror to provide some of the functionality needed for some of these use cases.

MultiStore uses vFiler0 to denote the physical hardware, and vFiler0 “owns” all the physical storage resources. You can create up to 64 vFiler instances, and active/active clustered configurations can support up to 130 vFiler instances (128 vFilers plus 2 vFiler0 instances) during a takeover scenario.

Each vFiler stores its configuration in a separate FlexVol (it’s own root vol, if you will). All the major protocols are supported within a vFiler context: NFS, CIFS, iSCSI, HTTP, and NDMP. Fibre Channel is not supported; you can only use Fibre Channel with vFiler0. This is due to the lack of NPIV support within Data ONTAP 7. (It’s theoretically possible, then, that if/when NetApp adds NPIV support to Data ONTAP that Fibre Channel would be supported within vFiler instances.)

Although it is possible to move resources between vFiler0 and a separate vFiler instance, doing so may impact client connections.

Managing vFilers appears to be the current weak spot; you can manage vFiler instances using the Data ONTAP CLI, but vFiler instances don’t have an interactive shell. Therefore, you have to direct commands to vFiler instances via SSH or RSH or using the vFiler context in vFiler0. You access the vFiler context by prepending the “vfiler” keyword to the commands at the CLI in vFiler0. Operations Manager 3.7 and Provisioning Manager can manage vFiler instances; FilerView can start, stop, or delete individual vFiler instances but cannot direct commands to an individual vFiler. If you need to manage CIFS on a vFiler instance, you can use the Computer Management MMC console to connect remotely to that vFiler instance to manage shares and share permissions, just as you can with vFiler0 (assuming CIFS is running within the vFiler, of course).

IPspaces are a logical routing construct that allow each vFiler to have its own routing table. For example, you may have a DMZ vFiler and an internal vFiler, each with their own, separate routing table. Up to 101 IPspaces are supported per controller. You can’t delete the default IPspace, as it’s the routing table for vFiler0. It is recommended to use VLANs and/or VIFs with IPspaces as a best practice.

One of the real advantages of using MultiStore and vFilers is the data migration and disaster recovery functionality that it enables when used in conjunction with SnapMirror. There are two sides to this:

  • “vfiler migrate” allows you to move an entire vFiler instance, including all data and configuration, from one physical storage system to another physical storage system. You can keep the same IP address or change the IP address. All other network identification remains the same: NetBIOS name, host name, etc., so the vFiler should look exactly the same across the network after the migration as it did before the migration.
  • “vfiler dr” is similar to “vfiler migrate” but uses SnapMirror to keep the source and target vFiler instances in sync with each other.

It makes sense, but you can’t use “vfiler dr” or “vfiler migrate” on vFiler0 (the physical storage system). My own personal thought regarding “vfiler dr”: what would this look like in a VMware environment using NFS? There could be some interesting possibilities there.

With regard to security, a Matasano security audit was performed and the results showed that there were no vulnerabilities that would allow “data leakage” between vFiler instances. This means that it’s OK to run a DMZ vFiler and an internal vFiler on the same physical system; the separation is strong enough.

Other points of interest:

  • Each vFiler adds about 400K of system memory, so keep that in mind when creating additional vFiler instances.
  • You can’t put more load on a MultiStore-enabled system than a non-MultiStore-enabled system. The ability to create logical vFilers doesn’t mean the physical storage system can suddenly handle more IOPS or more capacity.
  • You can use FlexShare on a MultiStore-enabled system to adjust priorities for the FlexVols assigned to various vFiler instances.
  • As of Data ONTAP 7.2, SnapMirror relationships created in a vFiler context are preserved during a “vfiler migrate” or “vfiler dr” operation.
  • More enhancements are planned for Data ONTAP 7.3, including deduplication support, SnapDrive 5.0 or higher support for iSCSI with vFiler instances, SnapVault additions, and SnapLock support.

Some of the potential use cases for MultiStore include file services consolidation (allows you to preserve file server identification onto separate vFiler instances), data migration, and disaster recovery. You might also use MultiStore if you needed support for multiple Active Directory domains with CIFS.

UPDATE: Apparently, my recollection of the presenters’ information was incorrect, and FTP is not a protocol supported with vFilers. I’ve updated the article accordingly.

Tags: , , , , , , , , , , , ,

HyTrust Launches Security Appliance

Monday, April 6, 2009 in Security, Virtualization by slowe | 4 comments

Today HyTrust launched its flagship product, the HyTrust Appliance, a security solution that is designed to centralize the control, management, and visibility for virtualized environments, in particular VMware Infrastructure environments. The HyTrust appliance achieves this through a number of key features:

  • The HyTrust Appliance provides integration with Active Directory or other LDAP-based directory services to enable centralized authentication. This allows organizations to leverage existing directory services for authentication, both for access via the VI Client or via SSH to the Service Console.
  • The HyTrust Appliance enables role-based access controls. These role-based access controls are defined in the appliance and permit organizations to control commands run in the Service Console as well as operations performed via the VI Client and vCenter Server.
  • The HyTrust Appliance provide secure logging and auditing functionality for all actions. Again, this logging occurs for every command and every action that is taken via any access method.

Since all traffic runs through the HyTrust Appliance, the solution has complete visibility and thus complete control over the traffic moving to or from the VMware ESX hosts. A number of different configurations are available for inserting the HyTrust Appliance into the flow of traffic, including using a different VLAN for ESX management traffic as well as a proxied configuration. The HyTrust Appliance can also ensure that the hosts it is protecting are configured to only accept traffic from the HyTrust Appliance itself, thus further ensuring that all access and actions are seen, controlled, and recorded.

The HyTrust Appliance will be available as both a hardware appliance as well as a virtual appliance. HyTrust also plans to make available a Community Edition at no charge; the Community Edition will support up to 3 VMware ESX hosts.

For more information, visit the HyTrust web site.

Tags: , , , ,

Storage Alignment Document

Tuesday, March 31, 2009 in Storage, Virtualization by slowe | 16 comments

NetApp has recently released TR-3747, Best Practices for File System Alignment in Virtual Environments. This document addresses the situations in which file system alignment is necessary in environments running VMware ESX/ESXi, Microsoft Hyper-V, and Citrix XenServer. The authors are Abhinav Joshi (he delivered the Hyper-V deep dive at Insight last year), Eric Forgette (wrote the Rapid Cloning Utility, I believe), and Peter Learmonth (a well-recognized name from the Toasters mailing list), so you know there’s quite a bit of knowledge and experience baked into this document.

There are a couple of nice tidbits of information in here. For example, I liked the information on using fdisk to set the alignment of a guest VMDK from the ESX Service Console; that’s a pretty handy trick! I also thought the tables which described the different levels at which misalignment could occur were quite useful. (To be honest, though, it took me a couple of times reading through that section to understand what information the authors were trying to deliver.)

Anyway, if you’re looking for more information on storage alignment, the different levels at which it may occur, and the methods used to fix it at each of these levels, this is an excellent resource that I strongly recommend reading. Does anyone have any pointers to similar documents from other storage vendors?

Tags: , , , , , , , , , ,

Next-Gen Stuff: Verifying the SHA-1 Fingerprint

Wednesday, March 25, 2009 in Security, Virtualization by slowe | 20 comments

This post is not necessarily specific to next-generation ESX/ESXi and vCenter Server, but it was prompted by behaviors in these products. (Besides, the truth is that I’m really just trying to be sensationalist and capitalize on interest in the next-generation products.)

When you add an ESX/ESXi host to vCenter Server in the next generation of products, you will receive a security warning that displays the SHA1 thumbprint (or fingerprint) of the ESX/ESXi host’s default SSL certificate. The fact that the dialog box displays the SHA1 fingerprint got me to thinking—how does one go about verifying the SHA1 fingerprint to ensure that the host to which you are connecting is really the host you think it is? I mean, that’s the idea behind displaying the fingerprint, isn’t it? Paranoid people will then go to the specific host in question, generate the fingerprint on the SSL certificate, and then compare the two fingerprints to make sure they are identical.

I haven’t figured out a way to do this for ESXi yet, but for ESX you can verify the SHA1 fingerprint of the SSL certificate using this command:

openssl x509 -sha1 -in /etc/vmware/ssl/rui.crt -noout
-fingerprint

This should all be on a single line; I’ve wrapped it here for readability. The command will then display the SHA1 fingerprint on the SSL certificate, which you can compare to the fingerprint displayed in the vCenter Server dialog box to ensure that the two values match. (If you’re really paranoid, you’ll run this command at the server’s physical console and not remotely. Unless, of course, you took the time to actually verify the SSH key fingerprints when you first connected via SSH, but that’s an entirely different post.)

So, here’s the real question: how does one verify the SHA1 fingerprint for an ESXi host? The ideal solution should not require the use of any unsupported hacks. (And yes, I know that you can view the SSL certificate, and thus the SHA1 fingerprint, by connecting to the ESXi host remotely using a web browser. But you still don’t know for sure that the host to which you connected is the host you thought it was, do you?)

UPDATE: At the ESXi console, logging in and selecting the “View Support Information” menu item will display the SSL fingerprint. Challenge solved!

Tags: , , , , , , ,

Viewing CDP Data on VMware ESX

Tuesday, March 24, 2009 in Networking, Virtualization by slowe | 9 comments

A couple of weeks ago I wrote about enabling Cisco Discovery Protocol (CDP) on next-gen ESX/ESXi and made the comment that I hadn’t yet found a way to view CDP data from the ESX side. One of the great things about writing a blog is that insightful and knowledgeable readers share some great information with you, and you learn a lot! That’s the situation here.

Viewing CDP data from the Cisco switch is easy. From the switch’s command prompt, use this command:

show cdp neighbors

This will display the CDP information that the switch has gathered. When CDP is enabled on ESX/ESXi, that will include information on which VMnics are attached to which switch ports.

From the ESX side, you can use this command:

esxcfg-info | more +/CDP\ Summary

This searches for the string “CDP Summary” in the output of the esxcfg-info command. The output from that command will include information about the switch to which the ESX host is connected, the ports to which the NICs are connected, and associated VLANs. The screenshot below shows some of the output from this command.

esxcfg-info-cdp.png

Thanks go to reader Larry for the information on this command. Other readers, feel free to continue to share information here. It is helpful!

Tags: , , , , ,

« Older entries § Newer entries »