On 06/14/2011 03:39 PM, Corey Bryant wrote:
>> Incremental support is fine by me, but we'll need it sooner or later.
>
> Qemu currently opens the specified copy-on-write file, finds a backing
> file name in the opened file's header, opens that backing file, and
> repeats.
>
> So it seems that eit
On 06/14/2011 04:18 PM, Eric Blake wrote:
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. Libv
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
On 06/14/2011 12:13 PM, Eric Blake wrote:
On 06/14/2011 07:31 AM, Corey Bryant wrote:
> - Starting Qemu with a backing file
What do you mean by this? Taking a guess:
In the case of a qcow2 image with a backing file, does that mean that
both the qcow2 image and it's backing file can both
On 06/14/2011 07:31 AM, Corey Bryant wrote:
> This patch contains the Qemu code to support this solution. I would
> like to solicit input from the libvirt community prior to starting
> the libvirt patch.
>
> Currently, Qemu opens an image file in addition to performing the
> necessary read and wri