Clone VM Problems and Questions

[ZTatZAU]

Hello, I am new to this forum and don't really know much about Vbox; though by following the Vbox 6.0.16 User Guide I have successfully setup several VMs for the purpose of testing software in different environments on my WIN7 Host Machine.

I am currently trying to Clone an existing WIN7 Guest VM (100GB with 34GB used & 66GB free) on the WIN7 Host machine and have had some problems. My first (unsuccessful) attempts were via the Vbox GUI by right clicking on the desired VM and selecting Clone. Then, following the prompts, I tried creating a FULL CLONE of the CURRENT MACHINE STATE as well as the EVERYTHING option. Each of these attempts resulted in the following ERROR message...

Failed to clone the virtual machine WIN7HP_SP1_x64.

Could not create the clone medium 'C:\Users\ZTatZAU\VirtualBox VMs\WIN7HP_SP1_2\WIN7HP_SP1_2.vdi' (VERR_IO_CRC).

Result Code: VBOX_E_FILE_ERROR (0x80BB0004)
Component: MediumWrap
Interface: IMedium {ad47ad09-787b-44ab-b343-a082a3f2dfb1}

Next, I got on this forum and read about @mpack's CloneVDI v4.01 tool and tried several of its variations; all of which resulted in the following ERROR message after reaching 80-85% on the progress.bar...

"Got OS Error 23 when reading from source file."

After reviewing the Vbox User Manual, I briefly considered trying VboxManage CloneVM in the command prompt window; but after a little more research here on this forum, I thought it a good idea to first do a CHKDSK on the Host's C:\ drive. Lo and behold, CHKDSK REPLACED BAD SECTORS in my WIN7 VM file (12KB in 3 bad sectors), after which I started the WIN7 VM and it seemed to work fine.

Now, before trying again to clone the WIN7 VM, I have a few questions.

1) Should I have, or should I still, run a CHKDSK on the WIN7 VM's C:\drive?

2) I am tending toward proceeding with @mpack's CloneVDI tool as it appears to provide more control over the cloning options than what the GUI's Clone Wizard provides.
My intent, if possible, is to continue running either my original WIN7 VM or the Cloned WIN7 VM on the same host machine, with no Windows 7 reactivation hassles, so I'd like to get the cloning process done correctly in order to do so.

My main concern is this paragraph taken from @mpack's CloneVDI v 4.01 release notes...

3. NOW STOP AND THINK - DO NOT RUN THE NEW VM YET. Instead go carefully through the
settings, making absolutely sure that the old and new VMs have the same settings,
especially for network MAC address, hard disk controller type and IO APIC setting. Failure
to do this properly may result in the guest failing to boot, or (with Windows guests) you
may have to reactivate - which is a big deal since your other VM is presumably already
activated with a different hardware profile. [ If you make this mistake then your only fix is
to clone the original again - and get the settings right this time before you boot! ]

I thought I had convinced myself to create my Clone with a new UUID (so the clone could co-exist with the original VM), as well as new Network MAC address. But now I'm not so sure about the MAC Addresses and other Clone settings, to be able to run either the original WIN7 VM or the Cloned WIN7 VM on the same host machine without the aforementioned hassles. Any guidance on this will be much appreciated!

ZT

[mpack]

OS error 23 reported by CloneVDI (but originating in Windows) equates to "CRC error", the same one reported by VBoxManage.

It tells you that you have physical damage to the host sectors underlying the source VDI. There is no real fix for that other than a backup.

And btw, chkdsk told you that three clusters were replaced, not sectors. Clusters are usually 4K in Windows, hence 3 clusters is 12K. A sector is 512 bytes. One cluster is 8 sectors (hence why it's called a cluster).

Yes, you may have to check data integrity inside the Win7 VM too, but take care (see below). Chkdsk on the host btw didn't actually "fix" bad clusters, it simply mapped new ones in. So 12KB of data was lost and replaced with random junk (or 0x00s or 0xFFs). That may or may not be important, it greatly depends on where that 12KB was.

Notes on running chkdsk inside the VM. If you just run chkdsk with default parameters it will only check the filesystem, not the disk surface. If the damage was not inside the directory data structures then it won't report finding any errors (though ideally, that's exactly what we'd like, since NTFS filesystem structures are journalled and hence very repairable). On a physical PC you would need to run a full surface scan to find the bad clusters, just as you already did on the host... but I suggest you don't do this inside the VM. You have now replaced the bad clusters so the error will not be findable, and I'm not sure that VirtualBox reflects bad host I/O into the VM either. Sans backup I think you just have to live with the knowledge that somewhere inside the VM there may be corrupted files, but it can't total more than 12KB.

I see no benefit in cloning the VDI (the clone will have the same damaged clusters), so I won't comment on your CloneVDI questions. And btw, the proper way to make a VM backup is to straight-copy the VM folder, not use a cloning tool).

[ZTatZAU]

Thanks mpack! Though not very encouraging, I do appreciate your thoughtful and informative reply! Please allow me a few comments and followup questions...

OS error 23 reported by CloneVDI (but originating in Windows) equates to "CRC error", the same one reported by VBoxManage.
It tells you that you have physical damage to the host sectors underlying the source VDI. There is no real fix for that other than a backup.

And btw, chkdsk told you that three clusters were replaced, not sectors... So 12KB of data was lost and replaced with random junk (or 0x00s or 0xFFs). That may or may not be important, it greatly depends on where that 12KB was... Sans backup I think you just have to live with the knowledge that somewhere inside the VM there may be corrupted files, but it can't total more than 12KB.

I'm really hoping that the lost 12KB of data will not be that consequential as there is really little, if any, important data stored on this particular WIN7 VM. Other than the WIN7 OS and a MS Edge browser, there is only one program installed...a copy of MS Access that I use for testing a custom database application. The intent of this clone was to uninstall the existing version of Access that was installed on the original VM, and replace it on the Cloned VM with another Access version to test the database application in other Access environments.

So the question in my mind is, at this point, would a clone operation (via the Vbox GUI, VboxManage, or the CloneVDI tool) likely complete successfully now (with no errors) even though I understand the clone would include 12KB of lost data?

Notes on running chkdsk inside the VM ... but I suggest you don't do this inside the VM. You have now replaced the bad clusters so the error will not be findable, and I'm not sure that VirtualBox reflects bad host I/O into the VM either.

Understood! Except for the part I've underlined and italicized. Can you explain what you mean by this and its ramifications?

I see no benefit in cloning the VDI (the clone will have the same damaged clusters), so I won't comment on your CloneVDI questions. And btw, the proper way to make a VM backup is to straight-copy the VM folder, not use a cloning tool).

In light of my comments above, might there still be a benefit in cloning the VDI even though it may contain the lost 12KB of data? And, as explained above, I wasn't trying to create a backup of the original VM but rather trying to create a duplicate of the VM with a different Access version installed on the clone... so I could run either VM on the same host.

If so, I would still appreciate your guidance on the particular cloning options that would facilitate doing so with no Windows issues or reactivation hassles.

Thanks again your assistance! ZT

[mpack]

Sorry, I misunderstood (or didn't notice) why you were making the clone. Yes, cloning the VM should work now. The clone will still have the 12KB of corrupted data - nothing can be done about that unless you find it. It's worthwhile running a filesystem check in case the damage is in the filesystem, otherwise there is no way to find it that I know of, other than compare MD5 checksums for every file on the drive. And it's probably not worth doing that - I'd just let the crash happen, then you know!

Virtual hardware can't have physical hardware failures, that is why I doubt that that host failures can be detected from inside a VM. If you did something inside the VM that triggered a host hardware problem then I'm pretty sure what you'd get is a host error message reported by VirtualBox, not a guest error message.

[ZTatZAU]

Sorry, I misunderstood (or didn't notice) why you were making the clone. Yes, cloning the VM should work now. The clone will still have the 12KB of corrupted data - nothing can be done about that unless you find it. It's worthwhile running a filesystem check in case the damage is in the filesystem, otherwise there is no way to find it that I know of, other than compare MD5 checksums for every file on the drive. And it's probably not worth doing that - I'd just let the crash happen, then you know!

Virtual hardware can't have physical hardware failures, that is why I doubt that that host failures can be detected from inside a VM. If you did something inside the VM that triggered a host hardware problem then I'm pretty sure what you'd get is a host error message reported by VirtualBox, not a guest error message.

Thanks again mpack!
I am still confused by this paragraph in your CloneVDI 4.01 Release Notes...

3. NOW STOP AND THINK - DO NOT RUN THE NEW VM YET. Instead go carefully through the
settings, making absolutely sure that the old and new VMs have the same settings,
especially for network MAC address, hard disk controller type and IO APIC setting. Failure
to do this properly may result in the guest failing to boot, or (with Windows guests) you
may have to reactivate - which is a big deal since your other VM is presumably already
activated with a different hardware profile. [ If you make this mistake then your only fix is
to clone the original again - and get the settings right this time before you boot! ]

If I proceed with the CloneVDI tool, can you provide the settings I should use to avoid the issues warned about in this paragraph. Again I want to be able to run the original VM or the Cloned VM on the same Host.

Thank you! ZT

[mpack]

Use the GUI and clone the VM, not a VDI by itself. CloneVDI is not needed here: the main purpose of CloneVDI these days is to handle special cases such as VDI header repair, a problem you do not have.

[ZTatZAU]

Use the GUI and clone the VM, not a VDI by itself. CloneVDI is not needed here: the main purpose of CloneVDI these days is to handle special cases such as VDI header repair, a problem you do not have.

That is exactly what I did last evening... Cloned the VM with the GUI... and everything seemed to be working fine, until Windows 7 advised of "hardware changes" and I have "3 days to reactivate Windows".

Do you have any suggestions on how to avoid this issue? ZT

[mpack]

Do you have any suggestions on how to avoid this issue? ZT

Was Win7 activated on this host already? If yes then there was options during cloning to preserve hardware signatures. If Win7 detects a changed motherboard or CPU then it will be deactivated.

[ZTatZAU]

Do you have any suggestions on how to avoid this issue? ZT

Was Win7 activated on this host already? If yes then there was options during cloning to preserve hardware signatures. If Win7 detects a changed motherboard or CPU then it will be deactivated.

Yes, Win7 has been activated on the original VM for a long time. As for Cloning options, I selected... Include only NAT Network Adapter MAC address.

And then I left, Keep Disk Names and Keep Hardware UUIDs - UNCHECKED thinking, (I guess mistakenly), that new UUIDs were required for the original and Cloned VMs to coexist on the same Host.

Are the Hardware UUIDs different than the VM's UUID, which much be unique? Will selecting both of these options likely avoid the WIN7 reactivation message?

Thanks! ZT

[mpack]

Hardware UUIDs are distinct (but usually the same as) the VM UUID, as well as being distinct from disk UUIDs. Just assume that lots of objects in VirtualBox have UUIDs to identify them.

When a VM is first created all those UUIDs are created, and as mentioned, the hardware UUID is usually made the same as the VM UUID. The purpose of the hardware UUID is to provide a motherboard hardware signature which the VM can report to the guest OS.

When you clone a VM you must create new UUIDs for most things (unless the clone VM is going to live on a different PC), but you are given the option to retain the hardware signature.

[ZTatZAU]

Hardware UUIDs are distinct (but usually the same as) the VM UUID, as well as being different from disk UUIDs. Just assume that lots of objects in VirtualBox have UUIDs to identify them.

When a VM is first created all those UUIDs are created, and as mentioned, the hardware UUID is usually made the same as the VM UUID. The purpose of the hardware UUID is to provide a motherboard hardware signature which the VM can report to the guest OS.

When you clone a VM you must create new UUIDs for most things (unless the clone VM is going to live on a different PC), but you are given the option to retain the hardware signature.

And are Keep Disk Names and Keep Hardware UUIDs the only options required to retain the hardware signature?
(NOTE! I'm just feeling my way along here!)
ZT

[mpack]

Disk names are not visible to the guest OS, so they can't affect activation.

[ZTatZAU]

Disk names are not visible to the guest OS, so they can't affect activation.

So does that mean that checking Keep Hardware UUIDs is all that's required to resolve the reactivation issue?

[mpack]

As far as I'm aware that is correct - but you are now straying into Windows support territory, which should be between you and Microsoft.

I would keep the MAC address too, but be aware that this means you can't have both VMs present on the same network at the same time.

[ZTatZAU]

As far as I'm aware that is correct - but you are now straying into Windows support territory, which should be between you and Microsoft.

I would keep the MAC address too, but be aware that this means you can't have both VMs present on the same network at the same time.

Thanks mpack! I appreciate your patience with this newbie!
I assume you mean by "you can't have both VMs present on the same network at the same time", that both VMs can't be RUNNING at the same time! Is this correct?

If so, there shouldn't be a problem as I don't intend to run both VMs at the same time; but rather only one of the VMs running at any given time.