Am 13.03.2011 06:51, schrieb Chunqiang Tang:
After the heated debate, I thought more about the right approach of
implementing snapshot, and it becomes clear to me that there are major
limitations with both VMDK's external snapshot approach (which stores each
snapshot as a separate CoW file)
On 03/13/2011 09:28 PM, Chunqiang Tang wrote:
In short, FVD's internal snapshot achieves the ideal properties of
G1-G6,
by 1) using the reference count table to only track static
snapshots, 2)
not keeping the reference count table in memory, 3) not updating the
on-disk static reference count
No, because the copy-on-write is another layer on top of the snapshot
and AFAICT, they don't persist when moving between snapshots.
The equivalent for external snapshots would be:
base0 - base1 - base2 - image
And then if I wanted to move to base1 without destroying base2 and
image,
On 03/14/2011 08:53 AM, Chunqiang Tang wrote:
No, because the copy-on-write is another layer on top of the snapshot
and AFAICT, they don't persist when moving between snapshots.
The equivalent for external snapshots would be:
base0- base1- base2- image
And then if I wanted to move to base1
Am 14.03.2011 14:22, schrieb Anthony Liguori:
On 03/13/2011 09:28 PM, Chunqiang Tang wrote:
In short, FVD's internal snapshot achieves the ideal properties of
G1-G6,
by 1) using the reference count table to only track static
snapshots, 2)
not keeping the reference count table in memory, 3)
IIUC, he already uses a refcount table. Actually, I think that a
refcount table is a requirement to provide the interesting properties
that internal snapshots have (see my other mail).
Refcount tables aren't a very complex thing either. In fact, it makes a
format much simpler to have one
Am 14.03.2011 15:02, schrieb Anthony Liguori:
On 03/14/2011 08:53 AM, Chunqiang Tang wrote:
No, because the copy-on-write is another layer on top of the snapshot
and AFAICT, they don't persist when moving between snapshots.
The equivalent for external snapshots would be:
base0- base1-
On Mon, Mar 14, 2011 at 1:53 PM, Chunqiang Tang ct...@us.ibm.com wrote:
Therefore, during normal execution of a
VM, images with snapshots are as fast as images without snapshot.
Hang on, an image with a snapshot still needs to do copy-on-write,
just like backing files. The cost of
Your use of current-state is confusing me because AFAICT,
current-state is just semantically another snapshot.
It's writable because it has no children. You only keep around one
writable snapshot and to make another snapshot writable, you have to
discard the former.
This is
Am 14.03.2011 15:25, schrieb Chunqiang Tang:
IIUC, he already uses a refcount table. Actually, I think that a
refcount table is a requirement to provide the interesting properties
that internal snapshots have (see my other mail).
Refcount tables aren't a very complex thing either. In fact, it
On 03/14/2011 09:15 AM, Kevin Wolf wrote:
The file system can keep a lot of these things around pretty easily but
with your proposal, it seems like there can only be one. If you support
many of them, I think you'll degenerate to something as complex as a
reference count table.
IIUC, he already
On Mon, Mar 14, 2011 at 1:53 PM, Chunqiang Tang ct...@us.ibm.com
wrote:
Therefore, during normal execution of a
VM, images with snapshots are as fast as images without snapshot.
Hang on, an image with a snapshot still needs to do copy-on-write,
just like backing files. The cost of
On 03/14/2011 09:21 AM, Kevin Wolf wrote:
Am 14.03.2011 15:02, schrieb Anthony Liguori:
On 03/14/2011 08:53 AM, Chunqiang Tang wrote:
No, because the copy-on-write is another layer on top of the snapshot
and AFAICT, they don't persist when moving between snapshots.
The equivalent for external
On Mon, Mar 14, 2011 at 2:25 PM, Chunqiang Tang ct...@us.ibm.com wrote:
IIUC, he already uses a refcount table. Actually, I think that a
refcount table is a requirement to provide the interesting properties
that internal snapshots have (see my other mail).
Refcount tables aren't a very
The file system can keep a lot of these things around pretty easily
but
with your proposal, it seems like there can only be one. If you
support
many of them, I think you'll degenerate to something as complex as a
reference count table.
IIUC, he already uses a refcount table.
Well,
On Mon, Mar 14, 2011 at 2:49 PM, Anthony Liguori anth...@codemonkey.ws wrote:
On 03/14/2011 09:21 AM, Kevin Wolf wrote:
Am 14.03.2011 15:02, schrieb Anthony Liguori:
On 03/14/2011 08:53 AM, Chunqiang Tang wrote:
No, because the copy-on-write is another layer on top of the snapshot
and
Am 14.03.2011 15:47, schrieb Anthony Liguori:
On 03/14/2011 09:15 AM, Kevin Wolf wrote:
The file system can keep a lot of these things around pretty easily but
with your proposal, it seems like there can only be one. If you support
many of them, I think you'll degenerate to something as
On Mon, Mar 14, 2011 at 3:04 PM, Chunqiang Tang ct...@us.ibm.com wrote:
The file system can keep a lot of these things around pretty easily
but
with your proposal, it seems like there can only be one. If you
support
many of them, I think you'll degenerate to something as complex as a
Am 14.03.2011 15:49, schrieb Anthony Liguori:
On 03/14/2011 09:21 AM, Kevin Wolf wrote:
Am 14.03.2011 15:02, schrieb Anthony Liguori:
On 03/14/2011 08:53 AM, Chunqiang Tang wrote:
No, because the copy-on-write is another layer on top of the snapshot
and AFAICT, they don't persist when moving
On 03/14/2011 10:03 AM, Kevin Wolf wrote:
The only problem with them is that they are metadata that must be
updated. However, I think we have discussed enough how to avoid the
greatest part of that cost.
Maybe I missed it, but in the WCE=0 mode, is it really possible to avoid
the writes for the
FVD's novel uses of the reference count table reduces the metadata
update
overhead down to literally zero during normal execution of a VM. This
gets
the bests of QCOW2's reference count table but without its oeverhead.
In
FVD, the reference count table is only updated when creating a
Am 14.03.2011 17:32, schrieb Chunqiang Tang:
FVD's novel uses of the reference count table reduces the metadata
update
overhead down to literally zero during normal execution of a VM. This
gets
the bests of QCOW2's reference count table but without its oeverhead.
In
FVD, the reference
Here is a detailed description. Relevant to the discussion of
snapshot,
FVD uses a one-level lookup table and a refcount table. FVD’s
one-level
lookup table is very similar to QCOW2’s two-level lookup table, except
that it is much smaller in FVD, and is preallocated and hence
Am 14.03.2011 20:23, schrieb Chunqiang Tang:
Here is a detailed description. Relevant to the discussion of
snapshot,
FVD uses a one-level lookup table and a refcount table. FVD’s
one-level
lookup table is very similar to QCOW2’s two-level lookup table, except
that it is much smaller
FVD's novel uses of the reference count table reduces the metadata
update
overhead down to literally zero during normal execution of a VM.
This gets
the bests of QCOW2's reference count table but without its
oeverhead. In
FVD, the reference count table is only updated when creating
On 03/12/2011 11:51 PM, Chunqiang Tang wrote:
In short, FVD's internal snapshot achieves the ideal properties of G1-G6,
by 1) using the reference count table to only track static snapshots, 2)
not keeping the reference count table in memory, 3) not updating the
on-disk static reference count
In short, FVD's internal snapshot achieves the ideal properties of
G1-G6,
by 1) using the reference count table to only track static
snapshots, 2)
not keeping the reference count table in memory, 3) not updating the
on-disk static reference count table when the VM runs, and 4)
It seems that there is great interest in QCOW2's
internal snapshot feature. If we really want to do that, the right
solution is
to follow VMDK's approach of storing each snapshot as a separate COW
file (see
http://www.vmware.com/app/vmdk/?src=vmdk ), rather than using the
reference
count
On 02/23/2011 05:50 PM, Anthony Liguori wrote:
I still don't see. What would you do with thousands of checkpoints?
For reverse debugging, if you store checkpoints at a rate of save,
every 10ms, and then degrade to storing every 100ms after 1 second,
etc. you'll have quite a large
On Fri, Feb 25, 2011 at 11:20 AM, Pavel Dovgaluk
pavel.dovga...@ispras.ru wrote:
On 02/23/2011 05:50 PM, Anthony Liguori wrote:
I still don't see. What would you do with thousands of checkpoints?
For reverse debugging, if you store checkpoints at a rate of save,
every 10ms, and then
Am 22.02.2011 19:18, schrieb Anthony Liguori:
On 02/22/2011 10:15 AM, Kevin Wolf wrote:
Am 22.02.2011 16:57, schrieb Anthony Liguori:
On 02/22/2011 02:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features
Chunqiang Tang ct...@us.ibm.com writes:
[...]
Now let’s talk about features. It seems that there is great interest in
QCOW2’ internal snapshot feature. If we really want to do that, the right
Great interest? Its use cases are demo, debugging, testing and such.
Kind of useful for developers,
On 02/22/2011 10:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features that you don't need (this is the correct
description for what you call misfeatures) _are_ implemented in a way
that they don't impact the normal case.
On 02/23/2011 07:43 AM, Avi Kivity wrote:
On 02/22/2011 10:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features that you don't need (this is the correct
description for what you call misfeatures) _are_ implemented in a
On 02/23/2011 03:13 AM, Kevin Wolf wrote:
Am 22.02.2011 19:18, schrieb Anthony Liguori:
On 02/22/2011 10:15 AM, Kevin Wolf wrote:
Am 22.02.2011 16:57, schrieb Anthony Liguori:
On 02/22/2011 02:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if
Am 23.02.2011 15:23, schrieb Anthony Liguori:
On 02/23/2011 07:43 AM, Avi Kivity wrote:
On 02/22/2011 10:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features that you don't need (this is the correct
description for
Am 23.02.2011 15:21, schrieb Anthony Liguori:
On 02/23/2011 03:13 AM, Kevin Wolf wrote:
Am 22.02.2011 19:18, schrieb Anthony Liguori:
On 02/22/2011 10:15 AM, Kevin Wolf wrote:
Am 22.02.2011 16:57, schrieb Anthony Liguori:
On 02/22/2011 02:56 AM, Kevin Wolf wrote:
On 02/23/2011 04:23 PM, Anthony Liguori wrote:
On 02/23/2011 07:43 AM, Avi Kivity wrote:
On 02/22/2011 10:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features that you don't need (this is the correct
description for
On 02/23/2011 08:38 AM, Kevin Wolf wrote:
Am 23.02.2011 15:23, schrieb Anthony Liguori:
On 02/23/2011 07:43 AM, Avi Kivity wrote:
On 02/22/2011 10:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features
On Wed, Feb 23, 2011 at 05:23:33PM +0200, Avi Kivity wrote:
On 02/23/2011 04:23 PM, Anthony Liguori wrote:
On 02/23/2011 07:43 AM, Avi Kivity wrote:
On 02/22/2011 10:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These
On 02/23/2011 09:23 AM, Avi Kivity wrote:
On 02/23/2011 04:23 PM, Anthony Liguori wrote:
On 02/23/2011 07:43 AM, Avi Kivity wrote:
On 02/22/2011 10:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features that you don't
On 02/23/2011 05:29 PM, Anthony Liguori wrote:
existed, what about snapshots? Are we okay having a feature in a
prominent format that isn't going to meet user's expectations?
Is there any hope that an image with 1000, 1000, or 1 snapshots is
going to have even reasonable performance in
On 02/23/2011 05:33 PM, Daniel P. Berrange wrote:
On Wed, Feb 23, 2011 at 05:23:33PM +0200, Avi Kivity wrote:
On 02/23/2011 04:23 PM, Anthony Liguori wrote:
On 02/23/2011 07:43 AM, Avi Kivity wrote:
On 02/22/2011 10:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if
On 02/23/2011 05:31 PM, Anthony Liguori wrote:
what about snapshots? Are we okay having a feature in a prominent
format that isn't going to meet user's expectations?
Is there any hope that an image with 1000, 1000, or 1 snapshots
is going to have even reasonable performance in qcow2?
On 02/23/2011 09:36 AM, Avi Kivity wrote:
On 02/23/2011 05:29 PM, Anthony Liguori wrote:
existed, what about snapshots? Are we okay having a feature in a
prominent format that isn't going to meet user's expectations?
Is there any hope that an image with 1000, 1000, or 1 snapshots is
On 02/23/2011 09:37 AM, Avi Kivity wrote:
On 02/23/2011 05:31 PM, Anthony Liguori wrote:
what about snapshots? Are we okay having a feature in a prominent
format that isn't going to meet user's expectations?
Is there any hope that an image with 1000, 1000, or 1 snapshots
is going to
On 02/23/2011 09:37 AM, Avi Kivity wrote:
On 02/23/2011 05:31 PM, Anthony Liguori wrote:
what about snapshots? Are we okay having a feature in a prominent
format that isn't going to meet user's expectations?
Is there any hope that an image with 1000, 1000, or 1 snapshots
is going to
Am 23.02.2011 16:29, schrieb Anthony Liguori:
On 02/23/2011 08:38 AM, Kevin Wolf wrote:
Am 23.02.2011 15:23, schrieb Anthony Liguori:
On 02/23/2011 07:43 AM, Avi Kivity wrote:
On 02/22/2011 10:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really
On 02/23/2011 05:47 PM, Anthony Liguori wrote:
I don't see how that works, since the memory image is duplicated for
each snapshot. So thousands of snapshots = terabytes of storage, and
hours of creating the snapshots.
Fabrice wanted to use CoW to as a mechanism to deduplicate the memory
On Wed, Feb 23, 2011 at 09:52:02AM -0600, Anthony Liguori wrote:
On 02/23/2011 09:37 AM, Avi Kivity wrote:
On 02/23/2011 05:31 PM, Anthony Liguori wrote:
what about snapshots? Are we okay having a feature in a
prominent format that isn't going to meet user's
expectations?
Is there any
On 02/23/2011 05:52 PM, Anthony Liguori wrote:
I still don't see. What would you do with thousands of checkpoints?
Er, hit send to quickly.
HPC is a big space where checkpointing is actually useful. An HPC
workload may take weeks to run to completion. If something fails
during the run,
On 02/23/2011 10:03 AM, Avi Kivity wrote:
On 02/23/2011 05:50 PM, Anthony Liguori wrote:
I still don't see. What would you do with thousands of checkpoints?
For reverse debugging, if you store checkpoints at a rate of save,
every 10ms, and then degrade to storing every 100ms after 1
On 02/23/2011 05:50 PM, Anthony Liguori wrote:
I still don't see. What would you do with thousands of checkpoints?
For reverse debugging, if you store checkpoints at a rate of save,
every 10ms, and then degrade to storing every 100ms after 1 second,
etc. you'll have quite a large number of
Am 23.02.2011 17:04, schrieb Anthony Liguori:
On 02/23/2011 10:03 AM, Avi Kivity wrote:
On 02/23/2011 05:50 PM, Anthony Liguori wrote:
I still don't see. What would you do with thousands of checkpoints?
For reverse debugging, if you store checkpoints at a rate of save,
every 10ms, and
Anthony Liguori anth...@codemonkey.ws writes:
On 02/18/2011 03:57 AM, Kevin Wolf wrote:
Am 18.02.2011 10:12, schrieb Markus Armbruster:
Kevin Wolfkw...@redhat.com writes:
Am 15.02.2011 20:45, schrieb Chunqiang Tang:
Chunqiang Tang/Watson/IBM wrote on 01/28/2011
Aurelien Jarno aurel...@aurel32.net writes:
[...]
I agree that the best would be to have a single format, and it's
probably a goal to have. That said, what is most important to my view is
having one or two formats which together have _all_ the features (and
here I consider speed as a
Am 22.02.2011 09:37, schrieb Markus Armbruster:
Anthony Liguori anth...@codemonkey.ws writes:
On 02/18/2011 03:57 AM, Kevin Wolf wrote:
Am 18.02.2011 10:12, schrieb Markus Armbruster:
Kevin Wolfkw...@redhat.com writes:
Am 15.02.2011 20:45, schrieb Chunqiang Tang:
Kevin Wolf kw...@redhat.com writes:
Am 22.02.2011 09:37, schrieb Markus Armbruster:
Anthony Liguori anth...@codemonkey.ws writes:
On 02/18/2011 03:57 AM, Kevin Wolf wrote:
Am 18.02.2011 10:12, schrieb Markus Armbruster:
Kevin Wolfkw...@redhat.com writes:
Am 15.02.2011 20:45,
On 02/22/2011 02:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features that you don't need (this is the correct
description for what you call misfeatures) _are_ implemented in a way
that they don't impact the normal case.
Am 22.02.2011 16:57, schrieb Anthony Liguori:
On 02/22/2011 02:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features that you don't need (this is the correct
description for what you call misfeatures) _are_ implemented
On 02/22/2011 10:15 AM, Kevin Wolf wrote:
Am 22.02.2011 16:57, schrieb Anthony Liguori:
On 02/22/2011 02:56 AM, Kevin Wolf wrote:
*sigh*
It starts to get annoying, but if you really insist, I can repeat it
once more: These features that you don't need (this is the correct
In any case, the next step is to get down to specifics. Here is the
page with the current QCOW3 roadmap:
http://wiki.qemu.org/Qcow3_Roadmap
Please raise concrete requirements or features so they can be
discussed and captured.
Now it turns into a more productive discussion, but it seems
Am 20.02.2011 23:13, schrieb Aurelien Jarno:
On Fri, Feb 18, 2011 at 10:57:05AM +0100, Kevin Wolf wrote:
Am 18.02.2011 10:12, schrieb Markus Armbruster:
Kevin Wolf kw...@redhat.com writes:
Am 15.02.2011 20:45, schrieb Chunqiang Tang:
Chunqiang Tang/Watson/IBM wrote on 01/28/2011 05:13:27 PM:
On Mon, Feb 21, 2011 at 8:59 AM, Kevin Wolf kw...@redhat.com wrote:
In fact, the only area where qcow2 in performs really bad in 0.14 is
cache=writethrough (which unfortunately is the default...). With
cache=none it's easy to find scenarios where it provides higher
throughput than QED.
Yeah,
Am 21.02.2011 14:44, schrieb Stefan Hajnoczi:
On Mon, Feb 21, 2011 at 8:59 AM, Kevin Wolf kw...@redhat.com wrote:
In fact, the only area where qcow2 in performs really bad in 0.14 is
cache=writethrough (which unfortunately is the default...). With
cache=none it's easy to find scenarios where
On 02/21/2011 08:10 AM, Kevin Wolf wrote:
Am 21.02.2011 14:44, schrieb Stefan Hajnoczi:
On Mon, Feb 21, 2011 at 8:59 AM, Kevin Wolfkw...@redhat.com wrote:
In fact, the only area where qcow2 in performs really bad in 0.14 is
cache=writethrough (which unfortunately is the default...).
Am 21.02.2011 16:16, schrieb Anthony Liguori:
On 02/21/2011 08:10 AM, Kevin Wolf wrote:
Am 21.02.2011 14:44, schrieb Stefan Hajnoczi:
On Mon, Feb 21, 2011 at 8:59 AM, Kevin Wolfkw...@redhat.com wrote:
In fact, the only area where qcow2 in performs really bad in 0.14 is
On Fri, Feb 18, 2011 at 10:57:05AM +0100, Kevin Wolf wrote:
Am 18.02.2011 10:12, schrieb Markus Armbruster:
Kevin Wolf kw...@redhat.com writes:
Am 15.02.2011 20:45, schrieb Chunqiang Tang:
Chunqiang Tang/Watson/IBM wrote on 01/28/2011 05:13:27 PM:
As you requested, I set up a wiki page
On Fri, Feb 18, 2011 at 7:11 PM, Kevin Wolf kw...@redhat.com wrote:
Am 18.02.2011 18:43, schrieb Stefan Weil:
Is maintaining an additional file format really so much work?
I have only some personal experience with vdi.c, and there maintainance
was largely caused by interface changes and done
Am 18.02.2011 10:12, schrieb Markus Armbruster:
Kevin Wolf kw...@redhat.com writes:
Am 15.02.2011 20:45, schrieb Chunqiang Tang:
Chunqiang Tang/Watson/IBM wrote on 01/28/2011 05:13:27 PM:
As you requested, I set up a wiki page for FVD at
http://wiki.qemu.org/Features/FVD
. It includes a
On 02/18/2011 03:57 AM, Kevin Wolf wrote:
Am 18.02.2011 10:12, schrieb Markus Armbruster:
Kevin Wolfkw...@redhat.com writes:
Am 15.02.2011 20:45, schrieb Chunqiang Tang:
Chunqiang Tang/Watson/IBM wrote on 01/28/2011 05:13:27 PM:
As you requested, I set up a wiki page for
Am 18.02.2011 10:57, schrieb Kevin Wolf:
Am 18.02.2011 10:12, schrieb Markus Armbruster:
Kevin Wolf kw...@redhat.com writes:
Yet another file format with yet another implementation is definitely
not what we need. We should probably take some of the ideas in FVD and
consider them for qcow3.
Am 18.02.2011 18:43, schrieb Stefan Weil:
Am 18.02.2011 10:57, schrieb Kevin Wolf:
Am 18.02.2011 10:12, schrieb Markus Armbruster:
Kevin Wolf kw...@redhat.com writes:
Yet another file format with yet another implementation is definitely
not what we need. We should probably take some of the
On 02/18/2011 01:11 PM, Kevin Wolf wrote:
A new file format like fvd would be a challenge for the existing ones.
Declare its support as unsupported or experimental, but let users
decide which one is best suited to their needs!
Basically this is what we did for QED. In hindsight I consider
On 02/18/2011 11:43 AM, Stefan Weil wrote:
Is maintaining an additional file format really so much work?
I have only some personal experience with vdi.c, and there maintainance
was largely caused by interface changes and done by Kevin.
Hopefully interfaces will stabilize, so changes will become
Am 18.02.2011 20:47, schrieb Anthony Liguori:
On 02/18/2011 01:11 PM, Kevin Wolf wrote:
A new file format like fvd would be a challenge for the existing ones.
Declare its support as unsupported or experimental, but let users
decide which one is best suited to their needs!
Basically
On 02/18/2011 02:49 PM, Kevin Wolf wrote:
Am 18.02.2011 20:47, schrieb Anthony Liguori:
On 02/18/2011 01:11 PM, Kevin Wolf wrote:
A new file format like fvd would be a challenge for the existing ones.
Declare its support as unsupported or experimental, but let users
decide which one
Am 18.02.2011 21:50, schrieb Anthony Liguori:
On 02/18/2011 02:49 PM, Kevin Wolf wrote:
Am 18.02.2011 20:47, schrieb Anthony Liguori:
On 02/18/2011 01:11 PM, Kevin Wolf wrote:
A new file format like fvd would be a challenge for the existing ones.
Declare its support as unsupported
78 matches
Mail list logo
