Bug 1459183

Summary: rebuild libvirt-python to pickup new flag for virDomainBlockCopy
Product: Red Hat Enterprise Linux 7 Reporter: Peter Krempa <pkrempa>
Component: libvirt-pythonAssignee: Peter Krempa <pkrempa>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.4CC: dyuan, jsuchane, lcheng, mzamazal, ovasik, rbalakri, virt-bugs, weizhan, xuzhang
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libvirt-python-3.2.0-3.el7 Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 1459113 Environment:
Last Closed: 2017-08-01 15:01:57 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: 1459113    
Bug Blocks: 1458548    

Description Peter Krempa 2017-06-06 13:24:08 UTC 
The changes required for bug 1459113 will add a new flag which will need the python bindings to be rebuilt.

+++ This bug was initially created as a clone of Bug #1459113 +++

virDomainBlockCopy works only for transient domains and refuses to run on persistent domains. This is due to technical reasons related to inability to restore block-copy operations after shutting off a VM and starting it again.

However if the block-copy operation was marked as temporary, without its recovery after VM restart, then the operation could be run also on persistent domains, with the same non-recovery limitation. So please add a flag to virDomainBlockCopy for that purpose.
Comment 4 lcheng 2017-06-09 05:37:42 UTC 
Verified on libvirt-3.2.0-9.el7.x86_64, qemu-kvm-rhev-2.9.0-8.el7.x86_64, libvirt-python-3.2.0-3.el7.x86_64.

Scenario 1:
1. Define a persistent guest and blockcopy with flag VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB. And then abort job.

# python
...
>>> import os
>>> import libvirt
>>> fd = open('/root/test.xml', 'rw')
>>> guestxml = fd.read()
>>> guestxml
"... <disk type='file' device='disk'>\n      <driver name='qemu' type='qcow2'/>\n      <source file='/var/lib/libvirt/images/libvirt-test-api'/>\n ..."
>>> conn = libvirt.open()
>>> dom = conn.defineXML(guestxml)
>>> dom.create()
0
>>> destxml = "<disk><source file='/tmp/test-api-blockcopy.img'/></disk>"
>>> dom.isPersistent()
1
>>> dom.isActive()
1
>>> dom.blockJobInfo('vda', 0)
{}
>>> dom.blockCopy("vda", destxml, None, libvirt.VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB)
0
>>> dom.blockJobInfo('vda', 0)
{'end': 1291255808L, 'bandwidth': 0L, 'type': 2, 'cur': 375586816L}
>>> dom.blockJobAbort('vda')
0
>>> dom.blockJobInfo('vda', 0)
{}
>>> 

2. Check guest xml and xml don't be changed.
# virsh dumpxml test
...
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/libvirt-test-api'/>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>
...


Scenario 2:

1. Define a persistent guest and blockcopy with flag VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB. And then abort job with flag VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT.

>>> dom.destroy()
0
>>> dom.undefine()
0
>>> dom = conn.defineXML(guestxml)
>>> dom.create()
0
>>> dom.blockJobInfo('vda', 0)
{}
>>> dom.blockCopy("vda", destxml, None, libvirt.VIR_DOMAIN_BLOCK_COPY_TRANSIENT_JOB)
0
>>> dom.blockJobAbort('vda' ,libvirt.VIR_DOMAIN_BLOCK_JOB_ABORT_PIVOT)
0
>>> dom.blockJobInfo('vda', 0)
{}

2. Check guest xml, blockcopy completed.
# virsh dumpxml test
...
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/tmp/test-api-blockcopy.img'/>
      <backingStore/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>
...

Move this bug to VERIFIED.
Comment 5 errata-xmlrpc 2017-08-01 15:01:57 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1847