Error on Linux: Failed to open virtual machine; NS_ERROR_INVALID_ARG (0X80070057)

[bzilak]

Hi!
I have multiple Linux installations on my computer, and VB 7.0.12 in several of them. I have accessed several VMs from various hosts with no problems. But now the error occurred when I tried to add a (existing) VM into VB Manager. As I said, I used that and some other VMs from different host systems and never had that problem.

Here are some observations I've got following some ideas I came across during my research. The disk space is not a problem, bacause I (successfully) added that VM in another host which has less free space than this one.

Next: I noticed that when I open Tools > Media > tab Optical disks there is, among others, "VBoxGuestAdditions.iso", which apparently stays attached to some VM (with Windows 11 in it), even if remove that .iso file from virtual CD, either from the VM or through VB Manager. Namely, I thought that I should remove GA CD from the list, but I found I can't.

Next: There are no files of the same name in any relevant folders. Namely, on this host's home partition there is no VB folder, and VMs are located in other partitions.

Next: There are no permission problems, because all relevant folders belong to me, the user ("$USER").

Both the host and the guest OS are Linux installations. VM is shut down. All those systems are up to date. How can I add this VM in this instance of VB?

[bzilak]

I have some new findings. The incapability of adding the VM has nothing to do with accessing it from other installations, because I removed the VM in question from VB on all other installations and still get the same error.

I have one clarification also: When some VM from the list of VMs in VB is, for example, on a non-mounted partition then there is displayed a message that the file is not found, but in my case there is no such a message and I can browse the VM file, but get the error message (immediately) afterwards.

Some of my VMs can be accessed from multiple host installations, and some can not.

[scottgus1]

Sounds like a complicated setup you have. I think we're going to need a detailed explanation of your setup, and perhaps zipped Virtualbox.XML's (global configuration data file, see https://www.virtualbox.org/manual/ch10. ... ata-global ) from each host, so we might get an idea what you see happening.

Note also, that the NS_ERROR numbers are only really helpful to the devs, which aren't most of us, and most often are common to many errors. The human-readable part of the error message may help better.

[bzilak]

Thank you for the quick response! Here is the setup.

Code: Select all

NAME        FSTYPE FSVER LABEL    FSAVAIL FSUSE% MOUNTPOINTS
sda                                              
├─sda1                                           
├─sda2      ext4   1.0   rezerv                  
├─sda3      ext4   1.0   Win        61,8G    16% /media/<user>/Win
├─sda5      swap   1                             [SWAP]
├─sda6      ext4   1.0   MXKDEr                  
└─sda7      ext4   1.0   NeonH        60G    87% /media/<user>/NeonH
sdb                                              
(...)
sdc                                              
(...)
sr0                                              
nvme0n1                                          
├─nvme0n1p1 ext4   1.0   tmp                     
├─nvme0n1p2                                      
├─nvme0n1p5 ext4   1.0   del                     
├─nvme0n1p6 ext4   1.0   antiXr                  
├─nvme0n1p7 ext4   1.0   MXh        15,9G    62% /media/<user>/MXh
├─nvme0n1p8 ext4   1.0   DebianR     3,3G    78% /
└─nvme0n1p9 ext4   1.0   DebianH    21,5G    48% /home

Disks "sdb" and "sdc" are of no interest, I suppose. I have 3 VMs: "Linux" and "Wine0" on sda7 and "Win11" on sda3.

VB is installed on: nvme0n1p6 (nvme0n1p7 is it's corresponding home partition, but there are ho VM files), nvme0n1p8 (nvme0n1p9 is it's /home, no VM's) and sda6 (sda7 is it's /home, with 2 VMs).

"Linux" (sda7) is accessible only from nvme0n1p9 (nvme0n1p8) and sda7 (sda6); but "Wine0" (sda7) and "Win11" (sda3) only from nvme0n1p7 (nvme0n1p6).

I'm sorry for the messy naming, I made some changes in the setup recently.

The error message I posted is the one I've got in the GUI, and here is the one from the CLI:

Code: Select all

$ VBoxManage registervm /media/<user>/NeonH/<user>/VirtualBox\ VMs/Wine0/Wine0.vbox

VBoxManage: error: Code NS_ERROR_INVALID_ARG (0x80070057) - Invalid argument value (extended info not available)
VBoxManage: error: Context: "OpenMachine(Bstr(a->argv[0]).raw(), Bstr(strPassword).raw(), machine.asOutParam()))" at line 160 of file VBoxManageMisc.cpp

[fth0]

For a test, please try the following:

Reboot your DebianR host, so that no VirtualBox component is running. Make a backup of the existing VirtualBox.xml and edit the file by hand, ignoring the big warning at the beginning . In the "GUI/GroupDefinitions" key, remove the last two ",m=..." parts of the value and save the file. See if the issue persists.

PS: With such a sophisticated setup, I assume that you know what you're doing. If I'm wrong, don't hesitate to ask.

PPS: As always: No backup, no mercy!

[bzilak]

The error remains the same. (It sounds like... never mind! ) I changed VirtualBox.xml from another OS, rebooted into DebianR, and tried to add the earlier inaccessible VMs, and got the same errors, both in the GUI and in the CLI. VirtualBox.xml remained as I saved it.

Just a remark: I am a bit surprised that my setup is so important, and a bit afraid is it the right way to investigate. Namely, suppose that I keep all of my VMs and only one host OS installed and delete all the others; then my setup would be simple, and some of my VMs unusable for me. I would rather follow that way of thinking, to concentrate on one host OS and make it access all of my VMs. Then I would decide what to do with VB on the other hosts.

[fth0]

The error remains the same.

Thanks for trying. With this test, we've eliminated a left-over connection between the VirtualBox.xml file and the Wine0 and Win11 VMs from the list of suspects.

Speaking of connections: In general, the global configuration file (VirtualBox.xml) points to the Virtual Machine files (*.vbox), and these in turn point to the virtual hard disk image files (e.g. *.vdi). The OpenMachine() function call, where the error is thrown, uses contents from the Wine0.vbox file to do some checks. Please provide a zip file with the Wine0.vbox, Win11.vbox and Linux.vbox files.

I am a bit surprised that my setup is so important

In a simple setup, each Virtual Machine file (*.vbox) is only pointed to by one global configuration file (VirtualBox.xml), so it cannot "transport information" from one setup to another. Whatever that "information" is. And if you would try to simplify your setup, as you're thinking about, it could happen that you take your problem with you with the parts that you keep. I'd therefore prefer to further analyze the existing problem a bit.

A few remarks regarding your earlier observations:

There are no permission problems, because all relevant folders belong to me, the user ("$USER").

The username ("$USER") isn't that significant, more important for permission problems would be the user ID ("$UID"). Does the user have the same user ID in all host OSes?

The incapability of adding the VM has nothing to do with accessing it from other installations, because I removed the VM in question from VB on all other installations and still get the same error.

AFAIU your setup, the VirtualBox.xml files are separate per Linux host, but the .vbox files are shared. In consequence, the latter could somehow "transport" problems from one host to another.

Note also, that the NS_ERROR numbers are only really helpful to the devs, which aren't most of us, and most often are common to many errors. The human-readable part of the error message may help better.

I'm not one of the VirtualBox developers, but I sometimes investigate issues in the (publicly available) VirtualBox source code, so please don't stop providing the error codes. Unfortunately, NS_ERROR_INVALID_ARG (0X80070057) is one of the ubiquitous error codes, also in the OpenMachine() implementation.

[bzilak]

Yes, $UID is 1000 in all host OSes.

I made some progress, I'll keep working, but I have some useful findings. I managed to access some earlier inaccessible VMs by booting into OS from which such one is accessible and emptying its CD drive, and doing so for each one of them.

But in some situations that does not resolve the problem. I'll investigate further, and will post more.

I'll provide the .vbox files later as needed.

[bzilak]

Thank you very much! I thought that I was not expecting too much, and that my setup was not too complicated for VB, but it turns out I was wrong. I don't want to seem ironical, although it is maybe inevitable, I just want to express my stance. I am just sorry, not unsatisfied, that my problem is too much for VB. Basically, I have two or three host OSes in a multi-boot configuration and I want to access the same VM from either of them; I have expected that this has been no problem at all.

VirtualBox is an amazing program, I am very thankful for it being at our disposal! I don't want to take up any more of your, or anyone's, time and effort if VB is not intended to cope with situations like mine; I thought that my problem would be of interest for VB team, but if it is not it is OK.

I will very appreciate your possible further help, as I do for the past one, but I don't want to bore you with too extravagant demands which interest only me.

[Martin]

Some years ago I had a similar setup.
Maybe it works better if you don't rely on the automatic mounting under /media/user and configure a fixed static mount point on both linux using the same mount point name.
Also you need to make sure that the guest configs only use relative paths inside their .xml files.

[bzilak]

Thank you, Martin, I'll consider your suggestions. I have my own ideas for testing, so I can't respond quickly on yours.

I realized that one of my concerns may be of common importance, that is the one I mentioned: If I create a VM, and put it in the "less accessible" state but which is locally normal, for example, according to my tests, put some .iso file in its CD drive, and then delete the host OS while keeping the VM, will the VM be normally (i.e. without any non-standard interventions on config files or so) usable for VB installations on other OSes of the same type, e.g. Linux? Maybe this requires particular testing, in which I am not interested right now, but I think that it is connected to the testing I do.

[fth0]

Thank you very much!

You're welcome!

I will very appreciate your possible further help, as I do for the past one, but I don't want to bore you with too extravagant demands which interest only me.

No, your problems are of interest to me! Otherwise, I wouldn't try to help.

Your setup is not too complicated for VirtualBox, but it's also not what many VirtualBox users do. In consequence, there could be bugs in VirtualBox and/or incompatibilities in your setup. The next things to check would be the contents of the Virtual Machine files (*.vbox), what includes the absolute/relative paths Martin mentioned.

PS: With your own experiments, you're constantly modifying all VirtualBox configuration files. So when you provide the Virtual Machine files (*.vbox), provide them together with the current global configuration file (VirtualBox.xml) of the DebianR host where the problem occurs.

[bzilak]

I think that I resolved the problem, at least for what I needed. I concluded that a VM is less accessible to other hosts if it is created with an .iso file in its CD drive. So I created a new VM with the same settings as the problematic one, but with empty CD drive and without HDD. Then I added the original .vdi, i.e. HDD, file, and that VM is accessible, without any problems, for other hosts.

But there are some interesting moments. I actually copied the original .vdi file into the new VM's folder, for the sake of backup. VB wouldn't attach that HDD file, complaining that its UUID already exists, which was, of course, true. Therefore if needed to remove the original .vdi file, which was not so obvious how to do. Eventually I deleted the snapshot that was attached to that .vdi file, and then it was also necessary to click the Refresh button above the list of HDDs, because otherwise the "Remove" and "Release" buttons stayed greyed out.

I also tested what happens if I leave an .iso file in VM's CD drive and boot into another host. As I expected, that VM then becomes inaccessible from the other host. Then I rebooted back into the first host, emptied the CD drive, and then the VM again became accessible from another host. Phew!

I think that I noticed that some hosts are not sensitive to leaving an .iso file in CD on another host, i.e. that some hosts kept the ability to access a VM with full CD drive.

It maybe seems that I didn't use much of your help, but I thank you all again. I followed my ideas, but many of them appeared only after posting a question, so you really helped me with your inspirative responses!

It seems to me that this discussion is useful, because it reveals some, I suppose, not so intended "features" of VirtualBox.

So, in a multi-boot configuration empty the VM's CD drive before booting into another host OS!

[fth0]

I think that I resolved the problem, at least for what I needed.

Congratulations for finding a solution yourself (with a little bit of our help)!

A little bit of technical background:

When a VM has a virtual DVD (e.g. an ISO file) in a virtual DVD drive, the Virtual Machine file (*.vbox) contains the fully qualified path to the ISO file in text form, unless the ISO file is located in the VM's folder (the absolute vs. relative path topic). If you used different paths to an ISO file from different hosts, than the behavior is expected. A look into the Virtual Machine files (*.vbox) could have indicated that (to you and to us). Did you use different paths?

[bzilak]

No, the paths on two most "antagonistic" hosts are the same. Let's go in order. It is easier to use names instead of numbers: sda6 and sda7 are the root and home of MX KDE, Antix is on nvme0n1p6 and nvme0n1p7, and Debian Gnome is on nvme0n1p8 and nvme0n1p9. sda7 is the biggest one, and all of VMs, except Win11, are on it. All the .iso files are on it, too, in a separate folder. We can set Win11 aside, because I don't need to access it outside of Antix.

So, Debian and Antix must use paths through "/media/" folder to either of the files, while MX accesses them in its own home partition.

As I wrote earlier, under the explanation of the setup, Debian and MX easily share the VMs, while Antix do not "cooperate" so well with them, which contradicts the paths setup.