qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v6 20/21] iotests: add incremental backup failur


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v6 20/21] iotests: add incremental backup failure recovery test
Date: Tue, 1 Dec 2015 10:31:31 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 30.11.2015 um 18:17 hat John Snow geschrieben:
> On 11/27/2015 12:14 PM, Kevin Wolf wrote:
> > Am 18.04.2015 um 01:50 hat John Snow geschrieben:
> >> Test the failure case for incremental backups.
> >>
> >> Signed-off-by: John Snow <address@hidden>
> >> Reviewed-by: Max Reitz <address@hidden>
> >> ---
> >>  tests/qemu-iotests/124     | 57 
> >> ++++++++++++++++++++++++++++++++++++++++++++++
> >>  tests/qemu-iotests/124.out |  4 ++--
> >>  2 files changed, 59 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/tests/qemu-iotests/124 b/tests/qemu-iotests/124
> >> index 5c3b434..95f6de5 100644
> >> --- a/tests/qemu-iotests/124
> >> +++ b/tests/qemu-iotests/124
> >> @@ -240,6 +240,63 @@ class TestIncrementalBackup(iotests.QMPTestCase):
> >>          self.check_backups()
> >>  
> >>  
> >> +    def test_incremental_failure(self):
> >> +        '''Test: Verify backups made after a failure are correct.
> >> +
> >> +        Simulate a failure during an incremental backup block job,
> >> +        emulate additional writes, then create another incremental backup
> >> +        afterwards and verify that the backup created is correct.
> >> +        '''
> >> +
> >> +        # Create a blkdebug interface to this img as 'drive1',
> >> +        # but don't actually create a new image.
> >> +        drive1 = self.add_node('drive1', self.drives[0]['fmt'],
> >> +                               path=self.drives[0]['file'],
> >> +                               backup=self.drives[0]['backup'])
> >> +        result = self.vm.qmp('blockdev-add', options={
> >> +            'id': drive1['id'],
> >> +            'driver': drive1['fmt'],
> >> +            'file': {
> >> +                'driver': 'blkdebug',
> >> +                'image': {
> >> +                    'driver': 'file',
> >> +                    'filename': drive1['file']
> >> +                },
> >> +                'set-state': [{
> >> +                    'event': 'flush_to_disk',
> >> +                    'state': 1,
> >> +                    'new_state': 2
> >> +                }],
> >> +                'inject-error': [{
> >> +                    'event': 'read_aio',
> >> +                    'errno': 5,
> >> +                    'state': 2,
> >> +                    'immediately': False,
> >> +                    'once': True
> >> +                }],
> >> +            }
> >> +        })
> >> +        self.assert_qmp(result, 'return', {})
> > 
> > John, how naughty of you!
> > 
> 
> And here I thought it was OK because nobody yelled!
> 
> The yell was just delayed.
> 
> > It's interesting how many tests break now that I tried to add some
> > advisory qcow2 locking so that people don't constantly break their
> > images with 'qemu-img snapshot' while the VM is running.
> > 
> > I think this one is a bug in the test case. I'm not completely sure how
> > to fix it, though. Can we move the blkdebug layer to the top level? I
> > think reusing the same qcow2 BDS (using a node name reference) would be
> > okay. We just need to avoid opening the qcow2 layer twice for the same
> > image.
> > 
> 
> I can either do that, or just fall back to fully allocating two images
> and modify the test accordingly.

Whatever is the easiest (and works).

> Is this for 2.5?

No, that's definitely 2.6. But if possible, I want to merge the qcow2
locking relatively early in the cycle because I want to see how
surprising the new behaviour would be for users and whether it's too
restrictive before we enable it in a release.

Kevin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]