Natively boot Virtualbox Image

"I am in the process of de-virtualising everything" - really? o_O why?

FWIW of your two suggested approaches, I'd migrate it but I'd be more than a little bit wary of this approach personally.

Your question is a little unclear: does the VM run now as it is? Unless you're having an actual problem other than being wary of virtualisation, my real suggestion is to actually leave it where it is, virtualised.

update to address comments

Ok, to address your comments, if the server is critical and currently running then I'd suggest borrowing "first do no harm" from the medical community. What I mean by that is that if you wish to change how this server is hosted at all, you should place the results of any migration onto a new server, so that the current server will be available as much as possible while you work on the new one, and so that anything you do cannot 'damage' the current service to your users. This approach will also allow you to take the time and do things right.

If you can't get the budget to do this with a critical system then you may have just found the reason why your predecessor made what appear to be a few very questionable choices...

As for the suitability of virtualisation, I'd say that your predecessor was barking mad to run a mission critical system in a virtualbox install on a workstation OS, but that doesn't mean that there's anything wrong with virtualisation per se. This is not really worse than running critical servers on old workstations "because that's all we had around at the time" and I think we've all seen that happen.

I'm running most (about 60 servers) of our production servers on eight VMWare ESXi servers and our development/testing environments on 3 Microsoft HyperV boxes - these are both free 'server quality' virtualisation products (though you do pay for the fancy tools to manage a datacentre full of them) and I've never had unplanned downtime from either of them. Both of these also have tools that allow you to migrate/import currently running servers so this could make a migration very simple

So given what you've described, I'd suggest:

1. Migrating the server to new hardware regardless of whether you choose to look at virtualisation with the 'right' tools or stay 'bare metal'.
2. Consider one of the "server quality" virtualisation tools, to hopefully take advantage of their migration/import tools to painlessly migrate away from the current, flawed, system.

VirtualBox is almost certainly the wrong tool for server virtualization, but that doesnt mean that you shouldn't virtualize. If you have a Standard 2008R2 license, it allows for one host and one guest install. If it's Enterprise, you get 4 guests.

Also, since you have 2008 R2, you have free access to the Hyper-V Server role. Hyper-V is an excellent solution that won't cost you any additional money. Unless you have a compelling reason to V2P your infrastructure, your "old skool" ways are going against the grain.

You cannot native boot a virtualbox image using bcdedit (you can set a VHD to native boot but not all images) I'm not sure why you would want to "devirtualize" everything unless "old school" is somehow synonymous with "scared". In short the whole "de-virtualize" idea isn't a good one.

If you really want to migrate this the best option I can think of is to power up the VM, use the Microsoft deployment toolkit to capture the image and redeploy that image to another machine (or the parent machine).

EDIT:

If crashes are the issue on the VM and not the server, chances are the Hypervisor is to blame (without more details on the crashes of course). I would add the hyper-v role to the parent 2008R2 server, after capturing the image with MDT ,and then (in order of preference)

1. rebuild the troublesome VM and migrate the data
2. use the MDT to try deploying to the Hyper-v VM

For people seeing this post (and not checking the date just wanting some help om something similar.)

heres what i would do, on the basic install (or the os on the real drive not the image) i would run a utility called driverbackup! (thats what its called on sourceforge) back up all the drivers, AND make sure you tick the restore file generation option.

THEN i would make sure the virtual system is off, a VHD file would be most apropriate, it u cannot get a vhd, i.e your using vmdk or the image was in a backup file say easeus PBP format, they have converter options, vmware has an option, i think virtualbox has an internal option, but i cannot remember what its called.

easeus todo backup has a backup image converter, to vmdk or vhd, if you use this app, select the vhd format, name and save somewhere.

then look up how to restore drivers to an offline image on microsoft technet site, look for your desired version, ie vista, 7, 2008,08 r2, 2012, 12 r2, 8, 8.1 etc.

the drivers you backed up HAVE to match the architecture of the os your gonna restore them to. ie X86 to X86, X64 to X64, IA64 to IA64 etc. (implying the virtual os was the same architecture, not the user is stupid etc)

follow the microsoft instructions to restore the drivers.

now once you have that completed, mount the VHD using diskmgmt.msc (click attach vhd) go find your file, once you do that click open/accept/etc

use your favorite tool to backup the drive image (as if it was a physical one) store the image on a seperate medium or place it somewhere on a network/external drive.

(e.g windows backup generates a folder and some files in it to go with that image backup)

if the program has a bootable utility, boot into that. this assumes you want RID of your current windows OS.

goto the option to restore the image. find a way to reach the image, i.e if networking is needed, you might of needed drivers in the bootable utility, wireless cannot work this way as there isnt a utility to scan networks and enter passwords, gui or command line to my knowledge.

if you still require multiboot options you could resize the host os to make room and create a space for your image restore.

after you find the image, put it over the destination (partition if multiboot) or (drive if wiping the drive fresh).

you should after its complete have an option now to boot into your os you restored, if multiboot, you will manually need to either edit the name of the item & partition UID for the boot configuration to find your newly restored os i.e. if its a different windows version ie say you restores 2012 r2 and you had 2008 r2, and it will boot but has a wrong name, or its the same os, but it is trying to boot to a wrong partition as that information is not updated to reflect the changes a tool called EASY BCD will help if u need to do it via gui, BUT you need a commercial licence if its a business you are doing this for.

now, you should be up an running with a virtual os put onto a physical drive, and it will now be as you wanted, no messing about migrating, or cutting and pasting stuff from folders or registries etc.

should JUST boot.

hope this helps anyone in need for some help and couldnt find a no nonsense get to the point way of sorting this kind of scenario out.

for me it came down to personally doing this kinda stuff with home os versions of stuff, as i am a home user, but it applies to commercial also as in the end, it is a windows os, it has folders, it has registries, it has a boot config, and they have uuid-like entries in this config, so they mainly operate the same when coming down to the real basics.

kind regards, Dez Ainsworth