can we hope a stable version in the near future?
hi,
i've to repeat myself old mail again:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/18095
i see there is a lots of development in kvm lately. there are many people working on many thing, but most of them improvements and extensions. and those who read the list can see there are many basic problems too. rhel/centos-5 host can't boot mandrake-10 guest, fedora latest kernel guest, rhel/centos-5 x86-64 guest crash during boot, 100%cpu usage, rhes-4 can't boot etc.
so imho it'd be useful to release a kvm version which fix all known bug and may be start a new branch for development asap.
how long do you plan to keep kvm in a development stage without a stable release?
i know it'll be a bit complicated to maintain 4 different tree (devel, stable x kernel, userspace), but it'd be very useful from the user's point of view.
just my 2c:-(
Signature · 1 line
Levente "Si vis pacem para bellum!"
I think that's one of the things that distro's are good for.
Quoted 26 lines · Farkas Levente
hi,
i've to repeat myself old mail again:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/18095i see there is a lots of development in kvm lately. there are many people working on many thing, but most of them improvements and extensions. and those who read the list can see there are many basic problems too. rhel/centos-5 host can't boot mandrake-10 guest, fedora latest kernel guest, rhel/centos-5 x86-64 guest crash during boot, 100%cpu usage, rhes-4 can't boot etc.
so imho it'd be useful to release a kvm version which fix all known bug and may be start a new branch for development asap.
how long do you plan to keep kvm in a development stage without a stable release?
i know it'll be a bit complicated to maintain 4 different tree (devel, stable x kernel, userspace), but it'd be very useful from the user's point of view.just my 2c:-(
Signature · 5 lines
Levente "Si vis pacem para bellum!" -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 4 lines · Farkas Levente
hi,
i've to repeat myself old mail again:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/18095
Quoted 14 lines
i see there is a lots of development in kvm lately. there are many people working on many thing, but most of them improvements and extensions. and those who read the list can see there are many basic problems too. rhel/centos-5 host can't boot mandrake-10 guest, fedora latest kernel guest, rhel/centos-5 x86-64 guest crash during boot, 100%cpu usage, rhes-4 can't boot etc.
so imho it'd be useful to release a kvm version which fix all known bug and may be start a new branch for development asap.
how long do you plan to keep kvm in a development stage without a stable release?
i know it'll be a bit complicated to maintain 4 different tree (devel, stable x kernel, userspace), but it'd be very useful from the user's point of view.
There is the maint/ series on git.kernel.org. It doesn't have formal releases though.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 20 lines · Avi Kivity
Quoted 4 lines · Farkas Levente
hi,
i've to repeat myself old mail again:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/18095Quoted 14 lines
i see there is a lots of development in kvm lately. there are many people working on many thing, but most of them improvements and extensions. and those who read the list can see there are many basic problems too. rhel/centos-5 host can't boot mandrake-10 guest, fedora latest kernel guest, rhel/centos-5 x86-64 guest crash during boot, 100%cpu usage, rhes-4 can't boot etc.
so imho it'd be useful to release a kvm version which fix all known bug and may be start a new branch for development asap.
how long do you plan to keep kvm in a development stage without a stable release?
i know it'll be a bit complicated to maintain 4 different tree (devel, stable x kernel, userspace), but it'd be very useful from the user's point of view.
Quoted 2 lines
There is the maint/ series on git.kernel.org. It doesn't have formal releases though.
do you plan any formal release? and it'd be nice to see the relationship between the current devel tree and the stable tree to eg. last stable 0.5 current devel 0.78.
on the other hand the real question are you plan to somehow stabilize any of the following release in the near future? in the last 1.5 years we wait for this. or you currently not recommend and not plan to use kvm in production? it's also an option but would be useful to know. in this case we (and probably many others) switch to xen, virtualbox, vmware or anything else as a virtualization platform.
in short do you have any public roadmap?
the term stable means for me:
- can use on different host (at least the latest rhel (if you're at rh), fedora, ubuntu)
- can use different guests (rhel, fedora, ubuntu, mandrake, windows 2000, xp, vista)
- can use mixed i386, x86_64 host guest,
- can use smp ie. more vcpu if the host has more core.
where "use" means: install, boot, run without kernel crash and none noticeable performance drop (10-20% less relative to the host is acceptable but 50% is not).
Signature · 1 line
Levente "Si vis pacem para bellum!"
Hi,
We integrated kvm-75 in our Proxmox VE 1.0 (http://pve.proxmox.com) as this was a quite stable release. We regularly test the most common Linux Distros and Windows (32 and 64 bit, including vista, 2008, windows7 (pre-beta)).
76 and 77 got some issues with 64-bit windows, but they seemed fixed in 78. We got a fast growing user base (see http://www.proxmox.com/forum/forumdisplay.php?f=11). So if you go for Proxmox VE you have a good change you get a tested and quite reliable KVM platform now and in future.
We did already migrations projects from VMware, XEN and others to Proxmox VE, including production MS Exchange 2003 servers with very good results.
Best Regards,
Martin Maurer
[email protected]
http://www.proxmox.com
____________________________________________________________________
Proxmox Server Solutions GmbH
Kohlgasse 51/10, 1050 Vienna, Austria
Phone: +43 1 545 4497 11 Fax: +43 1 545 4497 22
Commercial register no.: FN 258879 f
Registration office: Handelsgericht Wien
Quoted 33 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Farkas Levente
Sent: Sonntag, 09. November 2008 22:13
To: KVM
Subject: can we hope a stable version in the near future?hi,
i've to repeat myself old mail again:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/18095i see there is a lots of development in kvm lately. there are many people working on many thing, but most of them improvements and extensions. and those who read the list can see there are many basic problems too. rhel/centos-5 host can't boot mandrake-10 guest, fedora latest kernel guest, rhel/centos-5 x86-64 guest crash during boot, 100%cpu usage, rhes-4 can't boot etc.
so imho it'd be useful to release a kvm version which fix all known bug and may be start a new branch for development asap.
how long do you plan to keep kvm in a development stage without a stable release?
i know it'll be a bit complicated to maintain 4 different tree (devel, stable x kernel, userspace), but it'd be very useful from the user's point of view.just my 2c:-(
--
Levente "Si vis pacem para bellum!"
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 4 lines · Martin Maurer
Hi,
We integrated kvm-75 in our Proxmox VE 1.0 (http://pve.proxmox.com) as this was a quite stable release. We regularly test the most common Linux Distros and Windows (32 and 64 bit, including vista, 2008, windows7 (pre-beta)).
mandrake-10 can't boot on anything later then kvm-71:-(
Quoted 1 line
76 and 77 got some issues with 64-bit windows, but they seemed fixed in 78. We got a fast growing user base (see http://www.proxmox.com/forum/forumdisplay.php?f=11). So if you go for Proxmox VE you have a good change you get a tested and quite reliable KVM platform now and in future.
fedora's latest kernel can't boot on 77 and 78 and see my other notes.
Quoted 51 lines
We did already migrations projects from VMware, XEN and others to Proxmox VE, including production MS Exchange 2003 servers with very good results.
Best Regards,
Martin Maurer
[email protected]
http://www.proxmox.com____________________________________________________________________
Proxmox Server Solutions GmbH
Kohlgasse 51/10, 1050 Vienna, Austria
Phone: +43 1 545 4497 11 Fax: +43 1 545 4497 22
Commercial register no.: FN 258879 f
Registration office: Handelsgericht WienQuoted 33 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Farkas Levente
Sent: Sonntag, 09. November 2008 22:13
To: KVM
Subject: can we hope a stable version in the near future?hi,
i've to repeat myself old mail again:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/18095i see there is a lots of development in kvm lately. there are many people working on many thing, but most of them improvements and extensions. and those who read the list can see there are many basic problems too. rhel/centos-5 host can't boot mandrake-10 guest, fedora latest kernel guest, rhel/centos-5 x86-64 guest crash during boot, 100%cpu usage, rhes-4 can't boot etc.
so imho it'd be useful to release a kvm version which fix all known bug and may be start a new branch for development asap.
how long do you plan to keep kvm in a development stage without a stable release?
i know it'll be a bit complicated to maintain 4 different tree (devel, stable x kernel, userspace), but it'd be very useful from the user's point of view.just my 2c:-(
--
Levente "Si vis pacem para bellum!"
--
To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Signature · 1 line
Levente "Si vis pacem para bellum!"
Quoted 8 lines · Farkas Levente
Quoted 3 lines
There is the maint/ series on git.kernel.org. It doesn't have formal releases though.
do you plan any formal release? and it'd be nice to see the relationship between the current devel tree and the stable tree to eg. last stable 0.5 current devel 0.78.
The key to a formal release is a formal test suite. We've been building one (for a long while) but it isn't in production yet.
The plan is for it to be open so people can add their favorite guests, to ensure they will not regress.
Quoted 7 lines
on the other hand the real question are you plan to somehow stabilize any of the following release in the near future? in the last 1.5 years we wait for this. or you currently not recommend and not plan to use kvm in production? it's also an option but would be useful to know. in this case we (and probably many others) switch to xen, virtualbox, vmware or anything else as a virtualization platform.
kvm is used in production on several products. Just not the kvm-nn releases I make. The production versions of kvm are backed by testing, which makes all the difference. Slapping a 'stable' label over a release doesn't make it so.
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 10 lines · Avi Kivity
Quoted 8 lines · Farkas Levente
Quoted 3 lines
There is the maint/ series on git.kernel.org. It doesn't have formal releases though.
do you plan any formal release? and it'd be nice to see the relationship between the current devel tree and the stable tree to eg. last stable 0.5 current devel 0.78.
Quoted 5 lines
The key to a formal release is a formal test suite. We've been building one (for a long while) but it isn't in production yet.
The plan is for it to be open so people can add their favorite guests, to ensure they will not regress.
the question is not when but what happened with those bugs which cause test fail? the problem currently not that we don't know problems, but there are many known bugs just the reason and the solution not known. so
test suite can't help too much here (may be find more bugs).
Quoted 8 lines
Quoted 7 lines
on the other hand the real question are you plan to somehow stabilize any of the following release in the near future? in the last 1.5 years we wait for this. or you currently not recommend and not plan to use kvm in production? it's also an option but would be useful to know. in this case we (and probably many others) switch to xen, virtualbox, vmware or anything else as a virtualization platform.
Quoted 4 lines
kvm is used in production on several products. Just not the kvm-nn releases I make. The production versions of kvm are backed by testing, which makes all the difference. Slapping a 'stable' label over a release doesn't make it so.
there are many open source project which has stable and devel versions:-) actually almost all projects have a stable release along with the devel version. but kvm has not any in the last few years, that's why i think it's high time to stabilize 'a' version ie. frozen feature list and fix all known bugs.
Signature · 1 line
Levente "Si vis pacem para bellum!"
Quoted 16 lines · Farkas Levente
Quoted 14 lines · Avi Kivity
Quoted 9 lines · Farkas Levente
Quoted 4 lines
There is the maint/ series on git.kernel.org. It doesn't have formal releases though.
do you plan any formal release? and it'd be nice to see the relationship between the current devel tree and the stable tree to eg. last stable 0.5 current devel 0.78.
The key to a formal release is a formal test suite. We've been building one (for a long while) but it isn't in production yet.
Quoted 10 lines
Quoted 3 lines
The plan is for it to be open so people can add their favorite guests, to ensure they will not regress.
the question is not when but what happened with those bugs which cause test fail? the problem currently not that we don't know problems, but there are many known bugs just the reason and the solution not known. so
test suite can't help too much here (may be find more bugs).
Test suite will help since it's job is to run regression tests each night or even each commit. Once a new regression is introduced it will immediately revert it.
Now, when we have only very poor, old regression suite, it does not happen so regressions are detected by users, weeks after being committed.
We'll publish the test suite (based on autotest) next week. The more users will use it the better. Anyway our maintainer will run it each night.
Quoted 14 lines
Quoted 8 lines
Quoted 8 lines
on the other hand the real question are you plan to somehow stabilize any of the following release in the near future? in the last 1.5 years we wait for this. or you currently not recommend and not plan to use kvm in production? it's also an option but would be useful to know. in this case we (and probably many others) switch to xen, virtualbox, vmware or anything else as a virtualization platform.
Quoted 5 lines
kvm is used in production on several products. Just not the kvm-nn releases I make. The production versions of kvm are backed by testing, which makes all the difference. Slapping a 'stable' label over a release doesn't make it so.
Quoted 6 lines
there are many open source project which has stable and devel versions:-) actually almost all projects have a stable release along with the devel version. but kvm has not any in the last few years, that's why i think it's high time to stabilize 'a' version ie. frozen feature list and fix all known bugs.
You're right about the need for stable release, that's the idea of the 'maint' branches. maint/2.6.26 for both kernel and userspace is stable (using userspace irqchip). Now we'll stabilize another user/kernel pair based on 2.6.28
Thanks, Dor
Quoted 20 lines · Dor Laor
Quoted 14 lines
Quoted 8 lines
Quoted 8 lines
on the other hand the real question are you plan to somehow stabilize any of the following release in the near future? in the last 1.5 years we wait for this. or you currently not recommend and not plan to use kvm
in production? it's also an option but would be useful to know. in this case we (and probably many others) switch to xen, virtualbox, vmware or anything else as a virtualization platform.Quoted 5 lines
kvm is used in production on several products. Just not the kvm-nn releases I make. The production versions of kvm are backed by testing, which makes all the difference. Slapping a 'stable' label over a release doesn't make it so.
Quoted 6 lines
there are many open source project which has stable and devel versions:-) actually almost all projects have a stable release along with the devel version. but kvm has not any in the last few years, that's why i think it's high time to stabilize 'a' version ie. frozen feature list and fix all known bugs.
Quoted 5 lines
You're right about the need for stable release, that's the idea of the 'maint' branches.
maint/2.6.26 for both kernel and userspace is stable (using userspace irqchip).
Now we'll stabilize another user/kernel pair based on 2.6.28
that's a good news:-)
but does this means there will be a new kvm-x.y.z release and i can build the userspace from it _and_ build a kmod for eg. the latest rhel-5's kernel-2.6.18-92.1.18.el5? ie. i'll be able to install it on rhel-5 a kvm and kvm-kmod and it'll work? or it'll just run on the not even released 2.6.28 kernel?
and what is the relationship between maint release and kvm-nn and the next stable release?
is there a tarball for the current maint release? and the same question here can i build a kmod and userspace from that for rhel-5?
Signature · 1 line
Levente "Si vis pacem para bellum!"
Quoted 31 lines · Farkas Levente
Quoted 22 lines · Dor Laor
Quoted 15 lines
Quoted 9 lines
Quoted 9 lines
on the other hand the real question are you plan to somehow stabilize any of the following release in the near future? in the last 1.5 years we wait for this. or you currently not recommend and not plan to use kvm
in production? it's also an option but would be useful to know. in this case we (and probably many others) switch to xen, virtualbox, vmware or anything else as a virtualization platform.Quoted 6 lines
kvm is used in production on several products. Just not the kvm-nn releases I make. The production versions of kvm are backed by testing, which makes all the difference. Slapping a 'stable' label over a release doesn't make it so.
Quoted 7 lines
there are many open source project which has stable and devel versions:-) actually almost all projects have a stable release along with the devel version. but kvm has not any in the last few years, that's why i think it's high time to stabilize 'a' version ie. frozen feature list and fix all known bugs.
Quoted 6 lines
You're right about the need for stable release, that's the idea of the 'maint' branches.
maint/2.6.26 for both kernel and userspace is stable (using userspace irqchip).
Now we'll stabilize another user/kernel pair based on 2.6.28
Quoted 12 lines
that's a good news:-)
but does this means there will be a new kvm-x.y.z release and i can build the userspace from it _and_ build a kmod for eg. the latest rhel-5's kernel-2.6.18-92.1.18.el5? ie. i'll be able to install it on rhel-5 a kvm and kvm-kmod and it'll work? or it'll just run on the not even released 2.6.28 kernel?
and what is the relationship between maint release and kvm-nn and the next stable release?
is there a tarball for the current maint release? and the same question here can i build a kmod and userspace from that for rhel-5?
As always you'll have the option of using kvm as a kernel module. So even if the stable branch is based on 2.6.28, you can always take the kvm bits through 'make -C kernel sync LINUX=PATH' in the userspace.