虚机cbt

现象:

借助 VMware Data Recovery (VDR)、vSphere Data Protection (VDP) 或利用更改块跟踪 (CBT) 来执行增量式虚拟机备份而同时在 ESXi 5.x 主机上运行的任何第三方备份工具来运行虚拟机备份时,可能会遇到以下一个或所有症状:

  • 与通常情况相比,虚拟机备份较大
  • 增量备份所需的时间和空间与完整备份相同
  • 由于备份作业仍在运行或者超出备份时间段,快照删除任务失败
  • 尽管虚拟机中未进行重大更改,CBT 文件也会增大

原因:

出现此问题是因为使用 Storage vMotion 进行虚拟磁盘迁移期间已重置 CBT。这会导致备份工具无法识别自上次备份后哪些块已发生更改。此时将无法执行增量式虚拟机备份,而是需要完整备份。

解决:

这是一个影响 ESXi 5.0 的已知问题。

该问题在以下版本中已解决:

要解决此问题,请勿在虚拟机上使用 Storage vMotion 或 Storage DRS 来进行迁移备份。

要在受影响的虚拟机上解决此问题,请执行以下操作:

  1. 关闭虚拟机。
  2. 移除现有虚拟机快照。
  3. 为虚拟机禁用 CBT。有关详细信息,请参见 Enabling Changed Block Tracking (CBT) on virtual machines (1031873)
  4. 移除或重命名虚拟机目录中以 *-ctk.vmdk 文件扩展名结尾的所有文件。
  5. 为虚拟机重新启用 CBT。
  6. 打开虚拟机电源。
  7. 确保虚拟机不是使用 Storage vMotion 或 Storage DRS 进行迁移的。

补充:

在早期版本的 VDDK 中,虚拟机冷迁移时关闭电源,并且会导致更改块跟踪 (CBT) 状态丢失。在 VDDK 5.5 版本中,如果两个主机均可访问源数据存储和目标数据存储,则在冷迁移虚拟机后,会保留 CBT 状态。

另外,可以通过脚本方式实现,具体如下:

$vm="Name"

$vmtest = Get-vm $vm| get-view

$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec

$vmConfigSpec.changeTrackingEnabled = $true

$vmtest.reconfigVM($vmConfigSpec)

$snap=New-Snapshot $vm -Name "Enable CBT"

$snap | Remove-Snapshot -confirm:$false

时间: 2024-08-04 20:33:24

虚机cbt的相关文章

云与备份之(1):VMware虚机备份和恢复

本系列文章会介绍云与备份之间的关系,包括: (1)VMware 虚机备份和恢复 (2)KVM 虚机备份和恢复 (3)云与备份 (4)OpenStack 与备份 (5)公有云与备份 1. 与备份有关的VMWare基础知识 1.1 VMware 虚机磁盘在 ESXi 宿主机上的文件 简单来说,虚机的每个虚拟磁盘由ESXi 宿主机上的三个文件组成(这里的虚机名字是 sammy-target-win-small,下面是其第一个磁盘对应的三个文件): sammy-target-win-small.vmdk

创建ubuntu14.04 KVM虚机

琢磨了一天,终于方便的手工生成了kvm虚机,分享一下: 1,创建qcow2文件: ~]# qemu-img create -f qcow2 testnode1.qcow2 30G Formatting 'testnode1.qcow2', fmt=qcow2 size=32212254720 encryption=off cluster_size=65536 2,用virt-image启动一个kvm虚机 ~]#virt-install --name=testnode1 --ram 3072 --

KVM虚机克隆脚本

#!/bin/sh ############################################# ###         Auto Clone VM                 ### ###         2014-5-9                      ### ###         Owner: YiQiang.Wei            ### ###         Lastedit: 5-11                ### ###      

PowerShell 批量创建Linux虚机

Write-Host -NoNewline -ForegroundColor Magenta '请输入要创建的虚机名称(如:VLNX******)' [String]$VM_Name = Read-Host Write-Host -NoNewline -ForegroundColor Magenta '请输入需要放在哪台宿主机上(如:PWSR******)' [String]$VM_HostName= Read-Host Write-Host -NoNewline -ForegroundColo

从头搭建Openstack运行环境(五)--虚机添加floating ip

6.虚机添加floating ip 为虚机添加floating ip的功能是在neutron网络功能中非常重要的一项,在虚机创建完成后,如果此虚机所在的网络已经加入一个与外网的router中,那这个虚机可以通过SNAT的方式直接访问外网,但外网用户无法访问进虚机.如果想让外网用户访问虚机需要为虚机分配外网的floating ip.以下是为vm4虚机分配外网ip的具体步骤: 1)fixip与floating ip对应 vm4  fixip:10.0.2.84  floating ip:10.255

OpenStack虚机相关错误

OpenStack配置起来还是挺麻烦的,特别是网络那块.虽然官方文档越来越清晰,但有时还是会出各种错.排错主要是看日志.看官方文档和google 以下就一些虚机相关常见的错误做一下总结(基于Icehouse版): 1.起虚机时报 'No valid host' 错误 个人觉得 No valid host 是比较简单的错,那几个单词的意思就已经告诉我们很多信息了,No valid host 原因有很多种 (1)nova compute服务异常,用openstack-status查看各个服务是否是a

如何用ping来测试Azure虚机网络延迟的监测工作

ping操作是大家非常熟悉的测试网络连通性和延迟的操作,之前曾经听到有客户用不能"ping"通azure虚机来说事.因为客户需要能够实现对网络延迟的监测.而在windows Azure上我们是无法使用ping从外部监测Azure上的虚拟机,也无法从Azure虚拟机监测外部延迟的.因为ping基于ICMP协议,在WindowsAzure上,所有服务的对外接口都仅支持TCP和UDP协议.其实,我们可以做到实现对网络延迟的监测.微软technet提供了一个工具叫psping.可以从这里下载h

OpenStack虚机迁移live-migration失败(error: internal error Attempt to migrate guest to the same host)

现象:执行迁移live-migration操作后,显示成功迁移,但是实际没有执行迁移动作 解决过程: 在dashboard执行虚机热迁移操作,提示操作成功,但是实际虚机没有迁移: 之前遇到过内存不足导致迁移失败,但是经过查看发现源和目的节点资源充足: 然后在nova的log看到如下内容:DestinationDiskExists_Remote: The supplied disk path (/var/lib/nova/instances/e40708e3-7f19-4f9c-8d19-3e60

Nova: 虚机的块设备总结 [Nova Instance Block Device]

和物理机一样,虚拟机包括几个重要的部分:CPU.内存.磁盘设备.网络设备等.本文将简要总结虚机磁盘设备有关知识. 1. Nova boot CLI 中有关虚机块设备的几个参数 nova boot CLI 的完整参数如下: usage: nova boot [--flavor <flavor>] [--image <image>] //boot from image with id [--image-with <key=value>] //image metadata p