Bigwozza wrote:I thought VirtualBox was great when I came across it 12 months ago - now I know it is just an Alpha...
Warwick, I think that this conclusion isn't really justified. Hundreds of thousands if not millions of users find it a usable and stable product, so it isn't really Alpha code. It consistently runs faster than both the MS and VMware end-user products, and also runs stably across a range of platforms, so it is preferred by many "power users". What I would say is that in the PC world, most packages go out their way to be novice friendly, this does seem to be a low priority on the VBox roadmap. The whole area of virtualisation is very complex, and needs research to gain a minimum proficiency.
In terms of your problems, most of the complexities are nothing to do with virtualisation but to do with the architectural constraints of the Windows architecture and implementation. (i) There is not supported way to back up a raw boot partition onto a separate device using XP "out-of the box" or the bundled MS tools. This is not the case with Linux; you can do it with the stand OS tools. (ii) If you change the underlying H/W (which is what going from physical to virtual involves) then the OS refuses to boot. Again this just doesn't happen with Linux. The BSODs are caused by the intolerance of XP to new H/W configurations. You would have exactly the same problems if you had copied your laptop image to a new bare metal PC and attempted to boot it native, without any VM product in the way. So these are both Windows limitations and it is unfair to call VBox alpha code because of this. It would be a lot more valid to describe the Windows OS family as alpha code.
Because this is so easy to do in Linux, you really are at a disadvantage in trying to do this in Windows. MS
really don't want you to do this sort of thing and so you've got to use all sorts of tricks and 3rd party products. If I was doing this I would have:
- Prep'ed my system by having a major clean out of crap and all the stuff that I don't need; all those TMP files and MS patch kits that clog up the disk.
- Defrag'ed the system, turned off hibernation, installed a minimum pagefile.sys (2MB IIRC). Then run the MS systinternals sDelete utility to zero out the free space on the disk. At this point do a safety backup using whatever tool is convenient.
- Ensured that you are running a non-SMP kernel and HAL, swapping them out if necessary.
- Trashed the physical driver configuration in the device manager to remove all of the H/W specific device drivers which could stall the load. Run the MergeIDE utility and power off the machine.
- Boot a LiveCD and mount and smb share offered by the new system. dd if=/dev/hda1 | bzip -c > /smbshare/oldLaptopImageDump.bz2. Also dd if=/dev/hda of=/smbshare/oldLaptoMBR count=1 bs=512
- On the new machine, create a VDI which is the identical size as the old Laptop HDD. And then boot a LiveCD (CD or ISO) inside a VM with this VDI connected.
- Again mount the SMB share, then restore the old system MBR to the new VDI and run fdisk to reload the partition table. Then restore the oldLaptopImageDump.bz2 to the first partition. Because the geometry of this VDI is the same as the old system, the partition table and MBR will work fine. Shutdown the VM.
- Remove the LiveCD and boot the VM off hdd 0. You need the XP CD connected because some drivers will be missing.
- Install Guest Additions, and reset the Pagefile to a sensible value.
- Reactivate Windows. This will need phone call to MS.
This would take me a couple of hours start to finish.. The problem is that each of these points involved quite a lot of knowledge. We have posts which discuss each in depth on the forum. However if you don't have this knowledge then you've got an awful lot of learning to do, and the forum can help.
As I said, little of this complexity is to with VBox. Most is getting around restrictions in how you work with Windows systems. So please don't blame Sun here.