Bug 485031 - fet: do not force cd <image-dir> before creating a qemu image with relative-path backing-file
fet: do not force cd <image-dir> before creating a qemu image with relative-p...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kvm (Show other bugs)
5.4
All Linux
low Severity low
: ---
: ---
Assigned To: Tim Burke
Virtualization Bugs
: FutureFeature
Depends On:
Blocks: Rhel5KvmTier2
  Show dependency treegraph
 
Reported: 2009-02-11 04:26 EST by Uri Lublin
Modified: 2013-01-09 16:26 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-30 04:56:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Uri Lublin 2009-02-11 04:26:41 EST
Description of problem:
Currently there is a difference in the way "qemu-img create -b" opens a backing file and the way bdrv_open does that, when the backing file path is relative. The former calculates the relative path from the CWD, while the latter calculates the relative path from the image filename's directory. This inconsistency force the user to change-dir into the created-file directory when creating a new image.

For example, let the backing file be <images>/dir1/g1.qcow2
and let image to be  created be      <images>/dir2/g2.qcow2, the steps I need to run are:
1. cd <images>/dir2
2. qemu-img create -b ../dir1/g1.qcow2 -f qcow2 g2.qcow2
3. cd -

If I skip step 1 then both following options fail (let my CWD be e.g <images>)
 a. qemu-img create -b ../dir1/g1.qcow2 -f qcow2 dir2/g2.qcow2  or
 b. qemu-img create -b dir1/g1.qcow2 -f qcow2 dir2/g2.qcow

Option (a) fails to open the backing file and "qemu-img create" fails
Option (b) "qemu-img create" succeeds, but bdrv_open fails (e.g. "qemu-img info dir2/g2.qcow"), as the backing file path calculation result in <images>/dir2/dir1/g1.qcow2.

We suggest that the path calculation (full path from relative) will be done the same for qemu-img create and for qemu-img info (bdrv_open), making their behavior consistent. Thus qemu-img create will first calculate the backing file path relative to the created-file path (using path_combine), making (1)+(2)+(3) and (a) above the same.

In order to keep current behavior working, we suggest adding a new flag (-s or -r) to qemu-img create for the new suggested behavior.

I've posted the above suggestion to qemu-devel but got no response.
I plan to work on a patch once I'd have time.
Adding to bugzilla to keep track.
Comment 1 Dor Laor 2009-11-10 10:49:45 EST
Is it still relevant or solved?
Comment 2 Uri Lublin 2009-11-12 06:15:13 EST
This feature is not implemented yet.
As mentioned above the current behavior of qemu-img is confusing, especially to someone who is not used to working with qemu-img.
It is not literally needed, as everyone just cd into the appropriate directory before/as-part-of creating a new qemu image.

Note You need to log in before you can comment on or make changes to this bug.