Divya Garg <[email protected]> writes: > On 12/04/22 6:18 pm, Vitaly Kuznetsov wrote: >> Divya Garg <[email protected]> writes: >> >>> Hi Vitaly Kuznetsov ! >>> I was working on hyperv flags and saw that we introduced new >>> dependencies some >>> time back >>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__sourcegraph.com_github.com_qemu_qemu_-2D_commit_c686193072a47032d83cb4e131dc49ae30f9e5d7-3Fvisible-3D1&d=DwIBAg&c=s883GpUCOChKOHiocYtGcg&r=2QGHz-fTCVWImEBKe1ZcSe5t6UfasnhvdzD5DcixwOE&m=ln-t0rKlkFkOEKe97jJTLi2BoKK5E9lLMPHjPihl4kpdbvBStPeD0Ku9wTed7GPf&s=AtipQDs1Mi-0FQtb1AyvBpR34bpjp64troGF_nr_08E&e= >>> ). >>> After these changes, if we try to live migrate a vm from older qemu to newer >>> one having these changes, it fails showing dependency issue. >>> >>> I was wondering if this is the expected behaviour or if there is any work >>> around for handing it ? Or something needs to be done to ensure backward >>> compatibility ? >> Hi Divya, >> >> configurations with 'hv-stimer' and without 'hv-synic'/'hv-time' were >> always incorrect as Windows can't use the feature, that's why the >> dependencies were added. It is true that it doesn't seem to be possible >> to forward-migrate such VMs to newer QEMU versions. We could've tied >> these new dependencies to newer machine types I guess (so old machine >> types would not fail to start) but we didn't do that back in 4.1 and >> it's been awhile since... Not sure whether it would make much sense to >> introduce something for pre-4.1 machine types now. >> >> Out of curiosity, why do such "incorrect" configurations exist? Can you >> just update them to include missing flags on older QEMU so they migrate >> to newer ones without issues? >> > Hi Vitaly ! > > Thanks for the response. I understand that these were incorrect > configurations > and should be corrected. Only issue is, we want to avoid power cycling those > VMs. But yeah I think, since the configurations were wrong we should > update and > power cycle the VM. Just for understanding purpose, is it possible to > disable > the feature by throwing out some warning message and update libvirt to > metigate > this change and handle live migration ? >
I'm not exactly sure about libvirt, I was under the impression it makes sure that QEMU command line is the same on the destination and on the source. If there's a way to add something, I'd suggest you add the missing features (hv-time, hv-synic) on the destination rather than remove 'hv-stimer' as it is probably safer. > Or maybe update libvirt to not to ask for this feature from qemu during live > migration and handle different configuration on source and destination > host ? You can also modify QEMU locally and throw away these dependencies, it'll allow these configurations again but generally speaking checking that the set of hyper-v features is exactly the same on the source and destination is the right thing to do: there are no guarantees that guest OS (Windows) will keep behaving sane when the corresponding CPUIDs change while it's running, all sorts of things are possible I believe. -- Vitaly
