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. 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? -- Eduardo
