On Wed, Feb 29, 2012 at 12:05:32PM +0200, Avi Kivity wrote: > On 02/29/2012 11:58 AM, Daniel P. Berrange wrote: > > > > > > How about using a virtio-serial channel for this? You can transfer any > > > amount of information (including the dump itself). > > > > When the guest OS has crashed, any dumps will be done from the host > > OS using libvirt's core dump mechanism. The guest OS isn't involved > > and is likely too dead to be of any use anyway. Likewise it is > > quite probably too dead to work a virtio-serial channel or any > > similarly complex device. We're really just after the simplest > > possible notification that the guest kernel has paniced. > > If it's alive enough to panic, it's alive enough to kexec its kdump > kernel. After that it can do anything. > > Guest-internal dumps are more useful IMO that host-initiated dumps. In > a cloud, the host-initiated dump is left on the host, outside the reach > of the guest admin, outside the guest image where all the symbols are, > and sometimes not even on the same host if a live migration occurred. > It's more useful in small setups, or if the problem is in the > hypervisor, not the guest. I don't think guest vs host dumps should be considered mutually exclusive, they both have pluses+minuses. Configuring kexec+kdump requires non-negligable guest admin configuration work before it's usable, and this work is guest OS specific, if it is possible at all. A permanent panic notifier that's built in the kernel by default requires zero guest admin config, and can allow host admin to automate collection of dumps across all their hosts/guests. The KVM hypercall notification is fairly trivially ported to any OS kernel, by comparison with a full virtio + virtio-serial impl. 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 :| -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
