5:55 a.m.
Hi, we experienced a strange, non-reproducible error after a successful
migration to another host. When we called virDomainDestroyFlags with
VIR_DOMAIN_DESTROY_GRACEFUL flag after the migration on the source host,
we got VIR_ERR_OPERATION_INVALID (code 55) error. The same with
repeated virDomainDestroyFlags calls. Normally, we would expect either
success or VIR_ERR_NO_DOMAIN error. `virsh list' didn't show the VM.
Can anybody please explain to us when this can happen and what the error
means in this context? When we have good reasons to believe that the VM
is down (e.g. after a migration call successfully finishes) and we
receive such an error from virDomainDestroyFlags, is it safe to assume
the VM is basically gone and can we perform standard cleanup actions
(like removing related files from the host file system)?
Thank you,
Milan
6:23 a.m.
On Fri, Mar 17, 2017 at 11:55:13AM +0100, Milan Zamazal wrote:
Hi, we experienced a strange, non-reproducible error after a
successful
migration to another host. When we called virDomainDestroyFlags with
VIR_DOMAIN_DESTROY_GRACEFUL flag after the migration on the source host,
we got VIR_ERR_OPERATION_INVALID (code 55) error. The same with
repeated virDomainDestroyFlags calls. Normally, we would expect either
success or VIR_ERR_NO_DOMAIN error. `virsh list' didn't show the VM.
What about 'virsh list --all' - i expect you have an inactive guest
present, as calling destory on an inactive guest triggers OPERATION_INVALID
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
8:07 a.m.
"Daniel P. Berrange" <berrange(a)redhat.com> writes:
On Fri, Mar 17, 2017 at 11:55:13AM +0100, Milan Zamazal wrote:
> Hi, we experienced a strange, non-reproducible error after a successful
> migration to another host. When we called virDomainDestroyFlags with
> VIR_DOMAIN_DESTROY_GRACEFUL flag after the migration on the source host,
> we got VIR_ERR_OPERATION_INVALID (code 55) error. The same with
> repeated virDomainDestroyFlags calls. Normally, we would expect either
> success or VIR_ERR_NO_DOMAIN error. `virsh list' didn't show the VM.
What about 'virsh list --all' - i expect you have an inactive guest
present, as calling destory on an inactive guest triggers OPERATION_INVALID
I see. It's interesting, since we use transient domains. Are there
known circumstances when OPERATION_INVALID could be returned for a
transient domain? Can we assume that we never receive that error when
trying to destroy a running domain?
Thanks,
Milan
8:12 a.m.
On Fri, Mar 17, 2017 at 02:07:11PM +0100, Milan Zamazal wrote:
"Daniel P. Berrange" <berrange(a)redhat.com> writes:
> On Fri, Mar 17, 2017 at 11:55:13AM +0100, Milan Zamazal wrote:
>> Hi, we experienced a strange, non-reproducible error after a successful
>> migration to another host. When we called virDomainDestroyFlags with
>> VIR_DOMAIN_DESTROY_GRACEFUL flag after the migration on the source host,
>> we got VIR_ERR_OPERATION_INVALID (code 55) error. The same with
>> repeated virDomainDestroyFlags calls. Normally, we would expect either
>> success or VIR_ERR_NO_DOMAIN error. `virsh list' didn't show the VM.
>
> What about 'virsh list --all' - i expect you have an inactive guest
> present, as calling destory on an inactive guest triggers OPERATION_INVALID
I see. It's interesting, since we use transient domains. Are there
known circumstances when OPERATION_INVALID could be returned for a
transient domain? Can we assume that we never receive that error when
trying to destroy a running domain?
Cleanup & destruction of domains is an area where there is relatively
high level of concurrency in libvirt. So it is conceivable that you
would see OPERATION_INVALID for a transient guest if libvirt is part
way through cleaning it up - it shouldn't be in that state for very
long though
You'll never see OPERATION_INVALID if the guest is truely running - it
will either be shutoff, or in the process of becoming shutoff very soon.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
9:29 a.m.
"Daniel P. Berrange" <berrange(a)redhat.com> writes:
On Fri, Mar 17, 2017 at 02:07:11PM +0100, Milan Zamazal wrote:
> "Daniel P. Berrange" <berrange(a)redhat.com> writes:
>
> > On Fri, Mar 17, 2017 at 11:55:13AM +0100, Milan Zamazal wrote:
> >> Hi, we experienced a strange, non-reproducible error after a successful
> >> migration to another host. When we called virDomainDestroyFlags with
> >> VIR_DOMAIN_DESTROY_GRACEFUL flag after the migration on the source host,
> >> we got VIR_ERR_OPERATION_INVALID (code 55) error. The same with
> >> repeated virDomainDestroyFlags calls. Normally, we would expect either
> >> success or VIR_ERR_NO_DOMAIN error. `virsh list' didn't show the
VM.
> >
> > What about 'virsh list --all' - i expect you have an inactive guest
> > present, as calling destory on an inactive guest triggers OPERATION_INVALID
>
> I see. It's interesting, since we use transient domains. Are there
> known circumstances when OPERATION_INVALID could be returned for a
> transient domain? Can we assume that we never receive that error when
> trying to destroy a running domain?
Cleanup & destruction of domains is an area where there is relatively
high level of concurrency in libvirt. So it is conceivable that you
would see OPERATION_INVALID for a transient guest if libvirt is part
way through cleaning it up - it shouldn't be in that state for very
long though
We had the state returning OPERATION_INVALID for "infinite" time. That
could be caused by some bug or maybe problems with storage or whatever,
we don't know.
You'll never see OPERATION_INVALID if the guest is truely running
- it
will either be shutoff, or in the process of becoming shutoff very soon.
OK, thank you for explanation and clarification.
Regards,
Milan
2688
days inactive
2688
days old
4 comments
2 participants
participants (2)
-
Daniel P. Berrange -
Milan Zamazal