[Resolved] Copy VM or Export Appliance results in No bootable medium

[JasonA]

I have VirtualBox 5.2.30 runing on a Windows 10 version 1803 PC. I have a currently-working Virtual machines, running 64-bit Ubuntu 14.04.5 (old, but that's what I need !). The disk image is a VDI file that is sized at 128GB but dynamically allocated. Currently it has an actual size of about 34.5 GB.

I want to copy it to create a new VM, then update some of the software that was added to the base Ubuntu operating system (since I don't have enough space in the VDIs to install multiple versions side-by-side). This seems, at first look, pretty straightforward stuff.

So I start from the VirtualBox Manager GUI, right-click on the VM, and select Clone (in Expert mode). I choose a unique new machine name, then Clone type = Full Clone and Snapshots - Current machine state (which BTW was powered-off with no actual snapshot files in existence).

Then I try and run the new (cloned) VM. It always fails with "FATAL: No bootable medium found! System halted."

I also tried using the File -> Export Appliance and then File -> Import Appliance process (which is much slower !) but still, I got the same result.

If I do a binary comparison of the original and new VDI files, there are significant differences. I expected just to see a changed UUID embedded somewhere near the start of the file, but the changes I see are more extensive and seem to be scattered right through the new VDI file.

I have previously used these methods and NEVER had a problem. I don't know if it's something to do with being on the 5.2.30 version. I have no idea what VirtualBox version(s) I last used Clone and Export/Import Appliance. It always "just worked"

I also tried going to the Virtual Media Manager GUI, and using the Copy function from there, and then attaching that newly-copied VDI file to the new VM.

I did a comparison of VBOX file for the old and new VMs and they are the same with the exception of the UUIDs.

So I am left wondering why the resultant (copied/cloned) VDI file for the new VM is so completely different.

Any ideas ???

[socratis]

why the resultant (copied/cloned) VDI file for the new VM is so completely different

For starters the cloning process eliminates all zeroed clusters. It's another way of compacting a VDI. So, the VDI itself may look different, but the contents should remain the same.

You say you're not getting an error, and you've done this with other VMs. Any idea what might be different with this one? I would expect trouble if the GRUB was trying to boot from a specific hard drive UUID, but you say that you don't even get to the GPUB loading, which is weird.

Can you post the .vbox for the troubling VM? Also, since you seem knowledgeable enough, look in the .vbox for a section similar to this one:

<MediaRegistry>
  <HardDisks>
	<HardDisk uuid="{4634c117-7d4f-4d52-a80a-26dbfa183797}" location="Ubuntu 16.04.vdi" format="VDI" type="Normal">
	  <HardDisk uuid="{04ccd016-fa3b-4fa3-8962-1ff44e228bcc}" location="Snapshots/{04ccd016-fa3b-4fa3-8962-1ff44e228bcc}.vdi" format="VDI"/>
	</HardDisk>
  </HardDisks>
</MediaRegistry>

This one is from an Ubuntu 16.04, with a main VDI UUID of {4634c117-...}, and a snapshot UUID of {04ccd016-...} (the indented one, you shouldn't have that). Can you also post the output of the command:

• 
  VBoxManage showmediuminfo {4634c117-...}

where of course you replace that UUID with the one that's in your .vbox.

[JasonA]

Thanks to @socratis for the previous reply. I apologize for not being able to respond sooner.

It turns out that Forcepoint DLP Endpoint software had been installed on my PC by our corporate IT group, and that it somehow injects itself into VirtualBox's processes. Once a policy update was provided to prevent this, VirtualBox is running normally again. Strangely, the presence of Forcepoint didn't cause VirtualBox to complain when doing its hardening checks.

A side-effect of Forcepoint's interference is that with my VDI files residing on an external USB3 SSD (due to limited internal SSD capacity), whenever a new VM was started there was a sudden decrease in remaining disk space on my C: drive. If the VDI file was 30 GB, then I lost about the same from C: drive. If the VDI was 10GB, then the loss was about 10GB. What exactly Forcepoint was doing, I do not know - at a guess I'd say it was trying to make a copy to somehow analyze and possibly even forward to an analysis/reporting server. That's only a hunch, but with the way Forcepoint stealthily goes about its business and uses NTFS permissions to prevent ordinary users seeing inside certain parts of the system drive, it's difficult to tell for sure. Based on this instance, I'd say Forcepoint is poorly written and a resource hog.

Lesson learned: Any DLP (Data Leakage Protection) software is a nuisance !!!

[socratis]

Strangely, the presence of Forcepoint didn't cause VirtualBox to complain when doing its hardening checks.

The hardening check are done, and Forcepoint most probably was OK. VirtualBox doesn't reject all 3rd party applications that might enter its memory, only the ones that don't have matching certificates in the Windows Certificate Database. So, Forcepoint could easily get the OK...

What exactly Forcepoint was doing, I do not know - at a guess I'd say it was trying to make a copy to somehow analyze and possibly even forward to an analysis/reporting server

That's a plausible scenario. Why would that interefere with the ability of VirtualBox to export the VM, is also beyond my understanding.

Lesson learned: Any DLP (Data Leakage Protection) software is a nuisance !!!

As I said just yesterday:

Marking as [Resolved], although I have the feeling that a new, more realistic tag should be applied: [ItsThoseFreaking3rdPartyLeachAppsYetAgain]...

Thank you for the feedback and the solution, hope someone finds it useful in the future.