 |
» |
|
|
|
For additional information not included in the
online help and documentation for VSE Software, see Insight Dynamics VSE 4.1 Update 1 Documentation Addendum. Limitations | |
The following are limitations for Capacity Advisor. Moving a Virtual Machine Guest Shows Fewer Headroom Rating
Stars Than ExpectedWhen converting a server to a virtual machine
(VM) or moving a VM from one host to another, a list of target hosts
will each display a five-star headroom rating. For a VM host, this
rating is impacted by how well the workloads fit into the VM as well
as how well the VMs fit on the host. If any VM guest on the host
(including the guest currently being moved onto that host) has a low
headroom rating then it will impact the headroom rating shown for
that target host by showing fewer headroom stars than might be expected
from viewing the available resources indicated by the utilization
meters. For example, if a VM host contains a guest which
has a memory utilization of 100% (common with Hyper-V guests) and
a memory utilization limit of 100% for 0% of the time (a default global
utilization limit) then moving or adding a VM guest of any size and/or
utilization to this host will always return a headroom rating of one
star. See the Capacity Advisor online help “Units,
Terminology, and Associated Concepts” topic for more information
on interpreting the headroom star ranking. Workaround The recommended workaround is to remove the utilization
limit from the workload (not the global or scenario utilization limits)
of the metric(s) which may be significantly impacting the headroom
rating. Metrics will impact the headroom rating if they are 50% or
more of the specified limit, but the impact may not be significant
until approaching the limit. Taking the example above, where Hyper-V guests
show memory utilization of 100%, from the scenario workload tab, individually
select each Hyper-V guest and select the Edit Scenario Workload Utilization Limits… menu item to remove the memory utilization limit. Memory Allocation for ESX Guests May Appear to Vary over Time
Even Though the VM Configuration Has Not ChangedWhen viewing memory data for an ESX guest in the
Profile Viewer, the Allocation (light blue, dashed line) may appear
to vary over time, even though the amount of memory configured for
that guest has not changed. The reason for this is that the Allocation
represents “granted” memory for ESX guests (the amount
of physical memory that the ESX host has actually allocated to the
guest at any point in time). The “granted” memory may
be less than the amount of memory configured/requested for the guest
(based on the current memory utilization for the guest). So the “granted”
memory may be very low when the guest is idle. Incorrect Hyper-V Guest Memory Utilization May Limit Headroom
Ratings to One StarCapacity Advisor shows the memory utilization
of Hyper-V Virtual Machines as being 100% utilized all of the time.
This can lead to confusion in interpreting the profile viewer and
will limit any headroom ratings to at most one star with default utilization
limits. When stacking VMs onto VM hosts, Capacity Advisor
always uses the VM's allocated memory in deciding if a VM host
is full. This error will not affect using Smart Solver to rebalance
the VMs across several VM hosts, or manually moving VMs from host
to host. Workaround Remove
the memory utilization limit from the Hyper-V workloads. Removing
the memory utilization limit from the global or scenario limits will
also work but will impact workloads that are not Hyper-V. To remove
the default memory utilization limit use either of the following procedures. Outside of a Scenario (affects five-star headroom ratings displayed
for logical server activations and migrations): Select each Hyper-V guest in the Visualization tab. Select the ConfigureWorkload Utilization Limits... menu item from the VSE menu bar. Select the Memory Utilization% utilization limit. Click the Remove button. Click the OK button.
Inside of a Scenario (affects five-star headroom ratings displayed
for What-If actions within a planning scenario only): Select each Hyper-V guest in the Edit Scenario
Workload tab. Select the EditWorkload Utilization Limits... menu item. Select the Memory Utilization% utilization limit. Click the Remove button. Click the OK button.
Minor Issues | |
The following are minor issues for Capacity Advisor. Errors Occur When Starting a Manual Data Collection Prior to
Completion of First 5-Minute Sample Immediately after installing the Utilization Provider
on a server or after adding a server to the agentless data collection
configuration file, wait at least 5 minutes for an initial data sample
to be collected before manually requesting performing data collection
in Capacity Advisor. Capacity Advisor requires at least one data point
for a server to be useful in a planning scenario. Add Agentless Systems UI Does Not Prevent Configuration of
Hyper-V Hosts Step 1 of the Add Agentless Systems wizard incorrectly allows the selection of Hyper-V hosts. When the
underlying capagentlesscfg command is run on a
selected Hyper-V host, command output will indicate that the Hyper-V
host was not configured for VSE agentless data collection. In fact,
utilization data for Hyper-V hosts is collected agentlessly through
VMM, so there is no loss in functionality, despite the error message. “Collect ALL Capacity Advisor Data Nightly” Fails
with Large Number of Nodes On a CMS with over 1000 managed nodes, the nightly
schedule “capcollect all” task will fail with the following
error message: Can't spawn "cmd.exe": No such file or directory at C:\Program Files\HP\vse\bin\\capcollect.pl line 277. |
This error occurs at approximately 1500 managed
nodes. Workaround Delete the default scheduled task that is shipped
with the software, and create a new one. See “Gathering Data
for Capacity Advisor” in the HP Capacity Advisor
User's Guide for more information. This new task
will scale correctly, because of the way that HP SIM creates new tasks. Missing VM Host Subtype Causes Duplicate Workload Error Condition If the HP SIM system subtype for a VM host is
missing, but associations to its VM guests exist and the VM guest
subtype is defined, Capacity Advisor assumes that the system is physical
and not a VM host. Then, when a user opens a Capacity Advisor Edit Scenario screen, the screen displays the workloads
associated with this server as running on a physical server and on
the VM guests. This duplication causes the information popups for
the server and the VM guests to fail with the following message. Error generating screen. Attempting to create second instance of (hostname). |
Workaround Re-identify the VM host with its VM host subtypes. Verify a VM host subtype is listed for that VM host
in its HP SIM System page in the Product
Description table, System Subtype list. If there is no VM host subtype in the System page: If this is an Integrity VM host, ensure the WBEM VM
Provider is installed on the VM host. For Proliant VM hosts, ensure Virtual Machine Management
Pack (VMM) is identifying the VM host correctly. Then re-identify the VM host in HP SIM to correct
the Subtype settings using OptionsIdentify Systems....
Verify the VM host attribute exists in the System page and in the Virtualization tab. If the VM host subtype is listed in the System page and not in the Virtualization tab and/or not in the Edit Scenario page, then
log out of the current HP SIM session and log back in to clear any
caching issues.
capreport CLI Does Not Generate Trend Reports
for Some Locale Settings Running capreport from the
command line of a Microsoft Windows system that is set to a locale
other than English or Japanese does not work when the trend option
(-t trend) is used. Workaround The same reports can be accessed using the GUI,
which is not affected by this issue. Data Range Changes for Scenarios Created before an Upgrade In Version 4.0 of Capacity Advisor, the “Simulation Interval” (now referred to as “Data Range”) of a scenario excluded the start day specified and included the
end day specified. For example, a scenario specifying a simulation
interval of “Week Ending 12-19-2008”included the entire
day of 12-13-2008 through the entire day of 12-19-2008. However, the
common usage when specifying time intervals is for the start day to
be inclusive and the end day to be exclusive. Version 4.1 of Capacity Advisor interprets
the scenario simulation interval this way. With Version 4.1 of the
product, “Week Ending 12-19-2008” includes the entire
day of 12-12-2008 through the entire day of 12-18-2008. The result
is that when you upgrade a scenario from Version 4.0 to Version 4.1,
the simulation interval for the scenario moves back in time one day. Workaround To maintain the same simulation interval for scenarios
created under the previous release, move the end day of the scenario
forward one day. For example, if the scenario data range is “Week Ending 12-19-2008”, press the Edit Interval button in the scenario, and change the date to “12-20-2008”, and press the OK button. Capacity Advisor Data Collection Succeeds but is Not Displayed
in Profile Viewer Collecting Capacity Advisor data “succeeds” with no error message displayed for a system or group of systems
when collecting data (either from the capcollect CLI, the OptimizeCollect
Capacity Advisor Data... menu, or from
the Collect Capacity Advisor Data link on the
Profile Viewer). However no data is displayed in the Profile Viewer. Workaround If data is correctly displayed on the Visualization
tab, restart HP SIM in order to properly display data on the Workload
tab or Profile Viewer Current Day's Capacity Advisor Data can be Lost After performing a virtual to physical move (using
HP Server Migration Pack-Universal, for example), or after switching
from agentless data collection to the Utilization Provider, collecting
Capacity Advisor data may result in loss of data previously collected
for the current day. Workaround Wait 24 hours before collecting Capacity Advisor
data for systems that were either migrated from virtual to physical
systems or that have switched from agentless data collection to UP-based
data collection. Error Message from Agentless Data Collection May Indicate A
DNS Issue When the WMI Connection to the Host Has Failed When collecting agentless data, the following
error may be displayed (either in Virtualization Manager meter popups
or in the capcollect/Collect Capacity Advisor Data
output): "The IP address of the host X could
not be resolved". When this error is encountered the problem may not
be with DNS hostname/IP address resolution. It may instead be that
the target server is currently shutdown or otherwise inaccessible
via WMI. Workaround When you encounter this error message, run the vseassist managed node communication checks (select the
host(s) in the Visualization tab and then select
the DiagnoseTroubleshoot
VSE ManagementCheck VSE CMS to Managed Node
Communication... menu item), and verify
that the following (first three) tests pass: Managed system hostname resolution...................................[PASS]
WBEM port open.......................................................[PASS]
WBEM authentication..................................................[PASS] |
Only the first three tests relate to agentless collection. The SSH
and SNMP checks run by this vseassist command do
not apply to agentless collection. CPU Data Collected after VM Migrations (for the Time Period
Between the Previous Collection and the Last Migration) Between Hosts
with Dissimilar CPUs May be Inaccurate Capacity Advisor "normalizes" CPU utilization
based on the CPU speed of the system. For Virtual Machines, this is
based on the VM host's CPU speed. For x86 VM platforms (VMware
ESX, MSVS and Hyper-V), if VM's have been migrated between hosts
since the last data collection, Capacity Advisor will use the "current"
host's CPU speed for normalizing all data since the last collection,
even if some of that data was on hosts of a different CPU speed than
the current. Note that this is only a problem if the hosts that the
VM is migrated between have different CPU speeds. Workaround Whenever possible, collect Capacity Advisor data
for VMs just prior to migrating those VM's between hosts with
different CPU speeds. Operating System Name for VMM Systems Displayed Incorrectly
After OS Change If a system is dual-booted (or a different OS
is installed) and the new operating system is managed by VMM, the
operating system type will not be updated when a capcollect is performed. It will be updated if the new operating system is
collected via agentless or WBEM. The original OS on which the system
was booted will continue to be displayed. For example, if an x86 system
previously running Windows and licensed for Capacity Advisor had data
collected and is subsequently reprovisioned as an ESX VM host, registering
it with VMM and collecting Capacity Advisor data will continue to
show the system OS type as “Windows”. Workaround Perform the following: In a command window type capprofile -x workload-name
< file.txt. Edit the resulting file to remove everything except
the header and the first line of utilization data. Change the operating
system type in the header to the correct value: Type capprofile -i -o -S workload-name >file.txt.
Potential Race Conditions In Profile Viewer Using pan buttons in two instances of the profile
viewer within the same session will cause odd panning behavior. The
last pan button pressed will impact both profile viewers (after the
second one is reposted). There is also a small probability that using pan
buttons from multiple browser sessions simultaneously will cause a
null pointer exception (NPE). Workaround Open a second browser instance or use a browser
from a different machine if you need to use pan buttons from both
browser instances. Alternatively, if you want to use the same session,
pan to your desired position in one profile view, then use the pan
buttons in the second profile viewer. Workload Disappears After Move Workload Action The .OTHER workload is meant
to represent virtualization overhead in Capacity Advisor. If you explicitly
move a .OTHER workload in Capacity Advisor to a
server for which it is inappropriate, or to a server which already
has a .OTHER workload, the moved .OTHER workload disappears. Workaround HP recommends not moving .OTHER workloads to servers for which they are not intended. You can recover
this workload by choosing "undo action" to restore the workload to
its original place, then recover it.
|
Printable version
