virtualbox.org

I was informed yesterday that due to corporate policy my workstation is to be re-imaged with Windows 10, and I will need to figure out how to save anything I want to keep. Simple docs are easy, of course, but I have 10 VBox guests, totaling a little over 600 gb. My intent is to test exporting/importing the vm's as appliances. To test, I did the following:

On my Win7 Pro 64-bit workstation, create a vbox guest running Win 7 Pro 64 bit
On the vbox guest, install Win 7 Pro 64-bit
On the vbox guest, install vbox 5.2.22
On the host, export one of my linux guests as an appliance
On the guest, import the appliance.

Everything went well and the appliance imported. However, when i tried to start the new vm (the guest of the guest), it threw "Error: VT-x is not available (VERR_VMX_NO_VMX)"
The machine properties for the Win7 guest show hardware virtualization, enable vt-x/AMD-V as enabled.

I will attach the vbox log from the startup of the win7 guest .. the guest that is itself the host of the second guest.

Why export them? Simply copy the complete VIrtualBox VMs folder to a backup device. When you have VirtualBox back on your computer, restore the folder. Double-click the .vbox file for each vm to re-register it.

Hi, I don't have the same set up as yours but do you have the same issue as mine? Already started the thread but it seems all are busy.

I can see VT-x is not available which I have it as well on my machines.

viewtopic.php?f=6&t=90336#p433487

JIm - I tried the 'copy folder' method on my actual physical workstation as a test. Kept running into problems there. See https://community.oracle.com/thread/4185620. But thinking perhaps said problems were due to not having a 'clean' installation, thought I'd create a clean installation with a vbox guest. Of course it all should work, but I can't prove it if my test guest thinks it can't run a vbox guest itself -- regardless of how the vm is migrated.

I may end up having to request my desktop support group (who is driving the Wind 10 upgrade) to provide me with a physical test machine that they have imaged. That would be the ideal test platform anyway. But I am curious as to what I can learn by working through my current issue developing a test system. And I can't risk losing these VM's without a known, PROVEN migration/recovery method. In reality, I need to do that anyway, regardless of forced migrations, just so I have a good backup/recovery postition, which I've unfortunately neglected until now.

The task is trivially easy. Backup the entire "VirtualBox VMs" folder (I suggest that you fully shutdown - not suspend - the VMs first). Update the host OS. Copy the backed up "VirtualBox VMs" folder back into the user documents area of the upgraded host.

Now download and install VirtualBox.

Register each VM by visiting that VMs subfolder and double clicking the .vbox file.

If you have any error messages then report them. One common mistake with this procedure involves linked clones. If you use linked clones then you must register the base VM before you register any of the clones - and IMHO it would have been better not to use linked clones (the disk savings are a mirage).

Incidentally, the error message mentioned (VERR_VMX_NO_VMX) has been discussed too many times already. Since it started after Win10 was installed I'd say it's a good bet that it's caused by having Hyper-v enabled. Search the forums for past discussions of this error code. We also have a related FAQ: FAQ: I have a 64bit host, but can't install 64bit guests.

mpack - yes it should be trivially easy. That's what I thought when I started to test it.

"The task is trivially easy. Backup the entire "VirtualBox VMs" folder (I suggest that you fully shutdown - not suspend - the VMs first). Update the host OS. Copy the backed up "VirtualBox VMs" folder back into the user documents area of the upgraded host."

And for an initial test, on my existing machine, I did the following:
1) copied the folder of an individual vm - 'vbmigtest' (not the entire VirtualBox VMs folder, as I don't have the space),
2) delete the selected vm from the VBox Manager, selecting to delete the files as well.
3) restore the copied directory back to its original location in 'VirtualBox VMs'
4) From the Vbox Manager menu, selected ‘Machine’ -> ‘Add ..’
5) Drilled down to ‘vbmigtest’ and selected ‘vbmigtest.vbox’.
6) Got this message in a pop-up:

Failed to open virtual machine located in C:/VMLab/VirtualBoxVMs/vbmigtest/vbmigtest.vbox.
Medium 'C:\VMLab\VirtualBoxVMs\vbmigtest\vbmigtest.vdi' cannot be closed because it is still attached to 1 virtual machines.
Result Code: VBOX_E_OBJECT_IN_USE (0x80BB000C)
Component: MediumWrap
Interface: IMedium {4afe423b-43e0-e9d0-82e8-ceb307940dda}
Callee: IVirtualBox {9570b9d5-f1a1-448a-10c5-e12f5285adad}
Callee RC: VBOX_E_OBJECT_NOT_FOUND (0x80BB0001)

So, for all intents and purposes, how is this any different than " Backup the entire "VirtualBox VMs" folder (I suggest that you fully shutdown - not suspend - the VMs first). Update the host OS. Copy the backed up "VirtualBox VMs" folder back into the user documents area of the upgraded host."? Why would VBox think that file was already attached to a VM when I had just deleted that vm before trying to add it back?

The VDI is in use by another VM. Open the MediaManager and find out who that is.

Now I cannot reproduce the problem with vbox thinking the vdi is attached to some other machine. I guess we should close this thread. The 'vdi attached' is secondary to the opening subject, and the cited references for that (vt-x not available) quickly got into water over my head. And back on that, I think my manager has convinced the workstation support group to give me a real test machine.

Yes, I know that the migration should be trivially easy, but doing it without testing violates the first rule of wing-walking - "Never let hold of what you've got until you've got hold of something else." I think we've all, at some point in our careers, have been burned by something that "should" work ...