Hi,
I’m trying clarify situation for remote controlling VirtualBox on Windows using COM interface.
I found in SDKRef.pdf#page29 docs a comparison table SOAP (webservice) vs COM/XPCOM.
Docs says a preferable way (or one possible?) for remote control virtualbox on Windows host is WebService. Is WebService only one possible/required way for remote controlling vbox on Windows host?
As far as I know for Windows it is (in theory) possible to use Distributed COM.
I tried to register VboxClient-x86.dll and VboxProxyStub-x86.dll on a client system. After that I changed using dcomcnfg targets to a remote server (actual windows host). I even able to receive on remote guest a IVirtualBoxClient or IVirtualBox objects by calling CoCreateInstanceEx.
But if I’m trying call interface members - for IVirtualBoxClient I receive error - VboxSDS isn’t found, use vboxsds —register… (vboxsds service started manually on host). IVirtualBox just says Access Denied for any call, even for a version request. Actually, sounds like I just missing something with security settings/accounts usage. I already allowed Everyone to access all DCOM-specific activities.
Do you have any advice how to set up DCOM remote access? Is it possible or vbox has some unclear limitations which prevents working thru DCOM?
Thank you!
Usage DCOM for remote control, advices?
Re: Usage DCOM for remote control, advices?
I would strongly advise against attempting to use DCOM for talking to the VirtualBox API. Go for the webservice instead. Much better tools available, with sensible security mechanisms.
Very technically speaking using VirtualBox's API locally already needs DCOM, but the default registration doesn't make it available on anything but the local system. No one in the dev team ever tried going for "true DCOM", and that means it's untested, there are probably provisions missing for adequate security and so on. Bad idea.
Trouble with VBoxSDS is actually good news because it prevents people from getting as creative as you are. VBoxSDS is part of a fix to Microsoft's ignorance regarding a COM service which runs per user. They actually implemented something else (that the COM service runs per user session, which is clearly against the docs) but have explained in a KB article about 30 years ago that it is the current behavior and they don't know of a workaround.
Very technically speaking using VirtualBox's API locally already needs DCOM, but the default registration doesn't make it available on anything but the local system. No one in the dev team ever tried going for "true DCOM", and that means it's untested, there are probably provisions missing for adequate security and so on. Bad idea.
Trouble with VBoxSDS is actually good news because it prevents people from getting as creative as you are. VBoxSDS is part of a fix to Microsoft's ignorance regarding a COM service which runs per user. They actually implemented something else (that the COM service runs per user session, which is clearly against the docs) but have explained in a KB article about 30 years ago that it is the current behavior and they don't know of a workaround.
Re: Usage DCOM for remote control, advices?
Thank you very much for the clarification! Then I can drop this part for implementationklaus wrote: ↑2. Feb 2025, 17:15 I would strongly advise against attempting to use DCOM for talking to the VirtualBox API. Go for the webservice instead. Much better tools available, with sensible security mechanisms.
Very technically speaking using VirtualBox's API locally already needs DCOM, but the default registration doesn't make it available on anything but the local system. No one in the dev team ever tried going for "true DCOM", and that means it's untested, there are probably provisions missing for adequate security and so on. Bad idea.
Trouble with VBoxSDS is actually good news because it prevents people from getting as creative as you are. VBoxSDS is part of a fix to Microsoft's ignorance regarding a COM service which runs per user. They actually implemented something else (that the COM service runs per user session, which is clearly against the docs) but have explained in a KB article about 30 years ago that it is the current behavior and they don't know of a workaround.
