Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format

2013-08-15 Thread Kaveh Razavi
On 08/15/2013 10:32 AM, Stefan Hajnoczi wrote: I don't buy the argument about the page cache being evicted at any time: At the scale where caching is important, provisioning a measily 100 MB of RAM per guest should not be a challenge. cgroups can be used to isolate page cache between VMs if you

Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format

2013-08-14 Thread Kaveh Razavi
On 08/14/2013 03:50 PM, Alex Bligh wrote: > Assuming the cache quota is not exhausted, how do you know how that > a VM has finished 'creating' the cache? At any point it might > read a bit more from the backing image. I was assuming on shutdown. > I'm wondering whether you could just use POSIX ma

Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format

2013-08-14 Thread Kaveh Razavi
Hi, On 08/14/2013 11:29 AM, Stefan Hajnoczi wrote: > 100 MB is small enough for RAM. Did you try enabling the host kernel > page cache for the backing file? That way all guests running on this > host share a single RAM-cached version of the backing file. > Yes, indeed. That is why we think it m

Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format

2013-08-14 Thread Kaveh Razavi
On 08/14/2013 02:02 PM, Alex Bligh wrote: >> > Not really. I meant different backing images, and not necessarily >> > booting on the same host. > So how does your cache solve the problem you mentioned in that > para? > If you have a fast network (think 10GbE), then qcow2 can easily boot many VMs

Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format

2013-08-14 Thread Kaveh Razavi
On 08/14/2013 01:57 PM, Alex Bligh wrote: > I don't agree. The penalty for a qcow2 suffering a false positive on > a change to a backing file is that the VM can no longer boot. The > penalty for your cache suffering a false positive is that the > VM boots marginally slower. Moreover, it is expected

Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format

2013-08-14 Thread Kaveh Razavi
On 08/14/2013 01:16 AM, Alex Bligh wrote: > The above para implies you intend one cache file to be shared by > two VMs booting from the same backing image on the same node. > If that's true, how do you protect yourself from the following: > Not really. I meant different backing images, and not nec

Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format

2013-08-14 Thread Kaveh Razavi
On 08/14/2013 12:53 AM, Alex Bligh wrote: > What is this cache keyed on and how is it invalidated? Let's say a > 2 VM on node X boot with backing file A. The first populates the cache, > and the second utilises the cache. I then stop both VMs, delete > the derived disks, and change the contents of

Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format

2013-08-14 Thread Kaveh Razavi
On 08/13/2013 11:37 PM, Eric Blake wrote: > What is the QMP counterpart for hot-plugging a disk with the cache > attached? Is this something that can integrate nicely with Kevin's > planned blockdev-add for 1.7? > I do not know the details of this, but as long as it has proper support for backin

[Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format

2013-08-13 Thread Kaveh Razavi
Using copy-on-write images with the base image stored remotely is common practice in data centers. This saves significant network traffic by avoiding the transfer of the complete base image. However, the data blocks needed for a VM boot still need to be transfered to the node that runs the VM. On s