Ubuntu
uvtool package

uvtool won't clean up storage if vm does not exist

Bug #1452095 reported by Ryan Harper
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
uvtool (Ubuntu)
New
Medium
Unassigned

Bug Description

libvirtd crashed while creating VMs; this left storage volumes associated with the instance present. uvt-kvm destroy foo should clean up all related volumes, but because the VM is not currently defined, uvtool does not remove the volumes. However, if one attempts to create a new machine with the same name, uvtool complains that the volume already exists.

1. Ubuntu Vivid 15.04
2. $ apt-cache policy uvtool-libvirt
uvtool-libvirt:
  Installed: 0~bzr99-0ubuntu1
  Candidate: 0~bzr99-0ubuntu1
  Version table:
 *** 0~bzr99-0ubuntu1 0
        500 http://ports.ubuntu.com/ubuntu-ports/ vivid/universe ppc64el Packages
        100 /var/lib/dpkg/status
3. uvt-kvm delete foo should remove the VM definition (if present) and the related storage pool volumes (if present)
4. uvt-kvm delete stops after checking if foo is defined and then exits if it is not.

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: uvtool 0~bzr99-0ubuntu1
ProcVersionSignature: User Name 3.19.0-15.15-generic 3.19.3
Uname: Linux 3.19.0-15-generic ppc64le
ApportVersion: 2.17.2-0ubuntu1
Architecture: ppc64el
Date: Wed May 6 01:33:25 2015
PackageArchitecture: all
ProcEnviron:
 TERM=screen
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcLoadAvg: 0.14 0.95 1.22 1/1236 153263
ProcLocks:
 1: POSIX ADVISORY WRITE 149496 00:12:496503 0 0
 2: FLOCK ADVISORY WRITE 53972 00:32:362976 0 EOF
 3: POSIX ADVISORY WRITE 2114 00:12:99335 0 EOF
 4: POSIX ADVISORY WRITE 2130 00:12:90143 0 EOF
 5: FLOCK ADVISORY WRITE 2181 00:12:93227 0 EOF
ProcSwaps:
 Filename Type Size Used Priority
 /swap.img file 8388544 0 -1
ProcVersion: Linux version 3.19.0-15-generic (buildd@fisher02) (gcc version 4.9.2 (User Name 4.9.2-10ubuntu13) ) #15-User Name SMP Thu Apr 16 23:32:13 UTC 2015
SourcePackage: uvtool
UpgradeStatus: No upgrade log present (probably fresh install)
cpu_cores: Number of cores present = 20
cpu_coreson: Number of cores online = 20
cpu_smt: SMT is off

Revision history for this message
Ryan Harper (raharper) wrote :
Revision history for this message
Robie Basak (racb) wrote :

Thanks Ryan, I'll look into this.

I think there's code in uvtool that tries to unroll a failed create. Is it that this isn't working correctly, or did your libvirt crash kill uvtool before it could unroll?

The problem with trying to clean up later on a destroy is that uvtool can't detect which storage volumes relate to a VM if the VM's definition does not exist. I'm not sure that uvtool should try and guess in this case.

Robie Basak (racb)
Changed in uvtool (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Even running into this issue a few times, I agree that without the guest definition anymore uvtool better does not remove guessed image names.

I soemtimes hit it if I had "virsh undefine <guest>" to then remember "oh it still has images, :-(".

There could be two things thou:
2. a "uvt-kvm purge <guest>" command that will remove the files it would create for a guest of that name - with big warnings - that would avoid everyone having to learn which paths to look for
1. on uvt-kvm destroy with an undefined guest uvtool should emit a warning why it can't and mention the purge action

Doesn't change anything on the current triage of this, but I came by and wanted to share my idea for it.

Revision history for this message
Robie Basak (racb) wrote : Re: [Bug 1452095] Re: uvtool won't clean up storage if vm does not exist

On Thu, May 24, 2018 at 06:05:52AM -0000,  Christian Ehrhardt  wrote:
> 2. a "uvt-kvm purge <guest>" command that will remove the files it would create for a guest of that name - with big warnings - that would avoid everyone having to learn which paths to look for

IIRC, uvtool doesn't do any name guessing at destroy time currently.
"purge" would be the only command that follows this kind of heuristic.

I agree that it would be useful to follow this kind of heuristic in your
use case, but I'm not sure that it's appropriate to do this kind of
guessing in a top level subcommand. I'd like uvtool to be more robust in
the default case.

What if we gave destroy a --force/-f option to cause it to do things
even if some aspects of what it might do are already gone, and a
--guess-names option to make it follow the heuristic you suggest?

A downside is that -f --guess-names is tedious to type. Suggestions
welcome.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.