On Mon, Nov 25, 2024 at 07:25:12PM -0500, John wrote: > I am trying to migrate away from VMware Workstation Pro (16.2.5) on a Debian > 11/Bullseye host and have exported a Windows 10 guest to OVF. > > I have done the following before performing the latest import attempt in > VBox 7.1.4 on a Debian 12/Bookworm host. > OVF file: > - updated the file by changing "ElementName" to "Caption" > - updated the file by changing "vmware.sata.ahci" to "AHCI" > MF file: > - updated the hash for the modified OVF file
These steps are not required and haven't been needed for about ten years now. > Any recommendations on which direction to go with this error? Error logs to > check? > ########################################## > vboxmanage import 'Windows 10 x64.ovf' 2>&1 | tee importfailure > > 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100% > Interpreting /home/user/VMWARE_EXPORTED_VMs/Windows 10 x64.ovf... > OK. > 0%...10%...20%...NS_ERROR_INVALID_ARG > VBoxManage: error: Appliance import failed > VBoxManage: error: Unknown error during OVF import > VBoxManage: error: Details: code NS_ERROR_INVALID_ARG (0x80070057), > component ApplianceWrap, interface IAppliance > VBoxManage: error: Context: "RTEXITCODE handleImportAppliance(HandlerArg*)" > at line 1443 of file VBoxManageAppliance.cpp > Disks: > vmdisk1 60 http://www.vmware.com/interfaces/specifications/vmdk.html > Windows_10_x64-disk1.vmdk 40567882752 -1 > > Virtual system 0: > 0: Suggested OS type: "Other" > (change with "--vsys 0 --ostype <type>"; use "list ostypes" to list all > possible values) > 1: Suggested VM name "vm" > (change with "--vsys 0 --vmname <name>") > 2: Suggested VM group "/" > (change with "--vsys 0 --group <group>") > 3: Suggested VM settings file name "/root/VirtualBox VMs/vm/vm.vbox" > (change with "--vsys 0 --settingsfile <filename>") > 4: Suggested VM base folder "/root/VirtualBox VMs" > (change with "--vsys 0 --basefolder <path>") > 5: Number of CPUs: 2 > (change with "--vsys 0 --cpus <n>") > 6: Guest memory: 6208 MB > (change with "--vsys 0 --memory <MB>") > 7: USB controller > (disable with "--vsys 0 --unit 7 --ignore") > 8: Network adapter: orig bridged, config 2, extra type=bridged > 9: CD-ROM > (disable with "--vsys 0 --unit 9 --ignore") > 10: NVMe controller, type NVMe > (disable with "--vsys 0 --unit 10 --ignore") > 11: SATA controller, type AHCI > (disable with "--vsys 0 --unit 11 --ignore") > 12: Hard disk image: source image=Windows_10_x64-disk1.vmdk, target > path=Windows_10_x64-disk1.vmdk, controller=10;port=0 > (change target path with "--vsys 0 --unit 12 --disk path"; > change controller with "--vsys 0 --unit 12 --controller <index>"; > change controller port with "--vsys 0 --unit 12 --port <n>"; > disable with "--vsys 0 --unit 12 --ignore") > ########################################### It looks like you have uncovered a problem triggered when importing a VM which contains a disk attached to an NVMe storage controller. This normally works but might have been broken by a recent VirtualBox fix. A workaround for now would be to move the disk to the SATA controller during import. For example using the suggested options from above: $ VBoxManage import 'Windows 10 x64.ovf' --vsys 0 --unit 12 --controller 11 We've also fixed this issue now so that importing VMs which contain disks attached to NVMe storage controllers should work again with the next maintenance release of VirtualBox. > -- > Regards, > > John Cheers, Brent _______________________________________________ VBox-users-community mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/vbox-users-community _______________________________________________ Unsubscribe: mailto:[email protected]?subject=unsubscribe
