On Mon, Jan 28, 2019 at 06:22:30PM +0000, Dr. David Alan Gilbert wrote: > * Vitaly Kuznetsov (vkuzn...@redhat.com) wrote: > > Roman Kagan <rka...@virtuozzo.com> writes: > > > > > On Fri, Jan 25, 2019 at 02:46:42PM +0100, Vitaly Kuznetsov wrote: > > >> Roman Kagan <rka...@virtuozzo.com> writes: > > >> > > >> > On Fri, Jan 25, 2019 at 12:41:51PM +0100, Vitaly Kuznetsov wrote: > > >> >> In many case we just want to give Windows guests all currently > > >> >> supported > > >> >> Hyper-V enlightenments and that's where this new mode may come handy. > > >> >> We > > >> >> pass through what was returned by KVM_GET_SUPPORTED_HV_CPUID. > > >> > > > >> > How is the compatibility ensured on migration between kernels reporting > > >> > different feature sets? > > >> > > >> AFAIU we don't change anything in this regard (or, my intention was to > > >> not change anything): hv-all is converted to the individual hv-* > > >> properties (hv_cpuid_check_and_set()) actually sets cpu->hyperv_* flags > > >> according to what's supported by kernel so when we migrate we will > > >> require all these features supported. > > > > > > Migration relies on the upper layer to run the destination QEMU with the > > > identical command line (except for -incoming) as the source, and QEMU is > > > then supposed to set up identical environment in the target VM as was in > > > the source, or refuse to start if that's impossible. (If I'm > > > misunderstanding this Dave (cc-d) may want to correct me.) > > > > > > AFAICS this hv-all attribute will enable different feature sets > > > depending on the kernel it's run on, so the migration between different > > > kernels will appear to succeed, but the guest may suddenly encounter an > > > incompatible change in the environment. > > > > With 'hv-all' I'm trying to achieve behavior similar to '-cpu host' and > > AFAIK these VMs are migratable 'at your own risk' (if you do it directly > > from qemu). Libvirt (or whatever upper layer), however, would do CPU > > feature comparison and in case you have less features on the destination > > host than you had on the source code it will forbid the migration. I > > think if this also works for Hyper-V features than were fine. > > > > Dave, feel free to tell me I'm completely wrong with my assumptions) > > It does sound like -cpu host, but -cpu host does come with a health > warning and we often get subtle screwups where it doesn't quite behave > the same on the two sides, also qemu now warns (and with 'enforce' > enforces) a check at it's level rather than relying on libvirt. > > So hmm, yes it sounds like -cpu host, but I'd generally say it's not a > great thing to copy unless you're really really careful. > For example, in the -cpu host world people might have two machines > they think are the same - but then they find out one has HT disabled > or nesting enabled and so they're not actually the same. > > I'm not sure what the equivalent bear traps are in the Hyper-V world, > but I'd be surprised if there weren't any; for example what happens > when someone upgrades one of their hosts to some minor version that > adds/removes a feature? > > Also, how does libvirt figure out that the features are actually the > same - does it need a bunch of detection code?
We support "-cpu host" with libvirt because there is a genuine functional reasont to want to use that, as you can't get precisely the same result any other way. This isn't the case with 'hv-all', as it doesn't offer any feature that you can't already achieve by listing all the hv-XXX features explicitly. As such I don't expect libvirt to use 'hv-all' at all. There's no reason why QEMU can't support it anyway though, for the simplicity of people launching QEMU manually. Just need to document that migration caveat - its only safe if QEMU versions match on both sides. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|