Bug 3570 - [UPDATE REQUEST] [UPSTREAM UPDATE] libvirt
: [UPDATE REQUEST] [UPSTREAM UPDATE] libvirt
Status: RESOLVED FIXED
Product: Server Bugs
Classification: ROSA Server
Component: Main Packages
: unspecified
: All Linux
: Normal normal
: ---
Assigned To: Andrew Lukoshko
: ROSA Server Bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-01-13 14:59 MSK by Andrew Lukoshko
Modified: 2014-01-21 18:51 MSK (History)
1 user (show)

See Also:
RPM Package:
ISO-related:
Bad POT generating:
Upstream:
alexander.petryakov: qa_verified+
andrew.lukoshko: published_server+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Lukoshko 2014-01-13 14:59:04 MSK
* Previously, the libvirt python bindings for querying block job status could not distinguish between returning an error and no status available. As a consequence, the code that was polling for the completion of a block job had to deal with a python exception, and could not distinguish it from an actual error. After this update, the bindings now successfully determine if there is no job and return an empty dictionary in this case. As a result, the bindings can be used more reliably when managing block jobs.

* When two threads were working over the same domain, the first thread started a domain and the second attempted to destroy it. In such scenarios, a race condition could occur, causing a domain to disappear in both threads, and leaving the start daemon access freed of memory. As a consequence, the daemon terminated unexpectedly. To fix this bug, the critical section has been guarded by incrementing the reference counter of the domain. Whenever the domain is destroyed, the startup thread still holds the last reference which gets decremented once the startup process finishes. As a result, the daemon no longer crashes.

* Previously, when the user did not specify a model for the SCSI controller or did not specify a controller at all, libvirt failed to find a suitable SCSI controller model because it did not try the  virtio-scsi model. This bug has been fixed and libvirt now checks virtio-scsi when searching for a usable model. This also allows for a dynamic addition of a SCSI controller to a running domain.

https://rhn.redhat.com/errata/RHBA-2013-1856.html

https://abf.rosalinux.ru/build_lists/1513294
https://abf.rosalinux.ru/build_lists/1513295
Comment 1 Alexander Petryakov 2014-01-15 00:21:21 MSK
 libvirt-0.10.2-29.res6.2
*********************** RHEL Advisory *************************
* Previously, the libvirt python bindings for querying block job status could not distinguish between returning an error and no status available. As a consequence, the code that was polling for the completion of a block job had to deal with a python exception, and could not distinguish it from an actual error. After this update, the bindings now successfully determine if there is no job and return an empty dictionary in this case. As a result, the bindings can be used more reliably when managing block jobs.

* When two threads were working over the same domain, the first thread started a domain and the second attempted to destroy it. In such scenarios, a race condition could occur, causing a domain to disappear in both threads, and leaving the start daemon access freed of memory. As a consequence, the daemon terminated unexpectedly. To fix this bug, the critical section has been guarded by incrementing the reference counter of the domain. Whenever the domain is destroyed, the startup thread still holds the last reference which gets decremented once the startup process finishes. As a result, the daemon no longer crashes.

* Previously, when the user did not specify a model for the SCSI controller or did not specify a controller at all, libvirt failed to find a suitable SCSI controller model because it did not try the  virtio-scsi model. This bug has been fixed and libvirt now checks virtio-scsi when searching for a usable model. This also allows for a dynamic addition of a SCSI controller to a running domain.

https://rhn.redhat.com/errata/RHBA-2013-1856.html
***************************************************************
QA Verified