VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (1054 - 1056 of 16363)

Ticket Resolution Summary Owner Reporter
#4802 fixed Inaccessible Snapshots: Possible MachineState management bug? Bob
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 Bob
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 urbisunt
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.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy