Hang after Restore from .ova file

[jnb]

I have a Windows 7 (Home Premium) Host and a Linux Ubuntu (14.04 LTS) Guest.

I recently lost my hard drive irremediably I have bought a new one (old drive was Seagate, this is WD) and restored to a vanilla Win 7 all OK. I have installed latest VBox (5.1., including "Extensions" (but not "Guest Additions" yet). The (only) backup I have is a .ova file, created from VBox's (probably 5.1.6) Export Appliance. I have gone Import Appliance, pointed at the .ova on the memory stick, and it imported OK. I see I now have files Ubuntu.vbox & Ubuntu-disk2.vmdk on my HD.

When I now try to boot into Ubuntu, I get the purple screen, and I can go into grub if I want. But no matter what I do, the boot moves on from the purple screen to a black one (with a flashing underline cursor) and "hangs" there. Can't seem to get any information out, even if I boot into "safe mode" or change grub to be debug.

So now I am stuck & at a loss! So far as I recall, I did not have anything "special" on my old VBox Settings, and don't have any now. It seems to me that the issue should not lie inside Ubuntu, since all I am doing is restoring some image which should have all its original settings, so I am asking whether this is a VBox-side problem, and what I can do next?

EDIT:
My situation sounds a bit like http://askubuntu.com/questions/560200/g ... virtualbox, FWIW.

To be clear, after importing the .ova I have only the .vbox & .vmdk file I mentioned. There is no .vdi file anywhere. I don't mean to be dumb, but should there be?

FWIW, I attach the VBox.log, from a boot, where all I then did was a machine power off when it hung.

[mpack]

To be clear, after importing the .ova I have only the .vbox & .vmdk file I mentioned. There is no .vdi file anywhere. I don't mean to be dumb, but should there be?

No, there should not be a VDI. An exported appliance is not a backup (which would allow an exact restoration), it's an encoded translation of the original VM. The OVA standard came from VMWare, so translation of disks to VMDK format is one of the first steps, and it's a one way process.

I suspect there is something wrong with the imported disk, I don't see your issue as a VirtualBox problem unless you can provide better evidence. As it is, the VM launches, meaning that VirtualBox thinks everything is fine. Your problem is with the guest OS, not VirtualBox. As a total guess I'd say it's likely that your grub boot doesn't like that the disk UUID changed (a consequence of converting to VMDK).

If you want to back up a VirtualBox VM, just copy the VM folder to secondary storage. The export/import palaver does nothing useful - unless your intention was to migrate to VMWare!

[jnb]

Thank you for your reply.

>>If you want to back up a VirtualBox VM, just copy the VM folder to secondary storage. The export/import palaver does nothing useful - unless your intention was to migrate to VMWare!
The original .vdi image was 10GB. My "secondary storage" is an 8GB stick. The appliance export fitted (3GB?). My options were limited!

>>As a total guess I'd say it's likely that your grub boot doesn't like that the disk UUID changed (a consequence of converting to VMDK).
The UUID thing sounds like just the right thing to my ears, from a vague recollection of previous post issues. I have a Linux expert guy phoning me later

[jnb]

P.S.
So, if the restore can be made to work, am I now going to end up with a .vmdk image file instead of a .vdi? Does that make any difference?

[mpack]

You will have a disk with the wrong UUID, as I've already said. The guest OS doesn't care what the container format is, but in your case it does care about the UUID being changed. I recommend changing the grub boot to select the boot device by device name, rather than UUID, otherwise every time you clone the disk you'll get the same problem.

[jnb]

Dear mpack,

First & foremost thank you for your help.

I return here having successfully recovered my Ubuntu Guest. In fact, I am running from the imported .vmdk image as-is, without having had to make changes to it after all. If you want to hear my tale of woe, and perhaps have a chuckle, read on....

As I said, I lost the original hard disk, and had to reinstall Windows 7 (Home Premium) from scratch, and then VirtualBox. Both are 64-bit. I noticed that VB was only offering 32-bit guests for new VMs. And then that the settings on the restored VM were also 32-bit Ubuntu, with no 64-bit choice available. Now, I did not recall whether my Ubuntu guest had been 32- or 64-bit....

I went down to the BIOS and found that its "64-bit Virtualization" was set to Disabled. Enabling that now allowed my VB to set 64-bit Linux on the restored VM. Lo & behold, instead of just hanging silently during boot my Ubuntu now springs back into life perfectly!!

Now, all I had done was replace the original hard disk, and I swear there is no way that I changed the BIOS's Virtualization setting at any stage....

My thought is: could installing Windows Home Premium, which does not allow for Microsoft's whatever-their-virtual-VM thing is, have told the BIOS to disable its 64-bit Virtualization??

Meanwhile, it appears that although you said "the disk UUID changed (a consequence of converting to VMDK)" that did not in fact happen, as the original UUIDs are working fine? Also, should/could VirtualBox have detected that the restored .vmdk required a 64-bit guest and my settings were for 32-bit? I'm guessing not....

Conclusion: At the end of all of this, if you restore from 64-bit and try to run it under 32-bit, this is the behaviour you get!

[mpack]

Well done for finding a solution. As implied above, I do not use export/import beyond occasional tests of functionality: which I'm not prepared to repeat every time someone says something contrary to my conclusions! So, as far as I know the disk UUID always changed when you import a VM, which it must do otherwise it wouldn't be able to import the same VM twice. But, perhaps something was tweaked since my last test.

The VMDK UUID speculation was just that, prompted by your suggestion that the container format change (VDI to VMDK) might be significant. Apparantly the speculation was unfounded, and your problem was simply that VT-x was disabled in the host BIOS. In fact I see that the log says exactly that, but I didn't previously think to check because I was under the impression that this VM was previously working on the same host, and the only change was a new hdd. My bad, I should have noticed anyway.

p.s. Minor terminology point. I doubt your BIOS refers to 64bit virtualization. It just says "virtualization technology" or similar. 64bits is only relevant because VirtualBox only supports 64bit VMs when virtualization acceleration is available. This isn't a technical limitation, it was simply once of expedience: the devs didn't see the point in putting a lot of work into getting software-only 64bit to work, when nearly all 64bit capable x86 CPUs also these days have hardware virtualization capability.