VirtualBox

Opened 15 years ago

Closed 9 years ago

#3548 closed defect (obsolete)

VBoxSVC holds vm xml definition file open after VM is unregistered => Fixed in SVN

Reported by: James Lucas Owned by: Jens
Component: other Version: VirtualBox 2.1.4
Keywords: Cc:
Guest type: other Host type: other

Description (last modified by Frank Mehnert)

Executing a VBoxManage unregistervm <vmname> successfully unregisters the VM from the host. VBoxSVC fails to close the vm definition xml file and continues to hold open a R/W lock (FD flag u). This is noticeable if another VM is running because VBoxSVC will continue to run. VBoxSVC should close any open files belonging to a vm when unregistering it.

lsof output shows

COMMAND     PID      USER   FD      TYPE             DEVICE       SIZE       NODE NAME
VBoxSVC   27907    vmuser   25u      REG               0,24       3053  106102849 /vmuser/vmachines/Machines/1084/1084.xml

Change History (11)

comment:1 by James Lucas, 15 years ago

Machine::trySetRegistered (as called by VBoxManage) sets the machine as unregistered but doesn't make a call to unlockConfig(). It appears that Machine::uninit() is responsible for unlocking the config file however it is not called unless its parent exits (VBoxSVC?) or Machine::FinalRelease() is called (which VBoxManage does not do)

comment:2 by Jens, 15 years ago

I tried to reproduce this with our trunk build (both debug and release) but couldn't, host Ubuntu 8.10/amd64. Here's the test script I wrote to match your description. Please try it or suggest what needs to be different. The lsof output just shows other registered VM's xml files.

#!/bin/sh
#
# testcase3548 - VBoxSVC holds vm xml definition file open after VM is unregistered

set -eux

VBoxManage="./VBoxManage -nologo"
VirtualBox="./VirtualBox"
VMNAME="testcase3548"

# 0. Make sure a VBoxSVC is running.

$VBoxManage startvm Knoppix61

# 1. Delete VM remnants from previous test run, if any.

rm -rf "$HOME/.VirtualBox/Machines/$VMNAME"

# 2. Create a new vm for testing.

$VBoxManage createvm -name "$VMNAME"  # -register
$VBoxManage registervm     "Machines/$VMNAME/$VMNAME.xml"
$VBoxManage showvminfo     "$VMNAME"

# 3. Perform unregistervm.

$VBoxManage unregistervm   "$VMNAME"  # -delete

# 4. Look for xml files held open by VBoxSVC.

lsof | grep '^VBoxSVC.*xml$'
lsof | grep "$VMNAME"

comment:3 by James Lucas, 15 years ago

Hi Attoparsec

The key thing here is you need to have an start a vm to have the config file locked. If you modify your testcase to have the following code after the showvminfo line and before the unregister line.

VBoxHeadless -startvm "$VMNAME"  &
sleep 10
$VBoxManage controlvm "$VMNAME" poweroff
sleep 5

You will see that the config file is held open and locked after unregistering. I just verified this running your testcase with the extra lines.

+ /usr/sbin/lsof
+ grep testcase3548
VBoxSVC   18602    vmuser   27u      REG                8,5     2774     70341 /vmuser/.VirtualBox/Machines/testcase3548/testcase3548.xml

Either VBoxSVC needs to unlock the config file after a machine is powered off (session close) or when it unregisters a machine.

comment:4 by Jens, 15 years ago

Owner: set to Jens
Status: newassigned

Thanks for your feedback; I can reproduce it now.

comment:5 by Jens, 15 years ago

Summary: VBoxSVC holds vm xml definition file open after VM is unregisteredVBoxSVC holds vm xml definition file open after VM is unregistered => Fixed in SVN

comment:6 by Sander van Leeuwen, 15 years ago

Resolution: fixed
Status: assignedclosed

comment:7 by tommyj27, 15 years ago

This issue appears to be present in version 2.2.4.

comment:8 by chuckleberryfinn, 15 years ago

Resolution: fixed
Status: closedreopened

This bug is still present in VirtualBox 3.0.2r49928, guest and host OS are Windows XP. Vboxsvc process fails to close and holds a file lock on VirtualBox.xml, requires a full machine reboot to unlock the file. This is NOT fixed in the latest release.

comment:9 by Sander van Leeuwen, 15 years ago

You are unable to kill the VBoxSVC process? Note that if a VM process doesn't close properly (that includes killing the process by the user), VBoxSVC will never terminate by itself.

comment:10 by Sander van Leeuwen, 15 years ago

Also note that you reopened a defect that is different from your report. Better create a new one.

comment:11 by Frank Mehnert, 9 years ago

Description: modified (diff)
Resolution: obsolete
Status: reopenedclosed
Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use