3 Replies Latest reply on Mar 2, 2014 11:52 AM by pkam

    is ghetto compatible with ESXi 5.1u2 (build-1483097)

    pkam Novice

      Hi,

       

      recently I have updated on of my ESXi host to build-1483097.

      I downloaded the last ghettoVCB and updated config.

      I am getting error:

       

      2014-02-28 07:23:20 -- info: ERROR: failed to locate and extract VM_ID for win7!

      2014-02-28 07:23:20 -- info: ERROR: failed to locate and extract VM_ID for centos6!

       

      There are no spaces nor strange characters in VM names:

       

      # /usr/bin/vim-cmd vmsvc/getallvms

      Vmid    Name                   File                     Guest OS        Version   Annotation

      1      solaris   [datastore1] solaris/solaris.vmx   solaris10_64Guest   vmx-08             

      2      centos6   [nfs_esxi_centos6] centos6.vmx     rhel6_64Guest       vmx-08             

      4      win7      [nfs_esxi_windows7] win7.vmx       windows7Guest       vmx-08             

       

      My backup DS is NFS (ZFS based on omnios).

      Backup used to work properly before upgrades.

      I cannot think of any reason why that fails.

       

      Reagrds

      Piotr

        • 1. Re: is ghetto compatible with ESXi 5.1u2 (build-1483097)
          pkam Novice

          Replying to myself.

          I think I found the bug: the "failed to locate and extract VM_ID" error happens when a VM is located in root directory of a datastore.

           

          After the following steps:

          - shutdown VM

          - remove VM from ESXi

          - go to VM dir

          - ln -s . centos6

          - re-add the VM to ESXi

          - launch VM

           

          it is working OK.

          Just cannot believe nobody had hit this yet.

           

          Regards,

          Piotr

          • 2. Re: is ghetto compatible with ESXi 5.1u2 (build-1483097)
            Phatsta Enthusiast

            Usually you get this when you have a vm in the backup list that doesn't exist in the datastore, but it may be different in your case of course - and I'm glad you found the solution.

             

            I just want to say this once and for all; Whenever I have a problem with ghetto, I know it's almost always my own fault. You have to be humble about these things. Every, and I mean every, of my cases where I've setup ghetto it's succeded after I take away all the simple things like the backup volume being too small, the config being wrong or simply typing wrong. A common thing in my configs is that I copy an old config thats incorrect with the log date thing... there should be just one slash ( / ) but there are too many because Windows f***s it up I think. All in all, if you follow lamw's recommendations to the letter, it'll work 99% of the time. Just my exp. Thanks lamw for putting down the time to make this excellent script that works like a dream on the 50+ systems I manage. Really, thanks! ($ going your way when I get my cranky boss to cough it up).

             

            /Daniel Jokinen

            Linford Communication

            Sweden

            • 3. Re: is ghetto compatible with ESXi 5.1u2 (build-1483097)
              pkam Novice

              You are perfectly right and I admire the author of ghettoVCB script as much as you do.

              However, in this case, I cannot confirm I had a _bug_ in my config. What I had done was a _change_ to original config, but I had found no information about this being illegal. My scenario is as follows: I use NFS datastores (derived from ZFS based machine) for my VMs. Originally, when you create a VM inside a DS, ESXi puts files into a directory called the same as VM name (if you create "win7" VM, ESXi will create "win7" directory and put files there). Because I have different DS for each machine, the directories are not necessary for me. So, besides ESXi upgrade, I made some changes and put my VMs info root directory of their datastores, what I have not found being not allowed. However this is what makes ghettoVCB script fail.

               

              Regards,

              Piotr