于 2013-1-30 1:44, Paolo Bonzini 写道:
Il 29/01/2013 17:44, Stefan Hajnoczi ha scritto:
I'm planning to add offline mirroring to qemu-img. If you use an NBD
server as the destination, it can be used to send only the delta between
two snapshots via NBD.
I think this is the opposite of what you
On Mon, Jan 28, 2013 at 01:38:40PM +, Dietmar Maurer wrote:
If you've been using it for 4 years then it was without dm-thin, which is a
new
snapshot mechanism that solves limitations of classic LVM snapshot
volumes. So if you're referring to inefficient LVM snapshots then that
On Tue, Jan 29, 2013 at 10:58:56AM +0800, Wenchao Xia wrote:
于 2013-1-28 21:00, Stefan Hajnoczi 写道:
On Fri, Jan 25, 2013 at 05:16:46PM +0800, Wenchao Xia wrote:
于 2013-1-24 17:47, Stefan Hajnoczi 写道:
Case 3:
* What does blank data mean? Besides that the use case
makes sense.
Il 29/01/2013 14:27, Stefan Hajnoczi ha scritto:
and in step 5, may need export the delta data, not the whole disk
data.
NBD doesn't have a way to perform bdrv_is_allocated(). Either we need
to enhance the protocol or we need to add a QMP command to read
the allocation bitmap for an image.
Are you sure this work on shared iSCSI devices (I have my doubts)?
If by shared you mean clustering support so multiple hosts can access
volumes from the same pool, then the answer is no.
Unfortunately this is the standard setup with our environment.
If by shared you mean that there are
Il 29/01/2013 17:44, Stefan Hajnoczi ha scritto:
I'm planning to add offline mirroring to qemu-img. If you use an NBD
server as the destination, it can be used to send only the delta between
two snapshots via NBD.
I think this is the opposite of what you suggested, which is to run
On Tue, Jan 29, 2013 at 2:32 PM, Paolo Bonzini pbonz...@redhat.com wrote:
Il 29/01/2013 14:27, Stefan Hajnoczi ha scritto:
and in step 5, may need export the delta data, not the whole disk
data.
NBD doesn't have a way to perform bdrv_is_allocated(). Either we need
to enhance the protocol
On Fri, Jan 25, 2013 at 09:34:28AM +, Dietmar Maurer wrote:
Note: The proposed backup patches (already sent to the list) make
backups without creating internal/external snapshot. Consistency is
guaranteed by using COW.
I guess this can be implemented, or may already exist in
On Fri, Jan 25, 2013 at 05:16:46PM +0800, Wenchao Xia wrote:
于 2013-1-24 17:47, Stefan Hajnoczi 写道:
Case 3:
* What does blank data mean? Besides that the use case
makes sense.
Will remove the words.
* When discussing this use case in the past it was suggested that the
If you've been using it for 4 years then it was without dm-thin, which is a
new
snapshot mechanism that solves limitations of classic LVM snapshot
volumes. So if you're referring to inefficient LVM snapshots then that should
be solvable now.
Are you sure this work on shared iSCSI devices
于 2013-1-28 21:38, Dietmar Maurer 写道:
If you've been using it for 4 years then it was without dm-thin, which is a new
snapshot mechanism that solves limitations of classic LVM snapshot
volumes. So if you're referring to inefficient LVM snapshots then that should
be solvable now.
Are you sure
于 2013-1-28 21:00, Stefan Hajnoczi 写道:
On Fri, Jan 25, 2013 at 05:16:46PM +0800, Wenchao Xia wrote:
于 2013-1-24 17:47, Stefan Hajnoczi 写道:
Case 3:
* What does blank data mean? Besides that the use case
makes sense.
Will remove the words.
* When discussing this use case in
The solution seems OK in improving the performance, I just wondering if it
is possible to put it in lower level component, not qemu? It will make qemu
block layer more complicate,
Not that I am aware off - it just add a few lines to block.c, and only uses
existing
functionality already
Thanks for declaration, one more question:
3) will have a big image file, will you back up it or just leave it
there, not backup for internal snapshot?
Sorry, I do not understand that question. Why will I have a 'a big
image file', and what do you mean by 'backup' exactly?
To
于 2013-1-24 17:47, Stefan Hajnoczi 写道:
Case 3:
* What does blank data mean? Besides that the use case
makes sense.
Will remove the words.
* When discussing this use case in the past it was suggested that the
guest doesn't need to be paused during the LVM snapshot. Instead
于 2013-1-25 16:19, Dietmar Maurer 写道:
Thanks for declaration, one more question:
3) will have a big image file, will you back up it or just leave it
there, not backup for internal snapshot?
Sorry, I do not understand that question. Why will I have a 'a big
image file', and what do you
Note: The proposed backup patches (already sent to the list) make
backups without creating internal/external snapshot. Consistency is
guaranteed by using COW.
I guess this can be implemented, or may already exist in 3rd party
components, such as LVM2.
We used LVM to provide snapshots
On Thu, Jan 24, 2013 at 11:14:31AM +0800, Wenchao Xia wrote:
I like the use cases section. I think it would be best to start there
and fill in the details all the way down to the QMP API calls that need
to be made.
At that point we can be sure the use cases are covered and the API
于 2013-1-24 13:51, Dietmar Maurer 写道:
* Like Case 2, the benefit isn't clear to me. In a scenario where you
use both QEMU and LVM snapshots there is now an extra management
overhead of cleaning up 2 snapshots instead of just 1 when the user
wants to delete a snapshot. I think
My understanding is internal snapshots is obvious fast in both
deleting and reading, and I have similar questions, Dietmar, could u
tip more how you use this case while 2 snapshot layer exist?
To be honest, I don't really understand what you talk about here.
There are simply
于 2013-1-25 14:42, Dietmar Maurer 写道:
My understanding is internal snapshots is obvious fast in both
deleting and reading, and I have similar questions, Dietmar, could u
tip more how you use this case while 2 snapshot layer exist?
To be honest, I don't really understand what you talk
My understanding is internal snapshots is obvious fast in both
deleting and reading, and I have similar questions, Dietmar, could
u tip more how you use this case while 2 snapshot layer exist?
To be honest, I don't really understand what you talk about here.
There are simply
于 2013-1-25 15:20, Dietmar Maurer 写道:
My understanding is internal snapshots is obvious fast in both
deleting and reading, and I have similar questions, Dietmar, could
u tip more how you use this case while 2 snapshot layer exist?
To be honest, I don't really understand what you talk
Hi,
I am trying to enhancement qemu's snapshot functionality, and have
write a wiki draft on:
http://wiki.qemu.org/Features/VMSnapshotEnchancement
It mainly serves backup APP, the centric of it is:
1 fixing the vmstate size problem.
2 save vmstate lively for any type.
3 introduce new live
On Wed, Jan 23, 2013 at 07:33:02PM +0800, Wenchao Xia wrote:
I am trying to enhancement qemu's snapshot functionality, and have
write a wiki draft on:
http://wiki.qemu.org/Features/VMSnapshotEnchancement
It mainly serves backup APP, the centric of it is:
1 fixing the vmstate size problem.
I like the use cases section. I think it would be best to start there
and fill in the details all the way down to the QMP API calls that need
to be made.
At that point we can be sure the use cases are covered and the API
proposal will be easy to put together from the wiki page.
Comments about
* Like Case 2, the benefit isn't clear to me. In a scenario where you
use both QEMU and LVM snapshots there is now an extra management
overhead of cleaning up 2 snapshots instead of just 1 when the user
wants to delete a snapshot. I think this will be a headache.
My
27 matches
Mail list logo
