解决了

恒定错误“请在快照此VSTORE之前从Vstore中取消保护VM。”

H
徽章

你好！

我是这个Nutanix世界的新手。十多年来一直在处理标准服务器+存储。我们在这里有2个簇，每个站点中有3个节点，并具有地铁可用性。每个站点中有3个活跃的保护域（Active），这些保护域已复制到另一个站点（被动），反之亦然。

site1：

node1 -node3 -node5

PDS SITE1（活动）：prod_001，dev_001，infra_001

PDS SITE1（被动）：prod_002，dev_002，infra_002

站点2：

node2 -node4 -node6

PDS SITE2（活动）：prod_002，dev_002，infra_002

PDS SITE2（被动）：prod_001，dev_001，infra_001

在vCenter群集配置中，我们显然在site1和site2中对VMS/主机具有亲和力规则，从而阻止“奇数”节点中运行的VMS存储在“偶数”节点中。
有时我们必须将VM从一个站点迁移到另一个站点。因此，我们进行完整的VMOTION（计算和存储）。迁移后，我们开始不断收到带有此消息的警报：

Vstore Infra_001的快照状态：失败。VSTORE INFRA_001的VM受其他VSTORE的保护：VM = SXXXX96 VSTORES =（prod_002）。在快照此Vstore之前，请从VSTORE取消保护VM。

当我们存储VMotion A VM DataFiles从一个数据存储到另一个站点的另一个数据存储时，也会发生这种情况。我在Internet和Nutanix文档中进行了搜索，但没有发现如何处理这些错误。它说“在快照此Vstore之前，没有保护VMS到VSTORE””，但是我该怎么做呢？它在NCLI上完成了吗？棱镜？vCenter？我们在这里没有做什么吗？最好的做法是什么？

任何帮助将不胜感激。

谢谢

亨里克

图标

最好的答案谢尔盖·伊万诺夫（Sergei Ivanov）2020年9月2日，14:59

Hi Henrique,<\/p>

I have checked the history of your support cases and I have found a performance related case that was regarding the bug in VMware - when there are more than 5 NFS datastores connected via the same IP, the storage performance degrades over time. This issue is addressed in ESXi versions 6.5U3, 6.7U3 and newer. We have also applied a workaround from the AOS side and simply upgrading AOS to 5.10.4 and newer applies the fix, but the hosts need a reboot after that. That is what i can see happened in your situation - fix was already applied, but the reboot was pending. As i can see from the case, the issue was resolved after the hosts reboots were completed.<\/p>

Here is the information about that VMware bug:\u00a0https:\/\/kb.vmware.com\/s\/article\/67129<\/a><\/p>

We also have a KB about this issue with more details:\u00a0https:\/\/portal.nutanix.com\/kb\/6961<\/a><\/p>

\u00a0<\/p>","className":"post__content__best_answer"}">

查看原件
Hello!<\/p>

I\u2019m pretty new to this Nutanix world. Have been dealing with standard server+storage for more than a decade. We have 2 clusters here, with 3 nodes in each site with metro availability. There are 3 protection domains active in each site (active) that are replicated to the other site (passive) and vice-versa.\u00a0
\u00a0<\/p>

Site1:<\/p>

Node1 - Node3 - Node5<\/p>

PDs site1 (active): PROD_001, DEV_001, INFRA_001<\/p>

PDs site1 (passive):\u00a0PROD_002, DEV_002, INFRA_002<\/p>

\u00a0<\/p>

Site2:<\/p>

Node2\u00a0- Node4\u00a0- Node6<\/p>

PDs site2 (active): PROD_002, DEV_002, INFRA_002<\/p>

PDs site2\u00a0(passive): PROD_001, DEV_001, INFRA_001<\/p>

\u00a0<\/p>

In vCenter cluster configuration we obviously have affinity rules for VMs\/Hosts in site1\u00a0and VMs\/Hosts in site2, preventing the VMs running in \u201codd\u201d nodes from being stored in \u201ceven\u201d nodes.
Sometimes we have to migrate VMs from one site to another. So we do a complete vmotion (compute\u00a0and storage). After the migration, we start to constantly receive\u00a0alerts with this message:<\/p>

Snapshot status for vstore INFRA_001: Failed. Vstore INFRA_001 has VMs being protected by other vstore(s): VM = SXXXX96 vstores = (PROD_002). Please unprotect VMs from vstore(s) before snapshotting this vstore.<\/strong><\/p>

It also happens when we storage vmotion a VM datafiles from one datastore to another in the\u00a0 same site. I did a search in the internet and nutanix documentation and found nothing about how to deal with these errors. It says \u201cunprotect VMs to vstore before snapshotting this vstore\u201d but how do I do it? Is it done on ncli? Prism? vCenter? Is there something that we are not doing right here? What is the best practice?<\/p>

\u00a0<\/p>

Any help will be appreciated.<\/p>

Thanks<\/p>

Henrique<\/p>","quoteUsername":"HenriqueSteppan","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

该主题已关闭以供评论

11个答复

阿罗纳
秩
UserLevel 6
徽章 +5

嗨，亨里克，

如果我正确理解，您会在站点之间执行VM的故障转移，而当您看到错误时？

这句话中还有什么吗？“当我们存储VMotion A VM DataFiles从一个数据存储到另一个站点的另一个数据存储时，也会发生这种情况。”数据文件会发生什么？

根据计划的带有Metro可用性的故障转移，指南中概述了该过程在手动保护域（计划的故障转移）上失败- 您遵循的这些步骤是吗？

Hi Henrique,<\/p>

\u00a0<\/p>

If I understand correctly, you perform a failover of VMs between sites and that is when you see the error?<\/p>

Also is there anything missing in this sentence? \u201cIt also happens when we storage vmotion a VM datafiles from one datastore to another in the\u00a0 same site.\u201d What happens to the datafiles?<\/p>

\u00a0<\/p>

As per the planned failover with Metro Availability, the procedure is outlined in the guide Failing Over a Protection Domain Manually (Planned Failover)<\/a> \u2013 are these the steps that you follow?<\/p>","quoteUsername":"Alona","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

H
徽章

嗨，Alona，

这不是站点之间的故障转移，而是重新平衡。我们通常在Site1中创建过多的虚拟机，并且从存储/计算资源的角度来看，群集变得不平衡。由于DRS仅平衡计算资源（而且我们不喜欢存储DRS的工作方式），因此我们需要手动将整个虚拟机（计算和存储）从site1迁移到SITE1 2。两个站点都很活跃，在他们之间复制。

每次我们在站点之间迁移虚拟机时，我们都会收到这些错误。正如我所说，我们还拥有一个开发数据存储，首先在其中创建用于开发和测试目的的VM。有时，这些开发VM成为生产VM，并且需要转移到生产数据存储中，因此我们进行相同的迁移过程，并且错误也开始出现。

谢谢

亨里克

Hi Alona,<\/p>

It is not a failover between sites, just a rebalancing. We often create\u00a0too much virtual machines in site1 and the cluster got unbalanced from the storage\/computing resources\u00a0point of view. As DRS only balances compute resources (and we don\u2019t like the way storage DRS works) we need then to manually migrate the whole virtual machine (compute and storage) from site1 to site2. Both sites are active, replicating between themselves.\u00a0<\/p>

Everytime we migrate a virtual machine between sites we got these errors. As I said, we also have a DEV datastore where we firstly create VMs for dev and test purposes. Sometimes these DEV VMs became Production VMs and need to be moved to Production datastores, so we do the same migration process and the errors start to show up too.<\/p>

Thanks<\/p>

Henrique<\/p>","quoteUsername":"HenriqueSteppan","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

阿罗纳
秩
UserLevel 6
徽章 +5

Henrique，您是否使用任何第三方，即非Nutanix备份解决方案或工具？

Henrique, are you using any third party i.e. non-Nutanix backup solutions or tools by any chance?<\/p>","quoteUsername":"Alona","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
H
徽章

是的，我正在使用Veeam备份和复制，但仅用于备份。Veeam使用VMware快照来备份VM。它做对了，根本没有问题，创建快照，保存信息，删除快照并继续进行（我可以在日志中看到它）。我相信，我在内部看到的这些快照错误与Nutanix使用的某种类型的快照有关，以及它的引擎服务以复制节点/站点之间的数据。我不认为Nutanix使用VMware快照来复制。我对吗？

谢谢。

Yes, I\u2019m using Veeam Backup & Replication, but only for backups. Veeam uses vmware snapshots to backup the VMs. It is doing it right, no problem at all, create the snap, saves information, delete snap and goes on (I can see it in logs).\u00a0I believe that these\u00a0snapshot errors I see inside Prism are related to some type of snapshot used by nutanix and it\u2019s engine services to replicated data between nodes\/sites. I don\u2019t believe that nutanix uses vmware snapshots to replicated. Am I right?<\/p>

\u00a0<\/p>

Thanks.<\/p>","quoteUsername":"HenriqueSteppan","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

阿罗纳
秩
UserLevel 6
徽章 +5

这看起来像是我们工程团队的记录改进之一。可以肯定的是，您是否可以确认警报是否指向备份中使用的代理VM？

当您说VMware快照时，请记住，这是一个超融合的环境，并且由Nutanix专门处理和呈现存储空间。

您是对的，MA不依赖第三方的快照。

This looks suspiciously like one of the logged improvements with our Engineering team. To be sure, are you able to confirm whether the alert points towards the proxy VM used in backups or not?<\/p>

When you say VMware snapshots it is still important to keep in mind that this is a hyperconverged environment and the storage is handled and presented by Nutanix exclusively.<\/p>

You are right, MA does not rely on snapshots by third parties.<\/p>","quoteUsername":"Alona","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

H
徽章

我们不使用代理VM进行备份。

警报适用于我们环境中的普通VM。

We don\u2019t use proxy VMs for backups.<\/p>

The alerts are for ordinary VMs in our environment.\u00a0<\/p>","quoteUsername":"HenriqueSteppan","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

阿罗纳
秩
UserLevel 6
徽章 +5

在这种情况下，我建议通过Nutanix的支持提出这一点。

I would suggest raising this with Nutanix Support in this case.<\/p>","quoteUsername":"Alona","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
H
徽章

我做了很多次。没有人能够告诉我们命令或“毫无保护” VM的程序。始终是相同的行为，远程连接，在CLI中进行大量NCC检查，收集日志，删除警告和生活。

老实说，我对Nutanix解决方案感到非常失望。这是一个黑匣子，很多理论，许多具有复杂术语的“技术”，但没有人对此有深刻的了解。我们还有另一张与性能有关的问题的公开票，但仍有2个月的问题没有回应。由于Nutanix的性能极低，我们所有的SQL数据库服务器都需要迁移到服务器+存储解决方案（HPE+3PAR）。特别糟糕。

谢谢

I did it many times. No one was ever capable of telling us a command or a procedure to \u201cunprotect\u201d a VM. It\u2019s always the same behavior, connect remotely, run a lot of ncc checks in CLI, collect logs, delete warnings and life goes on.\u00a0<\/p>

To be honest, I\u2019m really disappointed with Nutanix solution. It\u2019s a black box, lots of theory, lots of \u201ctechnology\u201d with complicated terms\u00a0but no one has really deep knowledge\u00a0over it. We have another open ticket for a problem related to performance and still 2 months without response. All our SQL databases servers needed to be migrated to Server+Storage solutions\u00a0 (HPE+3PAR) due to extremely low performance in Nutanix.\u00a0Really bad.<\/p>

\u00a0<\/p>

Thank you<\/p>","quoteUsername":"HenriqueSteppan","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

阿罗纳
秩
UserLevel 6
徽章 +5

嗨，亨里克，

我似乎无法找到任何支持案例，请原谅我。如果您向我发送了带有最新支持案例号码的直接消息，我们将能够查看该案例，并希望向您提供解决方案。

Hi Henrique,<\/p>

I can\u2019t seem to locate any support cases, forgive me. If you send me a direct message with the latest support case number we\u2019d be able to review the case and hopefully provide with you with the solution.<\/p>","quoteUsername":"Alona","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

b

你好

相信这是由于连接到VM的ISO文件造成的（即使已断开CD/DVD）
编辑VM设置，然后将CD/DVD驱动器更改为客户端设备。
不知道是否需要它，但我也断开VM驱动器的连接。

Hi<\/p>

Believe this is due to ISO file beeing connected to VM (\u00a0even if CD\/DVD is disconnected )
Edit VM settings and change\u00a0\u00a0CD\/DVD drive to client device.
don\u2019t know if it is needed but I also disconnect the drive form the VM.<\/p>","quoteUsername":"BjornF","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

谢尔盖·伊万诺夫（Sergei Ivanov）
秩
UserLevel 4
徽章 +5

嗨，亨里克，

我已经检查了您的支持案例的历史记录，并且发现了与性能相关的案例，该案例与VMware中的错误有关 - 当通过相同的IP连接5个以上的数据存储时，存储性能会随着时间的推移而降低。此问题在ESXI版本6.5U3、6.7U3和更新中解决。我们还从AOS侧应用了解决方法，并简单地将AOS升级到5.10.4，并且更新了该修复程序，但是在此之后，主机需要重新启动。这就是我在您的情况下看到的 - 修复已经应用了，但是重新启动尚待审理。从案例中可以看到，在主机重新启动完成后，问题解决了。

这是有关该VMware错误的信息：https://kb.vmware.com/s/article/67129

我们也有一个关于此问题的KB，并提供更多细节：https://portal.nutanix.com/kb/6961

高级SRE |Nutanix全球支持|NSS＃464，NCAP，VCP6.5-DCV，RHCSA，CCNA，EMCSA，AWS和Google Cloud认证
Hi Henrique,<\/p>

I have checked the history of your support cases and I have found a performance related case that was regarding the bug in VMware - when there are more than 5 NFS datastores connected via the same IP, the storage performance degrades over time. This issue is addressed in ESXi versions 6.5U3, 6.7U3 and newer. We have also applied a workaround from the AOS side and simply upgrading AOS to 5.10.4 and newer applies the fix, but the hosts need a reboot after that. That is what i can see happened in your situation - fix was already applied, but the reboot was pending. As i can see from the case, the issue was resolved after the hosts reboots were completed.<\/p>

Here is the information about that VMware bug:\u00a0https:\/\/kb.vmware.com\/s\/article\/67129<\/a><\/p>

We also have a KB about this issue with more details:\u00a0https:\/\/portal.nutanix.com\/kb\/6961<\/a><\/p>

\u00a0<\/p>","quoteUsername":"Sergei Ivanov","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

条款和条件
Learn more about our cookies.<\/a>","cookiepolicy.button":"Accept cookies","cookiepolicy.button.deny":"Deny all","cookiepolicy.link":"Cookie settings","cookiepolicy.modal.title":"Cookie settings","cookiepolicy.modal.content":"We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.<\/a>","cookiepolicy.modal.level1":"Basic
Functional","cookiepolicy.modal.level2":"Normal
Functional + analytics","cookiepolicy.modal.level3":"Complete
Functional + analytics + social media + embedded videos"}}}">
Baidu