[libvirt] libvirt & virtio_net - host.freeze@reset.domain
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. poma
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 -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
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
On 04.07.2013 11:14, poma wrote:
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
OK, is this a side effect or not, but certainly kernel[1] with 'bridge-timer-fix.patch'[2] resolves issue aforementioned, so far. Thanks Cong, Josh. poma [1] http://koji.fedoraproject.org/koji/taskinfo?taskID=5569632 kernel-3.9.8-300.7.fc19.x86_64.rpm [2] https://bugzilla.redhat.com/show_bug.cgi?id=880035#c53 Ref. "fix for unreliable guest->host multicast triggers oops" https://bugzilla.redhat.com/show_bug.cgi?id=980254
participants (2)
-
Daniel P. Berrange -
poma