qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Add support for fd: protocol


From: Jamie Lokier
Subject: Re: [Qemu-devel] [PATCH] Add support for fd: protocol
Date: Tue, 24 May 2011 16:31:57 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

Stefan Hajnoczi wrote:
> On Mon, May 23, 2011 at 11:49 PM, Jamie Lokier <address@hidden> wrote:
> > Being able to override the backing file path would be useful anyway.
> >
> > I've already had problems when moving established qcow2 files between
> > systems, that for historical reasons contain either an absolute path
> > inside for the backing file, or some messy "../../whatever", or
> > "foo/bar/whatever", or "backing.img" (lots of different ones with the
> > same name), all of which are a pain to work around.
...
> Try the qemu-img rebase -f command:
> 
>     qemu-img uses the unsafe mode if "-u" is specified. In this mode, only the
>     backing file name and format of filename is changed without any
>     checks on the
>     file contents. The user must take care of specifying the correct new 
> backing
>     file, or the guest-visible content of the image will be corrupted.
> 
>     This mode is useful for renaming or moving the backing file to somewhere
>     else.  It can be used without an accessible old backing file, i.e. you can
>     use it to fix an image whose backing file has already been moved/renamed.

Yes indeed.  That feature was added after the last time I dealt with this 
problem.

However, I have wanted to open *precious*, *read-only* qcow2 images,
for example with -snapshot or the explicit equivalent, and for those
precious images I am loathe to let any tool write a single byte to
them.  The files are kept read-only, and often with the "immutable"
attribute on Linux, backed up and checksummed just to be sure.

I'd rather just override the value on the command line, so if that
feature may turn up for fd: related reasons, it'll be handy for the
read-only moved qcow2 file reason too.

-- Jamie



reply via email to

[Prev in Thread] Current Thread [Next in Thread]