This is simple: instead of clearing the bitmap, just leave the bitmap
data intact even in case of success.
Signed-off-by: John Snow js...@redhat.com
---
block.c | 9 -
block/backup.c| 17 ++---
block/mirror.c| 9 +++--
include/block/block.h
On 06/04/2015 06:20 PM, John Snow wrote:
If we wish to make differential backups a feature that's easy to access,
it might be pertinent to rename the dirty-bitmap mode to incremental
to make it clear what /type/ of backup the dirty-bitmap is helping us
perform.
This is an API breaking
If we wish to make differential backups a feature that's easy to access,
it might be pertinent to rename the dirty-bitmap mode to incremental
to make it clear what /type/ of backup the dirty-bitmap is helping us
perform.
This is an API breaking change, but 2.4 has not yet gone live,
so we have
Requires: 1433454372-16356-1-git-send-email-js...@redhat.com
[0/10] block: incremental backup transactions
It's entirely possible to use the incremental backup primitives to
achieve a differential backup mechanism, but in the interest of
ease of use, I am proposing the explicit addition
On 06/04/2015 06:20 PM, John Snow wrote:
It would be nice to have the flexibility to decide that
we would like multiple backup chains (perhaps of differing
frequency, or stored at different sites -- who knows.)
If the user didn't have the foresight to add all the requisite
bitmaps before
On 06/04/2015 06:20 PM, John Snow wrote:
Add the ability to copy one bitmap to a new bitmap.
Signed-off-by: John Snow js...@redhat.com
---
blockdev.c | 22 ++
qapi/block-core.json | 16
qmp-commands.hx | 30 ++
And then add the transaction that allows us to perform this
operation atomically.
Signed-off-by: John Snow js...@redhat.com
---
blockdev.c | 39 +++
qapi-schema.json | 4 +++-
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/blockdev.c
Add the ability to copy one bitmap to a new bitmap.
Signed-off-by: John Snow js...@redhat.com
---
blockdev.c | 22 ++
qapi/block-core.json | 16
qmp-commands.hx | 30 ++
3 files changed, 68 insertions(+)
diff --git
On 05/13/2015 02:40 PM, Fam Zheng wrote:
On Wed, 05/13 13:17, Wen Congyang wrote:
On 05/13/2015 11:11 AM, Fam Zheng wrote:
Before, we only yield after initializing dirty bitmap, where the QMP
command would return. That may take very long, and guest IO will be
blocked.
Do you have such case
This patch actually implements the transactional callback system
for the drive_backup action.
(1) We create a functional closure that envelops the original drive_backup
callback, to be able to intercept the completion status and return code
for the job.
(2) We inform the BlockJob layer
These structures are misnomers, somewhat.
(1) BlockTransactionState is not state for a transaction,
but is rather state for a single transaction action.
Rename it BlkActionState to be more accurate.
(2) The BdrvActionOps describes operations for the BlkActionState,
above. This name
We'd like to be able to specify the callback given to backup_start
manually in the case of transactions, so split apart qmp_drive_backup
into an implementation and a wrapper.
Switch drive_backup_prepare to use the new wrapper, but don't overload
the callback and closure yet.
Signed-off-by: John
Now that the structure formerly known as BlkTransactionState has been
renamed to something sensible (BlkActionState), re-introduce an actual
BlkTransactionState that actually manages state for the entire Transaction.
In the process, convert the old QSIMPLEQ list of actions into a QTAILQ,
to let
The goal here is to add a new method to transactions that allows
developers to specify a callback that will get invoked only once
all jobs spawned by a transaction are completed, allowing developers
the chance to perform actions conditionally pending complete success,
partial failure, or complete
Test simple usage cases for using transactions to create
and synchronize incremental backups.
Signed-off-by: John Snow js...@redhat.com
Reviewed-by: Max Reitz mre...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
---
tests/qemu-iotests/124 | 54
From: Kashyap Chamarthy kcham...@redhat.com
Although the canonical source of reference for QMP commands is
qapi-schema.json, for consistency's sake, update qmp-commands.hx to
state the list of supported transactionable operations, namely:
drive-backup
blockdev-backup
blockdev.c will create implicit virtio-blk-* devices for IF_VIRTIO
drives. I want to turn this on for the ARM virt board (now it has PCI),
so that users can use shorter and more comprehensible command lines.
Unfortunately, the code as it stands will always create an implicit
device, which means
If a user requests an IF_VIRTIO drive on the command line, don't
create the implicit PCI virtio device immediately, but wait until
the rest of the command line has been processed and only create the
device if the drive would otherwise be orphaned. This means that
if the user said
create_implicit_virtio_device() just adds a device to the device QEMU
options list. This means that it only has an effect if it is called
before vl.c processes that list to create all the devices. If it is
called after that (ie for hotplug drives created from the monitor) then
it has no effect. To
Now we have virtio-pci, we can make the virt board's default block
device type be IF_VIRTIO. This allows users to use simplified
command lines that don't have to explicitly create virtio-pci-blk
devices; the -hda c very short options now also work.
Signed-off-by: Peter Maydell
On Wed 03 Jun 2015 09:43:49 PM CEST, Max Reitz mre...@redhat.com wrote:
In order to handle host device passthrough, some guest device models
may call blk_is_inserted() to check whether the medium is inserted on
the host, when checking the guest tray status.
This tray status is inquired by
On Wed 03 Jun 2015 09:43:52 PM CEST, Max Reitz mre...@redhat.com wrote:
Fix the BlockBackend's AIOCB AioContext for aborting AIO in case there
is no BDS. If there is no implementation of AIOCBInfo::get_aio_context()
the AioContext is derived from the BDS the AIOCB belongs to. If that BDS
is
On Wed 03 Jun 2015 09:43:53 PM CEST, Max Reitz wrote:
guest_block_size is a guest device property so it should be moved into
the interface between block layer and guest devices, which is the
BlockBackend.
Signed-off-by: Max Reitz mre...@redhat.com
Reviewed-by: Alberto Garcia be...@igalia.com
Signed-off-by: Fam Zheng f...@redhat.com
---
block/vmdk.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/block/vmdk.c b/block/vmdk.c
index 3e4d84b..56626b0 100644
--- a/block/vmdk.c
+++ b/block/vmdk.c
@@ -1424,7 +1424,6 @@ static int vmdk_read(BlockDriverState *bs,
It has the similar issue with b1649fae49a8. Since the calculation
is repeated for a few times already, introduce a function so it can be
reused.
Signed-off-by: Fam Zheng f...@redhat.com
---
block/vmdk.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git
The buggy index_in_cluster was missed in b1649fae49a8. Fix that and dedup the
calculation.
Fam Zheng (2):
vmdk: Fix index_in_cluster calculation in vmdk_co_get_block_status
vmdk: Use vmdk_find_index_in_cluster everywhere
block/vmdk.c | 23 ++-
1 file changed, 14
On Wed 03 Jun 2015 10:13:33 PM CEST, Max Reitz wrote:
Signed-off-by: Max Reitz mre...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Alberto Garcia be...@igalia.com
Berto
From: Cornelia Huck cornelia.h...@de.ibm.com
Handle endianness conversion for virtio-1 virtqueues correctly.
Note that dataplane now needs to be built per-target.
Signed-off-by: Cornelia Huck cornelia.h...@de.ibm.com
Reviewed-by: Michael S. Tsirkin m...@redhat.com
Signed-off-by: Michael S.
On Wed 03 Jun 2015 10:13:34 PM CEST, Max Reitz mre...@redhat.com wrote:
If the image version should be upgraded, that is the first we should do;
if it should be downgraded, that is the last we should do. So split the
version change block into an upgrade part at the start and a downgrade
part
On Wed 03 Jun 2015 10:13:32 PM CEST, Max Reitz mre...@redhat.com wrote:
Signed-off-by: Max Reitz mre...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
Reviewed-by: Stefan Hajnoczi stefa...@redhat.com
Reviewed-by: Alberto Garcia be...@igalia.com
Berto
On Wed 03 Jun 2015 09:43:45 PM CEST, Max Reitz wrote:
Make bdrv_is_inserted(), blk_is_inserted(), and the callback
BlockDriver.bdrv_is_inserted() return a bool.
Suggested-by: Eric Blake ebl...@redhat.com
Signed-off-by: Max Reitz mre...@redhat.com
Reviewed-by: Alberto Garcia be...@igalia.com
On Wed 03 Jun 2015 09:43:47 PM CEST, Max Reitz wrote:
If bdrv_is_inserted() is called on the top level BDS, it should make
sure all nodes in the BDS tree are actually inserted.
Signed-off-by: Max Reitz mre...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
Reviewed-by: Alberto Garcia
On Wed 03 Jun 2015 09:43:46 PM CEST, Max Reitz wrote:
blk_is_available() returns true iff the BDS is inserted (which means
blk_bs() is not NULL and bdrv_is_inserted() returns true) and if the
tray of the guest device is closed.
blk_is_inserted() is changed to return true only if blk_bs() is
On Wed 03 Jun 2015 09:43:48 PM CEST, Max Reitz wrote:
bdrv_is_inserted() should be invoked recursively on the children of
quorum.
Signed-off-by: Max Reitz mre...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
+static bool quorum_is_inserted(BlockDriverState *bs)
+{
+
On 06/04/2015 06:37 AM, Alberto Garcia wrote:
On Wed 03 Jun 2015 09:43:48 PM CEST, Max Reitz wrote:
bdrv_is_inserted() should be invoked recursively on the children of
quorum.
Signed-off-by: Max Reitz mre...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
+static bool
35 matches
Mail list logo
