已知问题

vCenter 无共享迁移失败 ：在 8.17.5 至 8.18.0 版本中，针对 vCenter 目标的无共享迁移失败，在 8.17.3 和 8.17.4 版本中也可能失败。在获得修复之前，请通过 Turbonomic Swagger API 配置 discoverHAHosts 属性，以确保无共享迁移成功。
1. 通过浏览器登录 Turbonomic 实例。
  
  https://{your_instance_address}
2. 在浏览器中打开一个新标签页，转到下面的 Swagger API 请求。
  
  https://{your_instance_address}/swagger/#/[INTERNAL USE - NOT SUPPORTED]/getAllProbes
3. 单击 " 试用 "。
4. 从响应中找到 “type”:”vCenter” 的元素，并记录其 UUID。下面的示例是回复的精简版。
```
   {
    "uuid": "76241299676768",
    "category": "Hypervisor",
...
    "type": "vCenter",
    "readonly": false
  },
 
```
5. 在浏览器中打开一个新标签页，转到下面的 Swagger API 请求。
  
  https://{your_instance_address}/swagger/#/[INTERNAL USE - NOT SUPPORTED]/putProbeSpecificProperty
6. 单击试用，然后配置以下参数：
  - probeId UUID：上一步记录的 UUID
  - propertyName : discoverHAHosts
  - body: false
7. 单击执行。
  
  响应显示 200 代码，表明执行成功。
8. 连接到可访问 Turbonomic 部署的控制台、终端或管理用户界面。
9. 找到 mediation-vcenter pod。
```
kubectl get pods | grep mediation-vcenter
```
  响应与下面的示例类似，显示 mediation-vcenter pod 的名称。复制名称。
```
mediation-vcenter-6f86cd95d5-8c62p                        1/1  Running
```
10. 重新启动 pod。
```
kubectl delete pod <pod_name>
```
  例如：
```
kubectl delete pod mediation-vcenter-6f86cd95d5-8c62p
```
延迟显示多币种环境下的操作 ：更新到版本 8.17.5 或更高版本后，如果云提供商提供的计费数据使用多种货币，可能至少需要一个成本发现周期和一个计费发现周期，或大约一个小时，云工作负载的操作才会正确显示在操作中心。
大小不灵活的 AWS RI 的覆盖范围不正确 ：当添加计费目标时，由不支持大小灵活性的 RI（如所有 Windows RI）覆盖的 AWS 虚拟机可能会错误地触发扩展操作以增加 RI 覆盖范围，即使这些虚拟机已经完全覆盖。在这种情况下，操作详情将显示低于预期的源折扣范围值。

此外，如果该虚拟机被 Compute Savings Plan 部分覆盖，则包括该虚拟机在内的任何范围的 Discount Coverage 图表也可能显示少报的覆盖百分比。 Note ：这个问题不是新问题，以前的版本可能也受到过影响。
暂时移除 "管理列 "按钮 ： 管理列按钮用于自定义操作中心和泊车页面中列的可见性，由于在自定义和调整列时会出现页面渲染问题，该按钮已被暂时移除。问题解决后，按钮将恢复。
Azure 启用成本分配规则的账单报告 ：对于已启用成本分配规则的 Azure MCA 和 EA 帐户，计费报告可能会在 Discount Coverage widget 和 Cloud VM Scale 操作详情中显示不准确的折扣范围值。

这个问题源于 Azure 账单数据的限制：当 pricingModel 设置为 Reservation 时，不会填充 unitPrice 列。 Turbonomic 尝试使用当前发现的价格表来估算缺失的 unitPrice ，这可能与实际的历史计费率不同。因此，在 Source discount coverage 行动详情部分，折扣覆盖值可能会超过 100%，而 Discount coverage 小工具显示的 RI 和 SP 组合覆盖百分比可能会超过 100%。
即将退役的 Azure VM SKU 的 RI 费率不可用 ：微软宣布，某些 Azure VM SKU 将于 2028 年 5 月 1 日退役，此后将不再提供。因此，微软已从零售定价 API 中删除了这些 SKU 的 1 年期和 3 年期预留实例 (RI) 定价。因此， Turbonomic 无法检索这些虚拟机类型的 RI 费率，这可能会影响成本计算和建议。更多信息，请参阅 Azure 更新。
Azure VM 在 Microsoft Customer Agreement (MCA) 或 Enterprise Agreement (EA) 账户中的折扣覆盖范围值不正确 ：对于属于 Azure 帐户的虚拟机，如果该虚拟机同时受储蓄计划 (SP) 和预留实例 (RI) 的保护，折扣覆盖率图表可能会显示大于 100% 的组合覆盖率。出现该问题是因为 MCA 或 EA 费用报告中的 unitPrice 栏被错误地设置为 0。此问题不会影响由储蓄计划 (SP) 或保留实例 (RI) 覆盖的虚拟机，但不会同时影响这两种虚拟机。
AWS 虚拟机比额表操作中的不正确 RI 比率 ：当您为 AWS 虚拟机比额表操作选择有效成本基础时，"操作详情 "页面可能会显示所覆盖虚拟机的不正确 RI 比率。考虑到的RI率可能来自标准RI或可转换RI，这可能会导致成本计算不准确。
云虚拟机的重新配置操作不显示在操作中心 ：从版本 8.14.5 版本开始，云虚拟机的重新配置操作不显示在操作中心。
Kubeturbo 8.13.1 及更早版本需要 Turbonomic 版本进行部署 configMap：按照文档部署 Kubeturbo 8.13.1 或更早版本时，需要执行手动步骤才能成功部署 Kubeturbo 并将容器平台添加为 Turbonomic 中的目标。 configMap 中需要包含主要版本的以下一行，以 8.14 为例（适用于任何 8.14.x 版本）
```
"communicationConfig": {
                      "serverMeta": {
                      "version": "8.14",
```
当 Kubeturbo 和 Turbonomic 版本不匹配时，会出现发现问题或失败 ：使用与运行的 Turbonomic 版本不同的 Kubeturbo 代理可能会导致问题，包括发现失败、生成的操作数量减少或无操作。这反过来又会降低成本节约，增加环境中的性能风险。为避免这些差异，请将 Kubeturbo 代理版本与 Turbonomic 版本保持一致。更多信息，请参阅更新 Kubeturbo。
yum upgrade 更新到 8.11.4 版本后出现故障 ：在线或离线更新到版本 8.11.4 后， yum upgrade 可能会出现以下故障：
```
"GPG key retrieval failed: [Errno 14] curl#37 - "Couldn't open file /etc/pki/rpm-gpg/PGDG-RPM-GPG-KEY-RHEL7"
```
要解决这个问题，请运行以下命令下载并安装最新的 Postgres 签名密钥：
```
sudo yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm 
```
您必须连接互联网才能下载签名密钥。
当虚拟机由 AWS "节约计划 "覆盖时，"工作负载成本明细表 "中的按需成本不准确 ：当虚拟机由 AWS Savings Plan（节省计划）覆盖时，工作负载成本明细表可能会报告不准确的按需成本。这是因为此图表将任何覆盖资源的节省计划折扣视为随需应变成本的一部分，并且不会单独对这些折扣进行分类。
不正确处理数值几乎相同的标记 ：当标签值的字母数字字符相同，但特殊字符不同时，按标签分列的成本明细表会显示一个标签值，而忽略其他标签值。例如，它可能会显示 ab-1 ，而忽略 ab_1 和 ab%1。
Google Cloud C3 实例按需使用内存或 CPU 的情况缺失..：折扣覆盖率图表不包括 Google Cloud C3 实例的内存或 CPU 的按需使用情况。

MySQL 数据迁移的视图相关错误 ：对于 MySQL 5.7 到 MySQL 8.0 的就地迁移或 MySQL 5.7 实例和 MySQL 8.0 实例之间的完整数据迁移，可能会出现以下视图相关错误：

Issues reported by 'check table x for upgrade' command
vmtdb.app_daily_ins_vw - Table 'vmtdb.app_spend_by_hour' doesn't exist
vmtdb.app_daily_ins_vw - View 'vmtdb.app_daily_ins_vw' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
vmtdb.app_daily_ins_vw - Corrupt
vmtdb.app_daily_upd_vw - Table 'vmtdb.app_spend_by_hour' doesn't exist
vmtdb.app_daily_upd_vw - View 'vmtdb.app_daily_upd_vw' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

要解决此问题，请执行以下步骤：

连接到 MySQL 数据库服务器。

运行以下命令，并提供样本输出:

mysql> use vmtdb;
Database changed
mysql> SHOW FULL TABLES IN vmtdb WHERE TABLE_TYPE LIKE 'VIEW';
----------------------------------+
Tables_in_vmtdb         Table_type
----------------------------------+
app_daily_ins_vw       VIEW
app_daily_upd_vw        VIEW
app_monthly_ins_vw      VIEW
app_monthly_upd_vw      VIEW
service_daily_ins_vw    VIEW
service_daily_upd_vw    VIEW
service_monthly_ins_vw  VIEW
service_monthly_upd_vw  VIEW
vm_daily_ins_vw         VIEW
vm_daily_upd_vw         VIEW
vm_monthly_ins_vw       VIEW
vm_monthly_upd_vw       VIEW
----------------------------------+

继续放弃所有这些观点。

drop view app_daily_ins_vw, app_daily_upd_vw, app_monthly_ins_vw. app_monthly_upd_vw, service_daily_ins_vw, service_daily_upd_vw, service_monthly_ins_vw, service_monthly_upd_vw, vm_daily_ins_vw, vm_daily_upd_vw, vm_monthly_ins_vw, vm_monthly_upd_vw;

有关就地 MySQL 升级的更多信息，请参阅配置远程数据库。

从运行旧版本 Kubernetes 的 OVA 更新到 8.9.3 或更高版本时出错 ：当从运行旧版本的 8.9.3Kubernetes 或更高版本时，可能会遇到以下错误：
```
/opt/local/bin/t8c-license-service.sh >>>>> ERROR - Pre requirement check: FAILED
```
由于旧版本的 Kubernetes 不支持 License Service ，因此无法安装。其他 Turbonomic 组件的升级和 Turbonomic 的正常使用不受影响。

此错误影响 Kubernetes 早于 1.19 的版本。要检查 Kubernetes 版本，请运行以下命令：
```
kubectl version
```
如果遇到此错误并需要帮助，请联系您的 Turbonomic 代表。
Prometheus 部署到某些 Kubernetes 环境时组件失效 ：在某些客户提供的 Kubernetes 环境中部署 Turbonomic 时， Prometheus 组件可能会因无法写入附加卷而进入崩溃循环。要解决这个问题，可在 CR 文件的 prometheus 部分添加 securityContext ，指定 fsGroup ，如下所示：
```
spec:
  prometheus:
    server:
      securityContext:
        fsGroup: 2000
```
如果 CR 文件中尚不存在 prometheus 部分，请在顶级 spec 部分下添加新的部分。

修改 CR 文件后，应用该文件以激活更改。
PowerVM 面板上的 "顶级虚拟机 "和 "顶级主机 "部件显示不正确 ： PowerVM 面板上的 "顶级虚拟机 "和 "顶级主机 "部件可能会遇到与临时组有关的问题，临时组是在以下情况下创建的临时组：
- 点击供应链中的任何节点或实体时
- 在搜索和作用域中选择实体时
要解决这个问题，请执行以下步骤之一：
- 编辑 "排名靠前的 VM" 或 "排名靠前的主机" 窗口小部件以添加电源商品。
- 重新打开 PowerVM 组。
- 编辑URL，删除 "?entityType=查询字符串参数。
无法识别 vCenter 基于 VM-VM Dependency 规则的虚拟机重启依赖关系的 DRS 规则 ：对于 vCenter 服务器环境， Turbonomic 无法识别基于 VM-VM Dependency 规则的虚拟机重启依赖的 DRS 规则。通过 VM-Host 规则、群集亲和性或反亲和性规则来表达依赖关系，也许能达到类似的效果。
使用 oAuth 凭据时无法发现 AppDynamics 数据库服务器 ：对于 AppDynamics 环境，如果目标验证使用 oAuth 凭据，则 Turbonomic 无法发现数据库服务器。
策略更改不会显示在受影响范围的用户界面视图中 ：将 Turbonomic 视图的范围设置为组后，就可以查看影响给定组的自动化策略。如果为该组编辑策略，然后再次将视图范围扩大到该组，则策略更改不会显示在该组的显示屏中。

显示应该在下一轮增量发现后的 10 分钟内更新。如果该情况仍然存在，请从会话注销，然后再次登录以更新显示。
计划的 "优化改进 "图表中缺少或不正确的主机数据 ：对于操作指示配置新主机的情况，"优化改进 "图表在 "计划之后 "部分不包括要配置的主机。

如果操作建议您暂停主机，"优化改进 "图表应显示要暂停的主机没有利用率。在某些情况下，图表可以显示这些主机上的利用率。结果是当前作用域中其他主机上的利用率值不正确。
如果 Turbonomic 数据库使用 MariaDB 或 MySQL 的自定义（ non-3306 ）端口，则无法启动停车功能 ：对于 Turbonomic 部署，如果数据库使用 MariaDB 或 MySQL, 的自定义（ non-3306 ）端口，则无法启动停车功能。在这种情况下，应按如下方法禁用 charts_v1alpha1_xl_cr.yaml 资源的挂起功能：
```
spec:
  suspend:
    enabled: false
```
New Relic 终止支持与 Microsoft SQL Server 2012 监控集成。 ： Turbonomic 不再支持对通过 New Relic 发现的 Microsoft SQL 2012 进行监控和拼接。建议将 Microsoft SQL 实例升级到 New Relic 支持的版本。
将云虚拟机扩展到超大实例类型，即使有较小的实例类型可供扩展 ：当具有特定磁盘数量和磁盘类型的云虚拟机应用了启用 "实例存储感知扩展 "的策略时， Turbonomic 可能会建议将虚拟机扩展到非常大的实例类型，即使有较小、较便宜的实例类型可以充分满足虚拟机的资源需求。

要避免此问题，请禁用实例存储感知缩放，并将 VM 限制为其当前实例系列。例如，如果 AWS VM 当前正在运行 i3.2xlarge 实例类型，请将 i3 实例系列指定为 VM 的缩放约束。
New Relic MySQL 8.0 的 DB 缓存命中率值不正确 ：对于 New Relic MySQL 8.0， Turbonomic 中的 DB 缓存命中率值不正确，因为 New Relic MySQL 8.0 及更高版本不支持从缓存检索的查询百分比 (db.qCacheHitRatio)。更多信息，请参阅 New Relic 文档。
由于 Azure API 存在问题，导致 Azure 计费成本和指标不完整 ：当尝试在任何月份的第一天发现 Azure 计费目标配置分区成本导出时， Turbonomic 无法在客户的 Azure 存储账户中找到包含导出文件的目录。导出文件存在，但 Azure API 不会返回当天成本导出文件的正确存储位置。因此， Turbonomic 用户界面可能无法反映 Azure 在每月 1 日导出的任何计费成本，以及取决于该计费成本的指标。计费成本 (包括当月第一天的成本) 将在当月第二天开始出现。请注意，计费成本不限于当月第一天发生的费用。
替换主机计划无法放置 Nutanix 虚拟机 ：您可以在 Nutanix 集群上配置 "替换主机 "计划，用 HCI 模板替换主机。但是，该计划将无法创建 HCI 主机，并且将导致未放置的 VM。
硬件刷新计划无法将工作负载放置到 HCI 主机上 ：运行硬件更换计划时，该计划可能无法将工作负载放置到 HCI 主机上。如果计划作用域位于超融合环境中，那么该计划会正确放置工作负载。如果范围不在超融合环境中，则必须将计划范围扩大到整个群集，并且必须配置计划，用 HCI 模板替换群集中的所有主机。
具有 Automator 角色的作用域用户无法查看预订 ：这些用户可以创建但不能查看预订。其他用户角色可以查看这些预订。