I have never get success running vcbBackup nor vcbSbapshot commands on an VMWARE ESX server 3.5, for GENTOO virtual machines with vmware tools are installed up (those given with VMWARE ESX 3.5, up to date as we have support for vmware). I tried on different kernels without success and got no help from VMWARE as GENTOO is not supported by VMWARE ESX (this is their answer), what they immediatly noticed in /var/log/vmware/hostd.log and maybe could help us to understand : [2008-05-20 14:34:12.895 'VmMisc' 20671408 warning] Failed to find conversion from Gentoo to type: vim.vm.GuestOsDescriptor.GuestOsIdentifier [2008-05-20 14:34:12.904 'TaskManager' 33352624 info] Task Created : haTask-160-vim.VirtualMachine.createSnapshot-226 [2008-05-20 14:34:12.906 'vm:/vmfs/volumes/4798d109-84a47628-b0e3-001c23cf9d48/srv042-bes/srv042-bes.vmx' 33352624 info] State Transition (VM_STATE$ [2008-05-20 14:34:12.909 'VmMisc' 33352624 warning] Failed to find the guest family for guestos: Gentoo [2008-05-20 14:34:12.923 'ThreadPool' 33352624 panic] Worker: Unhandled exception: vmodl.fault.InvalidArgument [2008-05-20 14:34:12.923 'ThreadPool' 33352624 panic] Backtrace: [00] eip 0x12356ee [01] eip 0x10ff789 [02] eip 0x10b2925 [03] eip 0x91413fe [04] eip 0x9171ac3 [05] eip 0x917114a [06] eip 0x913cc4a [07] eip 0x1244db2 [08] eip 0x123f1c2 [09] eip 0x1243b8a [10] eip 0x123a7d7 [11] eip 0x885dd8 [12] eip 0x6656fca [2008-05-20 14:34:22.229 'VmMisc' 58235824 warning] Failed to find conversion from Gentoo to type: vim.vm.GuestOsDescriptor.GuestOsIdentifier [2008-05-20 14:34:52.231 'VmMisc' 20671408 warning] Failed to find conversion from Gentoo to type: vim.vm.GuestOsDescriptor.GuestOsIdentifier Many thanks for gentoo team help ! Reproducible: Always Steps to Reproduce: 1.install gentoo in an VMWARE ESX server 3.5, as a Virtual Machine (simply use existing one if you prefer 2.log on ESX console as user root 3.run command : vcbMounter -h localhost -a moref:nnn -r /some/where/to/backup adapt moref and target dir to your needs, you can get moref value using command :"vcbVmName -h localhost -s any" or use any other solution to point to vm (it does not make any difference ...) 4: then, you must restart vmware management services to unlock VMWARE console, (or it stay locked for days .... and VMWARE ESX hangs ) /etc/init.d/mgmt-vmware restart Actual Results: vcbMounter -h localhost -a moref:160 -r /backup/srv042-bes [2008-05-20 14:46:41.967 'App' 3076449088 info] Current working directory: /vmfs/volumes/4796227e-f62fb888-efda-001c23cf9d48/backup Password: Expected Results: Should backup VM : [root@srv050-bes backup]# vcbMounter -h localhost -a moref:160 -r /backup/srv042-bes [2008-05-20 15:04:54.899 'App' 3076457280 info] Current working directory: /vmfs/volumes/4796227e-f62fb888-efda-001c23cf9d48/backup Password: Copying "[DS_Others] srv042-bes/srv042-bes.vmx": 0%=====================50%=====================100% ************************************************** Copying "[DS_Others] srv042-bes/srv042-bes.nvram": 0%=====================50%=====================100% ************************************************** Copying "[DS_Others] srv042-bes/vmware-115.log": 0%=====================50%=====================100% ************************************************** Copying "[DS_Others] srv042-bes/vmware-116.log": 0%=====================50%=====================100% ************************************************** Copying "[DS_Others] srv042-bes/vmware-117.log": 0%=====================50%=====================100% ************************************************** Copying "[DS_Others] srv042-bes/vmware-112.log": 0%=====================50%=====================100% ************************************************** Copying "[DS_Others] srv042-bes/vmware-113.log": 0%=====================50%=====================100% ************************************************** Copying "[DS_Others] srv042-bes/vmware-114.log": 0%=====================50%=====================100% ************************************************** Copying "[DS_Others] srv042-bes/vmware.log": 0%=====================50%=====================100% ************************************************** Converting "/backup/srv042-bes/scsi0-0-0-srv042-bes_boot.vmdk" (compact file): 0%=====================50%=====================100% ************************************************** Converting "/backup/srv042-bes/scsi0-1-0-srv042-bes.vmdk" (compact file): 0%=====================50%=====================100% ************************************************** simply removing vmware tool module 'vmhgfs' from gentoo VM make backup possible but prevent VM tools talking to ESX. It looks like if ESX cannot stand GenToo linux VMs ...
Confirmed, I have exactly the same problem with VMware ESX 3.5. VMware ESX 3.0 worked fine. Did you find any possible solution for this Patrick?
I seem to have found a possible solution here: http://communities.vmware.com/thread/125432 # echo "Red Hat Enterprise Linux AS release 3 (Fake FC4)" > /etc/redhat-release I'll let you know if it works. It seems to me that VMware should just look at the OS type specified by the user when the VM was created if it fails to resolve it at runtime. It looks like a large bug in their software. FYI, I'm currently running all available ESX patches (build 95350).
I'm not sure how we can help with this, however, could I ask that you try using the open-vm-tools, rather than those provided as part of ESX and let me know if there's any difference? I don't know if vmware tools is related to the problem, but if so, it's much easier for us to work on and maintain open-vm-tools than it is the pre-distributed tools...
I can confirm that the solution suggested earlier works correctly (although it's only a workaround). However, the automatic vmware-tools upgrade will fail with /etc/redhat-release in place. Therefore, /etc/redhat-release should be removed when installing/upgrading vmware tools and be recreated afterwards. Mike: Thank you for your quick response. I don't believe there is anything Gentoo can do about this issue. However, it's important to leave to bug open until VMware fixes it so other people can learn from it. The problem only exists when using the vcSnapshot and vcBackup tools. When making a regular snapshot through the Virtual Infrastructure Client, the problem doesn't occur. VMware should add Gentoo to the vim.vm.GuestOsDescriptor.GuestOsIdentifier list on the ESX server side so Gentoo gets recognized and treated like other26xLinuxGuest. Also they should at least build in a fail-safe to prevent jobs from getting completely stuck and can only be fixed by an ESX reboot. Unfortunately, I'm not in a position at this time to do any more testing since the VMware server is a critical production system. Hopefully I'll get to it at a later time, or someone else will pick it up.
correction: I meant vcbBackup and vcbSnapshot instead of 'vc*'.
Many thank's to all for your help. I confirm that # echo "Red Hat Enterprise Linux AS release 3 (Fake FC4)" > /etc/redhat-release works fine ! this solution is exactly what I was looking. VMWARE support teams could give some help just suggesting to try such things. They simply refused to help us and we had to look closer to re-install our ESX servers with another distro. hopefully, we still have gentoo and we will be able to keep gentoo. many thank's to all gentoo people !
Is this still a problem with current versions?
(In reply to Andreas K. Hüttel from comment #7) > Is this still a problem with current versions? No reply.
