Custom Query (16363 matches)
Results (1054 - 1056 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #4802 | fixed | Inaccessible Snapshots: Possible MachineState management bug? | ||
| Description |
host: CentOS 5.3 (64 bit) guest: fedora 11 (64 bit) Virtualbox: 3.0.4 Hardware: mostly intel I'm having problems with a VM which is currently in an un-runnable state. Run from the GUI, it simply disappears after a moment (the GUI survives, but the "run" arrow greys out; from VBoxManage: VBoxManage startvm scteachplate VirtualBox Command Line Management Interface Version 3.0.4 (C) 2005-2009 Sun Microsystems, Inc. All rights reserved. Waiting for the remote session to open... ERROR: Virtual machine 'scteachplate' has terminated unexpectedly during startup Details: code NS_ERROR_FAILURE (0x80004005), component Machine, interface IMachine, callee <NULL> This wouldn't matter too much if I could revert it, but any attempt to discard or revert a snapshot from the GUI results in (randomly) one of three things: 1. the VM becomes greyed out, with a stop sign and "inaccessible". The "details" tab says: "The selected virtual machine is inaccessible. Please inspect the error message shown below and press the Refresh button if you want to repeat the accessibility check." (but a blank screen) 2. As above, except that the screen _does_ contain a message, such as: Result Code: Unknown Status 0x80000400 (0x00000400) (since I can't find any doco on this, it doesn't seem to be much different from 1) 3. VirtualBox segfaults Running from VBoxManage gives: VBoxManage discardstate scteachplate VirtualBox Command Line Management Interface Version 3.0.4 (C) 2005-2009 Sun Microsystems, Inc. All rights reserved. ERROR: Cannot discard the machine state as the machine is not in the saved state (machine state: 1) Details: code VBOX_E_INVALID_VM_STATE (0x80bb0002), component Console, interface IConsole, callee nsISupports Context: "ForgetSavedState(true)" at line 1201 of file VBoxManage.cpp This appears to originate from ConsoleImpl.cpp if (mMachineState != MachineState_Saved)
return setError (VBOX_E_INVALID_VM_STATE,
tr ("Cannot discard the machine state as the machine is "
"not in the saved state (machine state: %d)"),
mMachineState);
HRESULT rc = S_OK;
rc = mControl->SetRemoveSavedState(aRemove);
CheckComRCReturnRC (rc);
/*
* Saved -> PoweredOff transition will be detected in the SessionMachine
* and properly handled.
*/
rc = setMachineState (MachineState_PoweredOff);
Am I right in guessing that the assumption built into the comment may not always be correct? The system got into this state when the guest (fedora 11) hung during initial on-line update after installing OS and guest additions. I chose to turn the VM off (sorry, don't have a running VM right now, so I can't check the menu, but it's the last one on the list). I probably selected to discard the machine state, but I don't recall for sure. Of course, any advice on how to rescue the VM would also be greatly appreciated... |
|||
| #12385 | obsolete | Regression: snapshot merging scratch space allocated on wrong filesystem | ||
| Description |
Up to VB 4.2, scratch space for snapshot merging seems to have been allocated on the snapshot filesystem. This makes sense - snapshot space grows (and shrinks with deletions), so that users have to be aware that that space needs to be managed. In VB 4.3.2, some of the scratch space is allocated on the filesystem of the base image. This is a serious problem (for me, but I doubt I will be alone). If you are using a fixed-size .vdi, then it makes sense to allocate it its own partition (avoid fragmentation etc., perhaps other reasons), and since it is supposed to be fixed size, to allocate the partition only marginally larger than the vdi. 4.3 breaks this. The resulting errors are below. This was for an 18 GB .vdi resident on a 20GB (according to lvm) logical volume - I suspect there may be some GB-GiB confusion there. Anyway, I can be quite certain that the problem was use of scratch space on the .vdi filesystem, because the problem went away when I resized it to 22GB (but it will presumably reappear if I do a delete that requires over 2GB merge scratch space). I'm guessing this was probably an accidental change, but please can you revert it? I can see how it would be missed in testing, but for some users it will be a serious regression. For me, because the filesystem is on a logical volume, it just causes wasted space. For users with fixed partitions, it will be a major headache. Transcript before resizing of the logical volume: VBoxManage snapshot ubu_test delete ubuVB4.3.2 0%... Progress state: NS_ERROR_OUT_OF_MEMORY VBoxManage: error: Snapshot operation failed VBoxManage: error: Unable to merge storage '/ubuntu/ubu_test.vdi' - not enough free storage space. VBoxManage: error: Details: code NS_ERROR_OUT_OF_MEMORY (0x8007000e), component SessionMachine, interface IMachine VBoxManage: error: Context: "int handleSnapshot(HandlerArg*)" at line 431 of file VBoxManageSnapshot.cpp |
|||
| #1656 | duplicate | Slow Upload speed in Nat under xp | ||
| Description |
I have notticed that the upload speed in nat is ultra slow, in linux i have a 300 kbytes/seg upload speed and in virtualbox under xp only 80 . How can i fix it? I have tried it in 1.5 versions also and doesnt works. Tnkx. |
|||

