Bug 1071023

Summary: RHEV: Cannot start VMs that have more than 23 snapshots.
Product: Red Hat Enterprise Linux 6 Reporter: Jeff Cody <jcody>
Component: qemu-kvmAssignee: Jeff Cody <jcody>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.6CC: abaron, acathrow, areis, bazulay, bsarathy, chayang, famz, fsimonce, gwatson, iheim, jcody, juzhang, knoel, kwolf, lpeer, michen, mkalinin, mkenneth, pbonzini, qzhang, sgordon, shu, virt-maint, yeylon
Target Milestone: rc   
Target Release: 6.5   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1067576 Environment:
Last Closed: 2014-02-28 18:22:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1067576, 1072339, 1113583    
Bug Blocks: 1023565    
Attachments:
Description Flags
Script to reproduce relative pathname bug with just qemu-kvm and qemu-img none

Comment 1 Jeff Cody 2014-02-27 23:17:21 UTC
Created attachment 868778 [details]
Script to reproduce relative pathname bug with just qemu-kvm and qemu-img

Script to reproduce relative pathname bug with just qemu-kvm and qemu-img

Attached is a script to reproduce this bug with just qemu-kvm, and qemu-img.

This can be seen via either live snapshots, or image creation with qemu-img.

This script will do the following:

1) create test directory
2) create a qcow2 base image
3) launch qemu-kvm with qmp over localhost tcp
4) attempt to create 80 live snapshots with a relative pathname, to parent directory and then back into the test directory
5) run qemu-img, create a different set of 80 snapshots off the same base image.
6) kill the process started in step #3

All you should need to edit in the script is the executable path for qemu and qemu-img.

The test directory is left after the script runs, with the created snapshots and an output log, for later examination.

Expected outcome:
-355:  All snapshot created successfully (live and via qemu-img)
-415:  First ~24 snapshots succeed, those after that fail

Any fix should restore it back to -355 parity.

If you edit the script to create 150 snapshots instead of 80, you will see -355 fail as well.

Comment 3 Qunfang Zhang 2014-02-28 03:01:03 UTC
Hi, Jeff

Could you help to point out the difference between this bug and bug 1067576? Is the script in comment 1 is the scenario we need to test and verify for this bug? 


Thanks,
Qunfang

Comment 4 Jeff Cody 2014-02-28 11:57:18 UTC
(In reply to Qunfang Zhang from comment #3)
> Hi, Jeff
> 
> Could you help to point out the difference between this bug and bug 1067576?
> Is the script in comment 1 is the scenario we need to test and verify for
> this bug? 
> 
> 
> Thanks,
> Qunfang

Hi Qunfang,

This bug is for RHEL6.6, while the other bug is a z-stream candidate for RHEL6.5.  But RHEL6.6 will need a patch as well.

Comment 5 Qunfang Zhang 2014-02-28 13:27:55 UTC
(In reply to Jeff Cody from comment #4)
> (In reply to Qunfang Zhang from comment #3)
> > Hi, Jeff
> > 
> > Could you help to point out the difference between this bug and bug 1067576?
> > Is the script in comment 1 is the scenario we need to test and verify for
> > this bug? 
> > 
> > 
> > Thanks,
> > Qunfang
> 
> Hi Qunfang,
> 
> This bug is for RHEL6.6, while the other bug is a z-stream candidate for
> RHEL6.5.  But RHEL6.6 will need a patch as well.

Hi, Jeff

Thanks for the reply. But I'm still confused. Usually we will have a bug for rhel6.6, and then after it's approved by PM, it will be cloned to a new bug for rhel6.5-z.  Currently the sequence is just opposite and both the bugs have "rhel6.6.0?" flags. Could you help check and confirm? Also help fix me if it's wrong. 

Thanks!
Qunfang