Unable to get backed-up VM running with fresh VB install

[NotLIable]

A couple months ago my VB setup experienced problems, which ended up being a faulty BIOS chip, which caused Windows 7 (and VB) to see virtualization disabled even though it was enabled in the BIOS. Past that hurdle, VB is now running just fine, but I can't get my VM files, backed up via simple Windows copy to a different directory on the same disc drive during the problem time frame, up and running again. I have tried the procedure at Moving a VM viewtopic.php?f=35&t=55003 in this forum to no avail. I had backed up the Logs, Shared Files, and Snapshots subdirectories along with the .vbox, .vbox-prev and .vdi files. When I start the VM, it boots in the normal fashion, but none of my user-created files are there once I get into GNOME. It's like it's going back to the Base Install on 8 Dec. 2016 and not seeing all the work I did since that date until things went south in late June. There was a snapshot file dated 27 June, but today's VB session changed its date to 8 August. Are my user-created files stored in the .vdi file or a snapshot? I though snapshots just captured basic machine state stuff, but is it possible that all my Python work is gone as I didn't capture those files at some point? AUGH! I really need this stuff back, so help will be much appreciated.

[mpack]

Please report precise symptoms and error messages.

A VM that boots up but is missing a lot of files means that you did NOT follow the procedure in the FAQ. The symptom you describe can only happen when the VM uses snapshots, but the base VDI has been removed from its correct position at the start of the snapshot chain, and replaced in the VM over the newest position - or used as the base for a new VM.

As the FAQ says, the way to restore a VM backed up in the recommended manner is to (a) copy the entire VM folder (not piecemeal files) to the preferred host location, then (b) register the VM by using Machine|Add. Just to be entirely clear, the latter does NOT mean to create a new VM around the base VDI. That will not do the same thing at all.

A snapshot is a preserved past state of the VM. It includes both VM settings and disk contents, but not RAM (unless the VM was running when the snapshot was taken). The current state (not the base state) is the state which includes your latest data.

[NotLIable]

This is certainly informative and looks helpful. Can you direct me to the part of the FAQ to which you refer? I'm hoping to meet up soon with a friend who is skilled with VB to try and get past this problem.
Arthur

[mpack]

The FAQ is quite short and the first post there should be read from beginning to end. I won't provide a link since you did that yourself in post #1.

The second post in the faq deals with VirtualBox versions pre-4.0.0. You can ignore this if you only recently started using VirtualBox (i.e. in the last couple of years).

[NotLIable]

I believe I already took all the steps in the article, but I'll try again this evening, as detailed below.

Backed up files are in CentOS 7 Full DVD directory, structured thusly:
Logs subdirectory -- 4 log files, all dated 27 June 2017, which should be the date when everything was still alright.
Shared files subdirectory
Snapshots subdirectory -- 3 UUID # .vdi files, 2 .sav files from 8 December, one .vdi file I named TheFullDisk.vdi which I believe was created when I followed a recommendation to merge the snapshots in with the base .vdi file.
CentOS 7 Full DVD.vbox
CentOS 7 Full DVD.vbox-prev
CentOS 7 Full DVD.vdi

I copied all of these (except the TheFullDisk.vdi file) to a CentOS 7 Full DVD (test) directory to preserve the read-only copy described above. I trust you agree this satisfies the "The basic procedure for moving VMs created by VirtualBox v4.0.0 or later is to copy the VM folder (with contents) to your preferred location" aspect of your article.

I then started VB (v5.1.22), which only has listed the base CentOS 7 machine (I deleted all other VMs and all their files). I then select Machine | Add and choose, from the afore-described "CentOS 7 Full DVD (test)" directory, the "CentOS 7 Full DVD.vbox file bearing date 6/27/2017.

I'm not going further, as something at this point concerns me: While the base CentOS 7 correctly shows Red Hat (64-bit) and the proper CentOS 7.vdi file, the added machine differs, in that it shows Ubuntu (32-bit) as the OS and, more importantly (?), on SATA Port 0, "CentOS 7 Full DVD.vdi" as the disc file. That file is dated 12/8/2016, which is BEFORE all my Python code was developed. Does this mean I'm getting back a disc from December, WITHOUT incorporating the subsequent snapshots? I want/need (?) the whole shebang!

Advance thanks for your continued help, as my local VB guy has never done this and we've not yet met to bash heads on this matter.
Art

[socratis]

I copied all of these (except the TheFullDisk.vdi file) to a CentOS 7 Full DVD (test) directory to preserve the read-only copy described above. I trust you agree this satisfies the "The basic procedure for moving VMs created by VirtualBox v4.0.0 or later is to copy the VM folder (with contents) to your preferred location" aspect of your article.

These two sentences do not agree with each other. Either you copied the whole directory (hence following the article's instructions), or you didn't. It sounds like you may not have. Would you mind trying again? Without any conditionals?

Otherwise, please post the zipped "CentOS 7 Full DVD.vbox" file, along with a complete directory output of the VM's directory and its sub-directories.

[NotLIable]

Okey-dokey, here we go (again).

1) I made a full and complete copy (the 12/8/2016-dated .vdi file also, this time) of everything in the read-only "CentOS 7 Full DVD" directory, plopping it in "CentOS 7 Full DVD - Test" and allowing r/w access.

2) I then started VB (v5.1.22), which this time has listed the base CentOS 7 machine and the experimental one I was diddling with two days ago. VB generated an error on the Add operation:

Code: Select all

"Failed to open virtual machine located in C:/Users/A/Documents/Computers/CentOS/VirtualBox VMs/CentOS 7 Full DVD - Test/CentOS 7 Full DVD.vbox.

Trying to open a VM config 'C:/Users/A/Documents/Computers/CentOS/VirtualBox VMs/CentOS 7 Full DVD - Test/CentOS 7 Full DVD.vbox' which has the same UUID as an existing virtual machine.

Result Code: E_FAIL (0x80004005)
Component: MachineWrap
Interface: IMachine {b2547866-a0a1-4391-8b86-6952d82efaa0}
Callee: IVirtualBox {0169423f-46b4-cde9-91af-1e9d5b6cd945}"

I'm guessing this means that I'm trying to use the same .vdi file for two VMs, so I'll do a Machine | Remove on the experimental one and try again.

3) Repeated steps 1 and 2. This time, a VM with the name "CentOS 7 Full DVD (After VBGE)" appeared (good!), but as was the case before, the machine setting for Operating System is "Ubuntu (32-bit)" (see attached ScreenShot1.png).

4) Start the VM. Everything boots fine, but when I get into GNOME, it shows a "clean slate" (i.e., none of my files and folders are present). See ScreenShot2.png, attached.

I will note that the afore-mentioned VB friend and I met a couple days ago and his idea was that rather than trying to get my desired .vdi file bootable again, we should rather just add it to a bootable VM and copy all my stuff from it, but we couldn't accomplish that either, without lots of error messages during VM boot.

See the attached VBVMsDir.txt file, which contains the directory listings you requested. Although only 18 kB in size, I have ZIPd the "CentOS 7 Full DVD.vbox" file as you asked.

Thanks in advance for your assistance with this. Fingers will be crossed after this message goes out!

Art

P.S. Forum won't allow me to attach the two .png files, as they exceed 128 kB size.
P.P.S. Reduced .png file sizes and saved as JPEG to get 'em up here
P.P.P.S Max. of 3 files attached (augh)

[socratis]

1. If you want to make a copy, you make a copy and you put it somewhere safe. You do NOT make a duplicate and register that as well. You're going to get error messages about the duplicate VM, not a duplicate VDI.
2. A Virtual Machine is NOT just a VDI. It's ALL the things that are in the directory of the VM. That includes the '.vbox' file, which is the recipe of the VM. The VDI is the hard drive of said VM, and the {abcde...}.vdi files in the snapshots are the links of a chain for that hard drive.
3. Coming to the forums was the correct thing to do. Getting a friend and experimenting with things that you don't necessarily understand or haven't read in the manual (you did read it, right?) is not the correct thing to do, and can lead to one thing and one thing only; disaster. And I'm referring to snapshots. And the dates of the VDI files. You should be concerned only about the last one in the chain.
4. If you don't understand how a feature works, you do NOT experiment with data you don't want to lose. You experiment with a throw-away guest and you see if your understanding of said feature is the correct one. Yes, it takes more time, but ask yourself which is more valuable.
5. Now, your '.vbox' file and the directory structure seem to be correct. You don't need the "TheFullDisk.vdi" file. Unregister every VM (mainly the "CentOS 7" one) so that there are NO VMs in the left side. Check the Media Manager after that and make sure that there is nothing there, both in the HDs and in the CDs. Then simply register the new VM (the test) either by double-clicking in the '.vbox' file or by going 'Machine » Add'.
6. Yes there are limits to what you can attach to the forums, both in size and in number. Can you imagine what would happen if that was not the rule for the 388805 posts so far (not including this one)?

[NotLIable]

Sigh. No go.

Did a complete Remove Machine on all VMs (even deleted the directories and remnant files), copied all files from the read-only safekeeping directory to the "C:\Users\A\VirtualBox VMs" directory, set 'em for r/w access, and did a Machine Add operation. Loaded fine but reported OS as Ubuntu 32-bit. VM boots fine and reports last login as 27 June, which was promising, but once in, I could not see any of my Python or other files. Zip, squat, nada.

Perhaps relevant: I always shut down the VM using the "Power off the machine" option. I note on page 25 of the User Manual that "With this option, VirtualBox also stops running the virtual machine, but without saving its state." and "As a result, this should not normally be done, since it can potentially cause data loss or an inconsistent state of the guest system on disk." Even though I have snapshots, could this have resulted in loss of my files?

On page 29 of the User Manual there's more scary stuff: "The complete state of all the virtual disks attached to the machine is preserved. Going back to a snapshot means that all changes that had been made to the machine’s disks – file by file, bit by bit – will be undone as well. Files that were since created will disappear, files that were deleted will be restored, changes to files will be reverted. (Strictly speaking, this is only true for virtual hard disks in “normal” mode.)" My VDI is a normal mode file.

I am now quite worried that through failure to save state or perhaps take a more-recent snapshot or perhaps a destructive "revert to" operation I have trashed my data.

Art

[NotLIable]

Any other suggestions for a solution here? I'm still dead in the water.

[mpack]

I'm afraid my answer is the same now as it was at the start. Since backward time travel doesn't exist the only way a VM can revert to an earlier state is if you mounted an earlier state in the VM, either a snapshot or an older VDI. Which means that the VM was not backed up and restored as a unit. Which means that the FAQ wasn't followed. Which means that we have no way to know what you actually did, which limits suggestions for repair.

The only other thing I can think of for you to try: if you have a complete snapshot chain of VDI files then you can attempt a repair by copying all the VDIs into one folder, identify the newest snapshot, and clone it using CloneVDI, then build a new VM around the clone VDI. Be careful about UUIDs - don't preserve them if you intend to leave the older VM still registered. Obviously if the scenario is that you only have the base VDI left then this new VM too will exhibit the "time travel" effect.