[vbox-dev] A future direction... VBox 4.1 and GNS3 users

[Klaus Espenlaub]

On 25.05.2011 09:50, Alexey Eromenko wrote:
>>   VBoxManage.exe modifyvm "Windows XP immu 01" --nicproperty2 sport="10001"
>>   VBoxManage.exe modifyvm "Windows XP immu 01" --nicproperty2 dest="127.0.0.1"
>>   VBoxManage.exe modifyvm "Windows XP immu 01" --nicproperty2 dport="10002"
>>   (three separate properties!)
>
> This also works: (quotes around dport)
> --nicproperty2 "dport=10002"

quotes are not needed if there are no spaces or other funny characters...

> Thanks.
> Now after trying this I don't see what has changed, besides moving the
> UDP driver to a deeper level.
> (network-->udp became network-->generic-->udp)

Nothing has changed regarding the driver stacking. Just made things mor 
modular/generic, and having one property containing several properties 
was so weird that I split them up.

> Anyway the current way has several problems:
> 1. Incorrect parameters result in inability to start VM (VBoxManage
> needs to filter incorrect parameters somehow)
> If I type in driver incorrectly or parameter incorrectly, I should get
> some error from "VBoxManage", if possible.

This wasn't included in the contribution, and with the generic network 
attachment driver approach it's right now not possible to do any custom 
checks before the VM is started. For the VirtualBox API everything is 
just strings with no particular meaning. Only the driver knows what the 
properties mean and can do sanity checking.

Even checking the availability of driver is not helpful, as this would 
prevent loading/saving configs which refer to drivers which are not 
(yet) installed, which I find worse than detecting a typo only at VM start.

> 2. Inability to see vm info:
> VBoxManage showvminfo must show me sport, dest, dport

You're right... trying to find some time, but I can't promise that I can 
squeeze it in this or next week.

> 3. GUI, the same. I expect to see something like:
> Generic, UDPTunnel="sport=10001;dest=127.0.0.1;dport=10002"
> -or-
> Generic, VDE="/tmp/vdeswitch"
>
> Currently it is impossible to debug virtual topologies.

Same as 2.

Klaus