On Wed, Aug 21, 2013 at 06:56:52PM +0200, Paolo Bonzini wrote:
> Il 21/08/2013 18:55, Daniel P. Berrange ha scritto:
> > On Wed, Aug 21, 2013 at 06:51:11PM +0200, Paolo Bonzini wrote:
> >> Il 21/08/2013 18:48, Daniel P. Berrange ha scritto:
> >>> No, is the right thing to be using for this from
>
On Wed, Aug 21, 2013 at 06:51:11PM +0200, Paolo Bonzini wrote:
> Il 21/08/2013 18:48, Daniel P. Berrange ha scritto:
> > No, is the right thing to be using for this from
> > libvirt's pov & I don't think we should invent something new.
> > The element has always been intended to represent
> > han
Il 21/08/2013 19:26, Michael S. Tsirkin ha scritto:
> This is a QEMU bug that you happened to be Cc'd on.
Michael, this is bullshit and you know. I know you're more intelligent
than this. Stop it, please.
Paolo
On Wed, Aug 21, 2013 at 11:02:56AM -0600, Eric Blake wrote:
> On 08/21/2013 10:51 AM, Paolo Bonzini wrote:
> > Il 21/08/2013 18:48, Daniel P. Berrange ha scritto:
> >> No, is the right thing to be using for this from
> >> libvirt's pov & I don't think we should invent something new.
> >> The elem
Il 21/08/2013 18:55, Daniel P. Berrange ha scritto:
> On Wed, Aug 21, 2013 at 06:51:11PM +0200, Paolo Bonzini wrote:
>> Il 21/08/2013 18:48, Daniel P. Berrange ha scritto:
>>> No, is the right thing to be using for this from
>>> libvirt's pov & I don't think we should invent something new.
>>> The
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 21/08/2013 19:10, Eric Blake ha scritto:
> On 08/21/2013 10:56 AM, Paolo Bonzini wrote:
>>> eg it is valid to have present in the XML at all
>>> times, even if there's no pvpanic device present. That simply
>>> means the actions will never be tri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Il 21/08/2013 19:02, Eric Blake ha scritto:
> So, this boils down to a question of what SHOULD the valid states
> for be? Generically, we want
> destroy to not invalidate a guest, but also to
> not instantiate a pvpanic device; since that covers the
On 08/21/2013 10:56 AM, Paolo Bonzini wrote:
>> eg it is valid to have present in the XML at all
>> times, even if there's no pvpanic device present. That simply
>> means the actions will never be triggered.
>
> So are you suggesting to add a element to ? That
> may be fine, but it doesn't seem
On 08/21/2013 10:51 AM, Paolo Bonzini wrote:
> Il 21/08/2013 18:48, Daniel P. Berrange ha scritto:
>> No, is the right thing to be using for this from
>> libvirt's pov & I don't think we should invent something new.
>> The element has always been intended to represent
>> handling of guest panics,
Il 21/08/2013 18:48, Daniel P. Berrange ha scritto:
> No, is the right thing to be using for this from
> libvirt's pov & I don't think we should invent something new.
> The element has always been intended to represent
> handling of guest panics, not qemu internal errors.
Actually for Xen HVM gu
On Wed, Aug 21, 2013 at 06:43:13PM +0200, Paolo Bonzini wrote:
> The pvpanic mess is even bigger than anticipated. Let's fix the monitor's
> behavior (patch 1), get rid of all traces that the broken pvpanic existed
> (patch 2), and give it a new name so that libvirt can detect a design
> that work
The pvpanic mess is even bigger than anticipated. Let's fix the monitor's
behavior (patch 1), get rid of all traces that the broken pvpanic existed
(patch 2), and give it a new name so that libvirt can detect a design
that works (patch 3).
All downstreams are urged to apply patches 1+2 as soon as
12 matches
Mail list logo
