Hi again,
it seems that the sequence
VBOXHeadless startvm VM --vrdp=on --vrdpaddress 127.0.0.1 --vrdpport
391
VBoxManage controlvm VM savestate
VBOXHeadless startvm VM --vrdp=on --vrdpaddress 127.0.0.1 --vrdpport
391
always leads to the loss described below.
I would have expected either
a) either resuming with VBOXHeadless "just works",
b) or VBOXHeadless refusing work with an appropriate error message by NOT
loosing the saved state.
I tend to consider the current behaviour as a bug.
Can someone second this case?
Have a nice day,
Berny
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Voelker, Bernhard
Sent: Dienstag, 17. November 2009 17:32
To: [email protected]
Subject: [vbox-users] resuming with headless + vrdpport fails
Hi *,
maybe this one is failing deliberately ...
The VM was suspended i.e. in saved state - after having booted with the normal
GUI and then saved state. When I try to resume from that point in headless mode,
I get this error:
VBoxHeadless.exe --startvm XP2 --vrdp=on --vrdpaddress 127.0.0.1 --vrdpport
391
VirtualBox Headless Interface 3.0.12
(C) 2008-2009 Sun Microsystems, Inc.
All rights reserved.
ERROR: The machine is not mutable (state is 2)
Details: code VBOX_E_INVALID_VM_STATE (0x80bb0002), component Machine,
interface IMachine, callee IUnknown
Context: "COMSETTER(Port)(vrdpPort)" at line 877 of file VBoxHeadless.cpp
I'd understand that activating the RDB support to a saved machine which
initially
was not run via headless is not supported, but VBox's reaction resets the
machine's
state so that the saved state is lost.
BTW that's funny: while the "machine is not mutable", it's changed anyway. ;-)
Any hints? Or is this a bug/feature?
Have a nice day,
Berny
_______________________________________________
vbox-users mailing list
[email protected]
http://vbox.innotek.de/mailman/listinfo/vbox-users
_______________________________________________
vbox-users mailing list
[email protected]
http://vbox.innotek.de/mailman/listinfo/vbox-users