I can run the VM without any issues. However I cannot run vmkfstools when the VM is running either. Fail to lock the file error:
[root@DELL790:/vmfs/volumes/5c513450-b2f92ad8-2534-00e04c802311/Synology] vmkfstools -x check synoboot.vmdk
DiskLib_Check() failed for source disk ‘synoboot.vmdk’: Failed to lock the file (16392).
After I shutdown the VM, all vmdk files are checked and I got no errors.
[root@DELL790:/vmfs/volumes/5c513450-b2f92ad8-2534-00e04c802311/Synology] ls -l *.vmdk
-rw——- 1 root root 1311232 May 4 13:22 synoboot-ctk.vmdk
-rw——- 1 root root 32374784 May 4 12:48 synoboot-s001.vmdk
-rw——- 1 root root 566 May 4 12:46 synoboot.vmdk
[root@DELL790:/vmfs/volumes/5c513450-b2f92ad8-2534-00e04c802311/Synology] vmkfstools -x check synoboot.vmdk
Disk is error free
[root@DELL790:/vmfs/volumes/5c513450-b2f92ad8-2534-00e04c802311/Synology] vmkfstools -x check synoboot-ctk.vmdk
DiskLib_Check() failed for source disk ‘synoboot-ctk.vmdk’: The file specified is not a virtual disk (15).
[root@DELL790:/vmfs/volumes/5c513450-b2f92ad8-2534-00e04c802311/Synology] vmkfstools -x check synoboot-s001.vmdk
DiskLib_Check() failed for source disk ‘synoboot-s001.vmdk’: The file specified is not a virtual disk (15).
[root@DELL790:/vmfs/volumes/4e5f91c0-eb76a861-cbb4-00e04c802311/Synology] ls -l *.vmdk
-rw——- 1 root root 6554112 May 4 13:22 Synology-ctk.vmdk
-rw——- 1 root root 429496729600 May 4 13:22 Synology-flat.vmdk
-rw——- 1 root root 614 May 4 12:46 Synology.vmdk
[root@DELL790:/vmfs/volumes/4e5f91c0-eb76a861-cbb4-00e04c802311/Synology] vmkfstools -x check Synology.vmdk
Disk is error free
[root@DELL790:/vmfs/volumes/4e5f91c0-eb76a861-cbb4-00e04c802311/Synology] vmkfstools -x check Synology-ctk.vmdk
DiskLib_Check() failed for source disk ‘Synology-ctk.vmdk’: The file specified is not a virtual disk (15).
[root@DELL790:/vmfs/volumes/4e5f91c0-eb76a861-cbb4-00e04c802311/Synology] vmkfstools -x check Synology-flat.vmdk
DiskLib_Check() failed for source disk ‘Synology-flat.vmdk’: The file specified is not a virtual disk (15).
I have two disks for this VM. Please check the settings below.
Содержание
- ИТ База знаний
- Полезно
- Навигация
- Серверные решения
- Телефония
- Корпоративные сети
- Ошибки Cannot open the disk при включении виртуальной машины ESXi
- Неисправности
- Интенсив по Виртуализации VMware vSphere 7
- Решение
- System cannot find the file specified
- The parent virtual disk has been modified since the child was created
- Дополнительная информация
- Интенсив по Виртуализации VMware vSphere 7
- Полезно?
- Почему?
- Vmware disk is error free
- Fixing virtual disk errors in VMware
- Vmware disk is error free
ИТ База знаний
Курс по Asterisk
Полезно
— Узнать IP — адрес компьютера в интернете
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Калькулятор инсталляции IP — АТС Asterisk
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Ошибки Cannot open the disk при включении виртуальной машины ESXi
Не удается открыть диск
Неисправности
Вы не можете запустить виртуальную машину и получаете сообщения об ошибках зависимости диска и отсутствии файла.
Интенсив по Виртуализации VMware vSphere 7
Самое важное про виртуализацию и VMware vSphere 7 в 2-х часовом онлайн-интенсиве от тренера с 30-летним стажем. Для тех, кто начинает знакомство с виртуализацией и хочет быстро погрузиться в предметную область и решения на базе VMware
- В случае отсутствия файлов вы видите такие ошибки, как:
- В случае отсутствия файлов, в файле vmware.log виртуальной машины есть сообщения, похожие на:
- В случае сбоя зависимости снимка диска, в файле vmware.log виртуальной машины не будет ошибки «Невозможно найти указанный файл» (cannot find the file specified), но Вы увидите сообщения о том, что родительский виртуальный диск был изменён:
Эти ошибки могут возникать, если дескриптор диска виртуальной машины (VMDK) или файл данных отсутствуют или цепочка снимков стала несовместимой.
Решение
Это решение разбито на 2 части, в зависимости от проблемы:
- Вы не можете запустить виртуальную машину из-за ошибки system cannot find the file specified (Система не может найти указанный файл) или других ошибок, например — file not found (Файл не найден).
- Вы не можете запустить виртуальную машину из-за того, что the parent virtual disk has been modified since the child was created (Родительский виртуальный диск был изменён с момента создания дочернего диска).
System cannot find the file specified
Вы должны убедиться, что файлы диска виртуальной машины представлены должным образом.
- Для каждого диска, включая снимок диска, должен быть файл дескриптора в виде vmName.vmdk
- Кроме того, для базового диска также должен существовать файл с расширением flat.vmdk или separse.vmdk в виде vmName-flat.vmdk или vmName-separse.vmdk .
- Для снимка диска, должен быть файл с разрешением delta.vdmk или sesparse.vmdk в виде vmName-######-delta.vmdk или vmName-######-separse.vmdk .
Если файлы дескриптора отсутствуют, то Вам необходимо создать их заново.
Если файлы данных (-flat, -delta или –sparse) отсутствуют, возможно, потребуется восстановить виртуальную машину из резервной копии.
The parent virtual disk has been modified since the child was created
Эта проблема обычно возникает из-за несоответствия идентификатора содержимого (CID). Чтобы устранить несоответствие CID, необходимо отредактировать файлы дескрипторов VMDK, чтобы обеспечить согласованность цепочки снимков.
Дополнительная информация
Для дисков RDM не будет файла –flat или –sesparse для базового диска. Физический режим RDM будет иметь файл в виде vmName-rdmp.vmdk . Виртуальный режим RDM будет иметь файл в виде vmName-rdm.vmdk .
Если дескриптор RDMA отсутствует, его также можно создать заново.
Интенсив по Виртуализации VMware vSphere 7
Самое важное про виртуализацию и VMware vSphere 7 в 2-х часовом онлайн-интенсиве от тренера с 30-летним стажем. Для тех, кто начинает знакомство с виртуализацией и хочет быстро погрузиться в предметную область и решения на базе VMware
Полезно?
Почему?
😪 Мы тщательно прорабатываем каждый фидбек и отвечаем по итогам анализа. Напишите, пожалуйста, как мы сможем улучшить эту статью.
😍 Полезные IT – статьи от экспертов раз в неделю у вас в почте. Укажите свою дату рождения и мы не забудем поздравить вас.
Источник
Vmware disk is error free
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I got this error when creating a snapshot from a running VM.
After shutdown the VM, the snapshot can be taken. However, a snapshot is needed when the VM is running. Here is the error message. Please help!
Status: An error occurred while saving the snapshot: Object type requires hosted I/O.
Start Time: May 4, 2019 1:03:51 AM
Completed Time: May 4, 2019 1:04:05 AM
An error occurred while taking a snapshot: Object type requires hosted I/O.
An error occurred while saving the snapshot: Object type requires hosted I/O.
Additional Task Details:
VC Build: 10964411
Error Type: GenericVmConfigFault
Description Id: VirtualMachine.createSnapshot
Event Chain Id: 15566
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
synoboot.vmdk is not a ESXi format. You can not create snapshots for synoboot.vmdk before you convert it to ESXi format.
Apparently synoboot.vmdk was copied from Workstation or Fusion by somebody who was not aware of the different vmdk formats.
If you open synoboot.vmdk you will see that the createType is not VMFS but monolithicSparse.
DiskLib_Check() failed for source disk ‘synoboot-s001.vmdk’: The file specified is not a virtual disk (15).
So to sum it up — we are seeing expected behaviour here !
Power off the VM and run
vmkfstools -i synoboot.vmdk synoboot-esxi.vmdk
and then replace the WS-type vmdk with the newly created one.
After that is done you should be able to create a snapshot as expected.
________________________________________________
Do you need support with a VMFS recovery problem ? — send a message via skype «sanbarrow»
I do not support Workstation 16 at this time .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You may have virtual disk errors. Try steps outlined in this blog.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can run the VM without any issues. However I cannot run vmkfstools when the VM is running either. Fail to lock the file error:
[root@DELL790:/vmfs/volumes/5c513450-b2f92ad8-2534-00e04c802311/Synology] vmkfstools -x check synoboot.vmdk
DiskLib_Check() failed for source disk ‘synoboot.vmdk’: Failed to lock the file (16392).
After I shutdown the VM, all vmdk files are checked and I got no errors.
[root@DELL790:/vmfs/volumes/5c513450-b2f92ad8-2534-00e04c802311/Synology] ls -l *.vmdk
-rw——- 1 root root 1311232 May 4 13:22 synoboot-ctk.vmdk
-rw——- 1 root root 32374784 May 4 12:48 synoboot-s001.vmdk
-rw——- 1 root root 566 May 4 12:46 synoboot.vmdk
[root@DELL790:/vmfs/volumes/5c513450-b2f92ad8-2534-00e04c802311/Synology] vmkfstools -x check synoboot.vmdk
Disk is error free
[root@DELL790:/vmfs/volumes/5c513450-b2f92ad8-2534-00e04c802311/Synology] vmkfstools -x check synoboot-ctk.vmdk
DiskLib_Check() failed for source disk ‘synoboot-ctk.vmdk’: The file specified is not a virtual disk (15).
[root@DELL790:/vmfs/volumes/5c513450-b2f92ad8-2534-00e04c802311/Synology] vmkfstools -x check synoboot-s001.vmdk
DiskLib_Check() failed for source disk ‘synoboot-s001.vmdk’: The file specified is not a virtual disk (15).
[root@DELL790:/vmfs/volumes/4e5f91c0-eb76a861-cbb4-00e04c802311/Synology] ls -l *.vmdk
-rw——- 1 root root 6554112 May 4 13:22 Synology-ctk.vmdk
-rw——- 1 root root 429496729600 May 4 13:22 Synology-flat.vmdk
-rw——- 1 root root 614 May 4 12:46 Synology.vmdk
[root@DELL790:/vmfs/volumes/4e5f91c0-eb76a861-cbb4-00e04c802311/Synology] vmkfstools -x check Synology.vmdk
Disk is error free
[root@DELL790:/vmfs/volumes/4e5f91c0-eb76a861-cbb4-00e04c802311/Synology] vmkfstools -x check Synology-ctk.vmdk
DiskLib_Check() failed for source disk ‘Synology-ctk.vmdk’: The file specified is not a virtual disk (15).
[root@DELL790:/vmfs/volumes/4e5f91c0-eb76a861-cbb4-00e04c802311/Synology] vmkfstools -x check Synology-flat.vmdk
DiskLib_Check() failed for source disk ‘Synology-flat.vmdk’: The file specified is not a virtual disk (15).
I have two disks for this VM. Please check the settings below.
Источник
Fixing virtual disk errors in VMware
As a developer, I tend to use VMs extensively to test new features and deploy software that I wouldn’t like running on my main machine. VMware is brilliant in that it offers a free tool to create and run VMs — VMware Player.
As handy and great VMs are, they are also quite volatile and tend to break or get corrupt easily. If your host machine restarts unexpectedly or if the VM is not shut down properly etc. you may then experience issues the next time you try to restart. Below I have described how to resolve 3 of the most common corruption errors. The best place to look for issues, if not otherwise advised by the actual player is in the VMware log file which can be found at the directory where your VM is running from. I have a c:Virtual Machines directory for all my VMs.
1. The VM takes for ever to load/startup or presents you with a black screen and no progress
Close down VMware Player. Go to the directory where your VM files reside, search for and delete all directories and files ending in .lck
2. Warning: the system was unable to load a page of memory; this can be caused by network problems or a failing hard disk drive.
Go to the directory that your VM files reside, search for and delete all .vmem and .vmss files. These files hold the state of you VM before it was last shut down and are used to restore it to this state during start-up. If these files are corrupt for some reason, the VM startup will show the error above. Deleting these files allows you to reboot your VM OS with a clean slate.
3. Cannot open the disk ‘path of vmdk’ or one of the snapshot disks it depends on. Reason: the specific virtual disk needs repair
In this case, one of the vmdk files I corrupt and needs repairing. To fix this error, download and install the Virtual Disk Development Kit here (registration is required i’m afraid!)
Follow the steps below:
- Open the command line (cmd.exe)
- Navigate to the local installation of your VMware Dev kit (mine is the default C:Program FilesVMWareVirtual Disk Development Kitbin
- Type the following command “vmware-vsdiskmanager.exe” –R “the fully qualified path to your corrupt vmdk”
- Hit Enter
You should see the following message:
“The virtual disk “path of your corrupt vmdk file” was corrupted and has been successfully repaired.
Источник
Vmware disk is error free
While trying to deploy a VM on VMware ESXi 6.0, with 1.6 TB free storage capacity, the ESXi is throwing the following error message:
2016-02-02T17:22:48.296Z| vmx| I120: Msg_Question:
2016-02-02T17:22:48.296Z| vmx| I120: [msg.vmxaiomgr.retryabort.diskfull] The operation on the file «/vmfs/devices/deltadisks/17cf42b6-xyz-x86-64-101-2020201.0-s001.vmdk» failed (Bad address).
2016-02-02T17:22:48.296Z| vmx| I120+ The file system where disk «/vmfs/devices/deltadisks/17cf42b6-xyz-x86-64-101-2020201.0-s001.vmdk» resides is full.
2016-02-02T17:22:48.296Z| vmx| I120+ Select _Retry to attempt the operation again.
2016-02-02T17:22:48.296Z| vmx| I120+ Select Cancel to end the session.
Details of the configuration:
ESXi deployed on a system with sufficient RAM (above 32GB), 1.6 TB available space in the data Store.
The VM configuration is 2 GB RAM and VMversion 10, 25 GB Hard Disk space.
Hard disk Configured as LSI Logical SAS, ID (0:0)
Verified the /vmfs/devices/deltadisks directory and found the space to be occupied by only the image for the VM in consideration, i.e. 17cf42b6-xyz-x86-64-101-2020201.0-s001.vmdk of 25GB
The ESX doesn’t contain any other running Virtual Machines.
Can anyone suggest what is going wrong or what is happening with the system?
vmkernel.log shows the following from boot up to the point the error message is displayed:
2016-02-02T18:14:12.570Z cpu6:2696186)Sched: vm 2696217: 6485: Adding world ‘vmm0:VR_new’, group ‘host/user’, cpu: shares=-1 min=-1 minLimit=-1 max=-1, mem: shares=-1 min=-1 minLimit=-1 max=-1
2016-02-02T18:14:12.570Z cpu6:2696186)Sched: vm 2696217: 6500: renamed group 19676636 to vm.2696186
2016-02-02T18:14:12.570Z cpu6:2696186)Sched: vm 2696217: 6517: group 19676636 is located under group 4
2016-02-02T18:14:12.578Z cpu6:2696186)MemSched: vm 2696186: 8113: extended swap to 43176 pgs
2016-02-02T18:14:12.590Z cpu6:2696186)WARNING: MemSched: 6236: Psharing is disabled but ballooning is not.
2016-02-02T18:14:12.888Z cpu1:2696217)VMMVMKCall: 235: Received INIT from world 2696217
2016-02-02T18:14:12.890Z cpu1:2696261)WARNING: NetDVS: 658: portAlias is NULL
2016-02-02T18:14:12.890Z cpu1:2696261)Net: 2444: connected VR_new eth0 to VM Network, portID 0x3000018
2016-02-02T18:14:12.890Z cpu1:2696261)NetPort: 1573: enabled port 0x3000018 with mac 00:00:00:00:00:00
2016-02-02T18:14:12.900Z cpu19:34872)Config: 679: «SIOControlFlag2» = 0, Old Value: 1, (Status: 0x0)
2016-02-02T18:14:50.454Z cpu7:33407)NMP: nmp_ResetDeviceLogThrottling:3345: last error status from device naa.600605b006c4ed401b2488fc33246435 repeated 1 times
2016-02-02T18:14:57.089Z cpu1:2696229)WARNING: UserMem: 13591: vpn 0xb0048e81 status bad0026
2016-02-02T18:14:57.094Z cpu1:2696229)WARNING: UserMem: 13591: vpn 0xb0048ea1 status bad0026
2016-02-02T18:15:05.676Z cpu1:2696229)WARNING: UserMem: 13591: vpn 0xb003d116 status bad0026
2016-02-02T18:15:05.676Z cpu1:2696229)WARNING: UserMem: 13591: vpn 0xb003d116 status bad0026
2016-02-02T18:15:05.676Z cpu1:2696229)WARNING: UserMem: 13591: vpn 0xb003d116 status bad0026
2016-02-02T18:15:05.676Z cpu1:2696229)WARNING: UserMem: 13591: vpn 0xb003d116 status bad0026
2016-02-02T18:15:05.676Z cpu1:2696229)WARNING: UserMem: 13591: vpn 0xb003d116 status bad0026
2016-02-02T18:15:05.676Z cpu1:2696229)WARNING: UserMem: 13591: vpn 0xb003d116 status bad0026
Источник
VM wil not power-on and throws the following error:
Object type requires hosted I/O
SSH into the ESX-host that’s hosting the VM.
Browse to the VM-folder containing the disk files.
Run the following command:
vmkfstools -x check “disk.vmdk”
Disk needs repaired
vmkfstools -x repair “disk.vmdk”
Disk was successfully repaired.
Start VM from vCenter
Note: Thanks for all the replies. I’m glad I could be of service.
24 Responses to Object type requires hosted I/O
-
Robert Cipriani says:
Any idea why this would happen repeatedly for the same VM? I’m running Home Assistant in a VM. It’s a thick provisioned, lazily zeroed IDE disk, some flavor of Linux (I think Ubuntu). No issues with any other VMs.
-
i96danma says:
Exactly the same case as me, although I don’t have a lot of other VMs to compare to.
Btw, thanks Tim for a refreshingly short and concise how-to! 👍 -
Marcus says:
I have exactly the same issue – I run a large number of data centers and don’t have these issues except where I have deployed Home Assistant from their VMDK.
-
GM says:
exact same issue here.
-
-
Thank you! First result on Google and resolved my issue in seconds!
-
campur says:
Thank you!
First result on Google and resolved my issue in seconds!
🙂 -
Same here, HomeAssistant is the only VM I’ve ever seen do this.
-
Jon says:
same here, just happened with my HomeAssistant VM on ESX7, whoever built this VM didnt do a very good job
-
-
LexxOne says:
And yet another ditto — Home Assistant VMDK. There seems to be pattern emerging ;-P. Thanks Tim.
-
darishante says:
I’m pretty sure this page just saved my life. Thank you, sir.
-
Pingback: vmware Object type requires hosted I/O | Konkretor Blog, IT Stuff and more
-
Andrew says:
Another homeassistant user with the same issue. Thank you for posting!
-
Artem Baranov says:
Thank you, sir! Yet another bad HA vmdk drive was repaired)
-
safadig2015safadig says:
ditto..and another one .. Home Assistant VMDK bug
-
Ronny says:
Yup, another Home Assistant user here! Thanks! 🙂
-
Christian Haugen Matvik says:
-
Paul says:
Thanks so much for this! I moved my lan to a different subdomain (so that I can use proper SSL certificates). vCenter does NOT like this one bit, so after hours of debugging I had to disconnect vCenter from vSphere and just destroy it. Finally left with just vSphere and everything worked apart from Home Assistant.
In my case, I had additional drive images such as “hassos_ova-3.10-s001.vmdk” and “hassos_ova-3.10-s002.vmdk”.
If you have similar, you can just ignore these.
You get an error saying they are not a virtual disk and you can’t run the check tool on them anyway.Repairing the main “hassos_ova-3.10.vmdk” disk image got my HA instance back up and running. Thankyou!
-
Marcheta says:
Thanks you mate…
-
Lee says:
Another HomeAssistant user save by this!
Thank you.
-
Danny says:
Guess Im not the only HA user with this problem 🙂
-
Paul says:
I just had this error a 2nd time (I’m the same Paul as above).
My VM is actually running and operational, but Im trying to back up the VM using Synology Backup for Business. Over 20 VMs backup without problem, but this hassos VM fails with the same error… ‘Cannot take snapshot: Object type requires hosted I/O’There’s something really messed up about how this VM image was set up. I’m thinking I may just recreate it from scratch, instead of using the VM they provide.
-
Casper says:
Same here with HomeAssistant
-
Just had this issue with HA. 2 years after this post was first created, it’s still helping out people like me. Thanks!
-
Lexa Connexa says:
Same as everyone else, my HA created from the provided VMDK a meer two weeks ago had this problem today after a reboot. Thanks so much for the quick and easy instructions Tim, this was just what I needed today.
Leave a Reply
There IS something funky with distributions of the the vmdk
Snap shoting or attempting to clone the VM from disk image https://github.com/home-assistant/hassos/releases/download/2.11/hassos_ova-2.11.vmdk.gz
or
https://github.com/home-assistant/hassos/releases/download/3.5/hassos_ova-3.5.vmdk.gz
(the two I tried)
Fails with Object type requires hosted I/O
In Esxi 6.7 the Guest log file:
2019-11-11T03:39:17.573Z| vmx| A100: ConfigDB: Setting ide0:1.redo = «»
2019-11-11T03:39:17.573Z| vmx| I125: DISK: OPEN ide0:1 ‘/vmfs/volumes/86cb31ac-0843a890/Home/hassos_ova-3.5.vmdk’ persistent R[]
2019-11-11T03:39:17.578Z| vmx| I125: DISKLIB-LINK : «/vmfs/volumes/86cb31ac-0843a890/Home/hassos_ova-3.5.vmdk» : failed to open (Object type requires hosted I/O).
2019-11-11T03:39:17.578Z| vmx| I125: DISKLIB-CHAIN : «/vmfs/volumes/86cb31ac-0843a890/Home/hassos_ova-3.5.vmdk» : failed to open (Object type requires hosted I/O).
2019-11-11T03:39:17.590Z| vmx| I125: DISKLIB-DSCPTR: Opened [0]: «hassos_ova-3.5-s001.vmdk» (0x10a)
2019-11-11T03:39:17.590Z| vmx| I125: DISKLIB-LINK : Opened ‘/vmfs/volumes/86cb31ac-0843a890/Home/hassos_ova-3.5.vmdk’ (0x10a): twoGbMaxExtentSparse, 41943040 sectors / 20 GB.
2019-11-11T03:39:17.590Z| vmx| I125: DISKLIB-LIB : Opened «/vmfs/volumes/86cb31ac-0843a890/Home/hassos_ova-3.5.vmdk» (flags 0x10a, type twoGbMaxExtentSparse).
I found a work around:
Shutdown the VM and check the disk with vmkfstools
[root@esx01:/vmfs/volumes/yahda/Home] vmkfstools -x check hassos_ova-3.5.vmdk
Disk is error free
Then cloned it
[root@esx01:/vmfs/volumes/yahda/Home] vmkfstools -i hassos_ova-3.5.vmdk -d thin hassos_ova-3.5thin.vmdk
Destination disk format: VMFS thin-provisioned
Cloning disk 'hassos_ova-3.5.vmdk'...
Clone: 100% done.
Drop the original disk from the vm and add the hassos_ova-3.5thin.vmdk
Snapshots or cloning of the VM won’t work until you do this, something in the build process is messing up the VMDK.
-
jbennett
- Enthusiast
- Posts: 33
- Liked: 12 times
- Joined: Jun 23, 2015 3:47 pm
- Full Name: Justin Bennett
- Location: Los Angeles, CA
- Contact:
Backup Fails on VMs with VMware Tools Quiescence Enabled
We’ve been backing up these VMs for months successfully with VMware Tools Quiescence disabled. They’re all running on a single ESXi 6.0 host, all VMs running Windows Server 2012 R2 and VMware Tools build 9536.
The other day, I enabled «VMware Tools Quiescence», the backup job kicked off a failure to create snapshot «an error occurred while saving the snapshot: failed to quiesce the virtual machine». Other 2012 and 2012 R2 VMs with the same VMware Tools build had no issue backing up from the same host.
Found four related articles — none resolved the issue.
http://kb.vmware.com/selfservice/micros … Id=1002310
http://kb.vmware.com/selfservice/micros … Id=2034002
http://kb.vmware.com/selfservice/micros … Id=2069952
http://kb.vmware.com/selfservice/micros … Id=2006849
I’ve confirmed that the OS is receiving Event Log Errors 140, 157, 12289. I’ve tried shutting down the VMs, reinstalling VMware Tools, and rebooting them. No luck.
What DID fix the issue. I migrated the VMs to a newer ESXi host and upgraded VMware Tools to build 9541. This «appears» to have resolved / fixed issue. I’m am seeing Event Log Errors for 147, 150, 12289, but the backup is now completing when creating the snapshot. I’m going to migrate the VMs back during an off hour and test backup again — (going from virtual standard switch (VSS) to virtual distributed switch (VDS) is ok, but its failing to migrate from VDS to VSS).
Best of luck!
-Justin
[@cajeeper]|[http://www.allthingstechie.net]
-
jbennett
- Enthusiast
- Posts: 33
- Liked: 12 times
- Joined: Jun 23, 2015 3:47 pm
- Full Name: Justin Bennett
- Location: Los Angeles, CA
- Contact:
Re: Backup Fails on VMs with VMware Tools Quiescence Enabled
Post
by jbennett » Dec 16, 2015 11:10 pm
We are also using Application Aware Image Processing. We’ve been told VMware Tools Quiescence may help limit/minimize the snapshot VM stun — is this incorrect?
-Justin
[@cajeeper]|[http://www.allthingstechie.net]
-
jbennett
- Enthusiast
- Posts: 33
- Liked: 12 times
- Joined: Jun 23, 2015 3:47 pm
- Full Name: Justin Bennett
- Location: Los Angeles, CA
- Contact:
Re: Backup Fails on VMs with VMware Tools Quiescence Enabled
Post
by jbennett » Dec 16, 2015 11:34 pm
I take that back — upon further inspection, these VMs do not have Application Aware Processing, because their network connection live beyond access of our Veeam B&R server. They’re only accessible from our station network, not our server network.
-Justin
[@cajeeper]|[http://www.allthingstechie.net]
-
mkretzer
- Veeam Legend
- Posts: 982
- Liked: 288 times
- Joined: Dec 17, 2015 7:17 am
- Contact:
Re: Backup Fails on VMs with VMware Tools Quiescence Enabled
Post
by mkretzer » Dec 17, 2015 7:21 am
1 person likes this post
Hello,
we have this issue since VMware tools 10 which is included in the latest ESX 5.5U3.
It seems like 50 % of our tools upgraded VMs can no longer be quienced.
We opened a VMware ticket.
MK
-
Vitaliy S.
- Product Manager
- Posts: 26108
- Liked: 2482 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Backup Fails on VMs with VMware Tools Quiescence Enabled
Post
by Vitaliy S. » Dec 17, 2015 10:36 am
jbennett wrote:We’ve been told VMware Tools Quiescence may help limit/minimize the snapshot VM stun — is this incorrect?
Yes, there is no difference in how VM snapshot is committed, so this shouldn’t be the case. If you want to minimize the impact of snapshot commit operation, then integration with storage snapshots will definitely help here. Also we have an existing topic discussing this issue, please check it out, should be useful.
mkretzer wrote:we have this issue since VMware tools 10 which is included in the latest ESX 5.5U3.
It seems like 50 % of our tools upgraded VMs can no longer be quienced.
Does this also happen when you create VM snapshots manually via vSphere Client?
-
jbennett
- Enthusiast
- Posts: 33
- Liked: 12 times
- Joined: Jun 23, 2015 3:47 pm
- Full Name: Justin Bennett
- Location: Los Angeles, CA
- Contact:
Re: Backup Fails on VMs with VMware Tools Quiescence Enabled
Post
by jbennett » Dec 17, 2015 3:27 pm
PTide wrote:Have you considered using VIX API?
I like the VIX API option, but really, we need to reconfigure our VMs so Veeam can communicate with them. These systems that were erring are only RDP Hosts and I wasn’t really too concerned about application aware processing, but its nice to at least have the VMware Tools Quiesce function working — thus sharing all the info.
Vitaliy S. wrote:Yes, there is no difference in how VM snapshot is committed, so this shouldn’t be the case. If you want to minimize the impact of snapshot commit operation, then integration with storage snapshots will definitely help here. Also we have an existing topic discussing this issue, please check it out, should be useful.
We’ve been considering storage integration and been testing it out. Unfortunately, our current SANs are either not compatible or need major upgrading — besides the Ent Plus upgrade.
Thank you for this information about VIX API and storage snapshot integration.
-Justin
[@cajeeper]|[http://www.allthingstechie.net]
-
jbennett
- Enthusiast
- Posts: 33
- Liked: 12 times
- Joined: Jun 23, 2015 3:47 pm
- Full Name: Justin Bennett
- Location: Los Angeles, CA
- Contact:
Re: Backup Fails on VMs with VMware Tools Quiescence Enabled
Post
by jbennett » Dec 17, 2015 3:50 pm
FYI
I’ve just confirmed that the problem persisted after migrating the VMs back to the original ESXi host. The build number of the ESXi host showing the issue is 6.0.0, 2494585. So, my initial thought of upgrading VMware Tools from build 9536 going to build 9541 being a «fix» was wrong and meant nothing towards my issue.
The ESXi host that seemed to resolve the issue once the VMs were migrated to it is build number 6.0.0, 3247720.
I’m planning on patching the troubled ESXi host soon and I’ll report if upgrading it to the latest build makes any change.
-Justin
[@cajeeper]|[http://www.allthingstechie.net]
-
jbennett
- Enthusiast
- Posts: 33
- Liked: 12 times
- Joined: Jun 23, 2015 3:47 pm
- Full Name: Justin Bennett
- Location: Los Angeles, CA
- Contact:
Re: Backup Fails on VMs with VMware Tools Quiescence Enabled
Post
by jbennett » Dec 21, 2015 4:26 pm
2 people like this post
After updating the ESXi host running the VMs from 6.0.0, 2494585 to 6.0.0, 3247720 this weekend, the issue has appeared to been resolved — backups with VMware Tools Quiescence enabled and no snapshot issues. The solution maybe in the ESXi host’s build or maybe in the ESXi host’s reboot, not sure — just giving my feedback.
Good luck!
-Justin
[@cajeeper]|[http://www.allthingstechie.net]
-
btmaus
- Expert
- Posts: 138
- Liked: 10 times
- Joined: Jul 17, 2015 9:02 am
- Full Name: Glenn L
- Contact:
Re: Backup Fails on VMs with VMware Tools Quiescence Enabled
Post
by btmaus » Dec 22, 2015 9:26 am
mkretzer wrote:we have this issue since VMware tools 10 which is included in the latest ESX 5.5U3.
Same here, also experiencing the issue since going to 5.5U3a. VMs are in a DMZ network that VBR cannot reach, so have to use VMware Quiesce.
-
Vitaliy S.
- Product Manager
- Posts: 26108
- Liked: 2482 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: Backup Fails on VMs with VMware Tools Quiescence Enabled
Post
by Vitaliy S. » Dec 22, 2015 10:17 am
btmaus wrote:VMs are in a DMZ network that VBR cannot reach, so have to use VMware Quiesce.
You can use AAIP option for DMZ VMs too, network connection from VBR server to protected VMs is not required. Pre-freeze process can be done via VIX API, moreover it is done automatically if direct network connection cannot be used.
Who is online
Users browsing this forum: Majestic-12 [Bot] and 17 guests
I ran into a situation where the host had crashed because of a driver problem (vmw_ahci). After changing the driver and rebooting the host, one of the guest VMs then failed to power on with the following errors:
- File system specific implementation of LookupAndOpen[file] failed
- Object type requires hosted I/O
- Cannot open the disk ‘…vmdk’ or one of the snapshot disks it depends on.
- Module ‘Disk’ power on failed.
- Failed to start the virtual machine.
The solution was to repair the disk using vmkfstools. This particular VM was split into two files, vmname.vmdk and vmname-s001.vmdk. You will want to perform the commands on the primary (pointer) vmdk (not vmname-s###.vmdk).
From the ESXi console, issue the following command substituting your actual path:
vmkfstools -x check /path/to/vmname.vmdk
In this case vmkfstools reported that the disk should be repaired. It would be prudent at this point to back up your vmdk files before trying the repair. Then initiate the repair on the primary vmdk with:
vmkfstools -x repair /path/to/vmname.vmdk
Once you get a notification that the repair has completed, try to start your VM again.
This entry was posted in Uncategorized. Bookmark the permalink.