On Thu, Mar 03, 2011 at 09:06:25PM -0600, Jesse Cook wrote: > This patch enables the relative backing file path support provided by > qemu-img create. > > If the storage pool is not found with the specified path, check if the > file exists relative to the pool where the new image will be created by > prepending the storage pool path. > --- > src/storage/storage_backend.c | 32 ++++++++++++++++++++++++++++---- > 1 files changed, 28 insertions(+), 4 deletions(-) > > diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c > index 2eede74..bb49f22 100644 > --- a/src/storage/storage_backend.c > +++ b/src/storage/storage_backend.c > @@ -687,10 +687,34 @@ virStorageBackendCreateQemuImg(virConnectPtr conn, > return -1; > } > if (access(vol->backingStore.path, R_OK) != 0) { > - virReportSystemError(errno, > - _("inaccessible backing store volume %s"), > - vol->backingStore.path); > - return -1; > + /* If the backing store image is not found with the specified path, > + * check for the file relative to the pool path. */ > + int accessRetCode = -1; > + > + char *absolutePath = NULL; > + > + virBuffer absPathBuf = VIR_BUFFER_INITIALIZER; > + > + virBufferVSprintf(&absPathBuf, > + "%s/%s", > + pool->def->target.path, > + vol->backingStore.path); > + > + if (virBufferError(&absPathBuf)) { > + virBufferFreeAndReset(&absPathBuf); > + virReportOOMError(); > + return -1; > + } > + > + absolutePath = virBufferContentAndReset(&absPathBuf); Since you're only doing one single virBufferVSprintf() call, using virBuffer is overkill. You can get away with the simpler virAsprintf(&absolutePath, "%s/%s", pool->def->target.path, vol->backingStore.path);

> + accessRetCode = access(absolutePath, R_OK); > + VIR_FREE(absolutePath); > + if (accessRetCode != 0) { > + virReportSystemError(errno, > + _("inaccessible backing store volume %s"), > + vol->backingStore.path); > + return -1; > + } > } > } Regards, Daniel

On 03/03/2011 08:06 PM, Jesse Cook wrote: > This patch enables the relative backing file path support provided by > qemu-img create. > > If the storage pool is not found with the specified path, check if the > file exists relative to the pool where the new image will be created by > prepending the storage pool path. > --- > src/storage/storage_backend.c | 32 ++++++++++++++++++++++++++++---- > 1 files changed, 28 insertions(+), 4 deletions(-) > > @@ -687,10 +687,34 @@ virStorageBackendCreateQemuImg(virConnectPtr conn, > return -1; > } > if (access(vol->backingStore.path, R_OK) != 0) { > - virReportSystemError(errno, > - _("inaccessible backing store volume %s"), > - vol->backingStore.path); > - return -1; > + /* If the backing store image is not found with the specified path, > + * check for the file relative to the pool path. */ > + int accessRetCode = -1; > + > + char *absolutePath = NULL; > + > + virBuffer absPathBuf = VIR_BUFFER_INITIALIZER; > + > + virBufferVSprintf(&absPathBuf, > + "%s/%s", > + pool->def->target.path, > + vol->backingStore.path); I agree that we need to handle relative paths, but are they relative to the directory that owns the original qcow2 image, or are they relative to the cwd of the qemu process (not necessarily the same directory)? We need to make sure that we have the same interpretation of relative paths as qemu.

Meanwhile, shouldn't you only be computing an alternate name if vol->backingStore.path is relative? If it's absolute, then you would be generating /path/to/pool//path/to/backing, which is the wrong file compared to what qemu would be using.