Re: VBoxManage: change nictype, etc. while VM running
Posted: 26. Jan 2013, 02:18
I looked at the code some today and the VBoxManageControlVM.cpp that should control this is very limited in what it actually does. While it lists nicproperty it does not validate anything, meaning you can state nicproperty1 foo="bar" and it allows the command even though it does nothing. It does actually validate against nicproperty*, where if you have only n-1 adapter enabled and try to change n-2 it fails because NIC2 is turned off, so it must be the arguments that are not validated, valid, or simply does not exist.
I find where they are doing this in the UI code but have not found out yet how they are actually passing the command. Since the only resource we have to change hot settings is using VBoxManage controlvm, I can only assume that this was missed.
At first I thought that since it was a property that would be actually used in memory and not stored there would *not* be an actual change in the stored properties, but now I am not even sure about that.
Anyway have a look at the source and you can see what I am talking about.
/trunk/src/VBox/Frontends/VBoxManage/VBoxManageControlVM.cpp
I will keep looking but the code is very complex, which means it would be faster if one of the DEVs had an answer.
Note: Since the command was accepted I assumed (in error) that it was working. I should have fired up wireshark to test this further, so my bad.
I find where they are doing this in the UI code but have not found out yet how they are actually passing the command. Since the only resource we have to change hot settings is using VBoxManage controlvm, I can only assume that this was missed.
At first I thought that since it was a property that would be actually used in memory and not stored there would *not* be an actual change in the stored properties, but now I am not even sure about that.
Anyway have a look at the source and you can see what I am talking about.
/trunk/src/VBox/Frontends/VBoxManage/VBoxManageControlVM.cpp
I will keep looking but the code is very complex, which means it would be faster if one of the DEVs had an answer.
Note: Since the command was accepted I assumed (in error) that it was working. I should have fired up wireshark to test this further, so my bad.