Moving VMs to another hardware failed

[Suncatcher]

Well, could anybody explain me why did my VMs refused to boot after I moved them to another machine? I thought virtualization is that helps us to abstract from hardware and be free. Am I wrong?
I had 2 machines: one with ArchLinux and another with Windows 7 x64. After installing Virtualbox on another host and moving VMs there they didn't boot at all.
Arch machine freezes on this screen

ArchLinux.png (1.28 KiB) Viewed 3032 times

And Win 7 machine showes me this

Win7.png (13.94 KiB) Viewed 3032 times

Which means in English: "The Windows failed to start. Maybe this was caused my recent hardware or software changes. In order to solve the porblem:
1. User recovery disk
2. Bla-bla-bla
State: 0xx000000f
Information: Boot menu failure, because required device is not available"

Previous host (where machines were originally created) as well as current is Win 8.1 x64.

Here are logs for both VMs.

[mpack]

Seeing mention of RAMdisk, I'll make the total guess that you never actually installed Linux, you've been using it in live CD mode, suspending the VM after every session. I'd further guess that the suspended session is not suitable for the new PC. For the Windows guest - I'm not sure what the problem is, it could be a large number of things, so you'd need to dig further. E.g. it's possible that you corrupted the VDI when you copied it.

Incidentally, we don't need the entire contents of your PC - just a single (relevant) log is fine.

No, VMs are not totally isolated from the host PC. For example, the guest OS runs natively on the host CPU, so of course it will notice if the CPU changes radically. Plus, the VM can only use resources that are available and not already used in the host, so you can't disregard the host when considering the guest. And, host disk corruption can affect the guest too.

[Suncatcher]

I'll make the total guess that you never actually installed Linux, you've been using it in live CD mode

Wrong suggestion. I did the installation from scratch with my own hands: partitioning disks, configuring GRUB and so on.

E.g. it's possible that you corrupted the VDI when you copied it.

Is it possible to check consistence of the VDI (if I hadn't calculated MD5-sum berfore moving)? Is loading from one of the previous snapshots could be a solution for me?
AFAIK, snapshots are only incremental backups and cannot provide consistence themselves, but only with main backup. Are they?
What other steps can I perform?

For example, the guest OS runs natively on the host CPU, so of course it will notice if the CPU changes radically

The main point is that source and target machines are both Asus, both Windows 8 x64 and both have equal amount of RAM (12 Gb). The only difference is CPU and form-factor (source=laptop, target=barebone).

[scottgus1]

Check that you followed this method for moving your guests:
viewtopic.php?f=35&t=55003

Guests moved this way have the best chance to move happily. A couple things I've read about on the forum that can still go wrong include:

moving the guest when it is save-stated (solution: shut the guest down properly then copy it from the source host, or discard the saved state on the new host)

Your guest network is Bridged, and the card it's bridged to isn't on the new guest (solution: change which card the guest is bridged to before starting it on the new host)

I have bounced guests around and they do boot up just fine when they're moved properly. The change in CPU is seen by the guest, though, as mpack says. BTW snapshots aren't backups. They're points in time in the usage of the machine - technically they're new disks, which Virtualbox goes back through to present the correct data to the guest OS. They make the guest more delicate and should not be relied on for backing up. Best backup is to copy the whole guest folder, just like you were moving it.

[mpack]

The main point is that source and target machines are both Asus, both Windows 8 x64 and both have equal amount of RAM (12 Gb). The only difference is CPU and form-factor (source=laptop, target=barebone).

Well, as I said the VM can see the CPU change, so this could perhaps upset Windows, but you'd need to find out from Windows itself what it doesn't like about the new environment, and anyway it could be something as mundane as a corrupted VDI as I also said.

[Suncatcher]

Your guest network is Bridged, and the card it's bridged to isn't on the new guest (solution: change which card the guest is bridged to before starting it on the new host)

What do you mean? Should I switch to NAT or disable NIC at all?

[scottgus1]

Don't bother with that yet. Check the link and please tell us how you moved the guests.

[Suncatcher]

Don't bother with that yet. Check the link and please tell us how you moved the guests.

Of course, I checked this link before moving. I did everything in accordance with the manual:
1. Made copy of the VM folder
2. Added the VM through the menu
I don't see any pitfalls in this procedure.

[scottgus1]

Good, the correct procedure was used. OK, that should clear up a lot of possible troubleshooting tests.

But, the errors are unusual. As I mentioned, I've moved guests around and have not had anything unusual happen, other have too. Your errors seem unusual, meaning to me that something unusual has happened to cause the usual procedure to fail.

Only other thing I can think of for now is, as mpack mentioned, to check that the copies were made without errors. Disk errors on the former host, the transfer media, or the new host would hose the transferred guest. And booting the guest on the new host would very likely change the contents of the guest so doing a hash now would not confirm that the guests copied properly.

Myself, I would do the copy again. Run file-compares ("fc" command in Windows) on the files copied between the old host and the transfer media to confirm proper copy to the transfer media. Then on the new host, copy the guests and run the file compares again before trying to run them. Don't take short-cuts. The file-compares will take more time, but will show that the guests on the new host are bit-for-bit the same as on the old host and that disk error hasn't got in the way.

Then try to run the new copies, and tell us what happened. Oh, and if your guests on the old host required VT-x, be sure VT-x is turned on in the new host.

[Suncatcher]

Myself, I would do the copy again. Run file-compares ("fc" command in Windows) on the files copied between the old host and the transfer media to confirm proper copy to the transfer media. Then on the new host, copy the guests and run the file compares again before trying to run them. Don't take short-cuts. The file-compares will take more time, but will show that the guests on the new host are bit-for-bit the same as on the old host and that disk error hasn't got in the way.

Unfortunately, folders have been deleted from the old machine, and low-level formatting has been performed in addition to. So, second attempt does not seem possible.
My copy method comprises:
1. Firstly I made VHD from the drive where VMs were stored.
2. Then I copied this VHD over the network (Ethernet) to the new machine
3. Finally, I attach the VHD via the Disk Management on new machine and started VMs from there.
Starting from local partition was also tried but result was the same.
So, there is no other ways (except new copy) to check the consistence? Theoretically VMs could be corrupted during copy over the network.

[mpack]

If there was anything wrong with the VDI header then VirtualBox would let you know. As to the disk image itself, define "consistence"? The only way I know is with reference to a master copy that you can directly compare or at least compare checksums with.

[Suncatcher]

If there was anything wrong with the VDI header then VirtualBox would let you know.

So think I.

[scottgus1]

To me the fact that the guests start and you get something Linux-ish in the Linux guest and something Windows-ish in the Windows guest shows me Virtualbox is doing its job. But the data in the guests may have been kerflummuxed. A google search for "windows error 0xc000000f" turns up some results, most of which say to use the install CD to repair the OS. I have no idea how to fix the Linux guest.

Of course, I checked this link before moving. I did everything in accordance with the manual:
1. Made copy of the VM folder
2. Added the VM through the menu

Seems to conflict with this:

My copy method comprises:
1. Firstly I made VHD from the drive where VMs were stored.
2. Then I copied this VHD over the network (Ethernet) to the new machine
3. Finally, I attach the VHD via the Disk Management on new machine and started VMs from there.

FWIW, making a vhd of the entire host disk on which the guests reside isn't mentioned in the linked post as the proper way to move a VM. I wonder if the extra layer of virtualizing thus involved is getting in the way of Virtualbox's calculations? You could try copying your guests out of the mounted vhd to a regular physical disk then see what happens.