Unable to get copied disk to automatically boot

[paul_xedos]

Hi,

I'm having a difficult time getting a copied vmx and vmdk running Ubuntu on Vmware 6.7 (esxi and vsphere) to boot.

Registering the vm by pointing at the vmx file fails and I have to drop down to EFI and boot from file in order for the disk to boot. Obviously, this is not a great solution because booting will always require manual intervention

I thought I had found the solution by Creating a new vm with identical settings and pointing to the existing hard disk. This goes straight to dhcp boot ( as it did not find the boot drive). Switching to EFI and again booting from file is the only way I can bring the system up

It looks like the boot disk has lost its boot block but I'm not sure how to re-add this in vmware

Thanks

Paul

[Lalegre]

Hey,

When you choose to register the VMX what error do you get?

[scott28tt]

Moderator: I have sent you a private message, please check your Inbox in VMTN.

[paul_xedos]

Hi, Registering the VM works but the subsequent boot does not recognise the boot disk and skips over disk1, disk2 and moves on to trying to boot over the net. Another forum post suggested possible vmx corruption and therefore to Create New Vm and point at the existing vmdk file

[Lalegre]

Could it because of a vmx corruption. Could you please take an screenshot of the files in the VM folder inside the datastore and attach here the .vmx file so we can check?

[paul_xedos]

Thanks for the help - screenshot attached along with vmx file

So my method of backup is to copy the vmx file, take a snapshot in order to be able to copy the vmdk files ( otherwise they fail with device busy ) then remove the snapshot.

It's working fine on several other machines but not this one for some reason. The only difference I can see is that it has two disks but the boot up sequence just passes over both and tries lan booting before giving up

[Lalegre]

Hey Paul,

I can see these entries in the vmx file:

• scsi0:1.fileName = "perfweb.vmdk"
• scsi0:0.fileName = "perfweb_5.vmdk"

This means the VM when booting will try to find that VMDK to work in that exact SCSI Controller port. Could you please confirm if the server has those Hard Disks attached in the SCSI 0:0 and SCSI0:1 ports?

Also this way of copying the files is not the best approach as you are losing the chain of snapshots and the Guest OS basically is writing into the Snapshot file. What you are doing is not copying the last changes of the VM so instead of taking an Snapshot, I recommend you to Power-Off the VM and then do the actual copy of the files.

[paul_xedos]

Hi,

Yes the backup process is not ideal but the machine needs to stay up all the time as it is running a continuous test environment. Loss of an hour or two's data by not capturing the snapshots is not a big issue as long as we do not have to go back more than a day to recover the system

In terms of whether the disks are attached here's a screenshot. Thanks again for taking a look

[continuum]

Unfortunately guessing the timestamps for the snapshots is not conclusiv with your filelisting screenshot ...

Anyway - following the usual conventions it is quite unlikely that a VM with a diskorder like in your case:

• scsi0:1.fileName = "perfweb.vmdk"
• scsi0:0.fileName = "perfweb_5.vmdk"

occures in nature - it clearly looks like manually modified.

Instead we would expect that the VM grew from

• scsi0:0.fileName = "perfweb.vmdk"

over intermediate states like

• scsi0:0.fileName = "perfweb.vmdk"
• scsi0:1.fileName = "perfweb_1.vmdk"
• scsi0:2.fileName = "perfweb_2.vmdk"
• scsi0:3.fileName = "perfweb_3.vmdk"
• scsi0:4.fileName = "perfweb_4.vmdk"
• scsi0:5.fileName = "perfweb_5.vmdk"

then during a long, cold snowy winter, disks 1-4 deserted and moved south.

Nowadays the last 2 brave disks 0 and 5 still maintain their posts and would very likely use

• scsi0:0.fileName = "perfweb.vmdk"
• scsi0:5.fileName = "perfweb_5.vmdk"

or

• scsi0:0.fileName = "perfweb.vmdk"
• scsi0:1.fileName = "perfweb_5.vmdk"

Following ESXis naming conventions and other habbits "perfweb.vmdk" very likely is still the original bootdisk.

In that case bootorder in EFI-firmware probably never was changed after initial install.

I guess that your attempt to reassemble the VM did not work as expected when tried to add a disk with snapshot.

Then situation became confusing for a few minutes and you ended with an unexpcted oder of disks

- then next thing the VM tried to boot from network as it does not attempt to boot from scsi0:1 ...

Suggestion: expected downtime less than 5 minutes

- power off VM

- remove VM from inventory (just unregister - not delete it ..)

- then use embedded editor of winscp and edit the vmx-file

- change all entries starting with scsi0:0 to scsi0:XXX

- change all entries starting with scsi0:1 to scsi0:0

- change all entries starting with scsi0:XXX to scsi0:1

After that is done - save the vmx-file.

Delete the nvram-file which stores thje EFI-boot settings - or rename it..

That will reset boot-order to defaults.

Next reregister the VM and start it - I think that will do the trick.

Ulli

[continuum]

> Could you please confirm if the server has those Hard Disks attached in the SCSI 0:0 and SCSI0:1 ports?

Hi - that is really not necessary.

If that order is listed in current config - it means it really is also operating like that.

The GUI may get it wrong - but when ever you start a VM the vmx-file entries govern the config,

And vmx files dont lie

[paul_xedos]

Hi Ulli,

That was a great answer ( very humorously worded) but unfortunately not the fix. Same issue, I'm afraid

I'm pretty sure scsi0:1 is the boot disk because the drive size mirrors what I see on the running system  ( fdisk -l /dev/sda = 146gb, /dev/sdb = 275gb)

No idea how the scsi ids came to be swapped but certainly the original boots with those settings

So just to recap, on a copied system, waiting for the above screen to time out and going through to  Boot Maintenance Manager -> System Setup -> Boot from file is the only way to boot into the OS