Hello Flavio, Flavio Vinicius wrote:
> In summary that is what the system does. The problem I'm having is that > after a `VBoxManage controlvm poweroff` a new execution is queued at the > Worker, and when the `VBoxManage startvm name` is executed sometimes it > fails telling me that the machine is still powered on. In order to > bypass the problem I am using a busy-wait approach, only starting a new > execution when the `VBoxManage showvminfo name` tells me that the > machine is powered off. The problem is that sometimes the startvm > command still tells me that the machine is powered on. Apparently there > exists some race condition with the machine state and to bypass the > problem again I have to execute the `VBoxManage startvm name` more than > once (using a retry-loop). The VBoxManage approach is not perfect for this kind of tasks as it doesn't expose all the possibilities and introduces a great data overhead. If you start using our COM/XPCOM API directly, you will solve a lot of synchronization problems. There is an "sdk" subdirectory in the VirtualBox installation directory that contains some samples on how to use VirtualBox COM/XPCOM API. What may be the issue in your case is that VBoxManage doesn't report if the direct VM session is open or not (the session is not the same as the VM execution state). And if the direct session is still open after the last execution, "VBoxManage startvm name" will fail. If you provide me with more details (the sequence of actions, VBoxManage output, etc.), I'll be able to tell you more exactly what's going on in your case. But I recommend you to use the API directly once again. -- Regards, Dmitry A. Kuminov _______________________________________________ vbox-users mailing list [email protected] http://vbox.innotek.de/mailman/listinfo/vbox-users
