VDDK错误的美丽和恐怖之处在于,一方面,它是绝对清楚的,其破裂的位置,另一方面,它的原因以及现在如何修复是完全不可理解的。就像在Windows世界中RPC调用函数失败一样。
当然,虽然并非一切都如此可怕。一些错误具有非常具体的原因和处理方法。还有一些-众所周知的最常见原因和纠正方法列表。
当然,我们的Veeam技术支持会积累这些知识,今天我们将看看它们的条目。因此,我很高兴向您介绍最常见的VDDK错误以及消除这些错误的方法。
VDDK错误。这是什么?如何获得?
正如您可能从名称中猜测的那样,这些是VDDK Api(虚拟磁盘开发套件)级别的某种问题,这是与vSphere基础架构进行交互的最佳方法。它是单独的ESXi主机还是庞大的vCenter都无关紧要,但是如果我们需要从基础架构中写入或读取内容,最好的方法是免费的VDDK。
为了尽可能简化,这种交互看起来像这样:例如,Veeam服务器希望从主机读取某些内容(或写入内容)并向其发送请求。将创建一个读取调用,指示从哪个磁盘,要读取多少,从哪个偏移量到内存中的哪个缓冲区。或类似地,从指定的缓冲区写入。这很简单。
但这是一个完美的世界。
在现实生活中,有时这种简单算法会发生错误,因此无法完成请求。而不是预期的响应,而是一个错误号出现在我们的日志中,并仔细记录了该错误号。
今天,我们将讨论最常见的此类错误。
重要免责声明!
不确定-不!不要按任何东西!致电或写信给Veeam支持总是比尝试产品更好。幸运的是,我们的支持是说俄语和非常技术性的。
丝毫怀疑,请问:“我有这样的问题,我在网络上找到了这种解决方案,对我有帮助吗?” -正常且正确。不正常且不正确的是,不确定自己的动作,做了很多事情,然后要求在五分钟之内从废墟中恢复一切,以至于没有丢失任何东西。
是的,在这种情况下,我们当然会提供帮助,但是最好的战斗是没有的战斗。因此,始终尝试严格评估您的操作以及所有正常运行时间。
VDDK错误1:未知错误
实际上,关于此错误,我们有完整的HF文章。而且,正如它所说,如果您安装了太多的性能计数器,通常会发生此错误-并从VMware下载一个修补程序,它将为您解决所有问题。
一方面,甚至没有什么可评论的。这就是问题所在,这是描述(即使不是很清楚),最重要的是,这是药物的链接。但是,并非都那么简单。根据我们的观察,此错误不仅可能是由于计数器的无聊问题引起的,还可能是由于:
- VMDK . , , . — — . , . , , .
- datastore. . , .
- HBA . , . . ?
- , : ESXi vCenter.
恩,恩,你说,我已经赶上了。然后什么?如何理解现在是紧急运行新光盘的时候了-还是放个补丁然后呼气就足够了?
我会回答您-进行一系列简单的测试,以帮助您在发生问题时做出正确的决定。
- 我们启动Storage vMotion或仅将可疑机器克隆到另一个数据存储,然后尝试启动备份。如果克隆失败,则磁盘子系统中肯定存在问题。最大程度地偏执狂-并检查从磁盘到控制器的所有内容。
如果成功将其克隆并保存,则表明VMDK已损坏,因为在克隆过程中,VMware重新创建了其内容,现在那里肯定没有错误。
- , . , . « — » .
- , , , — VMware.
- , . , .
VDDK error 2: Value: 0x0000000000000002
几乎总是与VDDK错误1并存。根据我们的统计数据,错误的出现通常与vCenter / ESXi捆绑软件的某些版本有关,因此,此处的最佳建议是至少升级到6.7版。更好的是7.0。
如果没有帮助,请转到计划B。
当ESXi主机用完为NFC读取缓冲区分配的内存时,将显示错误本身。默认情况下,Veeam在异步NBD / NFC读取模式下运行,在正常情况下,这可能需要扩展此缓冲区。但这并不总是会发生。因此,要禁用此模式,有一个特殊的键:
Name: VMwareDisableAsyncIo
Path: HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication
Type: REG_DWORD
Value: 1
创建它之后,您需要重新启动Veeam Backup Service并为性能下降约10%做准备。
另一种选择是从主机侧登录并重新启动管理代理:
/etc/init.d/hostd restart
/etc/init.d/vpxa restart
该过程在VMware的KB中进行了详细描述,因此我们将不会对其进行重写。
在诊断过程中不会多余的一组标准选项:
- 将有错误的计算机迁移到另一台主机。
- 尝试其他传输模式-带有虚拟代理或DirectSAN的HotAdd。
VDDK错误3:参数之一无效
使用虚拟设备模式(也称为HotAdd模式)时,几乎总是会发生此错误。
这里没有什么特别的要告诉我的,我只给出两个知识库的链接,其中描述了许多选项,即使您立即获得支持,也将要求您做那里写的一切。
KB1218-可能出现的问题及其消除方法的一般说明。
KB1332-如果您的Veeam服务器充当HotAdd模式的代理
VDDK错误13:您无权访问此文件
对于这种情况,我们有KB2008。是的,有很多选择可以消除此问题,但是这是一个错误。几乎不可能明确地说出您的案子到底发生了什么,因此您需要遍历整个清单。
我还想说些什么。请特别注意“其他疑难解答”部分。是的,有很多东西写的,也许太明显了。但是即使是这样的陈词滥调也使最专业的专业人士望而却步。通常情况下,一周后试图独自解决所有问题,他们来寻求支持只是因为发现他们没有仔细阅读技术要求清单或类似的内容。花费的时间实在可惜和可惜。
和所有时间的两个提示:
- Veeam proxy , UUID . - , . , , .
- ( — ), , VDDK .
VDDK error 18000: Cannot connect to the host
在大多数情况下,此错误的错误在于VDDK本身的错误。具体来说,应归咎于gvmomi.dll库。而且他只在沉重的负担下表现自己。例如,当并行备份许多计算机时,功能之一变为0,并且库可能崩溃。然后其他一切都掉了。
这是个可悲的故事。
但是,这个故事中最糟糕的是,不可能准确地重现该错误的条件。这就是测试人员所说的浮动错误。因此,不可能确切地说出导致崩溃的并行计算机数量。
但是,根据官方发布说明此错误已完全修复。因此,正确的出路是更新主机。但是,如果由于某种原因无法执行此操作,那么我们唯一可以帮助的方法就是建议您减少同时处理的机器数量。
别无退路。
VDDK错误14008:无法联系指定的服务器
因此,如果这种麻烦使您不知所措,那么要做的第一件事就是检查网络。 vCenter和Veeam代理之间的通信很可能已关闭。检查是否所有端口都已打开且可访问,并且所有DNS名称是否都正确解析为预期的IP地址。此外,您需要检查失败的工作所涉及的特定代理,而不是旁边的代理(有情况)。
带有此错误的案例中有95%被标记为“客户端基础结构中的DNS /端口问题”关闭。
因此,我再次敦促您非常仔细地检查是否到处都显示了正确的DNS服务器,是否存在关闭的端口以及FQDN名称在哪个IP中进行了解析。
在较早版本的VDDK中,使用非默认端口与vCenter配合使用时出现类似的错误,这占了剩余的5%,但是现在VMware用其描述隐藏了知识库,这可能意味着该知识库不再相关。但是,您可以在2108658的Internet存档中搜索它(如果为VMware vCenter Server指定了非默认端口,则备份将失败)。
VDDK错误14009:服务器拒绝连接
而我们今天头号的最后一个错误是服务器拒绝连接。这里的一切都是绝对禁止的:某些东西阻止了主机和代理之间的连接。在大多数情况下,应该归咎于防火墙。但是-微妙的一点-不是因为端口关闭,而是由于引入的延迟。因此,首先,我们检查端口443的开放性,然后查看超时。
如果两个选项都没有提供任何帮助,请寻求支持。我们必须检查主机本身。也许他只是太忙了,没有时间及时回应,也许还有其他事情。
最后,一些有用的链接:
- 我们屡获殊荣的技术支持门户。
- Veeam支持知识库