VirtualBox

Ticket #3548 (reopened defect)

Opened 5 years ago

Last modified 5 years ago

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

Reported by: mjlucas Owned by: attoparsec
Priority: major Component: other
Version: VirtualBox 2.1.4 Keywords:
Cc: Guest type: other
Host type: other

Description

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

comment:1 Changed 5 years ago by mjlucas

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 Changed 5 years ago by attoparsec

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 Changed 5 years ago by mjlucas

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 Changed 5 years ago by attoparsec

  • Owner set to attoparsec
  • Status changed from new to assigned

Thanks for your feedback; I can reproduce it now.

comment:5 Changed 5 years ago by attoparsec

  • Summary changed from VBoxSVC holds vm xml definition file open after VM is unregistered to VBoxSVC holds vm xml definition file open after VM is unregistered => Fixed in SVN

comment:6 Changed 5 years ago by sandervl73

  • Status changed from assigned to closed
  • Resolution set to fixed

comment:7 Changed 5 years ago by tommyj27

This issue appears to be present in version 2.2.4.

comment:8 Changed 5 years ago by chuckleberryfinn

  • Status changed from closed to reopened
  • Resolution fixed deleted

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 Changed 5 years ago by sandervl73

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 Changed 5 years ago by sandervl73

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

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use