P2V w/VirtualBox 6.1 not working per instructions


Author
Message
AHansen
AHansen
Talented Member
Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)
Group: Forum Members
Posts: 51, Visits: 342
I'm the process of using Oracle's VirtualBox for testing purposes.  According to Reflect User Guide "converting" a Reflect backup image to a VHD VM is straight forward:
  1.   Using Macrium Reflect take an image of your physical machine.
  2.   Once you have an image, create a Rescue Media ISO image.
  3.   Create a Virtual Machine using your preferred hypervisor (Hyper-V, VMware, Virtual box...), assigning to it a vCPU, Memory and a Virtual Hard Disk.
  4.   Boot the VM using the created Rescue Media ISO image.
  5.   From the booted Rescue Media restore your image on to the Virtual Hard Disk attached to your VM.
  6.   Without exiting the Rescue Media, run the ReDeploy option.
  7.   Detach the ISO from your VM and reboot it.
I've made it to Step 5 but when I attempt select a backup located on a host drive Reflect Recovery seems to be restricted to what is accessible in the guest space:

I've added the needed drive as a shared folder in the VM settings to no effect.  In attempting to add the drive as Storage VirtualBox only accepts Virtual images for disks and iso etc for Optical drives
.
I've created a VM from a backup by
  1. creating VHD VM in VirtualBox
  2. mounting (MS-speak "attaching") the VHD using Disk Management
  3. restoring backup to mounted VHD
This approach results in about a 45 min restore for a 65GB drive with the source on an internal 7200rpm HDD (SATA III (6GB/s)) and the target a SATA III SSD. I'm hoping to significantly reduce the restore time by using Macrium's approach.

How do I get Reflect Rescue loaded in a VM guest find drives in the host environment?

Thanx in advance for your time & expertise.

Edited 8 September 2020 12:01 PM by AHansen
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)
Group: Forum Members
Posts: 7.9K, Visits: 55K
I'm pretty sure that the "shared folder" function requires the guest VM tools to be running within the guest anyway, which isn't possible in Rescue as opposed to full Windows.  The typical way you'd restore an image into a VM would be to have a network path from your guest VM to wherever your Reflect backup is stored.  If the latter is your host system, then that would involve setting up Windows file sharing on your host system so that the guest can see that folder.  But in that case, the guest will still need to pull the contents of the Reflect image across the virtual network and write its contents to the VHD file you're using for the VM's primary disk.  It sounds like you did was take the VHD file you would be using as the VM's primary disk and temporarily mount it within your HOST system to restore onto it using Reflect running on the host -- is that correct?  If so, that's probably faster than the network method since you wouldn't have the overhead of virtual networking.  45 minutes to restore 65 GB is roughly 20 MB/s.  That is a bit slow especially if the source and destination were separate physical disks.  Maybe the driver that Virtualbox uses to allow its VHD files to be mounted in a host OS is a bit slow?

In any case, to your last question of, "How do I get Reflect Rescue loaded in a VM guest find drives in the host environment?", the answer would be to create the network path I described above, but again I don't know if that will be faster.  There's no way to directly attach a Reflect image backup to a Virtualbox VM to have the VM use that exact file as its virtual disk.  You'd need viBoot for that.  And even that isn't really a great choice for "permanent" P2V; it's more for temporary use, such as disaster mitigation/recovery, briefly booting a backup to retrieve content, test it, etc.  The overhead from Reflect's default compression would be one issue, and although that could be mitigated by capturing an image backup with compression disabled, you'd still have the issue that your VM's virtual disk was hosted from a read-only file in a Macrium-proprietary format, rather than a VHD file that's standard for your hypervisor.  That isn't ideal for long-term use in my opinion.

Edited 8 September 2020 2:32 PM by jphughan
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)
Group: Forum Members
Posts: 7.9K, Visits: 55K
Actually there is another way to do this that would cut down on your time, assuming it would be feasible in your specific case.  You could mount a Virtualbox VHD on the system that you intend to P2V.  Make sure that VHD file resides on a drive that will NOT be captured.  Then use Reflect on that system you're P2V'ing to CLONE the system's source disk into that mounted VHD file.  You've now got that system's data straight into a VHD file, no need to make a Reflect backup first and then restore it later.  At that point, you'd attach that VHD to an actual VM, boot the VM into Rescue Media, and run ReDeploy.

AHansen
AHansen
Talented Member
Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)
Group: Forum Members
Posts: 51, Visits: 342
JP - thanx (again) for the prompt and (potentially) very interesting spin on this.  I've never actually done a clone before but this looks like a great way to try it without using a physical disk.

Let me give it shot ... I'll circle back with result.

AHansen
AHansen
Talented Member
Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)
Group: Forum Members
Posts: 51, Visits: 342
jphughan - 8 September 2020 2:35 PM
Actually there is another way to do this that would cut down on your time, assuming it would be feasible in your specific case.  You could mount a Virtualbox VHD on the system that you intend to P2V.  Make sure that VHD file resides on a drive that will NOT be captured.  Then use Reflect on that system you're P2V'ing to CLONE the system's source disk into that mounted VHD file.  You've now got that system's data straight into a VHD file, no need to make a Reflect backup first and then restore it later.  At that point, you'd attach that VHD to an actual VM, boot the VM into Rescue Media, and run ReDeploy.

The results are in and we have a success and a puzzle. But before I get into that I must make a small change to my original post with the following additions:
I've created a VM from a backup by
- create VHD VM in VirtualBox
- mount (MS-speak "attach") the VHD using Disk Management
- restore backup to mounted VHD
- mount Reflect Rescue .iso in guest and fix boot errors
- unmount Reflect Rescue .iso in guest and reboot guest


It worked but I don't understand why the restore/clone of a boot partition image doesn't necessarily result in a bootable disk:

Two questions:
  1. Particularly with respect to a clone isn't the target intended to be an exact duplicate of the source?
  2. What is the difference between Redeploy and Fix Boot Errors when m making a restore/clone target bootable?

RE: use clone rather than restore to "populate" virgin (unformatted) VHD - I did this twice. The first attempt took 5:48:38 (yes, nearly 6 hrs), the second attempt took 21:51 or 22 mins. In an "apples-to-Apples" comparison that means the clone to VHD approach took 56% less time than that needed using the restore to VHD approach. And actually the efficiency of the clone is slightly better than raw time comparison because when I used the restore approach only my core apps (Reflect, Firefox, Thunderbird, MS Office and Adobe Web suite) had been installed and when doing the clone approach all additional apps were installed bumping the source size up approx..4 GB.

So, an unqualified improvement in the second attempt at using the clone to VHD approach but what accounted for the huge time difference between the first and second tries? For reference, this is my disk layout:

Disk 1 is a SATA SSD, Disks 2 & 3 are SATA HDDs and Disk 4 is USB 3.1 HDD.

In your instructions you state "Make sure that VHD file resides on a drive that will NOT be captured."   I interpreted this as meaning do not have VHD located in C: if cloning C:.  Based on this experience, however, perhaps your advice went deeper than that.

An additional bit of background info is that VirtualBox takes approx. 4 mins to create a VHD on the SSD and approx. 13 mins to create an identical VHD on an internal SATA HDD.

The 6hr clone was to a target VHD on H:\ SSD Working space whilst the 22 min clone was to a target VHD on L: Virtual PC. I'm very puzzled by the vast difference in time given I expected the SSD target to be approx. 3 times as fast as the HDD target.  In both cases I used drag-n-drop placing C: on the virgin mounted VHD.

Rootman
Rootman
Talented Member
Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)Talented Member (113 reputation)
Group: Forum Members
Posts: 82, Visits: 1.1K
I've done this a few times.  As stated using a network drive is one option.  There is also a third way. Create a SECOND temporary VHD and copy your backup file directly to it. Attach it to the VM as a second disk.  Boot to the MR ISO and you will be able to see the other disk with it's backup file on it.  It is lightning fast this way.  There is a wonderful free mounting utility named ImDisk Toolkit that makes mounting a VHD on the host a snap.  I use it when copying the backup file to the guests second disk.  

As far as the non bootable VM.  First you need to make sure the image boots the same was as the original OS.  If it's EFI then choose EFI, if it's MBR then do NOT choose EFI.  I've found with VirtualBox that choosing an IDE drive for the controller type usually works, where choosing a SATA will not sometimes.  There is to real reason to change it to SATA once it's setup as there will be no performance gain to a virtual SATA controller, all of the controllers are virtualized anyway. If you really want it SATA then use the second disk, change IT to SATA, boot to the OS, let it find the 'new' hardware then down the guest.  Change the controller for the OS disk to SATA and boot again. 
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)
Group: Forum Members
Posts: 7.9K, Visits: 55K
@AHansen Not sure how to account for the log saying it copied an active partition and then the BCD note about not having copied an active partition.  Maybe that behavior is deliberate in a clone scenario where there's already an active disk and the error message is just oddly worded for this scenario?

Fix Boot Problems and ReDeploy are completely different tools, although I grant that what ReDeploy does can end up fixing boot problems.  Fix Boot Problems looks for and repairs issues such as Windows partitions not being marked as active, missing/incorrect BCD entries, missing/damaged EFI partition, and some other things I'm not thinking of right now.  ReDeploy will alter the Windows boot-time driver load behavior in order to ensure that the driver set it loads will allow it to boot on the system you're running on.  It's intended to be used when taking an image from one PC and restoring it to another PC.  Windows doesn't always boot properly if you change certain boot-critical hardware out from under it without making certain adjustments, and ReDeploy is meant to make those appropriate adjustments.  If you're using P2V then you may well need to use ReDeploy.

The major time difference you observed is likely the result of Reflect having used Rapid Delta Clone/Restore on subsequent attempts.  If your restore/clone log says "Looking for changes" somewhere, that's your indicator that RDC/RDR was used.  It's one of the major perks of having a paid version of Reflect, in my opinion, especially for people who do a lot of restores (e.g. people who are testing things) and/or who want to keep a clone target disk updated and therefore need to perform the same clone operation on a regular basis.

Rootman - 9 September 2020 11:16 AM
Create a SECOND temporary VHD and copy your backup file directly to it. Attach it to the VM as a second disk.  Boot to the MR ISO and you will be able to see the other disk with it's backup file on it.  It is lightning fast this way.

As far as the non bootable VM.  First you need to make sure the image boots the same was as the original OS.  If it's EFI then choose EFI, if it's MBR then do NOT choose EFI.  I've found with VirtualBox that choosing an IDE drive for the controller type usually works, where choosing a SATA will not sometimes.  There is to real reason to change it to SATA once it's setup as there will be no performance gain to a virtual SATA controller, all of the controllers are virtualized anyway. If you really want it SATA then use the second disk, change IT to SATA, boot to the OS, let it find the 'new' hardware then down the guest.  Change the controller for the OS disk to SATA and boot again. 

That other restore method would certainly work too, but then you have the time and temporary storage consumption penalties of having to copy a backup from its normal destination into this temporary VHD and then STILL performing a restore afterward.

ReDeploy should take care of the discrepancies you've highlighted, except having to match BIOS (not MBR) vs. UEFI booting.  Switching between those would require manual effort.

AHansen
AHansen
Talented Member
Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)
Group: Forum Members
Posts: 51, Visits: 342
@Rootman Thank you.  I've tried ImDisk but must be doing something wrong as the mounted disk is not showing in Disk Management or Reflect.  Simply select the VHD and then click OK, right?


Your advice "Create a SECOND temporary VHD and copy your backup file directly to it. Attach it to the VM as a second disk. Boot to the MR ISO and you will be able to see the other disk with it's backup file on it. It is lightning fast this way." worked great.  I did a clone rather a backup restore but the basic concept  is applicable.  Cut the processing time by more than 50%.   My process for creating a clone of the OS residing on SSD in a different partition/logical drive residing on the same physical SSD is now:
For first run:
  1. Create 2 new FIXED size VHDs (I use vBox for simplicity), one on an internal HDD and one in the target SSD partition [creating a dynamic virtual disk is practically instantaneous but using the dynamic took about 2.5 times as long to do restore/clone]
  2. Leave both VHDs in initial "unallocated" state
  3. mount HDD VHD and clone C:\OS using host Reflect to unallocated HDD virtual (≈ 20 mins for ≈ 70 gig source)
  4. Unmount HDD VHD, add (still unallocated) SSD VHD to HDD VHD guest Storage
  5. Start HDD VHD VM, boot into Reflect Recovery.ISO and either Redeploy or Fix Boot problems (for some reason I experienced Windows not Genuine and no desktop taskbar issues with Redeploy)
  6. Reboot into Reflect Recovery.ISO, clone OS to unallocated "drive" (≈ 10 mins same source)
  7. Activate Windows with unique key (may or may not require phone activation, I've had both happen)
  8. Backup activation state (I use this: Activation Backup - DISM) and copy to safe place
Subsequent runs
  1. Make sure VM's are NOT running (for safety exit vBox)
  2. Mount each VHD and do a diskpart/clean
  3. Repeat 3-6 above
  4. Restore activation states
Cleaning and reusing VHDs is necessary for Windows activation server to see "same hardware" (unless you've got unlimited license keysSmile).
I'm doing the "Texas Two Step" because I still do not understand why the first clone took almost 6 hrs.  If you see anything I can do to further streamline the process please let me know.

@jphughan - I've checked logs in Reflect and there is no mention of "Looking for changes" (& I agree that's a major perk when a backup can be restored in a few mins after an experiment).  I did a search for "Reflect" on my C: drive but didn't find anything additional.  Is there someplace more detailed logs are kept?


Edited 13 September 2020 9:49 AM by AHansen
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)Macrium Evangelist (11K reputation)
Group: Forum Members
Posts: 7.9K, Visits: 55K
Glad that process worked for you, but capturing an IMAGE of your source drive to that HDD VHD, as Rootman suggested, will almost certainly be faster than cloning to it, as you did. The reason is that the performance bottleneck in that step is very likely the write speed of the storage hosting that HDD VHD. An image by default uses compression, which reduces the amount of data to be written to the destination, and thus the impact of that bottleneck, whereas a clone does not use compression.

I don’t think more detailed logs about the job are kept anywhere that isn’t shown in Reflect, but Reflect stores its various logs in its C:\ProgramData folder. Can’t remember the exact path and can’t check at the moment.
Edited 13 September 2020 12:10 PM by jphughan
AHansen
AHansen
Talented Member
Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)Talented Member (107 reputation)
Group: Forum Members
Posts: 51, Visits: 342
jphughan - 13 September 2020 12:08 PM
Glad that process worked for you, but capturing an IMAGE of your source drive to that HDD VHD, as Rootman suggested, will almost certainly be faster than cloning to it, as you did. The reason is that the performance bottleneck in that step is very likely the write speed of the storage hosting that HDD VHD. An image by default uses compression, which reduces the amount of data to be written to the destination, and thus the impact of that bottleneck, whereas a clone does not use compression.
Ha! And therein lies a flawed base assumption on my part: that clone would be faster because it isn't compressed and an image would need to be UNcompressed in addition to copying the source. Hmmm ... it'll use the same number of VHDs.  I'll give it a whirl ...

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search