Hello people, libvirtd (libvirt) 1.0.5.2 virsh 1.0.5.2 virt-manager 0.10.0 Host: Linux localhost 3.9.8-300.fc19.x86_64 #1 SMP Thu Jun 27 19:24:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Guest1: Linux localhost 3.9.8-300.fc19.i686.PAE #1 SMP Thu Jun 27 19:29:30 UTC 2013 i686 (none) Guest2: Linux localhost 3.9.8-300.fc19.x86_64 #1 SMP Thu Jun 27 19:24:23 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux Virtual NIC - source & model: macvtap/NAT/bridge & virtio(virtio_net) Host freeze at "virsh reset <domain>" or "virt-manager - Force Reset" Need kernel.sysrq or power reset.

On 03.07.2013 13:43, Daniel P. Berrange wrote: > On Tue, Jul 02, 2013 at 01:25:21PM +0200, poma wrote: >> Hello people, >> >> libvirtd (libvirt) 1.0.5.2 >> virsh 1.0.5.2 >> virt-manager 0.10.0 >> >> Host: >> Linux localhost 3.9.8-300.fc19.x86_64 #1 SMP Thu Jun 27 19:24:23 UTC >> 2013 x86_64 x86_64 x86_64 GNU/Linux >> Guest1: >> Linux localhost 3.9.8-300.fc19.i686.PAE #1 SMP Thu Jun 27 19:29:30 UTC >> 2013 i686 (none) >> Guest2: >> Linux localhost 3.9.8-300.fc19.x86_64 #1 SMP Thu Jun 27 19:24:23 UTC >> 2013 x86_64 x86_64 x86_64 GNU/Linux >> >> >> Virtual NIC - source & model: >> macvtap/NAT/bridge & virtio(virtio_net) >> >> Host freeze at "virsh reset <domain>" or "virt-manager - Force Reset" >> Need kernel.sysrq or power reset. > > I don't believe this is a libvirt issue - the 'virsh reset' command > will issue the 'system_reset' QEMU monitor command. This in turn > does an immediate reset of the guest CPUs/machine. > > Even if QEMU is doing the wrong thing, the kernel should obviously > never freeze/crash in this way - it should be robust against a > malicious QEMU process. > > You should probably send this message to the main QEMU and/or KVM > mailing lists so that it comes to the attention of people who are > more familiar with QEMU + virtio-net > > > Regards, > Daniel > Thanks for your response. Mateusz hit the same issue[1] as well. OK, here we go. poma [1] https://lists.fedoraproject.org/pipermail/users/2013-July/436984.html