Re: [libvirt] [Qemu-devel] pvpanic plans?
Ping! Hu Tao hu...@cn.fujitsu.com writes: Hi All, I know it's been a long time since this thread. But qemu 1.7 is releasing, do you have any consensus on this? Thanks. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] pvpanic plans?
On Thu, Aug 22, 2013 at 03:09:06PM -0500, Anthony Liguori wrote: Paolo Bonzini pbonz...@redhat.com writes: Also, a virtio watchdog device makes little sense, IMHO. PV makes sense if emulation has insufficient performance, excessive CPU usage, or excessive complexity. We already have both an ISA and a PCI watchdog, and they serve their purpose wonderfully. Neither of which actually work with modern versions of Windows FWIW. Correct, although someone could write a driver! Plus emulated watchdogs do not take into account steal time or overcommit in general. I've seen multiple cases where a naive watchdog has a problem in the field when the system is under heavy load. The watchdog devices in qemu run on guest time. However the watchdog *daemon* inside the guest probably does behave badly as you describe. Changing the device model isn't going to help this, but it would definitely make sense to fix the daemon (although I don't know how -- is steal time exposed to guests?) I don't necessarily think a virtio-watchdog is a bad idea. For one thing it'd mean we would have a watchdog device that works on ARM. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] pvpanic plans?
On Thu, Aug 22, 2013 at 01:25:32PM -0500, Anthony Liguori wrote: I believe that the watchdogs we emulate today are not supported by a majority of guests. BTW this is not true. The two watchdog devices are supported by all Linux guests. Windows guests do not support them, but Windows lacks[1] any sort of watchdog framework so lack of device support is the least of your problems. There would be nothing for the device to plug into (unlike the /dev/watchdog API on Linux), nor is there any daemon to support it (unlike the 15 year old watchdog daemon on Linux). Rich. [1] Yes, this exists: http://msdn.microsoft.com/en-us/library/ms856963.aspx but it requires a special version of Windows. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] pvpanic plans?
On Tue, Aug 27, 2013 at 04:08:12PM +0300, Ronen Hod wrote: So the right solution is to send a heart-beat to a management application (using qemu-ga or whatever), and let it decide how to handle it. Agreed. The qemu watchdog lets you do this already. You can (using the qemu monitor, or libvirt) capture watchdog events and put them into your management application. Watchdog firing does *not* necessarily mean a guest reboot. [Note what I say applies to the qemu watchdog device. The Linux watchdog daemon may independently initiate a guest reboot, but you can configure it to perform other actions instead.] Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] pvpanic plans?
On Tue, Aug 27, 2013 at 02:13:34PM +0100, Daniel P. Berrange wrote: On Thu, Aug 22, 2013 at 09:16:57PM +0200, Paolo Bonzini wrote: Il 22/08/2013 19:53, Laszlo Ersek ha scritto: We should just introduce a simple watchdog device based on virtio and call it a day. Then it's cross platform, solves the guest enumeration problem, and libvirt can detect the presence of the new device. If the guest doesn't initialize the proposed virtio-panic device, then it will lie dormant too, just like the current pvpanic device. That's good. However a new (standalone) virtio device will take up yet another PCI function (a full device if you want it to be hotpluggable). PCI functions are scarcer than ioports. Not just that. Panic notifiers are called in a substantially unknown environment, with locks taken or interrupts already set up. This is why we went for a simple ISA device. Configuration via ACPI follows naturally from there, and anyway any other standard of the day would have had the same problem with Windows. At some point we had ACPI methods instead of a simple ioport write, but we had to remove that because the ACPI subsystem might have had its lock taken. Also, a virtio watchdog device makes little sense, IMHO. PV makes sense if emulation has insufficient performance, excessive CPU usage, or excessive complexity. We already have both an ISA and a PCI watchdog, and they serve their purpose wonderfully. I also don't think that panic notifiers watchdogs are really serving the same purpose. The panic notifier is an alert to a specific known kernel crash. A watchdog is merely a timeout, which is inferred to mean /something/ went wrong. Both have their uses IMHO we should not conflate the two. Exactly this. They are two different things. Of course ILOs combine both (and more) in one mega-device :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] pvpanic plans?
On Tue, Aug 27, 2013 at 8:20 AM, Richard W.M. Jones rjo...@redhat.com wrote: On Tue, Aug 27, 2013 at 04:08:12PM +0300, Ronen Hod wrote: So the right solution is to send a heart-beat to a management application (using qemu-ga or whatever), and let it decide how to handle it. This is host-centric solution and assumes that a management tool is making all of the decisions. This doesn't work in an IaaS environment where these sort of policy decisions need to be driven from the guest. Furthermore, you really want the watchdog daemon to run with real time priority which implies a heightened privilege level. This rules out using qemu-ga for that purpose. Agreed. The qemu watchdog lets you do this already. You can (using the qemu monitor, or libvirt) capture watchdog events and put them into your management application. Watchdog firing does *not* necessarily mean a guest reboot. Ack, but the current watchdog does not work for Windows guests and is not aware of guest time. That's why I think having a virtio-ilo makes sense. This is not a solved problem today. Regards, Anthony Liguori [Note what I say applies to the qemu watchdog device. The Linux watchdog daemon may independently initiate a guest reboot, but you can configure it to perform other actions instead.] Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] pvpanic plans?
On Tue, Aug 27, 2013 at 08:26:53AM -0500, Anthony Liguori wrote: That's why I think having a virtio-ilo makes sense. This is not a solved problem today. What's the scope of virtio-ilo? If it's anything like a real ILO it's going to do a lot of not-very-related things, such as: - pvpanic-type function - watchdog-type function - remote console / serial ports - remote CD-ROM - remote power switch qemu already does nearly all of this ... Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] pvpanic plans?
On 08/27/2013 11:06 AM, Richard W.M. Jones wrote: On Thu, Aug 22, 2013 at 03:09:06PM -0500, Anthony Liguori wrote: Paolo Bonzini pbonz...@redhat.com writes: Also, a virtio watchdog device makes little sense, IMHO. PV makes sense if emulation has insufficient performance, excessive CPU usage, or excessive complexity. We already have both an ISA and a PCI watchdog, and they serve their purpose wonderfully. Neither of which actually work with modern versions of Windows FWIW. Correct, although someone could write a driver! Plus emulated watchdogs do not take into account steal time or overcommit in general. I've seen multiple cases where a naive watchdog has a problem in the field when the system is under heavy load. The watchdog devices in qemu run on guest time. However the watchdog *daemon* inside the guest probably does behave badly as you describe. Changing the device model isn't going to help this, but it would definitely make sense to fix the daemon (although I don't know how -- is steal time exposed to guests?) I don't necessarily think a virtio-watchdog is a bad idea. For one thing it'd mean we would have a watchdog device that works on ARM. Rich. I believe that a watchdog is not the way to go. You need host-side decision making. Say that the guest did not receive CPU/Disk/network resources for a lengthy period of time, but the host knows that this is due to host resources availability. In such cases, you certainly do not want to reboot all the guests, especially since rebooting 50 Windows VMs could be a nightmare. BTW, Windows guest disable some of their watchdogs when they detect the presence of Hyper-V, we use it to overcome BSODs! So the right solution is to send a heart-beat to a management application (using qemu-ga or whatever), and let it decide how to handle it. Ronen. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] pvpanic plans?
On 22/08/13 20:33, Anthony Liguori wrote:
Laszlo Ersek ler...@redhat.com writes:
On 08/22/13 18:10, Paolo Bonzini wrote:
The thread from yesterday has died off (perhaps also because of
my inappropriate answer to Michael, for which I apologize to him
and everyone). I took some time to discuss the libvirt requirements
further with Daniel Berrange and Eric Blake on IRC. If anyone is
interested, I can give logs. This is a suggestion for how to
proceed in both QEMU and libvirt.
The analysis is pretty overwhelming :)
I have read Anthony's response and I'm not trying to argue -- I'm just
spending a few thoughts on this and I'm willing to let them go to waste.
In general I think we should minimize the quirks the user (who edits the
libvirt XML) has to know about. Interactions between some XML elements,
without explicit inter-references (formulated as attributes, like
controller/index) are Bad (TM). So,
== Builtin pvpanic ==
QEMU will remove pvpanic from pc-1.5 in 1.6.1 and 1.5.4. This does not
break migration.
== Support in libvirt for current functionality ==
libvirt will add a panic-notifier/ element, and possibly a capability
for it accessible via virsh capabilities. There are two possibilities:
1) On QEMU 1.5.4/1.6.1 and newer (and on QEMU 1.6.0 with a machine type
other than pc-1.5), on_crash will only work if the element is there.
On QEMU 1.5.0-1.5.3, and on QEMU 1.6.0 with the pc-1.5 machine type,
on_crash will be obeyed always, and may override e.g. reboot-on-panic
if a guest driver exist.
I don't like this because there's some interplay between on_crash and
panic_notifier, which even depends on the qemu version.
2) On all versions, on_crash will only work if the element is there.
I like this, because, if on_crash doesn't work without panic_notifier
*at all*, then we can just drop panic_notifier, and make on_crash mean
(on_crash panic_notifier) in the original sense.
IOW, drop panic_notifier, and make on_crash work *always*.
In turn, there are two ways to implement (2):
2a) libvirt will always add -global pvpanic.iobase=0 to neutralize
the builtin pvpanic device if present. panic-notifier/
will create the device with -device pvpanic,iobase=0x505
Advantage: no changes to QEMU
Disadvantage 1: writes to port 0 with QEMU 1.{5.0,5.1,5.2,5.3,6.0}
and pc-1.5 machine type will write to a pvpanic device instead of
the DMA controller. Probably harmless, and limited to some QEMU
versions.
Disadvantage 2: libvirt has knowledge of the pvpanic port number
Updating this paragraph with my above suggestion:
- (s/pvpanic.iobase/pvpanic.ioport/g)
- if on_crash is absent:
- for 1.{5.0,5.1,5.2,5.3,6.0}, add -global pvpanic.ioport=0
- for other versions, do nothing
- if on_crash is present:
- for 1.{5.0,5.1,5.2,5.3,6.0}, do nothing,
- for other versions, pass -device pvpanic
(knowledge of 0x505 is unneeded)
Just to further complicate things...
pvpanic is not going to be present on S390, PPC, ARM, or MIPS because of
the fact that it's x86 specific.
What about crashed state? I have implemented this state after the guest entered
disabled wait (by convention used by all s390 OSes for crashes)
See commit 08eb8c85e3967b97865d46acadf26dc908fbb094
Author: Christian Borntraeger borntrae...@de.ibm.com
Date: Fri Apr 26 11:24:47 2013 +0800
Wire up disabled wait a panicked event on s390
Should we remove that as well? From s390 point of view, after allowing
the crashed-running transition the feature would probably work as expected.
Christian
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] pvpanic plans?
On 22 August 2013 21:09, Anthony Liguori anth...@codemonkey.ws wrote: Paolo Bonzini pbonz...@redhat.com writes: Not just that. Panic notifiers are called in a substantially unknown environment, with locks taken or interrupts already set up. If you make the panic notify a config space write, then on virtio-pci, it's an outb to a fixed offset within a io address that after boot is static. So the address could be stored in a global and accessed without a lock. Fine for virtio-mmio too, obviously. I have a vague recollection that config space writes on virtio-s390 are weird though. (would also be an issue if we wanted to implement the virtio-console emergency write functionality.) -- PMM -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
