[libvirt][PATCH] running libvirt on the latest kvm snapshot
Hi. Libvirt tryes to extract kvm version from the string "QEMU PC emulator version <major>.<minor>.<micro> (kvm-<version>)..." For examle, # kvm -help | head -1 QEMU PC emulator version 0.10.0 (kvm-85), Copyright (c) 2003-2008 Fabrice Bellard The problem occures if you are trying to run it on the devel version of kvm: # kvm -help | head -1 QEMU PC emulator version 0.10.0 (kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard The virParseNumber() obvioulsy fails on the "devel" string here. I proposeto setup `kvm_version' to 1000 (that's enough, I think) in that case, so all checks, such as if (kvm_version > 74) ... will pass.
Anton Protopopov wrote:
Hi.
Libvirt tryes to extract kvm version from the string "QEMU PC emulator version <major>.<minor>.<micro> (kvm-<version>)..." For examle, # kvm -help | head -1 QEMU PC emulator version 0.10.0 (kvm-85), Copyright (c) 2003-2008 Fabrice Bellard
The problem occures if you are trying to run it on the devel version of kvm: # kvm -help | head -1 QEMU PC emulator version 0.10.0 (kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard The virParseNumber() obvioulsy fails on the "devel" string here. I propose to setup `kvm_version' to 1000 (that's enough, I think) in that case, so all checks, such as if (kvm_version > 74) ... will pass.
Yeah, I've run into this too. The problem with just setting kvm_version to a huge number is that if you built a kvm development snapshot a long time in the past, and you run it now, then you will be turning on features your old development snapshot didn't necessarily have. On the other hand, if you are running development snapshots, you get to keep both pieces when things break. Maybe we can set the kvm_version number very high like you say, but also dump a warning message out to the logfile saying this is a development version so the poor sap who has to debug something like this has a fighting chance. Any other opinions? -- Chris Lalancette
On Fri, Aug 07, 2009 at 01:57:34PM +0200, Chris Lalancette wrote:
Anton Protopopov wrote:
Hi.
Libvirt tryes to extract kvm version from the string "QEMU PC emulator version <major>.<minor>.<micro> (kvm-<version>)..." For examle, # kvm -help | head -1 QEMU PC emulator version 0.10.0 (kvm-85), Copyright (c) 2003-2008 Fabrice Bellard
The problem occures if you are trying to run it on the devel version of kvm: # kvm -help | head -1 QEMU PC emulator version 0.10.0 (kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard The virParseNumber() obvioulsy fails on the "devel" string here. I propose to setup `kvm_version' to 1000 (that's enough, I think) in that case, so all checks, such as if (kvm_version > 74) ... will pass.
Yeah, I've run into this too. The problem with just setting kvm_version to a huge number is that if you built a kvm development snapshot a long time in the past, and you run it now, then you will be turning on features your old development snapshot didn't necessarily have. On the other hand, if you are running development snapshots, you get to keep both pieces when things break. Maybe we can set the kvm_version number very high like you say, but also dump a warning message out to the logfile saying this is a development version so the poor sap who has to debug something like this has a fighting chance. Any other opinions?
Fix kvm to include a relevant version number instead of just the 'devel' eg, Instead of QEMU PC emulator version 0.10.0 (kvm-devel), Copyright (c) 2003-2008 have QEMU PC emulator version 0.10.0 (kvm-85-devel), Copyright (c) 2003-2008 So that its clear this development release, is the one immediately following on from the kvm-85 stable release. That would let us automatically enable the features upto & including kvm-85 which would at least make it functional, albeit without letting us use the new features. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Daniel P. Berrange wrote:
Fix kvm to include a relevant version number instead of just the 'devel'
eg, Instead of
QEMU PC emulator version 0.10.0 (kvm-devel), Copyright (c) 2003-2008
have
QEMU PC emulator version 0.10.0 (kvm-85-devel), Copyright (c) 2003-2008
So that its clear this development release, is the one immediately following on from the kvm-85 stable release. That would let us automatically enable the features upto & including kvm-85 which would at least make it functional, albeit without letting us use the new features.
Yeah, not a bad idea. It's easy enough to force this on your own personal builds by doing $ echo kvm-89 > KVM_VERSION at the top-level of your qemu-kvm directory before you build. However, it would be nice if it was the default; I'll propose it on kvm-devel. -- Chris Lalancette
Daniel P. Berrange schrieb:
Fix kvm to include a relevant version number instead of just the 'devel' eg, Instead of
QEMU PC emulator version 0.10.0 (kvm-devel), Copyright (c) 2003-2008
have
QEMU PC emulator version 0.10.0 (kvm-85-devel), Copyright (c) 2003-2008
So that its clear this development release, is the one immediately following on from the kvm-85 stable release. That would let us automatically enable the features upto & including kvm-85 which would at least make it functional, albeit without letting us use the new features.
Daniel
For me a kvm-85-devel would be a development-build prior to releasing kvm-85. If the kvm-85-devel would go public the *-devel annex had simply to be removed. But that is a philosophical argument. Gerrit.
Gerrit Slomma wrote:
For me a kvm-85-devel would be a development-build prior to releasing kvm-85. If the kvm-85-devel would go public the *-devel annex had simply to be removed. But that is a philosophical argument.
Right. I really don't actually care either way, we just need a way to distinguish which version of -devel we are actually looking at. -- Chris Lalancette
On Sat, Aug 08, 2009 at 01:20:19AM +0200, Gerrit Slomma wrote:
Daniel P. Berrange schrieb:
Fix kvm to include a relevant version number instead of just the 'devel' eg, Instead of
QEMU PC emulator version 0.10.0 (kvm-devel), Copyright (c) 2003-2008
have
QEMU PC emulator version 0.10.0 (kvm-85-devel), Copyright (c) 2003-2008
So that its clear this development release, is the one immediately following on from the kvm-85 stable release. That would let us automatically enable the features upto & including kvm-85 which would at least make it functional, albeit without letting us use the new features.
Daniel
For me a kvm-85-devel would be a development-build prior to releasing kvm-85. If the kvm-85-devel would go public the *-devel annex had simply to be removed. But that is a philosophical argument.
That won't work, because libvirt needs to enable the minimum number of features guarenteed to work with the binary. If you increment the version number first then each new feature added to libvirt+kvm devel trees will immediately break compatability with older devel trees. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Fri, 2009-08-07 at 13:02 +0100, Daniel P. Berrange wrote:
On Fri, Aug 07, 2009 at 01:57:34PM +0200, Chris Lalancette wrote:
Anton Protopopov wrote:
Hi.
Libvirt tryes to extract kvm version from the string "QEMU PC emulator version <major>.<minor>.<micro> (kvm-<version>)..." For examle, # kvm -help | head -1 QEMU PC emulator version 0.10.0 (kvm-85), Copyright (c) 2003-2008 Fabrice Bellard
The problem occures if you are trying to run it on the devel version of kvm: # kvm -help | head -1 QEMU PC emulator version 0.10.0 (kvm-devel), Copyright (c) 2003-2008 Fabrice Bellard The virParseNumber() obvioulsy fails on the "devel" string here. I propose to setup `kvm_version' to 1000 (that's enough, I think) in that case, so all checks, such as if (kvm_version > 74) ... will pass.
Yeah, I've run into this too. The problem with just setting kvm_version to a huge number is that if you built a kvm development snapshot a long time in the past, and you run it now, then you will be turning on features your old development snapshot didn't necessarily have. On the other hand, if you are running development snapshots, you get to keep both pieces when things break. Maybe we can set the kvm_version number very high like you say, but also dump a warning message out to the logfile saying this is a development version so the poor sap who has to debug something like this has a fighting chance. Any other opinions?
Fix kvm to include a relevant version number instead of just the 'devel'
eg, Instead of
QEMU PC emulator version 0.10.0 (kvm-devel), Copyright (c) 2003-2008
have
QEMU PC emulator version 0.10.0 (kvm-85-devel), Copyright (c) 2003-2008
So that its clear this development release, is the one immediately following on from the kvm-85 stable release. That would let us automatically enable the features upto & including kvm-85 which would at least make it functional, albeit without letting us use the new features.
kvm_version shouldn't be needed for newer versions of qemu-kvm - we should just use the qemu version to detect new features. i.e. we only need to be able to parse kvm_version for older releases; for newer releases we just need to be able to detect the qemu version and whether it's upstream qemu or the kvm fork of qemu. That's why we do: if (STRPREFIX(p, QEMU_KVM_VER_PREFIX)) { *is_kvm = 1; p += strlen(QEMU_KVM_VER_PREFIX); } we don't actually parse the number because, for kvm-86 an later, we don't actually care about the kvm version number. I've just sent a patch to kvm@vger to change the default version string from 'kvm-devel' to 'qemu-kvm-devel'. That's enough to fix the problem for us. Cheers, Mark.
participants (5)
-
Anton Protopopov -
Chris Lalancette -
Daniel P. Berrange -
Gerrit Slomma -
Mark McLoughlin