On 06/14/2011 01:55 PM, Corey Bryant wrote:
>> So we would need something like -drive
>> file=fd:4,format=qcow2,backing=fd:5
>>
>> and since backing files can be nested, we'd need some way of specifying
>> more than one level of backing file. Libvirt already knows how to walk
>> a chain of backing images in qcow2 files (it has to, in order to set
>> sVirt SELinux permissions on all of those files so that qemu can open()
>> each file), so it wouldn't be much harder for libvirt to instead do the
>> open() and pass each fd.
>>
> Right. So what I was talking about here (and poorly stated) is that
> starting Qemu with a copy-on-write image file causes a reopen of the
> backing file. In this case you would only be passing the fd of the
> copy-on-write file to Qemu. I've fenced that off as unsupported for now.
>
> I like your approach for passing multiple fds. Do you think backing file
> support is needed immediately with this patch?
Incremental support is fine by me, but we'll need it sooner or later.
And for the nested backing file case, does:
-drive file=fd:4,format=qcow2,backing=fd:5,backing=fd:6
work, or would we need:
-drive file=fd:4,format=qcow2,backing1=fd:5,backing2=fd:6
That is, can you have more than one backing=, or do you need distinct
backingN=, and if you have to support multiple N, we must make sure the
solution allows arbitrarily deep nesting (or at least as deep as any
current limits qemu places on qcow2 backing file nesting).