Hi, tumbleweed, is there a way to prevent qemu from updating virtualized hardware inside the virtualisation? as example: sometimes when qemu is updated, the virtial machines OS (windows 10 or windows xp) find new "hardware" and at least in windows xp i have now a huge amount of broken (most is invisible inside system-controll) hardware . and of course the "fingerprint" of the system will change. -> only solution i think about is to virtualize windows inside a virtualized tumbleweed which will then never be updated any more, running on an updated real hardware tumbleweed. so that the windows image will never be run by a new qemu version. anybody has a better solution? some command line options i could via virt-manager pass to qemu? like "stay ALWAYS on hardware qemu version 6.0 ????" simoN -- www.becherer.de
07.01.2021 13:37, Simon Becherer пишет:
Hi,
tumbleweed,
is there a way to prevent qemu from updating virtualized hardware inside the virtualisation?
as example: sometimes when qemu is updated, the virtial machines OS (windows 10 or windows xp) find new "hardware" and at least in windows xp i have now a huge amount of broken (most is invisible inside system-controll) hardware . and of course the "fingerprint" of the system will change.
-> only solution i think about is to virtualize windows inside a virtualized tumbleweed which will then never be updated any more, running on an updated real hardware tumbleweed. so that the windows image will never be run by a new qemu version.
anybody has a better solution? some command line options i could via virt-manager pass to qemu? like "stay ALWAYS on hardware qemu version 6.0 ????"
I do not know about virt-manager, but qemu-system-x86_64 -machine help lists supported platforms and you can always give exact value. Defaults (like "pc" or "q35") are normally aliased to the latest supported version and so may change when qemu is updated.
Hi, Am 07.01.21 um 13:12 schrieb Andrei Borzenkov:
lists supported platforms and you can always give exact value. Defaults (like "pc" or "q35") are normally aliased to the latest supported version and so may change when qemu is updated.
i checked the (autogenerated (from libvirt)) quemu commandline: (ps fax |grep quemu) there is the parameter -machine pc-q35-4.2 inside. this parameter is since 15.juni2020 (generation of the libvirt xml file) inside. so it was since there started with this parameter. but after an update of qemu some components (in special the networkadapter, has changed.) the networkadapter is also inside the config line e1000e. but windows10 has found a new one (a new e1000e) and i have had to set for the new adapter my fixed ipv4 adress. simoN -- www.becherer.de
On 1/7/21 9:44 AM, Simon Becherer wrote:
i checked the (autogenerated (from libvirt)) quemu commandline: (ps fax |grep quemu)
there is the parameter -machine pc-q35-4.2 inside. this parameter is since 15.juni2020 (generation of the libvirt xml file) inside. so it was since there started with this parameter. but after an update of qemu some components (in special the networkadapter, has changed.) the networkadapter is also inside the config line e1000e. but windows10 has found a new one (a new e1000e) and i have had to set for the new adapter my fixed ipv4 adress.
simoN
Simon, Does this happen with every update of qemu? I can see this happening as a one-off when qemu or libvirt has a major change that changes how hardware is seen from the guest, but generally speaking, what the guest sees as hardware shouldn't change. -- David C. Rankin, J.D.,P.E.
Hi david, Am 09.01.21 um 22:19 schrieb David C. Rankin:
Does this happen with every update of qemu? I can see this happening as a one-off when qemu or libvirt has a major change that changes how hardware is seen from the guest, but generally speaking, what the guest sees as hardware shouldn't change.
not every update, but i see it at least two times in the last 2 years. and it brakes for me my installation of a propetary software in win10 who has a copy protection. i have then always to make a phone call to the software company and ask for new key-number. that's annoying. (i own a permanent license for one computer but the computer should not change the hardware) - the host did not change, but quemu (or libvirt) (but libvirt has always the same xml file, so i think its qemu itselfe) changed the virtual hardware.
seen from the guest, but generally speaking, what the guest sees as hardware shouldn't change.
yes, that's also my opinion for "virtualisazion" of a complete system. but how to solve this problem? i have fear that the software company some day says i have to buy a new license. (even if its still on same hardware but quemu update)) and of course, my older windows xp's where i run also proprietary software has this huge list of "broken or not any more installed" hardware. simoN -- www.becherer.de
10.01.2021 17:09, Simon Becherer пишет:
Hi david,
Am 09.01.21 um 22:19 schrieb David C. Rankin:
Does this happen with every update of qemu? I can see this happening as a one-off when qemu or libvirt has a major change that changes how hardware is seen from the guest, but generally speaking, what the guest sees as hardware shouldn't change.
not every update, but i see it at least two times in the last 2 years. and it brakes for me my installation of a propetary software in win10 who has a copy protection. i have then always to make a phone call to the software company and ask for new key-number. that's annoying. (i own a permanent license for one computer but the computer should not change the hardware) - the host did not change, but quemu (or libvirt) (but libvirt has always the same xml file, so i think its qemu itselfe) changed the virtual hardware.
seen from the guest, but generally speaking, what the guest sees as hardware shouldn't change.
yes, that's also my opinion for "virtualisazion" of a complete system. but how to solve this problem?
You did not provide any information at all. Show full qemu command line in both cases, tell what exact versions of qemu are used in each case, explain which device was changed, provide information from Windows in both cases that show difference. So far the only information was e1000e; I do not really see any fundamental changes that would explain new device looking at commit history.
i have fear that the software company some day says i have to buy a new license. (even if its still on same hardware but quemu update)) and of course, my older windows xp's where i run also proprietary software has this huge list of "broken or not any more installed" hardware.
simoN
participants (3)
-
Andrei Borzenkov -
David C. Rankin -
Simon Becherer