本人新手。
目前進行NBU虛擬機備份的時候，一些客戶端時常發現11錯誤（系統呼叫失敗）或者是13錯誤（檔案讀取失敗）
特征是：備份到一部分的時候，備份失敗。例如400G的虛擬機備份到200G的時候就顯示這個資訊。
一般來說，會是空間不足的問題嗎？還是虛擬空間的問題？具體有什么推薦調整的方式。
報case，顯示以下資訊：
1.vxms日志顯示我們每次備份到那個資料量大小就中斷的原因是：該主機每次都只能備份yzbbxt-db.vmdk 磁盤，而磁盤yzbbxt-db_1.vmdk在嘗試讀取3次失敗后就退出了，即yzbbxt-db_1.vmdk磁盤沒有正常讀取。
日志如下：
Begin:vfm_read [19:02:39.0393 : ]
In: nreq=1
vfm_obj_t { orig_name = [HDS_HUS_LUN1_2TB] yzbbxt-db/yzbbxt-db.vmdk }
[ I/O Req ]
vfm_io_req_t { offset = 214748270080 reqlen = 65536 bytes_trans = 0 bytes_req = 0 error = 0 }
Out:
[ I/O Req ]
vfm_io_req_t { offset = 214748270080 reqlen = 65536 bytes_trans = 65536 bytes_req = 0 error = 0 } --214748270080是讀取的資料量，會增長的
End:(0)
Begin:vfm_read [19:02:39.0395 : ]
In: nreq=1
vfm_obj_t { orig_name = [HDS_HUS_LUN1_2TB] yzbbxt-db/yzbbxt-db.vmdk }
[ I/O Req ]
vfm_io_req_t { offset = 214748335616 reqlen = 29184 bytes_trans = 0 bytes_req = 0 error = 0 }
Out:
[ I/O Req ]
vfm_io_req_t { offset = 214748335616 reqlen = 29184 bytes_trans = 29184 bytes_req = 0 error = 0 }
End:(0)
Begin:vfm_close [19:02:39.0397 : ] ---關閉讀取
In: vfm_obj_t { orig_name = [HDS_HUS_LUN1_2TB] yzbbxt-db/yzbbxt-db.vmdk } ---這是這個盤讀取完成的標記
End:(0) --正常回傳
Begin:vfm_open_file_name [19:02:39.0431 : ]
In: filename=<vix>[HDS_HUS_LUN1_2TB] yzbbxt-db/yzbbxt-db_1.vmdk ---開始讀取下一塊盤
flags=2
context=
Out:
rflags=0
vfm_obj_t { orig_name = [HDS_HUS_LUN1_2TB] yzbbxt-db/yzbbxt-db_1.vmdk }
End:(0)
Begin:vfm_read [19:02:39.0432 : ]
In: nreq=1
vfm_obj_t { orig_name = [HDS_HUS_LUN1_2TB] yzbbxt-db/yzbbxt-db_1.vmdk }
[ I/O Req ]
vfm_io_req_t { offset = 0 reqlen = 35328 bytes_trans = 0 bytes_req = 0 error = 0 } ---沒有讀取到資料，回傳11錯誤，這種操作嘗試了3次都失敗。
End:(11)
2.bpbkar日志中有明確的讀取3次失敗的記錄
19:03:02.806: [1604.568] <2> tar_base::V_vTarMsgW: TRV - Read of VM file read 0 bytes, should have read 35328 bytes, will be issuing retry 1 of 3 (../flashmap.cpp:2006)
19:03:03.806: [1604.568] <2> tar_base::V_vTarMsgW: TRV - VxMS Error message 1 = fiml_read_file vfm_read
message 2 = stat 11 req.io_error 0 (../vxms_bridge.cpp:320) ----bkbkar日志在讀取檔案時報11錯誤。
19:03:03.806: [1604.568] <2> tar_base::V_vTarMsgW: TRV - Read of VM file read 0 bytes, should have read 35328 bytes, will be issuing retry 2 of 3 (../flashmap.cpp:2006)
.....
19:03:04.807: [1604.568] <2> tar_base::V_vTarMsgW: TRV - Read of VM file read 0 bytes, should have read 35328 bytes, will be issuing retry 3 of 3 (../flashmap.cpp:2006)
以下為ESX server的日志：
1.您這ESX server的時間和北京時間有時差，不過時差是一天內不算問題
2.vpxa的日志中針對disk的update，我給你做了如下2端日志的對比，明顯顯示，opid如果能夠正常更新就會正常退出，但是opid SWI-9e91f12e一直更新不過去，請檢查。
正常日志，會很快update：
2016-09-14T06:37:07.128Z [550C7B70 verbose 'VpxaHalCnxHostagent' opID=WFU-91f9690] [WaitForUpdatesDone] Received callback
2016-09-14T06:37:07.128Z [550C7B70 verbose 'VpxaHalCnxHostagent' opID=WFU-91f9690] [VpxaHalCnxHostagent::ProcessUpdate] Applying updates from 5434414 to 5434415 (at 5434414)
2016-09-14T06:37:07.128Z [550C7B70 verbose 'hostdvm' opID=WFU-91f9690] [VpxaHalVmHostagent] 34: GuestInfo changed 'guest.disk'
2016-09-14T06:37:07.129Z [550C7B70 verbose 'halservices' opID=WFU-91f9690] [VpxaHalServices] VmGuestDiskChange Event for vm(40) 34
2016-09-14T06:37:07.129Z [550C7B70 verbose 'vpxavpxaInvtVm' opID=WFU-91f9690] [VpxaInvtVmChangeListener] Guest DiskInfo Changed
2016-09-14T06:37:07.129Z [550C7B70 verbose 'VpxaHalCnxHostagent' opID=WFU-91f9690] [WaitForUpdatesDone] Starting next WaitForUpdates() call to hostd
2016-09-14T06:37:07.129Z [550C7B70 verbose 'VpxaHalCnxHostagent' opID=WFU-91f9690] [WaitForUpdatesDone] Completed callback
opID=SWI-9e91f12e 更新不成功。（這個opid你得找vmware去做對應，我只知道這個opid update失敗）。
2016-09-14T06:46:26.181Z [FFB03B70 verbose 'vpxavpxaMoVm' opID=SWI-9e91f12e] [VpxaMoVm::CheckMoVm] did not find a VM with ID 59 in the vmList
2016-09-14T06:46:26.181Z [FFB03B70 verbose 'vpxavpxaAlarm' opID=SWI-9e91f12e] [VpxaAlarm] VM with vmid = 59 not found
2016-09-14T06:46:36.183Z [FFB03B70 verbose 'vpxavpxaMoVm' opID=SWI-9e91f12e] [VpxaMoVm::CheckMoVm] did not find a VM with ID 59 in the vmList
2016-09-14T06:46:36.183Z [FFB03B70 verbose 'vpxavpxaAlarm' opID=SWI-9e91f12e] [VpxaAlarm] VM with vmid = 59 not found
3.hostd.log日志中關于這個磁盤yzbbxt-db_1.vmdk有error ，請找vmware去分析。
2016-09-14T03:34:27.003Z [2A681B70 verbose 'Default' opID=69c6fd79-a9 user=vpxuser] AdapterServer: target='vim.VirtualMachine:37', method='queryChangedDiskAreas'
2016-09-14T03:34:27.017Z [2A681B70 error 'Vmsvc.vm:/vmfs/volumes/5036aacb-761921f0-4ceb-3440b5b0b762/yzbbxt-db/yzbbxt-db.vmx' opID=69c6fd79-a9 user=vpxuser] Cannot compute changes for disk /vmfs/volumes/5036aacb-761921f0-4ceb-3440b5b0b762/yzbbxt-db/yzbbxt-db_1.vmdk: Unknown change epoch.
2016-09-14T03:34:27.017Z [2A681B70 info 'Default' opID=69c6fd79-a9 user=vpxuser] AdapterServer caught exception: vim.fault.FileFault
2016-09-14T03:34:27.017Z [2A681B70 info 'Solo.Vmomi' opID=69c6fd79-a9 user=vpxuser] Activation [N5Vmomi10ActivationE:0x28694ca0] : Invoke done [queryChangedDiskAreas] on [vim.VirtualMachine:37]
4.該ESX server 是否使用了Vcenter，建議把backup hosts主機的IP 地址決議也添加到 ESX server上。
uj5u.com熱心網友回復：
這個問題不清楚，幫頂～uj5u.com熱心網友回復：
到專門的論壇去問問吧，沒有接觸過這個的，誰也不清楚；轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/117725.html
標籤：高級技術