Built vm image file retains random temp filename

Bug #568687 reported by Marcus Bointon on 2010-04-22
This bug affects 7 people
Affects Status Importance Assigned to Milestone
Ubuntu Server papercuts
vm-builder (Ubuntu)

Bug Description

This is just a small feature request. While vmbuilder is running, it constructs the new VM in /tmp under a randomly generated folder name like 'tmpkJv90L'. When it's finished, it moves the completed image file to the location given by the --dest option, however, it retains the cryptic folder name as the filename for the image file. So for example if I specified --dest /home/me/webserver --hostname webserver and I end up with a folder containing run.sh and an image file called tmpkJv9OL.qcow2. It would be nicer and easier to manage if it called it webserver.qcow2, possibly appending numbers or letters to deal with filename clashes.

Chuck Short (zulcss) on 2010-04-26
Changed in vm-builder (Ubuntu):
importance: Undecided → Wishlist
status: New → Confirmed

Indeed, vmbuilder under Lucid keeps the temporary name.
Because of this, automated scripts that look for disk0.qcow2 or so, fail.
Of course, we can work around it, but I'd like to see clear names again.
It is difficult to identify the correct image now when vmbuilder creates several disk images.

summary: - Bulit vm image file retains random temp filename
+ Built vm image file retains random temp filename

One alternative solution to just naming the image after the hostname would be to introduce a new parameter --image (or something) which would take the filename of the image to generate. For example, --image /var/lib/libvirt/images/webserver.qcow2. I always found it confusing to have one directory per image, which can only contain one file per directory. I'd much rather have all images in one directory.

dbrossard (dbrossard) wrote :

This still happens under precise 12.04

Brian Candler (b-candler) wrote :

Still in 14.04.

The other problem with the current "directory containing temporary name" approach is that it does not properly map to any libvirt storage type (either 'file' or 'directory'), and therefore cannot be managed properly through virsh or virt-manager, e.g. you can't clone it.

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

Other bug subscribers