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/ovirt-devel@redhat.com/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
