Great post describing placement policies within the UCS environment:
http://jeremywaldrop.wordpress.com/2010/08/26/cisco-ucs-vnicvhba-placement-policies/
Data center compute, storage and virtualization blog to share tips and tricks with the world.
Showing posts with label UCS Configuration. Show all posts
Showing posts with label UCS Configuration. Show all posts
9.14.2011
9.12.2011
ESXi Caches Old MAC address from UCS Service Profile
Per CSCte08176:
VMware's ESXi hypervisor caches the MAC address of it's physical NIC after it put's it in promiscuous mode. If the administrator subsequently changes the mac-address value defined in the associated service profile for that blade, the NIC will have a new MAC address, while the older MAC is not removed or updated from the ESXi hypervisor. This potentially leads to a MAC address conflict if the initial MAC address is re-assigned to a different blade (via service profile association).
One way to confirm this problem is by collecting "esxcfg-nics -l" and "esxcfg-vmknic -l", and comparing the mac-address output in both. The first one should correctly display the mac-address assigned in the service-profile while the second will display the cached mac-address.
VMware KB article: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1031111
As a workaround, administrators can do a "esxcfg-vmknic -d" to delete the virtual nic which is using the cached mac address. On recreation of that virtual nic it will have a VMW OUI MAC address.
VMware's ESXi hypervisor caches the MAC address of it's physical NIC after it put's it in promiscuous mode. If the administrator subsequently changes the mac-address value defined in the associated service profile for that blade, the NIC will have a new MAC address, while the older MAC is not removed or updated from the ESXi hypervisor. This potentially leads to a MAC address conflict if the initial MAC address is re-assigned to a different blade (via service profile association).
One way to confirm this problem is by collecting "esxcfg-nics -l" and "esxcfg-vmknic -l", and comparing the mac-address output in both. The first one should correctly display the mac-address assigned in the service-profile while the second will display the cached mac-address.
VMware KB article: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1031111
As a workaround, administrators can do a "esxcfg-vmknic -d" to delete the virtual nic which is using the cached mac address. On recreation of that virtual nic it will have a VMW OUI MAC address.
9.02.2011
SFTP Files off of FI
At first glance, it seems that in 1.4(3m), SFTP file transfers don't ask for a password from the FI to a remote server, but it does... just not after it asks for your username. SFTP transfers also now provide a sliding timeline so you can see the percentage of file transfer that has been completed.
UCS-B(local-mgmt)# copy workspace:/techsupport/20110828134224_UCS_UCSM.tar sftp:
Server name/IP: 14.0.25.91
Remote username: jen
Remote filepath: /ucsm.tar
jen@14.0.25.91's password:
Hello, I'm freeFTPd 1.0Connected to 14.0.25.91.
sftp> put /workspace/techsupport/20110828134224_UCS_UCSM.tar "/ucsm.tar"
Uploading /workspace/techsupport/20110828134224_UCS_UCSM.tar to /ucsm.tar
/workspace/techsupport/20110828134224_UCS 100% 14MB 1.4MB/s 00:10
sftp> quit
UCS-B(local-mgmt)#
UCS-B(local-mgmt)# copy workspace:/techsupport/20110828134224_UCS_UCSM.tar sftp:
Server name/IP: 14.0.25.91
Remote username: jen
Remote filepath: /ucsm.tar
jen@14.0.25.91's password:
Hello, I'm freeFTPd 1.0Connected to 14.0.25.91.
sftp> put /workspace/techsupport/20110828134224_UCS_UCSM.tar "/ucsm.tar"
Uploading /workspace/techsupport/20110828134224_UCS_UCSM.tar to /ucsm.tar
/workspace/techsupport/20110828134224_UCS 100% 14MB 1.4MB/s 00:10
sftp> quit
UCS-B(local-mgmt)#
8.30.2011
Serial over LAN Configuration on UCS Blades
Serial over LAN (SoL) is a mechanism that enables the input and output of the serial port of a managed system to be redirected via an SSH session over IP. SoL provides a means of reaching the host console via CIMC.
The SoL session will display line-oriented information such as boot messages, and character-oriented screen menus such as BIOS setup menus. If the server boots an operating system or application with a bitmap-oriented display, such as Windows, the SoL session will no longer display. If the server boots a command-line-oriented operating system (OS), such as Linux, you may need to perform additional configuration of the OS in order to properly display in an SoL session.
In the SoL session, your keystrokes are transmitted to the console except for the function key F2. To send an F2 to the console, press the Escape key, then press 2.
In order to configure SoL on your UCS blades, you would first need to create a Serial over LAN policy that enables the feature and provides you with the ability to set the baud rate:
Once this is complete, the policy can be applied to your blade's service profile. Applying this policy to your service profile will not require a blade reboot.
It is also recommended that an IPMI policy be assigned to the service profile as well.
Additionally, the BIOS of the blade needed to be configured in order to enable the serial interface for console redirection. This canbe done via a BIOS policy, or directly in the BIOS of the blade by going to Server Management -> Console Redirection. Ensure that the baud rate matches what was set inside of your SoL policy.
At this point, you can SSH into the IP of the KVM for the UCS blade. This is found under the Admin tab -> Communication Services -> Management IP Pool. The username and password that is used to log into the session should be the same as that, which was created previously in the IPMI profile. You should now be able to log into the console as a user other than root. Note: If you launch the SSH to CIMC for SoL, you will receive an error message if you are on a Mac:
In Windows XP, I received this same error message, but in order to resolve it, needed to associate my SSH client in UCSM under Options -> External Applications:
After this, I was able to successfully have an SSH session launches to the KVM IP of the specified blade:
Note: I made the following modifications to my RedHat host.
Added the following to /etc/inittab:
se:2345:respawn:/sbin/agetty 9600 ttyS0
Added the following to /etc/securetty:
ttyS0
The SoL session will display line-oriented information such as boot messages, and character-oriented screen menus such as BIOS setup menus. If the server boots an operating system or application with a bitmap-oriented display, such as Windows, the SoL session will no longer display. If the server boots a command-line-oriented operating system (OS), such as Linux, you may need to perform additional configuration of the OS in order to properly display in an SoL session.
In the SoL session, your keystrokes are transmitted to the console except for the function key F2. To send an F2 to the console, press the Escape key, then press 2.
In order to configure SoL on your UCS blades, you would first need to create a Serial over LAN policy that enables the feature and provides you with the ability to set the baud rate:
Once this is complete, the policy can be applied to your blade's service profile. Applying this policy to your service profile will not require a blade reboot.
It is also recommended that an IPMI policy be assigned to the service profile as well.
Additionally, the BIOS of the blade needed to be configured in order to enable the serial interface for console redirection. This canbe done via a BIOS policy, or directly in the BIOS of the blade by going to Server Management -> Console Redirection. Ensure that the baud rate matches what was set inside of your SoL policy.
At this point, you can SSH into the IP of the KVM for the UCS blade. This is found under the Admin tab -> Communication Services -> Management IP Pool. The username and password that is used to log into the session should be the same as that, which was created previously in the IPMI profile. You should now be able to log into the console as a user other than root. Note: If you launch the SSH to CIMC for SoL, you will receive an error message if you are on a Mac:
In Windows XP, I received this same error message, but in order to resolve it, needed to associate my SSH client in UCSM under Options -> External Applications:
After this, I was able to successfully have an SSH session launches to the KVM IP of the specified blade:
Note: I made the following modifications to my RedHat host.
Added the following to /etc/inittab:
se:2345:respawn:/sbin/agetty 9600 ttyS0
Added the following to /etc/securetty:
ttyS0
Subscribe to:
Posts (Atom)







