date:20170220

[libvirt-users] 答复: Virsh command hanging

2017-02-20 Thread 王李明

I have this problem in centos6.5

when I upgrade to centos 7.1 this problem is soluted

maybe you can upgrade your os version

 

 

 

发件人: libvirt-users-boun...@redhat.com [mailto:libvirt-users-boun...@redhat.com] 
代表 abhishek jain
发送时间: 2017年2月21日 13:51
收件人: libvirt-users@redhat.com
主题: [libvirt-users] Virsh command hanging

 

Hi,

 

I started the VMs with libvirt 3 days ago (17th Feb).  Now when I am trying to 
shutdown the domain, all my virsh command is hanging even  virt-manager remains 
in "connecting.."  mode and is not showing active domains.

When   I set  the libvirt debug env and call "virsh list"  it hangs in poll. 
Here is the log

setenv LIBVIRT_DEBUG 1 virsh list

2017-02-21 05:31:09.241+: 125812: debug : virEventPollCalculateTimeout:320 
: Calculate expiry of 0 timers

2017-02-21 05:31:09.241+: 125811: debug : virEventPollUpdateHandle:146 : 
EVENT_POLL_UPDATE_HANDLE: watch=2 events=0

2017-02-21 05:31:09.241+: 125812: debug : virEventPollCalculateTimeout:346 
: Timeout at 0 due in -1 ms

2017-02-21 05:31:09.241+: 125812: debug : virEventPollRunOnce:614 : 
EVENT_POLL_RUN: nhandles=2 timeout=-1

2017-02-21 05:31:09.241+: 125811: debug : virEventPollInterruptLocked:701 : 
Interrupting

2017-02-21 05:31:09.241+: 125812: debug : virEventPollRunOnce:625 : Poll 
got 1 event(s)

2017-02-21 05:31:09.242+: 125812: debug : virEventPollDispatchTimeouts:410 
: Dispatch 0

2017-02-21 05:31:09.242+: 125812: debug : virEventPollDispatchHandles:455 : 
Dispatch 2

2017-02-21 05:31:09.242+: 125812: debug : virEventPollDispatchHandles:469 : 
i=0 w=1

2017-02-21 05:31:09.242+: 125812: debug : virEventPollDispatchHandles:483 : 
EVENT_POLL_DISPATCH_HANDLE: watch=1 events=1

2017-02-21 05:31:09.242+: 125812: debug : virEventPollCleanupTimeouts:501 : 
Cleanup 0

2017-02-21 05:31:09.242+: 125812: debug : virEventPollCleanupTimeouts:537 : 
Found 0 out of 0 timeout slots used, releasing 0

2017-02-21 05:31:09.242+: 125812: debug : virEventPollCleanupHandles:549 : 
Cleanup 2

2017-02-21 05:31:09.242+: 125812: debug : virEventRunDefaultImpl:244 : 
running default event implementation

2017-02-21 05:31:09.242+: 125812: debug : virEventPollCleanupTimeouts:501 : 
Cleanup 0

2017-02-21 05:31:09.242+: 125812: debug : virEventPollCleanupTimeouts:537 : 
Found 0 out of 0 timeout slots used, releasing 0

2017-02-21 05:31:09.242+: 125812: debug : virEventPollCleanupHandles:549 : 
Cleanup 2

2017-02-21 05:31:09.242+: 125812: debug : virEventPollMakePollFDs:378 : 
Prepare n=0 w=1, f=4 e=1 d=0

2017-02-21 05:31:09.242+: 125812: debug : virEventPollMakePollFDs:378 : 
Prepare n=1 w=2, f=6 e=0 d=0

2017-02-21 05:31:09.242+: 125812: debug : virEventPollCalculateTimeout:320 
: Calculate expiry of 0 timers

2017-02-21 05:31:09.242+: 125812: debug : virEventPollCalculateTimeout:346 
: Timeout at 0 due in -1 ms

2017-02-21 05:31:09.242+: 125812: debug : virEventPollRunOnce:614 : 
EVENT_POLL_RUN: nhandles=1 timeout=-1 <>

 

 

here is the log snippet of  /var/log/libvirt/libvirtd.log

2017-02-17 06:18:26.198+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:18:41.022+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:18:56.017+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:19:11.019+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:19:26.016+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:19:41.021+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:19:56.014+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:20:11.021+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:20:26.014+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:20:41.014+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:20:56.016+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:21:11.019+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:21:26.018+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:21:41.022+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:21:56.019+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:22:11.020+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-17 06:22:26.012+: 5052: error : daemonStreamHandleAbort:609 : 
stream aborted at client request

2017-02-18 01:53:36.308+: 5052: warning :

[libvirt-users] Virsh command hanging

2017-02-20 Thread abhishek jain

Hi,
I started the VMs with libvirt 3 days ago (17th Feb).  Now when I am trying to 
shutdown the domain, all my virsh command is hanging even  virt-manager remains 
in "connecting.."  mode and is not showing active domains.When   I set  the 
libvirt debug env and call "virsh list"  it hangs in poll. Here is the 
logsetenv LIBVIRT_DEBUG 1 virsh list

2017-02-21 05:31:09.241+: 125812: debug :virEventPollCalculateTimeout:320 : 
Calculate expiry of 0 timers

2017-02-21 05:31:09.241+: 125811: debug :virEventPollUpdateHandle:146 : 
EVENT_POLL_UPDATE_HANDLE: watch=2 events=0

2017-02-21 05:31:09.241+: 125812: debug :virEventPollCalculateTimeout:346 : 
Timeout at 0 due in -1 ms

2017-02-21 05:31:09.241+: 125812: debug :virEventPollRunOnce:614 : 
EVENT_POLL_RUN: nhandles=2 timeout=-1

2017-02-21 05:31:09.241+: 125811: debug :virEventPollInterruptLocked:701 : 
Interrupting

2017-02-21 05:31:09.241+: 125812: debug :virEventPollRunOnce:625 : Poll got 
1 event(s)

2017-02-21 05:31:09.242+: 125812: debug :virEventPollDispatchTimeouts:410 : 
Dispatch 0

2017-02-21 05:31:09.242+: 125812: debug :virEventPollDispatchHandles:455 : 
Dispatch 2

2017-02-21 05:31:09.242+: 125812: debug :virEventPollDispatchHandles:469 : 
i=0 w=1

2017-02-21 05:31:09.242+: 125812: debug :virEventPollDispatchHandles:483 : 
EVENT_POLL_DISPATCH_HANDLE: watch=1 events=1

2017-02-21 05:31:09.242+: 125812: debug :virEventPollCleanupTimeouts:501 : 
Cleanup 0

2017-02-21 05:31:09.242+: 125812: debug :virEventPollCleanupTimeouts:537 : 
Found 0 out of 0 timeout slots used,releasing 0

2017-02-21 05:31:09.242+: 125812: debug :virEventPollCleanupHandles:549 : 
Cleanup 2

2017-02-21 05:31:09.242+: 125812: debug :virEventRunDefaultImpl:244 : 
running default event implementation

2017-02-21 05:31:09.242+: 125812: debug : virEventPollCleanupTimeouts:501: 
Cleanup 0

2017-02-21 05:31:09.242+: 125812: debug :virEventPollCleanupTimeouts:537 : 
Found 0 out of 0 timeout slots used,releasing 0

2017-02-21 05:31:09.242+: 125812: debug :virEventPollCleanupHandles:549 : 
Cleanup 2

2017-02-21 05:31:09.242+: 125812: debug :virEventPollMakePollFDs:378 : 
Prepare n=0 w=1, f=4 e=1 d=0

2017-02-21 05:31:09.242+: 125812: debug :virEventPollMakePollFDs:378 : 
Prepare n=1 w=2, f=6 e=0 d=0

2017-02-21 05:31:09.242+: 125812: debug : virEventPollCalculateTimeout:320: 
Calculate expiry of 0 timers

2017-02-21 05:31:09.242+: 125812: debug :virEventPollCalculateTimeout:346 : 
Timeout at 0 due in -1 ms

2017-02-21 05:31:09.242+: 125812: debug :virEventPollRunOnce:614 : 
EVENT_POLL_RUN: nhandles=1 timeout=-1<>



here is the log snippet of  /var/log/libvirt/libvirtd.log2017-02-17 
06:18:26.198+: 5052: error :daemonStreamHandleAbort:609 : stream aborted at 
client request

2017-02-17 06:18:41.022+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-17 06:18:56.017+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-17 06:19:11.019+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-17 06:19:26.016+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-17 06:19:41.021+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-17 06:19:56.014+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-17 06:20:11.021+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-17 06:20:26.014+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-17 06:20:41.014+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-17 06:20:56.016+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-17 06:21:11.019+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-17 06:21:26.018+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-17 06:21:41.022+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-17 06:21:56.019+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-17 06:22:11.020+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-17 06:22:26.012+: 5052: error :daemonStreamHandleAbort:609 : stream 
aborted at client request

2017-02-18 01:53:36.308+: 5052: warning :virKeepAliveTimerInternal:156 : No 
response from client 0xe14160 after 5keepalive messages in 30 seconds

2017-02-18 01:53:47.346+: 5052: warning :virKeepAliveTimerInternal:156 : No 
response from client 0xe14c70 after 5 keepalivemessages in 30 seconds 
/var/log/libvirt/libvirtd.log


What could be the problem. I am running virsh (0.10.2) on RHEL6
Thanks for your help in advance.

Re: [libvirt-users] "virsh list" ahngs

2017-02-20 Thread Yunchih Chen




On 02/20/2017 09:07 PM, Martin Kletzander wrote:

On Sat, Feb 18, 2017 at 12:21:31AM +0800, Yunchih Chen wrote:


`virsh list` hangs on my server that hosts a bunch of VMs.
This might be due to the Debian upgrade I did on Feb 15, which upgrades
`libvirt` from 2.4.0-1 to 3.0.0-2.
I have tried restarting libvirtd for a few times, without luck.

Attached below are some relevant logs; let me know if you need some more
for debugging.
Thanks for your help!!

root@vm-host:~# uname -a
Linux vm-host 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 (2016-07-18) x86_64
GNU/Linux

root@vm-host:~# apt-cache policy libvirt-daemon
libvirt-daemon:
  Installed: 3.0.0-2
  Candidate: 3.0.0-2
  Version table:
 *** 3.0.0-2 500
500 http://debian.csie.ntu.edu.tw/debian testing/main amd64
Packages
100 /var/lib/dpkg/status

root@vm-host:~# strace -o /tmp/trace -e trace=network,file,poll virsh
list  # hangs forever .
^C
root@vm-host:~# tail -10 /tmp/trace
access("/etc/libvirt/libvirt.conf", F_OK) = 0
open("/etc/libvirt/libvirt.conf", O_RDONLY) = 5
access("/proc/vz", F_OK)= -1 ENOENT (No such file or
directory)
socket(AF_UNIX, SOCK_STREAM, 0) = 5
connect(5, {sa_family=AF_UNIX,
sun_path="/var/run/libvirt/libvirt-sock"}, 110) = 0
getsockname(5, {sa_family=AF_UNIX}, [128->2]) = 0
poll([{fd=5, events=POLLOUT}, {fd=6, events=POLLIN}], 2, -1) = 1
([{fd=5, revents=POLLOUT}])
poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}], 2, -1) = ?
ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
+++ killed by SIGINT +++

root@vm-host:~# lsof /var/run/libvirt/libvirt-sock # hangs too ...
^C



This is weird =)  Can you attach to libvirtd using gdb (with installed
debuginfo) and run 't a a bt' to see where the daemon hangs?  I think
it's not accepting connections and that's what virsh is waiting for.


Thanks for your help!  Please refer to the previous thread.
https://www.redhat.com/archives/libvirt-users/2017-February/msg00057.html

--
--
Yun-Chih Chen 陳耘志
Network/Workstation Assistant
Dept. of Computer Science and Information Engineering
National Taiwan University
Tel: +886-2-33664888 ext. 217/204
Email: ta...@csie.ntu.edu.tw
Website: http://wslab.csie.ntu.edu.tw/

___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

Re: [libvirt-users] "virsh list" hangs

2017-02-20 Thread Yunchih Chen


On 02/20/2017 09:10 PM, Michal Privoznik wrote:

On 17.02.2017 17:18, Yunchih Chen wrote:

`virsh list` hangs on my server that hosts a bunch of VMs.
This might be due to the Debian upgrade I did on Feb 15, which upgrades
`libvirt` from 2.4.0-1 to 3.0.0-2.
I have tried restarting libvirtd for a few times, without luck.

Attached below are some relevant logs; let me know if you need some more
for debugging.
Thanks for your help!!

root@vm-host:~# uname -a
Linux vm-host 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 (2016-07-18) x86_64
GNU/Linux

root@vm-host:~# apt-cache policy libvirt-daemon
libvirt-daemon:
   Installed: 3.0.0-2
   Candidate: 3.0.0-2
   Version table:
  *** 3.0.0-2 500
 500 http://debian.csie.ntu.edu.tw/debian testing/main amd64
Packages
 100 /var/lib/dpkg/status

root@vm-host:~# strace -o /tmp/trace -e trace=network,file,poll virsh
list  # hangs forever .
^C
root@vm-host:~# tail -10 /tmp/trace
access("/etc/libvirt/libvirt.conf", F_OK) = 0
open("/etc/libvirt/libvirt.conf", O_RDONLY) = 5
access("/proc/vz", F_OK)= -1 ENOENT (No such file or
directory)
socket(AF_UNIX, SOCK_STREAM, 0) = 5
connect(5, {sa_family=AF_UNIX,
sun_path="/var/run/libvirt/libvirt-sock"}, 110) = 0
getsockname(5, {sa_family=AF_UNIX}, [128->2]) = 0
poll([{fd=5, events=POLLOUT}, {fd=6, events=POLLIN}], 2, -1) = 1
([{fd=5, revents=POLLOUT}])
poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}], 2, -1) = ?
ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
+++ killed by SIGINT +++

root@vm-host:~# lsof /var/run/libvirt/libvirt-sock # hangs too ...

This is very suspicious. Looks like the daemon is in some weird state
and hence virsh is unable to get list of domains.

# ps axf | grep libvirtd
# gdb -p $(pgrep libvirtd)
(gdb) t a a bt

if you could run those commands and share the output that might shed
more light.

Michal


Unfortunately, gdb also hangs when attaching to libvirt 

root@vm-host:~# gdb -q -p $(pgrep libvirtd)
Attaching to process 9556
[New LWP 9557]
[New LWP 9558]
[New LWP 9559]
[New LWP 9560]
[New LWP 9561]
[New LWP 9562]
[New LWP 9563]
[New LWP 9564]
[New LWP 9565]
[New LWP 9566]
[New LWP 9567]
[New LWP 9568]
[New LWP 9569]
[New LWP 9570]
[New LWP 9571]
[New LWP 9572]
^C^C^C^C^C^C^C^C^C^C^C

It must be killed with SIGKILL, and libvirtd will die with gdb.

Here[1] is the output of the following command:

strace -o /tmp/gdb-full-trace.txt -s 1024 -f gdb -q -p $(pgrep libvirtd)

Thanks for your help : )

[1] https://www.csie.ntu.edu.tw/~yunchih/s/gdb-full-trace.txt

--
--
Yun-Chih Chen 陳耘志
Network/Workstation Assistant
Dept. of Computer Science and Information Engineering
National Taiwan University
Tel: +886-2-33664888 ext. 217/204
Email: ta...@csie.ntu.edu.tw
Website: http://wslab.csie.ntu.edu.tw/

___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

Re: [libvirt-users] Libvirt behavior when mixing io=native and cache=writeback

2017-02-20 Thread Gionatan Danti


On 20/02/2017 14:02, Martin Kletzander wrote:

On Fri, Feb 17, 2017 at 02:52:06PM +0100, Gionatan Danti wrote:

How about using --xml to supply the destination XML which would have
io="threads" specified?



This seems to work, excellent suggestion! Thank you.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8

___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

Re: [libvirt-users] "virsh list" hangs

2017-02-20 Thread Michal Privoznik

On 17.02.2017 17:18, Yunchih Chen wrote:
> 
> `virsh list` hangs on my server that hosts a bunch of VMs.
> This might be due to the Debian upgrade I did on Feb 15, which upgrades
> `libvirt` from 2.4.0-1 to 3.0.0-2.
> I have tried restarting libvirtd for a few times, without luck.
> 
> Attached below are some relevant logs; let me know if you need some more
> for debugging.
> Thanks for your help!!
> 
> root@vm-host:~# uname -a
> Linux vm-host 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 (2016-07-18) x86_64
> GNU/Linux
> 
> root@vm-host:~# apt-cache policy libvirt-daemon
> libvirt-daemon:
>   Installed: 3.0.0-2
>   Candidate: 3.0.0-2
>   Version table:
>  *** 3.0.0-2 500
> 500 http://debian.csie.ntu.edu.tw/debian testing/main amd64
> Packages
> 100 /var/lib/dpkg/status
> 
> root@vm-host:~# strace -o /tmp/trace -e trace=network,file,poll virsh
> list  # hangs forever .
> ^C
> root@vm-host:~# tail -10 /tmp/trace
> access("/etc/libvirt/libvirt.conf", F_OK) = 0
> open("/etc/libvirt/libvirt.conf", O_RDONLY) = 5
> access("/proc/vz", F_OK)= -1 ENOENT (No such file or
> directory)
> socket(AF_UNIX, SOCK_STREAM, 0) = 5
> connect(5, {sa_family=AF_UNIX,
> sun_path="/var/run/libvirt/libvirt-sock"}, 110) = 0
> getsockname(5, {sa_family=AF_UNIX}, [128->2]) = 0
> poll([{fd=5, events=POLLOUT}, {fd=6, events=POLLIN}], 2, -1) = 1
> ([{fd=5, revents=POLLOUT}])
> poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}], 2, -1) = ?
> ERESTART_RESTARTBLOCK (Interrupted by signal)
> --- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
> +++ killed by SIGINT +++
> 
> root@vm-host:~# lsof /var/run/libvirt/libvirt-sock # hangs too ...

This is very suspicious. Looks like the daemon is in some weird state
and hence virsh is unable to get list of domains.

# ps axf | grep libvirtd
# gdb -p $(pgrep libvirtd)
(gdb) t a a bt

if you could run those commands and share the output that might shed
more light.

Michal

___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

Re: [libvirt-users] "virsh list" ahngs

2017-02-20 Thread Martin Kletzander


On Sat, Feb 18, 2017 at 12:21:31AM +0800, Yunchih Chen wrote:


`virsh list` hangs on my server that hosts a bunch of VMs.
This might be due to the Debian upgrade I did on Feb 15, which upgrades
`libvirt` from 2.4.0-1 to 3.0.0-2.
I have tried restarting libvirtd for a few times, without luck.

Attached below are some relevant logs; let me know if you need some more
for debugging.
Thanks for your help!!

root@vm-host:~# uname -a
Linux vm-host 4.6.0-1-amd64 #1 SMP Debian 4.6.4-1 (2016-07-18) x86_64
GNU/Linux

root@vm-host:~# apt-cache policy libvirt-daemon
libvirt-daemon:
  Installed: 3.0.0-2
  Candidate: 3.0.0-2
  Version table:
 *** 3.0.0-2 500
500 http://debian.csie.ntu.edu.tw/debian testing/main amd64
Packages
100 /var/lib/dpkg/status

root@vm-host:~# strace -o /tmp/trace -e trace=network,file,poll virsh
list  # hangs forever .
^C
root@vm-host:~# tail -10 /tmp/trace
access("/etc/libvirt/libvirt.conf", F_OK) = 0
open("/etc/libvirt/libvirt.conf", O_RDONLY) = 5
access("/proc/vz", F_OK)= -1 ENOENT (No such file or
directory)
socket(AF_UNIX, SOCK_STREAM, 0) = 5
connect(5, {sa_family=AF_UNIX,
sun_path="/var/run/libvirt/libvirt-sock"}, 110) = 0
getsockname(5, {sa_family=AF_UNIX}, [128->2]) = 0
poll([{fd=5, events=POLLOUT}, {fd=6, events=POLLIN}], 2, -1) = 1
([{fd=5, revents=POLLOUT}])
poll([{fd=5, events=POLLIN}, {fd=6, events=POLLIN}], 2, -1) = ?
ERESTART_RESTARTBLOCK (Interrupted by signal)
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
+++ killed by SIGINT +++

root@vm-host:~# lsof /var/run/libvirt/libvirt-sock # hangs too ...
^C



This is weird =)  Can you attach to libvirtd using gdb (with installed
debuginfo) and run 't a a bt' to see where the daemon hangs?  I think
it's not accepting connections and that's what virsh is waiting for.


signature.asc
Description: Digital signature
___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

Re: [libvirt-users] Libvirt behavior when mixing io=native and cache=writeback

2017-02-20 Thread Martin Kletzander


On Fri, Feb 17, 2017 at 02:52:06PM +0100, Gionatan Danti wrote:

Hi all,
I write about libvirt inconsistent behavior when mixing io=native and
cache=writeback. This post can be regarded as an extension, or
clarification request, of BZ 1086704
(https://bugzilla.redhat.com/show_bug.cgi?id=1086704)

On a fully upgraded CentOS6 x86-64 machine, starting a guest with
io=native and cache=writeback is permitted: no errors are raised and the
VM (qemu, really) silently use "io=threads" instead. A warning should be
raised, but I find reasonable that the VM is permitted to run.

On a fully upgraded CentOS7 x86-64 machine, starting a guest with
io=native and cache=writeback is *not* permitted: an error is raised and
the guest is not started. While it is absolutely OK to alert the user
about the configuration error, I feel the VM should be started as on
CentOS6. Anyway, this is not a big problem when dealing with a single host.

A more concerning behavior is that when trying to migrate a guest from
the very first CentOS6 machine, which starts and runs such a guest with
io=native and cache=writeback without problems, to a CentOS7 host, live
migration aborts with an error:

[root@source] virsh migrate Totem --live --copy-storage-all --persistent
--verbose --unsafe qemu+ssh://root@172.31.255.11/system



How about using --xml to supply the destination XML which would have
io="threads" specified?


error: unsupported configuration: native I/O needs either no disk cache
or directsync cache mode, QEMU will fallback to aio=threads

This error persists even if the VM config file is changed to use
"io=threads". Of course, the running image continue to have "io=native"
on its parameters list, but it does not really honor the "io=native"
directive, so I find strange that live migration can not proceed. I
think it is very reasonable to raise an error, but such error should not
block the live migration process.

In short: there is some method to live migrate a running VM configured
with "io=native" (but which is really using "io=threads" internally) and
"cache=writeback"?

Thanks.

--
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.da...@assyoma.it - i...@assyoma.it
GPG public key ID: FF5F32A8

___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users


signature.asc
Description: Digital signature
___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

Re: [libvirt-users] Determining domain job kind from job stats?

2017-02-20 Thread Milan Zamazal

Jiri Denemark  writes:

> On Fri, Feb 17, 2017 at 12:38:24 +0100, Milan Zamazal wrote:
>> Jiri Denemark  writes:
>> 
>> > On Fri, Feb 10, 2017 at 21:50:19 +0100, Milan Zamazal wrote:
>> >> Hi, is there a reliable way to find out to what kind of job does the
>> >> information returned from virDomainGetJobStats or provided in
>> >> VIR_DOMAIN_EVENT_ID_JOB_COMPLETED event callback belong to?
>> >
>> > No, libvirt expects that the caller knows what job it started. All jobs
>> > currently reported using virDomainGetJobStats API or
>> > VIR_DOMAIN_EVENT_ID_JOB_COMPLETED event are internally implemented as
>> > migration in QEMU driver (either to a file or to a network socket),
>> > which may confuse any heuristics for detecting the job type from the set
>> > of fields returned by libvirt.
>> 
>> I see, thank you for explanation.
>> 
>> > What is the problem you are trying to solve?
>> 
>> There are basically two problems:
>> 
>> - When the job completion callback is called, I need to distinguish what
>>   kind of job was it to perform the appropriate actions.  It would be
>>   easier if I knew the job type directly in the callback (no need to
>>   coordinate anything), but "external" job tracking is also possible.
>
> An immediate answer would be: "don't rely on the completion callback and
> just check the return value of the API which started the job", but I
> guess you want it because checking the return value is not possible when
> the process which started the job is not running anymore as described
> below.

Well, avoiding using the completion callback is probably OK for me.
(In case of the process restart, I don't expect having everything
perfectly working, just some basic sanity.)

>> - If I lost track of my jobs (e.g. because of a crash and restart), I'd
>>   like to find out whether a given VM is migrating.  Examining the job
>>   looked like a good candidate to get the information, but apparently
>>   it's not.  Again, I can probably arrange things to handle that, but to
>>   get the information directly from libvirt (not necessarily via job
>>   info) would be easier and more reliable.
>
> Apparently you are talking about peer-to-peer migration, 

Yes.

> otherwise the migration would be automatically canceled when the
> process which started it disappears. I'm afraid this is not currently
> possible in general. You might be able to get something by checking
> the domain's status, but it won't work in all cases.

Too bad.  Could some future libvirt version provide that information?

Thank you for clarification,
Milan

___
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users

[libvirt-users] 答复: Virsh command hanging

[libvirt-users] Virsh command hanging

Re: [libvirt-users] "virsh list" ahngs

Re: [libvirt-users] "virsh list" hangs

Re: [libvirt-users] Libvirt behavior when mixing io=native and cache=writeback

Re: [libvirt-users] "virsh list" hangs

Re: [libvirt-users] "virsh list" ahngs

Re: [libvirt-users] Libvirt behavior when mixing io=native and cache=writeback

Re: [libvirt-users] Determining domain job kind from job stats?

9 matches

Site Navigation

Mail list logo

Footer information