Cisco Cisco Unified MeetingPlace 7.0 Guida Alla Risoluzione Dei Problemi
The information in this document was created from the devices in a specific lab environment. All of the
devices used in this document started with a cleared (default) configuration. If your network is live, make sure
that you understand the potential impact of any command.
devices used in this document started with a cleared (default) configuration. If your network is live, make sure
that you understand the potential impact of any command.
Conventions
Refer to Cisco Technical Tips Conventions for more information on document conventions.
Co-residency and “Quality of Service”
A key principal of both network convergence and virtualization is the sharing of hardware resources.
A converged IP network shares network hardware among multiple traffic streams (voice, video,
storage access, other data).
storage access, other data).
•
A virtualized server (or virtualization host) shares compute, storage and network hardware among
multiple application virtual machines (VMs).
multiple application virtual machines (VMs).
•
In both cases, quality of service is required to protect UC from non-UC applications when hardware resources
are finite, as such:
are finite, as such:
QoS in routing and switching network hardware to ensure voice/video network traffic gets the needed
bandwidth and protection from delay and jitter.
bandwidth and protection from delay and jitter.
•
Adherence to UC virtualization rules (e.g. physical/virtual hardware sizing, co-residency policy, etc.)
to ensure UC VMs get the needed CPU, memory, storage capacity and storage/network performance.
to ensure UC VMs get the needed CPU, memory, storage capacity and storage/network performance.
•
It is impossible for Cisco to test every combination of hardware and application for VM co-residency,
particularly for 3rd party app VMs whose behavior may be unpredictable or not clearly defined. Therefore,
Cisco only guarantees Cisco UC app VM performance when installed on a UCS Tested Reference
Configuration (see http://docwiki.cisco.com/wiki/Tested_Reference_Configurations_%28TRC%29) and then
only when all conditions in the co-residency policy are followed (see
http://docwiki.cisco.com/w/index.php?title=Unified_Communications_Virtualization_Sizing_Guidelines).
particularly for 3rd party app VMs whose behavior may be unpredictable or not clearly defined. Therefore,
Cisco only guarantees Cisco UC app VM performance when installed on a UCS Tested Reference
Configuration (see http://docwiki.cisco.com/wiki/Tested_Reference_Configurations_%28TRC%29) and then
only when all conditions in the co-residency policy are followed (see
http://docwiki.cisco.com/w/index.php?title=Unified_Communications_Virtualization_Sizing_Guidelines).
For other environments, uncertainty can be reduced by pre-deployment testing, baselining, following general
principles of virtualization, and following the rules of Cisco UC virtualization (at
http://www.cisco.com/go/uc-virtualized). However, Cisco cannot guarantee that VMs will never be starved
for resources and never have performance problems.
principles of virtualization, and following the rules of Cisco UC virtualization (at
http://www.cisco.com/go/uc-virtualized). However, Cisco cannot guarantee that VMs will never be starved
for resources and never have performance problems.
Key Support Considerations for Non-UC and 3rd party Virtual Machines
To enable Cisco TAC to effectively provide support when running Cisco UC VMs co-resident with
non-UC/3rd-party app VMs, customers must ensure either of the following:
non-UC/3rd-party app VMs, customers must ensure either of the following:
Non-UC/3rd party VMs are non-critical and are able to be temporarily powered-down if required to
facilitate troubleshooting.
facilitate troubleshooting.
•
If no VMs are non-critical, then spare capacity must be provisioned on virtualization hosts or physical
servers for relocation (temporary or permanent) of VMs as solutions to application performance
problems. Spare capacity is already a recommended design best practice for redundancy or to provide
temporary staging of VMs when maintenance is required on hardware or software. Examples of
“spare capacity” are extra “empty” physical servers (to provide “hot-standby” or temporary staging),
or existing blade/rack-mount servers not fully utilized.
servers for relocation (temporary or permanent) of VMs as solutions to application performance
problems. Spare capacity is already a recommended design best practice for redundancy or to provide
temporary staging of VMs when maintenance is required on hardware or software. Examples of
“spare capacity” are extra “empty” physical servers (to provide “hot-standby” or temporary staging),
or existing blade/rack-mount servers not fully utilized.
•
To enable Cisco TAC to effectively provide support when running Cisco UC VMs co-resident with
non-UC/3rd-party app VMs, Cisco may require the following activities from the customer for problem
non-UC/3rd-party app VMs, Cisco may require the following activities from the customer for problem