[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device
From: |
Eduardo Habkost |
Subject: |
Re: [Qemu-devel] [PATCH v6 2/7] hw/misc: add vmcoreinfo device |
Date: |
Tue, 17 Apr 2018 19:53:54 -0300 |
User-agent: |
Mutt/1.9.2 (2017-12-15) |
On Tue, Apr 17, 2018 at 06:31:57PM -0400, Cole Robinson wrote:
> On 04/17/2018 05:11 PM, Eduardo Habkost wrote:
> > On Tue, Apr 17, 2018 at 03:12:03PM -0400, Cole Robinson wrote:
> > [...]
> >> Reviving this... did any follow up changes happen?
> >>
> >> Marc-André patched virt-manager a few months back to enable -device
> >> vmcoreinfo for new VMs:
> >>
> >> https://www.redhat.com/archives/virt-tools-list/2018-February/msg00020.html
> >>
> >> And I see there's at least a bug tracking adding this to openstack for
> >> new VMs:
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1555276
> >>
> >> If this feature doesn't really have any downsides, it would be nice to
> >> get this tied to new machine types. Saves a lot of churn for higher
> >> levels of the stack
> >
> > I understand this would be nice to have considering the existing
> > stacks, but at the same time I would like the rest of the
> > stack(s) to really try to not depend on QEMU machine-types to
> > define policy/defaults.
> >
> > Every feature that is hidden behind an opaque machine-type name
> > and not visible in the domain XML and QEMU command-line increases
> > the risk of migration and compatibility bugs.
> >
>
> What exactly is the migration compatibility issue with turning on the
> equivalent of -device vmcoreinfo for -M *-2.13+ ? Possibly prevents
> backwards migration to older qemu but is that even a goal?
I mean the extra migration compatibility code that needs to be
maintained on older machine-types. It's extra maintenance burden
on both upstream and downstream QEMU trees.
>
> > This was being discussed in a mail thread at:
> > https://www.mail-archive.com/address@hidden/msg01196.html
> >
> > Quoting Daniel, on that thread:
> >
> > ] Another case is the pvpanic device - while in theory that could
> > ] have been enabled by default for all guests, by QEMU or a config
> > ] generator library, doing so is not useful on its own. The hard
> > ] bit of the work is adding code to the mgmt app to choose the
> > ] action for when pvpanic triggers, and code to handle the results
> > ] of that action.
> >
> > From that comment, I understand that simply making QEMU create a
> > pvpanic device by default on pc-2.13+ won't be useful at all?
> >
>
> This qemu-devel thread was about -device vmcoreinfo though, not pvpanic.
> vmcoreinfo doesn't need anything else to work AFAICT and shouldn't need
> any explicit config, heck it doesn't even have any -device properties.
>
> Like Dan says pvpanic isn't a 'just works' thing, and I know for windows
> VMs it shows up in device manager which has considerations for things
> like SVVP. I think vmcoreinfo doesn't have the same impact
>
Oops, nevermind. I confused both.
> There are some guest visible things that we have turned on for new
> machine types in the past, pveoi and x2apic comes to mind.
Yes, we have tons of guest-visible things that we tie to the
machine-type. What I'm looking for is a solution to make this
less frequent in the future.
--
Eduardo