0 Replies Latest reply on Apr 21, 2017 11:11 PM by DerekShaw

    why does ghettovcb-restore.sh rename my vmdks, and can I prevent that?

    DerekShaw Enthusiast

      so after years of using ghettovcb.sh and occasionally restoring a vmdk or machine, or moving them to a new esxi server "manually" (using cp and vmkfstools -i), I finally had a big-enough job that I decided it was worthwhile to look at ghettovcb-restore.sh (retiring an 8-year-old box and moving the machines to a new home).

       

      Well, that was nice!  Way easier!

       

      But...  I have carefully standardized my processes across a number of clients, and one of those standards is reflected in what I name the vmdks on various multi-disk machines, especially linux servers (think root.vmdk, boot.vmdk, usr.vmdk home.vmdk...)

       

      So now I have a bunch of machines with vmname-0.vmdk, vmname-1.vmdk vmname-2.vmdk, etc. that I want to rename back to something meaningful.  I know how to do this, and it's not really that onerous (except for my propensity for typos), but I'd like to avoid it in the future.

       

      Anybody got any input on maintaining vmdk names when restoring vms with the restore script? I'd like to hack on it, but I have too big a backlog of promises to keep.

       

      Thanks in advance!

      d.

       

      PS - it also appears that the log file is over-written for each line/vm in the file "vms_to_restore" -- that is:

       

      cat /vmfs/volumes/backupstore0/ghettoVCB/vms_to_restore

      #"<DIRECTORY or .TGZ>;<DATASTORE_TO_RESTORE_TO>;<DISK_FORMAT_TO_RESTORE>;<OPTIONAL_RESTORED_VM_DISPLAY_NAME>"

      # DISK_FORMATS

      # 1 = zeroedthick

      # 2 = 2gbsparse

      # 3 = thin

      # 4 = eagerzeroedthick

      # e.g.

      # "/vmfs/volumes/dlgCore-NFS-bigboi.VM-Backups/WILLIAM_BACKUPS/VCAP/VCAP-2009-08-18--1;/vmfs/volumes/himalaya-local-SATA.RE4-GP:Storage;1"

      "/vmfs/volumes/backupstore0/_ghettobackups/trac/trac-2017-04-22_01-26-09;/vmfs/volumes/datastore0;3"

      "/vmfs/volumes/backupstore0/_ghettobackups/legacy0/legacy0-2017-04-22_01-26-09;/vmfs/volumes/datastore0;3"

      "/vmfs/volumes/backupstore0/_ghettobackups/sageserver/sageserver-2017-04-22_01-26-09;/vmfs/volumes/datastore0;3"

      "/vmfs/volumes/backupstore0/_ghettobackups/sageclient1/sageclient1-2017-04-22_01-26-09;/vmfs/volumes/datastore0;3"

      "/vmfs/volumes/backupstore0/_ghettobackups/VIW-WiFi_D-Link-CWM/VIW-WiFi_D-Link-CWM-2017-04-22_01-26-09;/vmfs/volumes/datastore0;3"

      "/vmfs/volumes/backupstore0/_ghettobackups/crm-server/crm-server-2017-04-22_01-26-09;/vmfs/volumes/datastore0;3"

      "/vmfs/volumes/backupstore0/_ghettobackups/heidi_tools_win7/heidi_tools_win7-2017-04-22_01-26-09;/vmfs/volumes/datastore0;3"

       

      when invoked with this command:

      /vmfs/volumes/backupstore0/ghettoVCB/ghettoVCB-restore.sh -c /vmfs/volumes/backupstore0/ghettoVCB/vms_to_restore -l /vmfs/volume/backupstore0/_ghettobackups/ghettoVCB-restore-$(date +%Y-%m-%d:%R:%S).log

       

      yields this logfile

      ghettoVCB-restore-2017-04-22:04:30:55.log

       

      containing only this:

      [root@nas1 /viw1pool/esxi_backupstore0/_ghettobackups]# cat ghettoVCB-restore-2017-04-22\:04\:30\:55.log

      Option --adaptertype is deprecated and hence will be ignored

      Destination disk format: VMFS thin-provisioned

      Cloning disk '/vmfs/volumes/backupstore0/_ghettobackups/heidi_tools_win7/heidi_tools_win7-2017-04-22_01-26-09/sysdrive.vmdk'...

      Clone: 100% done.

      Registering heidi_tools_win7 ...

      End time: Sat Apr 22 05:53:15 UTC 2017

      ################## Completed restore for heidi_tools_win7! #####################

       

       

      Start time: Sat Apr 22 04:30:55 UTC 2017

      End   time: Sat Apr 22 05:53:15 UTC 2017

      Duration  : 82.33 Minutes

       

       

      ---------------------------------------------------------------------------------------------------------------

      NB -- the Duration of 82 minutes is correct forthe restore of all the VMs, not just the last one...