<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 11.10.2016 17:30, Cole Robinson
wrote:<br>
</div>
<blockquote
cite="mid:60a2732f-9c03-afc0-2fe2-abcc8795284e@redhat.com"
type="cite">
<pre wrap="">On 10/05/2016 12:01 PM, Mikhail Feoktistov wrote:
</pre>
<blockquote type="cite">
<pre wrap="">In _do_async_install we have a race.
We create domain in guest.start_install() and
it begins to start. Then we check vm.is_shutoff()
but domain doesn't have "running" state.
It's still starting.
Then we try to start it by vm.startup() and
we get an exception from libvirt.
</pre>
</blockquote>
<pre wrap="">
Interesting. Sounds like we need another state field in libvirt to indicate a
VM is 'starting' but not yet 'running', similar to shutdown vs shutoff. But
anyways. We don't see this with typical virt-manager usage since the libvirt
qemu driver vm.create() call will always leave the VM in the running state if
it returns successfully
</pre>
<blockquote type="cite">
<pre wrap="">This patch change this logic.
Do not raise exception in the following cases:
We stop domain which is already stopped
We start domain which is already started
The same logic is in Nova project in Openstack
---
virtManager/domain.py | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/virtManager/domain.py b/virtManager/domain.py
index a707f25..c18395f 100644
--- a/virtManager/domain.py
+++ b/virtManager/domain.py
@@ -1372,7 +1372,11 @@ class vmmDomain(vmmLibvirtObject):
@vmmLibvirtObject.lifecycle_action
def shutdown(self):
self._install_abort = True
- self._backend.shutdown()
+ try:
+ self._backend.shutdown()
+ except libvirt.libvirtError, e:
+ if e.get_error_code() != libvirt.VIR_ERR_OPERATION_INVALID:
+ raise
@vmmLibvirtObject.lifecycle_action
def reboot(self):
@@ -1401,7 +1405,11 @@ class vmmDomain(vmmLibvirtObject):
for error in pre_startup_ret:
raise RuntimeError(error)
- self._backend.create()
+ try:
+ self._backend.create()
+ except libvirt.libvirtError, e:
+ if e.get_error_code() != libvirt.VIR_ERR_OPERATION_INVALID:
+ raise
@vmmLibvirtObject.lifecycle_action
def suspend(self):
</pre>
</blockquote>
<pre wrap="">
Can we isolate this OPERATION_INVALID handling to virtManager/create.py ?
Adding this to generic code means we need to check that skipping this error is
appropriate for all uses. In create.py we can at least add a comment that this
is required for virtuozzo installs</pre>
</blockquote>
Thank you, Cole. I have found strange <span id="result_box"
class="short_text" lang="en"><span class="">behavior in Virtuozzo
containers.<br>
I need to research it, and after that I'll send another patch.<br>
Please ignore this patch.<br>
</span></span>
<blockquote
cite="mid:60a2732f-9c03-afc0-2fe2-abcc8795284e@redhat.com"
type="cite">
<pre wrap="">
Thanks,
Cole
</pre>
</blockquote>
<br>
</body>
</html>