解决了

恒定错误“请在快照此vstore之前从vstore vms vms。”

  • 2020年5月7日
  • 11回复
  • 4664观点
H
徽章

你好！

我对这个Nutanix的世界来说很新。已经处理了标准服务器+存储超过了十多年。我们这里有2个群集，每个站点中有3个节点，带有地铁的可用性。在每个站点（活动）中有3个保护域，该域在复制到其他网站（被动）和反之亦然。

Site1：

node1 - node3 - node5

PDS Site1（Active）：Prod_001，DEV_001，INFRA_001

PDS Site1（被动）：PROD_002，DEV_002，INFRA_002

Site2：

node2 - node4 - node6

PDS Site2（Active）：Prod_002，DEV_002，INFRA_002

PDS Site2（被动）：PROD_001，DEV_001，INFRA_001

在vCenter Cluster Configuration中，我们显然对Site2中的Site1和VM /主机中的VM /主机具有关联规则，防止在“奇数”节点中运行的VM存储在“偶数”节点中。
有时我们必须将VM从一个站点迁移到另一个站点。所以我们做一个完整的vMotion（计算和存储）。迁移后，我们开始不断接收此消息的警报：

vstore infra_001的快照状态：失败。vstore infra_001有VMS受到其他vstore保护的VM：VM = SXXXX96 VStores =（Prod_002）。请在快照此vstore之前从vstore vms从vstore vms。

当我们将VM数据存储在同一站点中的另一个数据存储中存储VM数据文件时，也会发生。我在Internet和Nutanix文档中进行了搜索，并没有发现如何处理这些错误。它说“在快照此vstore之前将虚拟机归于VSTORE”，但我该怎么做？它在ncli上完成了吗？棱镜？vCenter？有什么我们在这里做的事情吗？什么是最好的做法？

任何帮助将不胜感激。

谢谢

H警里

图标

最好的答案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回复

alona.
秩
UserLevel 6.
徽章 +5

嗨Henrique，

如果我理解正确，你在网站之间执行虚拟机的故障转移，那就是看到错误的时候？

这句话也有什么遗失吗？“当我们将VM数据存储在同一站点中的一个数据存储器中存储VM数据文件时，也会发生。”数据文件会发生什么？

根据具有地铁可用性的计划故障转移，指南中概述了该过程手动失败保护域（计划的故障转移）- 是你关注的步骤吗？

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 Works的方式），然后我们需要从Site1到Site2手动迁移整个虚拟机（计算和存储）。两个站点都处于活动状态，自身之间复制。

每次我们在站点之间迁移虚拟机我们都会迁移这些错误。正如我所说，我们还有一个开发数据存储，我们首先为开发和测试目的创建VM。有时，这些Dev VM成为生产VM，需要移动到生产数据存储，因此我们执行相同的迁移过程，错误也开始显示。

谢谢

H警里

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"}}}">

alona.
秩
UserLevel 6.
徽章 +5

Henrique，您是否使用任何第三方I.。

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"}}}">

alona.
秩
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"}}}">

alona.
秩
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"}}}">

alona.
秩
UserLevel 6.
徽章 +5

嗨Henrique，

我似乎无法找到任何支持案例，请原谅我。如果您向我发送直接留言，其中我们能够审核案例并希望与您提供解决方案的最新支持案例。

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.

你好

相信这是由于ISO文件蜜蜂连接到VM（即使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

嗨Henrique，

我已经检查了您的支持案例的历史，我找到了关于VMware中的错误的性能相关的情况 - 当通过相同的IP连接超过5个NFS数据存储时，存储性能随着时间的推移而劣化。此问题是在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.

Sr. 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"}}}">

Baidu