)]}'
{"nova/virt/libvirt/driver.py":[{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"75ed661cb12e6fd548df6b0e3a919e4d47e8f5e0","unresolved":false,"context_lines":[{"line_number":676,"context_line":"                        # steal time from the cloud host. ie 15 wallclock"},{"line_number":677,"context_line":"                        # seconds may have passed, but the VM might have only"},{"line_number":678,"context_line":"                        # have a few seconds of scheduled run time."},{"line_number":679,"context_line":"                        is_okay \u003d True"},{"line_number":680,"context_line":""},{"line_number":681,"context_line":"                if not is_okay:"},{"line_number":682,"context_line":"                    with excutils.save_and_reraise_exception():"}],"source_content_type":"text/x-python","patch_set":2,"id":"7a016987_a7217ca1","line":679,"updated":"2015-05-17 19:31:29.000000000","message":"We should log something here.\n\nNot sure if we need to retry in here or possibly hit a case where this method is recursively called because of the kwargs[\u0027is_running\u0027] check below.\n\nWe could update the method signature to pass a retry count, recursively call _delete, and if we hit that 3 times or something we fail","commit_id":"46f14322d17674222264810bd982022389f83a6d"},{"author":{"_account_id":6873,"name":"Matt Riedemann","email":"mriedem.os@gmail.com","username":"mriedem"},"change_message_id":"84d6812f11b622a7be3235bd12ad3696cf6c9579","unresolved":false,"context_lines":[{"line_number":676,"context_line":"                        # steal time from the cloud host. ie 15 wallclock"},{"line_number":677,"context_line":"                        # seconds may have passed, but the VM might have only"},{"line_number":678,"context_line":"                        # have a few seconds of scheduled run time."},{"line_number":679,"context_line":"                        is_okay \u003d True"},{"line_number":680,"context_line":""},{"line_number":681,"context_line":"                if not is_okay:"},{"line_number":682,"context_line":"                    with excutils.save_and_reraise_exception():"}],"source_content_type":"text/x-python","patch_set":2,"id":"3afb71cf_37ddbbe0","line":679,"in_reply_to":"7a016987_5f3dd78d","updated":"2015-06-08 17:52:52.000000000","message":"ack, yeah, WIP here, I\u0027ll re-work this a bit.","commit_id":"46f14322d17674222264810bd982022389f83a6d"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"797d5139355ccbc0e55852338db3e8d6c7a6749d","unresolved":false,"context_lines":[{"line_number":676,"context_line":"                        # steal time from the cloud host. ie 15 wallclock"},{"line_number":677,"context_line":"                        # seconds may have passed, but the VM might have only"},{"line_number":678,"context_line":"                        # have a few seconds of scheduled run time."},{"line_number":679,"context_line":"                        is_okay \u003d True"},{"line_number":680,"context_line":""},{"line_number":681,"context_line":"                if not is_okay:"},{"line_number":682,"context_line":"                    with excutils.save_and_reraise_exception():"}],"source_content_type":"text/x-python","patch_set":2,"id":"7a016987_5f3dd78d","line":679,"in_reply_to":"7a016987_a7217ca1","updated":"2015-05-28 16:56:44.000000000","message":"So this is ignoring the failure to destroy the guest that libvirt reported, and pretending it has gone away. I don\u0027t think this is going to be safe.\n\nConsider if QEMU is stuck due to a stall in the I/O subsystem, using a cinder volume. Nova marks the guest as destroyed on this host, even though QEMU still exists in zombie state. Nova is now free to start a guest on a different host using this same cinder volume. If the storage system comes back to life in the original host, that in-flight I/O may then complete before the zombie QEMU finally gets reaped.  But there is already a new guest using that original cinder volume. So we end up with concurrent writes to the same volume from two hosts and likely data corruption in the filesystem inside that volume.\n\nI understand the desire to make the gate system more reliable, but we cannot do that at the cost of risking data corruption in production systems.\n\nIf we get EBUSY, then I think the safe thing todo is to just re-try the dom.destroy() API call, which I think should result in another 15 second loop trying to kill the guest. How many times we re-try is open for debate, but if we do give up eventually, we should make sure Nova continues to consider the guest as active and *not* release its resources.","commit_id":"46f14322d17674222264810bd982022389f83a6d"}]}