Hi Syed, Glad to help you here. Please find the below links which are useful for DC. CCIE Data Center CCIE Data Center Online Resources CCIE Data Center Reading List That is correct you could install the emulator directly on the machine. HTH Siva ... View more

Hi Walter, Could be the leap second bug looking at the version on UCS Regards, Siva ... View more

Hi, This is a an often asked question. What Service Profile modifications will cause a reboot? Answer: *Will cause a reboot:*   MAC address changes with Oplin/Menlo.     Port or Node WWN changes.     Adding (when capacity permits) or removing an interface.     Applying a new boot-from-SAN policy that has "reboot on boot order change" clicked.     Enabling failover for a vNIC that didn't have it enabled previously.     Changing host firmware pack that has pack-items different from running firmware versions on the associated server     Changing firmware host pack itself that is being used by service-profiles. Note that this could reboot all the servers using this pack.  *Changes that are harmless:*     Modifying the VLAN membership of a NIC     Changing a NIC's status from access port to trunk     Changing the VSAN membership of a vHBA     Applying an IPMI or SoL policy.     Modifying static pinning through pin-groups    Modifying an adapter policy Normally creating a service-profile should not require other server reboot, but if your  servers already have pending activities, changing the configuration would  require reboot for it to take effect. We have seen similar problem after adding a vlan to UCS domain and various  servers are requesting a reboot. This typically happens when there is an underlying change  that needs to take effect on the physical server, possibly a firmware update on a specific  component. Reference bug CSCub34427 A reboot of the server will prevent the message from occurring. You can also check your Maintenance policy on your service profile or template and make sure  that it is set to "User Ack" instead of "Immediate", so when you click "OK" , none of the servers would reboot immediately, all servers that require reboot would  be in the flashing pending activities. Then you can open the pending activities panel  reboot the servers one by one when they are ready. Regards, Siva ... View more

Hello Sebastian, Good question! Please refer install and upgrade guide for information for running UC apps on UCS To achieve good performance please make sure the drivers are updated as per HCL Find ESXi Version and RAID/NIC/HBA Driver Some servers may come with a RAID array configured from the factory.  Even if this is the case you should verify that the array settings match those specified in the Cisco Collaboration on virtualized servers document. Here are some very useful tips to achieve good raid performance on LSI RAID controllers on UCS What can cause a bad raid performance? One of the most common issues for a bad system performance is having the cache being disabled! " A cache is a temporary memory (storage area) where frequently accessed data can be stored for rapid acces. " The first thing to check is if the RAID Cache is ON, and enable it if it is not. * Some RAID controllers without a BATTERY BACKUP UNIT on board switch the cache OFF by default! * Some RAID controllers need to set more than just one single parameter in order to enable the cache. RAID controllers with LSI chipset have following options: Default Write Policy:        Write Through; Write Back Cache Policy:                    Cached; Direct Disk cache policy:            Enabled; Disabled Read Policy:                      Readahead; None; Adaptive In order to get the cache enabled, please go to RAID Controller BIOS and make sure following options are selected: Default Write Policy: Write Back Cache Policy: Cached Disk cache policy: Enabled Read Policy: Adaptive / In some cases Readahead can be better. Example:   Configure Sequential Access Patterns > Use sequential access patterns in the range of 64 KB to 1MB               > Use random access patterns in the range of 0.5 KB to 8 KB More Drives > To achieve maximum performance, connect enough drives to saturate the MegaRAID controller. Use Adaptive Read Policy >  This policy should be used for alll configurations and directs the controller to use read-ahead if the two most recent disk access ocurred in sequential sectors. If all read requets are random, the algorithm automatically changes to No Read Ahead while still evaluating all requests for possible sequential operation. LSI does not recommend using the Always Read Ahead policy.  Write Policy: Write-Through > With the Writte-through caching strategy, data is written to disk before a completion status is returned to the host operating system. This is considered more secure, because a power failure is less likely to cause undetected drive write data loss. Recommended option Write-through policy for RAID 0, RAID 1 and RAID 10 configurations with streaming or sequential data writes, because it can avoid copying data into a cache. Write Policy: Write-Back > With the Write-Back caching strategy, a completion status is sent to the host operating system as soon as data is written to the RAID cache. DATA is written to the disk when it is forced out of the controller cache memory. Write-back is more efficient in environments with "bursty" write activity. Using the Write-back policy to achieve optimum performance in RAID 0, RAID 1, and RAID 10 configurations with transactional (random real world) reads. Recommended using the Write-back policy to achieve optimum performance in all RAID 5 and RAID 6 configurations because it can improve the performance of data redundancy generation.  Cache Policy: Direct I/O recommended for all RAID level configurations. HTH Siva ... View more

Hi Walter, There are couple of bugs which I know could have caused the problem. We have several fixes went in the later release where these issues got resolved. HTH Siva ... View more

Hi Sarah, Thanks for your question. In UCS B environment, many components are described as many different type of virtual component such as vnic, vnmic,vif, vethernet, virtual circuit, border port, uplink port, server port, virtual cable, physical cable. It is not surprising that there can be confusion about what path packets are actually taking through the UCS infrastructure. However, knowing the full data path through the UCS infrastructure is very critical to understand where to troubleshoot. Users will often complain of high latency or dropped packets on their hosts/VM's. It can affect a single host or multiple hosts, depending on the traffic pattern. You should also understand and collect following information and it will also be helpful if you want assistance from Cisco TAC: If there are virtual systems involved in the tests on both sides, are these on UCS blades on both sites or just the one site? A topology for the tests you ran. Include and & all devices in the path from source to destination. The difference in behavior is likely going to involve different devices and/or paths.  Gather a UCSM show tech and upload it to your case. Check your QoS settings.  Were the ESX VIC enic drivers on your UCS ESX hosts ever updated as per cisco recommendations?      Interoperability matrix Have you looked for drops throughout the path from UCS source vNIC to egress UCS for any drops or Pauses? The commands would help you get there. The first step is to identify the affected blades. The following SAM CLI command provides complete path info for server NIC / vHBA show service-profile circuit server X/Y There are other commands which does not completely trace the path. connect nxos show pinning border-interfaces show pinning server-interfaces For example, in a Virtualised environment, we may see ping packet loss to VM's and also the Host vmk/management interfaces. We can then connect to the IOM in the chassis housing the affected blades: UCS-6296-A# connect iom 1 Attaching to FEX 1 ... fex-1# From the IOM, there are several useful commands. 1) Identify backplane (HIF) and Network Interfaces (NIF) experiencing packet loss: (Woodside for Gen2 IOM, Redwood for Gen1 IOM) fex-1# show platform software woodside loss fex-1# show platform software redwood loss This will show any/all interfaces that have loss or pause frames seen. From there, we wcan drill down to specific interfaces. Troubleshooting guide HTH Siva ... View more

Hi Srini, Thanks for your question. We have  cisco diagnosctic tool was designed as a multipurpose tool for troubleshooting, stress testing, and burning in new equipment before entering Cisco UCS Blade Server Diagnostics tool for Cisco UCS Blade Servers enables you to verify the health of the hardware components on your servers. The diagnostics tool provides a variety of tests to exercise and stress the various hardware subsystems on the Cisco UCS Blade Servers, such as memory and CPU. You can use the tool to run a sanity check on the state of your Cisco UCS Blade Servers after you fix or replace a hardware component. You can also use this tool to run comprehensive burn-in tests before you deploy a new Cisco UCS Blade Server in your production environment. UCS diagnostic tool There are other multiple 3rd party tools available too aid in performance testing, benchmarking and help with isolation of possible network, fabric, I/O performance issues. IOMeter is a common tool that I use, which is a free open  source tool  to test disk performance. Moreover, you can measure the I/O  transfer rate and the average I/O response time. IOMeter can be used  with Windows 2003 and 2008.   Another tool, IORate developed by EMC, which also helps measure performance.   One more tool - IPerf Iperf was developed by NLANR/DAST as a modern alternative for measuring  maximum TCP and UDP bandwidth performance. Iperf allows the tuning of  various parameters and UDP characteristics. Iperf reports bandwidth,  delay jitter, datagram loss.  As always we recommend try booting the blades up with a required OS and have it run test loads before migrating production workloads as secondary test. HTH Siva ... View more

Hi Walter, This is specific to 2104. When you have a chassis normally has 2 paths each via both IOM. If one goes down you have single path from that specific chassis to the outside network. HTH Siva ... View more

Hi Sasi, Thanks for your question. We have few bugs around HW failure on IOM's and replace sometimes to have new revised hardware version. I would be able to provide more information if you have the error code as this may be related to environmental or ASIC failure. CSCuc94895 2104 IOM reboots randomly with reset status register 0x00000000 HTH Siva ... View more

This is how you apply timeouts for http connections policy-map multi-match HTTP class HTTP connection advanced-options HTTP class-map match-any HTTP 2 match port tcp eq www parameter-map type connection HTTP set timeout inactivity 1200 Then apply this service-policy globally or in the interface from where the traffic is coming in ... View more

HI Kirk,   Thats right.    Regards, Siva     ... View more

Hello,   I dont think its available today. But we do have an enhancement filed to address this in the future.   https://tools.cisco.com/bugsearch/bug/CSCue92823/?referring_site=bugquickviewredir ... View more

Hi Kirk,   refer doc below for supported cards with UCSM   http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/c-series_integration/ucsm2-0-2/b_UCSM_202_C-Integration/b_UCSM_202_C-Integration_chapter_011.html   The following are the only supported card combinations for the servers to be used in UCSM mode.  Only Cisco Virtual Interface Cards (VICs) installed in the server. Do not mix with CNAs or Ethernet cards.  Only one type of CNA (Q or E) installed in the server. Do not mix with VICs or Ethernet adapters.  Only one type of Ethernet adapter (B or I) installed in the server. Do not mix with VICs or CNAs. - Siva ... View more

Hi, refer the KB article   http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2033751   see if that helps!   - Siva ... View more