Opened 2 months ago
Last modified 25 hours ago
#22326 reopened defect
Export fails for ... reasons => fixed in svn/7.1.x x>6
| Reported by: | James Moe | Owned by: | |
|---|---|---|---|
| Component: | OVF | Version: | VirtualBox-7.1.4 |
| Keywords: | VBoxManage export falure | Cc: | |
| Guest type: | other | Host type: | Linux |
Description
VBox version: 7.1.4_SUSEr165100
opensuse tumbleweed 20250220
Linux 6.13.3-1-default x86_64
I have been unable to export VMs several weeks now. Below is the sum total of information I can extract from VBoxManage. My account is in the "vboxusers" group.
$ /usr/bin/VBoxManage export os2v4.52 --output=/d500g/backups/vbox/os2v4.52.ovf VBoxManage: error: Code NS_ERROR_ABORT (0x80004004) - Operation aborted (extended info not available) VBoxManage: error: Context: "ExportTo(pAppliance, Bstr(pszAbsFilePath).raw(), pVSD.asOutParam())" at line 1867 of file VBoxManageAppliance.cpp ----[ end ]----
Attachments (3)
Change History (20)
by , 2 months ago
comment:1 by , 2 months ago
The bulk of the work for exporting a VM happens in VBoxSVC so could you capture the logs from VBoxSVC as described here:
https://www.virtualbox.org/wiki/VBoxMainLogging
You want the 'main_appliance' log group so thus you would first run a command like:
$ env VBOXSVC_RELEASE_LOG_FLAGS="time thread tsc" VBOXSVC_RELEASE_LOG_DEST=dir=/tmp \ VBOXSVC_RELEASE_LOG=main_appliance.e.l.l2.l3.f VBoxSVC
in one window and then in another run the 'VBoxManage export ...' command. Afterwards there should be a log file in /tmp named VBoxSVC.log. Once completed could you upload that file here?
Two unrelated items from the provided VBox.log:
00:00:00.490453 Oracle VM VirtualBox Extension Pack (Version: 6.1.36 r152435; VRDE Module: VBoxVRDP; Crypto Module: unusable because of 'VBoxExtPackVMRegister returned VERR_VERSION_MISMATCH, pReg=0000000000000000 ErrInfo='Helper version mismatch - expected 0x30000 got 0x50000'')
The Oracle VM VirtualBox Extension Pack must be the same version of VirtualBox which is running on the host, in this case 7.1.4.
00:00:17.979308 VMMDev: Guest Additions information report: Version 7.1.0 r164728 '7.1.0' [...] 00:00:20.716082 VMMDev: Guest Log: VBoxSFR0Init: version 6.1.36 r152435VBoxSFR0Init: g_fpfnDevHlp=136816c0 u32Version=10000 u32Session=fde42a20 pfnServiceEP=f39d3a20 g_u32Info=0 (0x0)
This is odd, it looks like you have both the VirtualBox 7.1.0 and 6.1.36 Guest Additions installed. See if you can uninstall both of these and install the 7.1.4 GAs.
comment:2 by , 2 months ago
It did not get very far per those instructions:
$ env VBOXSVC_RELEASE_LOG_FLAGS="time thread tsc" VBOXSVC_RELEASE_LOG_DEST=dir=/tmp VBOXSVC_RELEASE_LOG=main_appliance.e.l.l2.l3.f VBoxSVC env: ‘VBoxSVC’: No such file or directory
comment:3 by , 2 months ago
On Linux the VBoxSVC binary is delivered as /usr/lib/virtualbox/VBoxSVC.
comment:5 by , 2 months ago
The log is very short since it is from an invocation to export a VM to a cloud service such as Oracle OCI and the logging was only enabled for exporting a VM into a local appliance. Is this definitely the correct VBoxSVC.log? Was the command just 'VBoxManage export os2v4.52 --output=/d500g/backups/vbox/os2v4.52.ovf' or were there any other options supplied?
comment:6 by , 2 months ago
The log is very short since it is from an invocation to export a VM to a cloud service such as Oracle OCI ...
Is there a setting somewhere that would override the "output" option?
Is this definitely the correct VBoxSVC.log?
I presume so. There was no log vbox log file in /tmp/ before trying the export. Then there was after the export. The date and time were consistent for a new file.
Was the command just 'VBoxManage export os2v4.52 --output=/d500g/backups/vbox/os2v4.52.ovf'?
Yes, that is the complete command.
Here is the VBOX environment:
$ env | grep VBOX VBOXSVC_RELEASE_LOG_FLAGS=time thread tsc VBOXSVC_RELEASE_LOG=main.e.l.f+gui.e.l.f VBOXSVC_RELEASE_LOG_DEST=dir=/tmp
comment:7 by , 2 months ago
I just discovered this in the system journal:
2025-02-26T13:37:46-07:00 sma-station14l kernel: DCon01[308615]: segfault at 557bd3919004 ip 0000557bd3292b86 sp 00007f9dcd6fe520 error 4 in VBoxSVC[251b86,557bd3171000+4e7000] likely on CPU 10 (core 4, socket 0)
2025-02-26T13:37:46-07:00 sma-station14l kernel: Code: c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 1f 80 00 00 00 00 48 85 db 74 db 48 89 d8 48 83 e8 01 75 08 eb d0 48 83 c0 01 74 ca <45> 39 64 c5 00 75 f3 eb a4 90 41 83 ff 01 19 c0 48 83 c4 08 83 e0
2025-02-26T13:37:46-07:00 sma-station14l systemd-coredump[308627]: Process 308607 (VBoxSVC) of user 1000 terminated abnormally with signal 11/SEGV, processing...
2025-02-26T13:37:46-07:00 sma-station14l systemd[1]: Started Process Core Dump (PID 308627/UID 0).
2025-02-26T13:37:46-07:00 sma-station14l systemd[1]: Started Pass systemd-coredump journal entries to relevant user for potential DrKonqi handling.
2025-02-26T13:37:46-07:00 sma-station14l systemd-coredump[308628]: [🡕] Process 308607 (VBoxSVC) of user 1000 dumped core.
Stack trace of thread 308615:
#0 0x0000557bd3292b86 n/a (n/a + 0x0)
#1 0x0000557bd329fe04 n/a (n/a + 0x0)
#2 0x0000557bd361752e n/a (n/a + 0x0)
#3 0x00007f9dcfb33c29 VBoxNsxpXPTC_InvokeByIndex (VBoxXPCOM.so + 0x81c29)
#4 0x00007f9dcd819e1b n/a (VBoxXPCOMIPCC.so + 0x17e1b)
#5 0x00007f9dcd81a89d n/a (VBoxXPCOMIPCC.so + 0x1889d)
#6 0x00007f9dcf7985cb n/a (VBoxRT.so + 0x1985cb)
#7 0x00007f9dcf798732 n/a (VBoxRT.so + 0x198732)
#8 0x00007f9dcf798959 n/a (VBoxRT.so + 0x198959)
#9 0x00007f9dcf79d2ac n/a (VBoxRT.so + 0x19d2ac)
#10 0x00007f9dcf85b43d n/a (VBoxRT.so + 0x25b43d)
#11 0x00007f9dcee98292 start_thread (libc.so.6 + 0x98292)
#12 0x00007f9dcef1d4fc __clone3 (libc.so.6 + 0x11d4fc)
Stack trace of thread 308609:
#0 0x00007f9dcee9459e __futex_abstimed_wait_common (libc.so.6 + 0x9459e)
#1 0x00007f9dcee97420 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x97420)
#2 0x00007f9dcf85d2f2 n/a (VBoxRT.so + 0x25d2f2)
#3 0x00007f9dcf79a501 RTReqQueueProcess (VBoxRT.so + 0x19a501)
#4 0x00007f9dcf85afde n/a (VBoxRT.so + 0x25afde)
#5 0x00007f9dcf79d2ac n/a (VBoxRT.so + 0x19d2ac)
#6 0x00007f9dcf85b43d n/a (VBoxRT.so + 0x25b43d)
#7 0x00007f9dcee98292 start_thread (libc.so.6 + 0x98292)
#8 0x00007f9dcef1d4fc __clone3 (libc.so.6 + 0x11d4fc)
Stack trace of thread 308607:
#0 0x00007f9dcef1a9fc __select (libc.so.6 + 0x11a9fc)
#1 0x0000557bd36517a7 n/a (n/a + 0x0)
#2 0x0000557bd3651c6d n/a (n/a + 0x0)
#3 0x0000557bd324da7c n/a (n/a + 0x0)
#4 0x00007f9dcee2a2ae __libc_start_call_main (libc.so.6 + 0x2a2ae)
#5 0x00007f9dcee2a379 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2a379)
#6 0x0000557bd324e025 n/a (n/a + 0x0)
ELF object binary architecture: AMD x86-64
2025-02-26T13:37:46-07:00 sma-station14l systemd[1]: [email protected]: Deactivated successfully.
2025-02-26T13:37:46-07:00 sma-station14l drkonqi-coredump-processor[308629]: "/usr/lib/virtualbox/VBoxSVC" 308607 "/var/lib/systemd/coredump/core.VBoxSVC.1000.3116df6cff504822b4ccb3652c957725.308607.1740602266000000.zst"
2025-02-26T13:37:46-07:00 sma-station14l systemd[3372]: Started Launch DrKonqi for a systemd-coredump crash (PID 308629/UID 0).
2025-02-26T13:37:46-07:00 sma-station14l systemd[1]: [email protected]: Deactivated successfully.
2025-02-26T13:37:46-07:00 sma-station14l drkonqi-coredump-launcher[308644]: Unable to find file for pid 308607 expected at "kcrash-metadata/VBoxSVC.3116df6cff504822b4ccb3652c957725.308607.ini"
2025-02-26T13:37:46-07:00 sma-station14l drkonqi-coredump-launcher[308644]: Nothing handled the dump :O
comment:8 by , 2 months ago
Can you upload the VM's settings file located at $HOME/VirtualBox VMs/os2v4.52/os2v4.52.vbox? You can redact any details therein that you don't want to share such as information which might qualify as Personally Identifiable Information (PII) like usernames or etc. With the .vbox file we should be able to get a better idea of what is going wrong.
comment:9 by , 2 months ago
Settings file attached.
Oh! And I have updated the Extensions for both VirtualBox Manager and the VM.
comment:10 by , 2 months ago
The problem looks to be in parsing the OStype value. As a workaround can you try the following:
VBoxManage modifyvm os2v4.52 --x86-long-mode=off
and then try out your 'VBoxManage export' command? You can re-enable long-mode after the export.
comment:11 by , 2 months ago
That worked. I do not remember it taking 10 minutes to do the backup. Then again, it has been quite a while since I paid attention to it.
comment:12 by , 2 months ago
An oddity: The list of 3 storage units for the VM is named /d500g/vbox/os2v4.52-disk00[1, 2, 3].vmdk. The backup created files /d500g/backups/vbox/os2v4.52-disk00[2, 3, 4].vmdk.
Is this expected?
$ ll /d500g/backups/vbox/ -rw-r--r-- 1 jmoe users 728M Mar 1 12:57 os2v4.52-disk002.vmdk -rw-r--r-- 1 jmoe users 1.9G Mar 1 12:59 os2v4.52-disk003.vmdk -rw-r--r-- 1 jmoe users 13G Mar 1 13:07 os2v4.52-disk004.vmdk -rwx------ 1 jmoe users 14K Mar 1 12:57 os2v4.52.ovf* $ ll /d500g/vbox/ -rw------- 1 jmoe users 729M Jun 15 2023 os2v4.52-disk001.vmdk -rw------- 1 jmoe users 1.9G Jun 15 2023 os2v4.52-disk002.vmdk -rw------- 1 jmoe users 13G Jun 15 2023 os2v4.52-disk003.vmdk -rw-rw-r-- 1 jmoe users 15K Mar 25 2023 os2v4.52.ovf
comment:13 by , 8 weeks ago
Thanks for the fix verification, the fix for this has gone back into the gate and will be part of the next maintenance release of VirtualBox.
The disk numbering generated by the export process which gets written to the OVF file (and then is used by the import process for naming the disks in the imported VM) is generic and is based purely on the order of the disk media found in the VM's configuration file. So in this case the os2v4.52.vbox file lists the ISO attached to the DVD drive first and thus it gets assigned 'disk1' and then the three hard disks get assigned 'disk2', 'disk3', and 'disk4'. If you remove the ISO from the DVD drive and do another export then the disks would be named 'disk1', 'disk2', and 'disk3'. In short it's a simple counter of the disk media as they appear in the VM's configuration file and it has always worked this way. Most people don't notice as they have a single disk named something like 'windows-disk1.vmdk' and the export+import process results in 'windows-disk001.vmdk'.
comment:15 by , 5 days ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
| Summary: | Export fails for ... reasons → Export fails for ... reasons => fixed in svn/7.1.x x>6 |
This issue has been addressed in VirtualBox 7.1.8 which was recently released and is available here.
comment:16 by , 27 hours ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
The opensuse repo finally updated VBox to 7.1.8.
# VBoxManage -V 7.1.8_SUSEr168469
Here is the result with the new version.
$ sudo /usr/bin/VBoxManage export os2v4.52 --output=/d500g/backups/vbox/os2v4.52.ovf [sudo] password for root: VBoxManage: error: Could not find a registered machine named 'os2v4.52' VBoxManage: error: Details: code VBOX_E_OBJECT_NOT_FOUND (0x80bb0001), component VirtualBoxWrap, interface IVirtualBox, callee nsISupports VBoxManage: error: Context: "FindMachine(Bstr(strMachine).raw(), machine.asOutParam())" at line 1790 of file VBoxManageAppliance.cpp
The message occurs for any command, not limited to "export."
$ sudo VBoxManage modifyvm os2v4.52 --x86-long-mode=off VBoxManage: error: Could not find a registered machine named 'os2v4.52' VBoxManage: error: Details: code VBOX_E_OBJECT_NOT_FOUND (0x80bb0001), component VirtualBoxWrap, interface IVirtualBox, callee nsISupports VBoxManage: error: Context: "FindMachine(Bstr(a->argv[0]).raw(), machine.asOutParam())" at line 842 of file VBoxManageModifyVM.cpp
The VM starts and runs without a problem.
comment:17 by , 25 hours ago
(sigh)
User error. I was running it as root. It does, indeed, perform the backup.
VBox.log