From glommer at redhat.com Tue Feb 3 20:11:31 2009 From: glommer at redhat.com (Glauber Costa) Date: Tue, 3 Feb 2009 18:11:31 -0200 Subject: [fedora-virt] QEMU new Package Message-ID: <20090203201131.GA15314@poweredge.glommer> Hi guys. I've built a qemu image in here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 It contains the basic work to get qemu package updated. Basically, we're talking about getting the qemu code from svn and creating multiple packages, so one could grab just the architecture of interest. Todo, is the creation of a meta-package to grab'em all at once. This is also the first step in merging qemu and kvm packages, which I'd like to do in two steps. 1) This one. 2) replace qemu-svn with kvm-userspace The later is not as trivial as it seems. Nobody exercices this path usually, and we're likely to find bugs that prevent the build to finish (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have it sorted out. If no one has any major opposition to the state of things, I intend to commit it to CVS tomorrow (with some minor changes), and put it into rawhide so we can start having a more serious testing out of it. From pasik at iki.fi Tue Feb 3 20:24:47 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Tue, 3 Feb 2009 22:24:47 +0200 Subject: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages Message-ID: <20090203202447.GU15052@edu.joroinen.fi> Hello! For those interested in testing pv_ops dom0 kernels it seems latest Xen packages in rawhide contain bzImage dom0 kernel support in Xen hypervisor. rawhide report: 20090203 changes xen-3.3.1-3.fc11 ---------------- * Tue Feb 3 17:00:00 2009 Gerd Hoffmann - 3.3.1-3 - backport bzImage support for dom0 builder. -- Pasi From berrange at redhat.com Tue Feb 3 21:58:59 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 3 Feb 2009 21:58:59 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090203201131.GA15314@poweredge.glommer> References: <20090203201131.GA15314@poweredge.glommer> Message-ID: <20090203215859.GC9735@redhat.com> On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote: > Hi guys. > > I've built a qemu image in here: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > It contains the basic work to get qemu package updated. Basically, > we're talking about getting the qemu code from svn and creating multiple > packages, so one could grab just the architecture of interest. > Todo, is the creation of a meta-package to grab'em all at once. > > This is also the first step in merging qemu and kvm packages, which > I'd like to do in two steps. > > 1) This one. > 2) replace qemu-svn with kvm-userspace > > The later is not as trivial as it seems. Nobody exercices this path > usually, and we're likely to find bugs that prevent the build to finish > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have > it sorted out. > > If no one has any major opposition to the state of things, I intend to > commit it to CVS tomorrow (with some minor changes), and put it into > rawhide so we can start having a more serious testing out of it. Has anyone discussed with the upstream QEMU developers about doing a new release. I've seen no such discussions on the public qemu-devel list. If QEMU guys are planning a new release soon, then we'd have no need for a CVS snapshot, or at least confidence that QEMU guys consider it geting stable enough that a release is viable. If the QEMU devs don't consider a new release viable I'd like to know why they think this, *before* we subject Fedora users to a CVS snapshot. 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 :| From markmc at redhat.com Tue Feb 3 22:08:03 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 03 Feb 2009 22:08:03 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090203215859.GC9735@redhat.com> References: <20090203201131.GA15314@poweredge.glommer> <20090203215859.GC9735@redhat.com> Message-ID: <1233698883.25222.2.camel@blaa> On Tue, 2009-02-03 at 21:58 +0000, Daniel P. Berrange wrote: > On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote: > > Hi guys. > > > > I've built a qemu image in here: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > It contains the basic work to get qemu package updated. Basically, > > we're talking about getting the qemu code from svn and creating multiple > > packages, so one could grab just the architecture of interest. > > Todo, is the creation of a meta-package to grab'em all at once. > > > > This is also the first step in merging qemu and kvm packages, which > > I'd like to do in two steps. > > > > 1) This one. > > 2) replace qemu-svn with kvm-userspace > > > > The later is not as trivial as it seems. Nobody exercices this path > > usually, and we're likely to find bugs that prevent the build to finish > > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have > > it sorted out. > > > > If no one has any major opposition to the state of things, I intend to > > commit it to CVS tomorrow (with some minor changes), and put it into > > rawhide so we can start having a more serious testing out of it. > > Has anyone discussed with the upstream QEMU developers about doing a > new release. I've seen no such discussions on the public qemu-devel > list. If QEMU guys are planning a new release soon, then we'd have > no need for a CVS snapshot, or at least confidence that QEMU guys > consider it geting stable enough that a release is viable. If the > QEMU devs don't consider a new release viable I'd like to know why > they think this, *before* we subject Fedora users to a CVS snapshot. Yep, see: http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00138.html Given that plan, pulling in svn snapshots is similar to pulling in release candidates from upstreams that do release candidates. Cheers, Mark. From berrange at redhat.com Tue Feb 3 22:10:05 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 3 Feb 2009 22:10:05 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <1233698883.25222.2.camel@blaa> References: <20090203201131.GA15314@poweredge.glommer> <20090203215859.GC9735@redhat.com> <1233698883.25222.2.camel@blaa> Message-ID: <20090203221005.GE9735@redhat.com> On Tue, Feb 03, 2009 at 10:08:03PM +0000, Mark McLoughlin wrote: > On Tue, 2009-02-03 at 21:58 +0000, Daniel P. Berrange wrote: > > On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote: > > > Hi guys. > > > > > > I've built a qemu image in here: > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > > > It contains the basic work to get qemu package updated. Basically, > > > we're talking about getting the qemu code from svn and creating multiple > > > packages, so one could grab just the architecture of interest. > > > Todo, is the creation of a meta-package to grab'em all at once. > > > > > > This is also the first step in merging qemu and kvm packages, which > > > I'd like to do in two steps. > > > > > > 1) This one. > > > 2) replace qemu-svn with kvm-userspace > > > > > > The later is not as trivial as it seems. Nobody exercices this path > > > usually, and we're likely to find bugs that prevent the build to finish > > > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have > > > it sorted out. > > > > > > If no one has any major opposition to the state of things, I intend to > > > commit it to CVS tomorrow (with some minor changes), and put it into > > > rawhide so we can start having a more serious testing out of it. > > > > Has anyone discussed with the upstream QEMU developers about doing a > > new release. I've seen no such discussions on the public qemu-devel > > list. If QEMU guys are planning a new release soon, then we'd have > > no need for a CVS snapshot, or at least confidence that QEMU guys > > consider it geting stable enough that a release is viable. If the > > QEMU devs don't consider a new release viable I'd like to know why > > they think this, *before* we subject Fedora users to a CVS snapshot. > > Yep, see: > > http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00138.html > > Given that plan, pulling in svn snapshots is similar to pulling in > release candidates from upstreams that do release candidates. Lucky timing ! Reaction so far from QEMU upstream seems fairly positive, so testing the SVN snapshot in rawhide leading upto the release would be reasonable, particularly as he proposed date of end of month would fit in with F11 freeze reasonably well. 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 :| From markmc at redhat.com Tue Feb 3 22:34:12 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Tue, 03 Feb 2009 22:34:12 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090203201131.GA15314@poweredge.glommer> References: <20090203201131.GA15314@poweredge.glommer> Message-ID: <1233700452.25222.18.camel@blaa> (cc-ed a few people who were interested on irc) On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote: > Hi guys. > > I've built a qemu image in here: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > It contains the basic work to get qemu package updated. Basically, > we're talking about getting the qemu code from svn and creating multiple > packages, so one could grab just the architecture of interest. > Todo, is the creation of a meta-package to grab'em all at once. Okay, so this adds ~30 sub-packages. In retrospect, maybe ajax and co. have a point saying that's a bit excessive :-) One downside to so many sub-packages is that it means the total size of the RPMs is ~15Mb instead of ~10Mb. The on-disk size of the current qemu package is ~50Mb. What most people care about is /usr/bin/qemu (and in future qemu-kvm). Those bits only have a ~3Mb on-disk size. Each other target adds ~1.5Mb. How about splitting it this way: qemu: - /usr/bin/qemu - /usr/bin/qemu-system-x86_64 (only on x86_64, obviously) - qemu-kvm - qemu-nbd - docs - BIOSes - keymaps - init script qemu-img - /usr/bin/qemu-img qemu-system: - qemu-system-arm - qemu-system-cris - qemu-system-i386 - qemu-system-m68k - qemu-system-mips - qemu-system-mips64 - qemu-system-mips64el - qemu-system-mipsel - qemu-system-ppc - qemu-system-ppc64 - qemu-system-ppcemb - qemu-system-sh4 - qemu-system-sh4eb - qemu-system-sparc qemu-linux: - qemu-alpha - qemu-arm - qemu-armeb - qemu-cris - qemu-debuginfo - qemu-i386 - qemu-m68k - qemu-mips - qemu-mipsel - qemu-ppc - qemu-ppc64 - qemu-ppc64abi32 - qemu-sh4 - qemu-sh4eb - qemu-sparc - qemu-sparc32plus - qemu-sparc64 - qemu-x86_64 One thing I don't like too much about that is if you do a yum update from the current package you lose all the stuff in qemu-system and qemu-linux. I doubt that would cause anyone trouble in practice, though. Cheers, Mark. From berrange at redhat.com Tue Feb 3 22:44:39 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 3 Feb 2009 22:44:39 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <1233700452.25222.18.camel@blaa> References: <20090203201131.GA15314@poweredge.glommer> <1233700452.25222.18.camel@blaa> Message-ID: <20090203224439.GI9735@redhat.com> On Tue, Feb 03, 2009 at 10:34:12PM +0000, Mark McLoughlin wrote: > (cc-ed a few people who were interested on irc) > > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote: > > Hi guys. > > > > I've built a qemu image in here: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > It contains the basic work to get qemu package updated. Basically, > > we're talking about getting the qemu code from svn and creating multiple > > packages, so one could grab just the architecture of interest. > > Todo, is the creation of a meta-package to grab'em all at once. > > Okay, so this adds ~30 sub-packages. In retrospect, maybe ajax and co. > have a point saying that's a bit excessive :-) > > One downside to so many sub-packages is that it means the total size of > the RPMs is ~15Mb instead of ~10Mb. > > The on-disk size of the current qemu package is ~50Mb. What most people > care about is /usr/bin/qemu (and in future qemu-kvm). Those bits only > have a ~3Mb on-disk size. Each other target adds ~1.5Mb. > > How about splitting it this way: > > qemu: > - /usr/bin/qemu > - /usr/bin/qemu-system-x86_64 (only on x86_64, obviously) Err, qemu-system-x86_64 exists just fine on 32-bit hosts. > - qemu-kvm This should go away altogether I hope. Until it does, just keeping it whereever the x86 emulators are should be fine. > - qemu-nbd This one should be separate, since it is generally useful even without any of the emulators - eg by Xen, or anyone else wishing a nbd client for disk images. > - docs > - BIOSes > - keymaps > - init script > > qemu-img > - /usr/bin/qemu-img > > qemu-system: > > - qemu-system-arm > - qemu-system-cris > - qemu-system-i386 What's this for ? 'qemu' is always i386, and that shouldn;t be changed because far too much assumes 'qemu' is always the i386 binary. > - qemu-system-m68k > - qemu-system-mips > - qemu-system-mips64 > - qemu-system-mips64el > - qemu-system-mipsel > - qemu-system-ppc > - qemu-system-ppc64 > - qemu-system-ppcemb > - qemu-system-sh4 > - qemu-system-sh4eb > - qemu-system-sparc Why not group them into related sets. eg, all PPC variants in one package, all the 'sh' variants, and all the 'mips' variants, and all x86 variants. That'd compress the # of sub-RPMS to a small handful qemu-system-x86 qemu-system-mips qemu-system-sh qemu-system-ppc qemu-system-sparc qemu-system-68k > qemu-linux: > > - qemu-alpha > - qemu-arm > - qemu-armeb > - qemu-cris > - qemu-debuginfo > - qemu-i386 > - qemu-m68k > - qemu-mips > - qemu-mipsel > - qemu-ppc > - qemu-ppc64 > - qemu-ppc64abi32 > - qemu-sh4 > - qemu-sh4eb > - qemu-sparc > - qemu-sparc32plus > - qemu-sparc64 > - qemu-x86_64 This seems reasonable - judging by how broken most of these are, I find it hard to believe they're used much, so having them in one sub-RPM ought to be fine. > One thing I don't like too much about that is if you do a yum update > from the current package you lose all the stuff in qemu-system and > qemu-linux. I doubt that would cause anyone trouble in practice, though. Just keep 'qemu' as a meta-package pulling in all the sub-RPMs. People who only want the x86 bits will probably going from a starting point of having the 'kvm' RPM installed. If we make system-system-x86 sub-RPM replace+obsolete 'kvm', then updates from people who just have KVM will keep a lightweight install, and those who have the full QEMU stack will not be broken either. 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 :| From berrange at redhat.com Tue Feb 3 22:53:47 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 3 Feb 2009 22:53:47 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090203201131.GA15314@poweredge.glommer> References: <20090203201131.GA15314@poweredge.glommer> Message-ID: <20090203225347.GJ9735@redhat.com> On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote: > Hi guys. > > I've built a qemu image in here: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > It contains the basic work to get qemu package updated. Basically, > we're talking about getting the qemu code from svn and creating multiple > packages, so one could grab just the architecture of interest. > Todo, is the creation of a meta-package to grab'em all at once. > > This is also the first step in merging qemu and kvm packages, which > I'd like to do in two steps. > > 1) This one. > 2) replace qemu-svn with kvm-userspace > > The later is not as trivial as it seems. Nobody exercices this path > usually, and we're likely to find bugs that prevent the build to finish > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have > it sorted out. > > If no one has any major opposition to the state of things, I intend to > commit it to CVS tomorrow (with some minor changes), and put it into > rawhide so we can start having a more serious testing out of it. The major blocker here is that it breaks upgrades. ie, upgrade to F11 and you end up with an install with no emulators present. 'qemu' should stay as a package which pulls in everything - by Requires on all the sub-RPMs. I agree with mark that there are too many sub-RPMs here. I think we should group related archs, so that all x86 related system emulators are in one sub-RPM, all mips together, all sh together, etc Also, the /etc/init.d/qemu script will need updating to take account of the fact that not all usermode emulators will be present - it should only register binary format handlers for those which are actually installed. Also, you'll need to have the keymap files in a sub-RPM that all the qemu-system-X packages can depend on, since the keymap data files are needed for all the binaries which support SDL & VNC. 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 :| From dlbewley at lib.ucdavis.edu Wed Feb 4 00:18:14 2009 From: dlbewley at lib.ucdavis.edu (Dale Bewley) Date: Tue, 03 Feb 2009 16:18:14 -0800 Subject: [fedora-virt] F11 features - sVirt Mandatory Access Control In-Reply-To: <1233319365.3989.79.camel@blaa> References: <1232625199.4964.35.camel@blaa> <1233319365.3989.79.camel@blaa> Message-ID: <1233706694.11724.28.camel@tofu.lib.ucdavis.edu> On Fri, 2009-01-30 at 12:42 +0000, Mark McLoughlin wrote: > Hey, > Yet another feature page: > > https://fedoraproject.org/wiki/SVirt_Mandatory_Access_Control I've just begun to work on the F11 release notes here: http://fedoraproject.org/wiki/Documentation_Virtualization_Beat -- Dale Bewley - Unix Administrator - Shields Library - UC Davis GPG: 0xB098A0F3 0D5A 9AEB 43F4 F84C 7EFD 1753 064D 2583 B098 A0F3 From markmc at redhat.com Wed Feb 4 07:30:51 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 04 Feb 2009 07:30:51 +0000 Subject: [fedora-virt] F11 features - sVirt Mandatory Access Control In-Reply-To: <1233706694.11724.28.camel@tofu.lib.ucdavis.edu> References: <1232625199.4964.35.camel@blaa> <1233319365.3989.79.camel@blaa> <1233706694.11724.28.camel@tofu.lib.ucdavis.edu> Message-ID: <1233732651.4137.13.camel@blaa> Hi Dale, On Tue, 2009-02-03 at 16:18 -0800, Dale Bewley wrote: > On Fri, 2009-01-30 at 12:42 +0000, Mark McLoughlin wrote: > > Hey, > > Yet another feature page: > > > > https://fedoraproject.org/wiki/SVirt_Mandatory_Access_Control > > I've just begun to work on the F11 release notes here: > > http://fedoraproject.org/wiki/Documentation_Virtualization_Beat Nice work :-) One thing that's missing is a "new features and improvements" for KVM - both the kvm package, and the kvm support in the kernel. Thanks, Mark, From markmc at redhat.com Wed Feb 4 08:41:56 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 04 Feb 2009 08:41:56 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090203224439.GI9735@redhat.com> References: <20090203201131.GA15314@poweredge.glommer> <1233700452.25222.18.camel@blaa> <20090203224439.GI9735@redhat.com> Message-ID: <1233736916.4137.45.camel@blaa> On Tue, 2009-02-03 at 22:44 +0000, Daniel P. Berrange wrote: > On Tue, Feb 03, 2009 at 10:34:12PM +0000, Mark McLoughlin wrote: > > (cc-ed a few people who were interested on irc) > > > > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote: > > > Hi guys. > > > > > > I've built a qemu image in here: > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > > > It contains the basic work to get qemu package updated. Basically, > > > we're talking about getting the qemu code from svn and creating multiple > > > packages, so one could grab just the architecture of interest. > > > Todo, is the creation of a meta-package to grab'em all at once. > > > > Okay, so this adds ~30 sub-packages. In retrospect, maybe ajax and co. > > have a point saying that's a bit excessive :-) > > > > One downside to so many sub-packages is that it means the total size of > > the RPMs is ~15Mb instead of ~10Mb. > > > > The on-disk size of the current qemu package is ~50Mb. What most people > > care about is /usr/bin/qemu (and in future qemu-kvm). Those bits only > > have a ~3Mb on-disk size. Each other target adds ~1.5Mb. > > > > How about splitting it this way: > > > > qemu: > > - /usr/bin/qemu > > - /usr/bin/qemu-system-x86_64 (only on x86_64, obviously) > > Err, qemu-system-x86_64 exists just fine on 32-bit hosts. Yeah, what I was getting at was that the qemu package would only contain an emulator for the native architecture. So, qemu wouldn't contain the x86_64 emulator on 32 bit. That was when I thought /usr/bin/qemu was just a hardlink to the native system emulator. Now that I see that /usr/bin/qemu is always i386 (even on e.g. ppc), I don't like this idea of the base package containing just the native emulator so much anymore. > > - qemu-kvm > > This should go away altogether I hope. Until it does, just > keeping it whereever the x86 emulators are should be fine. Yep. > > - qemu-nbd > > This one should be separate, since it is generally useful > even without any of the emulators - eg by Xen, or anyone > else wishing a nbd client for disk images. Agree, but I'd be inclined not to bother until someone actually wants it. > > - docs > > - BIOSes > > - keymaps > > - init script > > > > qemu-img > > - /usr/bin/qemu-img > > > > qemu-system: > > > > - qemu-system-arm > > - qemu-system-cris > > - qemu-system-i386 > > What's this for ? 'qemu' is always i386, and that shouldn;t > be changed because far too much assumes 'qemu' is always the > i386 binary. Right, my mistake - the name was just taken from glommer's proposed qemu-system-i386 package which would contain /usr/bin/qemu. > > - qemu-system-m68k > > - qemu-system-mips > > - qemu-system-mips64 > > - qemu-system-mips64el > > - qemu-system-mipsel > > - qemu-system-ppc > > - qemu-system-ppc64 > > - qemu-system-ppcemb > > - qemu-system-sh4 > > - qemu-system-sh4eb > > - qemu-system-sparc > > Why not group them into related sets. eg, all PPC > variants in one package, all the 'sh' variants, > and all the 'mips' variants, and all x86 variants. > That'd compress the # of sub-RPMS to a small handful > > qemu-system-x86 > qemu-system-mips > qemu-system-sh > qemu-system-ppc > qemu-system-sparc > qemu-system-68k Sounds reasonable enough. > > qemu-linux: > > > > - qemu-alpha > > - qemu-arm > > - qemu-armeb > > - qemu-cris > > - qemu-debuginfo > > - qemu-i386 > > - qemu-m68k > > - qemu-mips > > - qemu-mipsel > > - qemu-ppc > > - qemu-ppc64 > > - qemu-ppc64abi32 > > - qemu-sh4 > > - qemu-sh4eb > > - qemu-sparc > > - qemu-sparc32plus > > - qemu-sparc64 > > - qemu-x86_64 > > This seems reasonable - judging by how broken most of these > are, I find it hard to believe they're used much, so having > them in one sub-RPM ought to be fine. > > > One thing I don't like too much about that is if you do a yum update > > from the current package you lose all the stuff in qemu-system and > > qemu-linux. I doubt that would cause anyone trouble in practice, though. > > Just keep 'qemu' as a meta-package pulling in all the sub-RPMs. > > People who only want the x86 bits will probably going from a starting > point of having the 'kvm' RPM installed. If we make system-system-x86 > sub-RPM replace+obsolete 'kvm', then updates from people who just have > KVM will keep a lightweight install, and those who have the full QEMU > stack will not be broken either. Yeah, sounds good. So, in summary: qemu-img - /usr/bin/qemu-img qemu-common: - /usr/bin/qemu-nbd - docs - BIOSes - keymaps - init script qemu-system-x86: - /usr/bin/qemu - qemu-system-x86_64 - /usr/bin/qemu-kvm qemu-system-arm: - qemu-system-arm qemu-system-cris: - qemu-system-cris qemu-system-m68k - qemu-system-m68k qemu-system-mips - qemu-system-mips - qemu-system-mips64 - qemu-system-mips64el - qemu-system-mipsel qemu-system-ppc - qemu-system-ppc - qemu-system-ppc64 - qemu-system-ppcemb qemu-system-sh - qemu-system-sh4 - qemu-system-sh4eb qemu-system-sparc - qemu-system-sparc qemu-linux: - qemu-alpha - qemu-arm - qemu-armeb - qemu-cris - qemu-debuginfo - qemu-i386 - qemu-m68k - qemu-mips - qemu-mipsel - qemu-ppc - qemu-ppc64 - qemu-ppc64abi32 - qemu-sh4 - qemu-sh4eb - qemu-sparc - qemu-sparc32plus - qemu-sparc64 - qemu-x86_64 qemu: - meta package requiring all sub-packages Cheers, Mark. From harish at redhat.com Wed Feb 4 08:49:41 2009 From: harish at redhat.com (Harish Pillay) Date: Wed, 04 Feb 2009 16:49:41 +0800 Subject: [fedora-virt] F11 features - sVirt Mandatory Access Control In-Reply-To: <1233732651.4137.13.camel@blaa> References: <1232625199.4964.35.camel@blaa> <1233319365.3989.79.camel@blaa> <1233706694.11724.28.camel@tofu.lib.ucdavis.edu> <1233732651.4137.13.camel@blaa> Message-ID: <498956A5.5000906@redhat.com> > http://fedoraproject.org/wiki/Documentation_Virtualization_Beat >From that page, it says: 'The kernel-xen package has been obsoleted by the integration of paravirtualization operations in the upstream kernel. The kernel package in Fedora 11 supports booting as a guest domU, but will not function as a dom0 until such support is provided upstream. The most recent Fedora release with dom0 support is Fedora 8.' As I write this, I am running F10 on a hardware virt enabled machine (Dell Latitude D620) and have installed F10 and other distros as guests. Hence, the statement above is unclear to me for F10 is running as both dom0 and domU. Am I not reading something right? -- Harish Pillay 9v1hp hpillay at redhat.com +65.9636.9253 gpg id: 746809E3 gpg fingerprint: F7F5 5CCD 25B9 FC25 303E 3DA2 0F80 27DB 7468 09E3 From markmc at redhat.com Wed Feb 4 09:30:34 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 04 Feb 2009 09:30:34 +0000 Subject: [fedora-virt] F11 features - sVirt Mandatory Access Control In-Reply-To: <498956A5.5000906@redhat.com> References: <1232625199.4964.35.camel@blaa> <1233319365.3989.79.camel@blaa> <1233706694.11724.28.camel@tofu.lib.ucdavis.edu> <1233732651.4137.13.camel@blaa> <498956A5.5000906@redhat.com> Message-ID: <1233739834.4137.50.camel@blaa> On Wed, 2009-02-04 at 16:49 +0800, Harish Pillay wrote: > > http://fedoraproject.org/wiki/Documentation_Virtualization_Beat > > >From that page, it says: > > 'The kernel-xen package has been obsoleted by the integration of > paravirtualization operations in the upstream kernel. The kernel package > in Fedora 11 supports booting as a guest domU, but will not function as > a dom0 until such support is provided upstream. The most recent Fedora > release with dom0 support is Fedora 8.' > > As I write this, I am running F10 on a hardware virt enabled machine > (Dell Latitude D620) and have installed F10 and other distros as guests. > Hence, the statement above is unclear to me for F10 is running as both > dom0 and domU. > > Am I not reading something right? I think you're using KVM, not Xen :-) Dom0 and DomU are only terms we use in relation to Xen - when talking about KVM, we usually use the terms "host" and "guest". The release note could be changed to "Xen Kernel Support" rather than "Unified Kernel Image" and be moved towards the end of the notes. A casual user doesn't really even need to know about KVM vs. Xen. Cheers, Mark. From berrange at redhat.com Wed Feb 4 10:49:28 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 4 Feb 2009 10:49:28 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <1233736916.4137.45.camel@blaa> References: <20090203201131.GA15314@poweredge.glommer> <1233700452.25222.18.camel@blaa> <20090203224439.GI9735@redhat.com> <1233736916.4137.45.camel@blaa> Message-ID: <20090204104928.GE7580@redhat.com> On Wed, Feb 04, 2009 at 08:41:56AM +0000, Mark McLoughlin wrote: > So, in summary: > > qemu-img > - /usr/bin/qemu-img > > qemu-common: > - /usr/bin/qemu-nbd > - docs > - BIOSes > - keymaps > - init script > > qemu-system-x86: > - /usr/bin/qemu > - qemu-system-x86_64 > - /usr/bin/qemu-kvm > > qemu-system-arm: > - qemu-system-arm > > qemu-system-cris: > - qemu-system-cris > > qemu-system-m68k > - qemu-system-m68k > > qemu-system-mips > - qemu-system-mips > - qemu-system-mips64 > - qemu-system-mips64el > - qemu-system-mipsel > > qemu-system-ppc > - qemu-system-ppc > - qemu-system-ppc64 > - qemu-system-ppcemb > > qemu-system-sh > - qemu-system-sh4 > - qemu-system-sh4eb > > qemu-system-sparc > - qemu-system-sparc > > qemu-linux: > - qemu-alpha > - qemu-arm > - qemu-armeb > - qemu-cris > - qemu-debuginfo > - qemu-i386 > - qemu-m68k > - qemu-mips > - qemu-mipsel > - qemu-ppc > - qemu-ppc64 > - qemu-ppc64abi32 > - qemu-sh4 > - qemu-sh4eb > - qemu-sparc > - qemu-sparc32plus > - qemu-sparc64 > - qemu-x86_64 > > qemu: > - meta package requiring all sub-packages ACK, this gets my vote. 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 :| From berrange at redhat.com Wed Feb 4 10:56:35 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 4 Feb 2009 10:56:35 +0000 Subject: [fedora-virt] F11 features - sVirt Mandatory Access Control In-Reply-To: <498956A5.5000906@redhat.com> References: <1232625199.4964.35.camel@blaa> <1233319365.3989.79.camel@blaa> <1233706694.11724.28.camel@tofu.lib.ucdavis.edu> <1233732651.4137.13.camel@blaa> <498956A5.5000906@redhat.com> Message-ID: <20090204105635.GG7580@redhat.com> On Wed, Feb 04, 2009 at 04:49:41PM +0800, Harish Pillay wrote: > > http://fedoraproject.org/wiki/Documentation_Virtualization_Beat > > >From that page, it says: > > 'The kernel-xen package has been obsoleted by the integration of > paravirtualization operations in the upstream kernel. The kernel package > in Fedora 11 supports booting as a guest domU, but will not function as > a dom0 until such support is provided upstream. The most recent Fedora > release with dom0 support is Fedora 8.' > > As I write this, I am running F10 on a hardware virt enabled machine > (Dell Latitude D620) and have installed F10 and other distros as guests. > Hence, the statement above is unclear to me for F10 is running as both > dom0 and domU. I don't know what you're running, but it certainly isn't a Fedora Xen Dom0, since this does not exist. F9, F10 and F11 only support Xen DomU The only host virtualization support is KVM 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 :| From pasik at iki.fi Wed Feb 4 11:03:50 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Wed, 4 Feb 2009 13:03:50 +0200 Subject: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: References: <20090203202447.GU15052@edu.joroinen.fi> Message-ID: <20090204110350.GW15052@edu.joroinen.fi> On Tue, Feb 03, 2009 at 10:18:53PM -0200, Itamar Reis Peixoto wrote: > I need to configure something to boot dom0 ? > Well you need to have dom0 kernel.. (there's no dom0 capable kernel in fedora/rawhide yet, so you need to compile/build/get one yourself). Nothing to configure really.. just configure grub.conf in the normal way to boot Xen and dom0 kernel. -- Pasi > > On Tue, Feb 3, 2009 at 6:24 PM, Pasi K?rkk?inen wrote: > > Hello! > > > > For those interested in testing pv_ops dom0 kernels it seems latest Xen > > packages in rawhide contain bzImage dom0 kernel support in Xen hypervisor. > > > > > > rawhide report: 20090203 changes > > > > > > xen-3.3.1-3.fc11 > > ---------------- > > * Tue Feb 3 17:00:00 2009 Gerd Hoffmann - 3.3.1-3 > > - backport bzImage support for dom0 builder. > > > > > > -- Pasi > > > > _______________________________________________ > > Fedora-virt mailing list > > Fedora-virt at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-virt > > > > > > -- > ------------ > > Itamar Reis Peixoto > > e-mail/msn: itamar at ispbrasil.com.br > sip: itamar at ispbrasil.com.br > skype: itamarjp > icq: 81053601 > +55 11 4063 5033 > +55 34 3221 8599 From hpillay at redhat.com Wed Feb 4 11:17:26 2009 From: hpillay at redhat.com (Harish Pillay) Date: Wed, 04 Feb 2009 19:17:26 +0800 Subject: [fedora-virt] F11 features - sVirt Mandatory Access Control In-Reply-To: <1233739834.4137.50.camel@blaa> References: <1232625199.4964.35.camel@blaa> <1233319365.3989.79.camel@blaa> <1233706694.11724.28.camel@tofu.lib.ucdavis.edu> <1233732651.4137.13.camel@blaa> <498956A5.5000906@redhat.com> <1233739834.4137.50.camel@blaa> Message-ID: <49897946.9060905@redhat.com> > I think you're using KVM, not Xen :-) That's right. I am running KVM. > Dom0 and DomU are only terms we use in relation to Xen - when talking > about KVM, we usually use the terms "host" and "guest". > > The release note could be changed to "Xen Kernel Support" rather than > "Unified Kernel Image" and be moved towards the end of the notes. A > casual user doesn't really even need to know about KVM vs. Xen. Indeed. The clarity was what was missing. -- Harish Pillay 9v1hp hpillay at redhat.com +65.9636.9253 gpg id: 746809E3 gpg fingerprint: F7F5 5CCD 25B9 FC25 303E 3DA2 0F80 27DB 7468 09E3 From hpillay at redhat.com Wed Feb 4 11:19:03 2009 From: hpillay at redhat.com (Harish Pillay) Date: Wed, 04 Feb 2009 19:19:03 +0800 Subject: [fedora-virt] F11 features - sVirt Mandatory Access Control In-Reply-To: <20090204105635.GG7580@redhat.com> References: <1232625199.4964.35.camel@blaa> <1233319365.3989.79.camel@blaa> <1233706694.11724.28.camel@tofu.lib.ucdavis.edu> <1233732651.4137.13.camel@blaa> <498956A5.5000906@redhat.com> <20090204105635.GG7580@redhat.com> Message-ID: <498979A7.6030502@redhat.com> >> 'The kernel-xen package has been obsoleted by the integration of >> paravirtualization operations in the upstream kernel. The kernel package >> in Fedora 11 supports booting as a guest domU, but will not function as >> a dom0 until such support is provided upstream. The most recent Fedora >> release with dom0 support is Fedora 8.' >> >> As I write this, I am running F10 on a hardware virt enabled machine >> (Dell Latitude D620) and have installed F10 and other distros as guests. >> Hence, the statement above is unclear to me for F10 is running as both >> dom0 and domU. > > I don't know what you're running, but it certainly isn't a Fedora Xen > Dom0, since this does not exist. F9, F10 and F11 only support Xen DomU > > The only host virtualization support is KVM I think Mark has already alluded to the fact that page is not specific about Xen. I am running KVM. -- Harish Pillay 9v1hp hpillay at redhat.com +65.9636.9253 gpg id: 746809E3 gpg fingerprint: F7F5 5CCD 25B9 FC25 303E 3DA2 0F80 27DB 7468 09E3 From ondrejj at salstar.sk Wed Feb 4 12:16:28 2009 From: ondrejj at salstar.sk (Jan ONDREJ (SAL)) Date: Wed, 4 Feb 2009 13:16:28 +0100 Subject: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: <20090204110350.GW15052@edu.joroinen.fi> References: <20090203202447.GU15052@edu.joroinen.fi> <20090204110350.GW15052@edu.joroinen.fi> Message-ID: <20090204121628.GI18191@salstar.sk> > > On Tue, Feb 3, 2009 at 6:24 PM, Pasi K?rkk?inen wrote: > > > Hello! > > > > > > For those interested in testing pv_ops dom0 kernels it seems latest Xen > > > packages in rawhide contain bzImage dom0 kernel support in Xen hypervisor. I am trying to compile current 2.6.29 kernel (as described here: http://wiki.xensource.com/xenwiki/XenParavirtOps), but without success yet. When trying to boot ./vmlinux ro ./arch/x86/boot/bzImage (also with xen-hypervisor-3.3.1-3.fc11) I still get something like this: (XEN) *** LOADING DOMAIN 0 *** (XEN) elf_xen_note_check: ERROR: Will only load images built for the generic loader or Linux images My grub.conf entry: title Xen TEST root (hd0,0) kernel /boot/xen-3.3.gz noreboot module /boot/xen/vmlinux root=/dev/sda1 ro earlyprintk=xen pci=nomsi module /boot/xen/initrd.img [root at note ~]# file /boot/xen-3.3.gz /boot/xen/vmlinux /boot/xen/initrd.img /boot/xen/bzImage /boot/xen-3.3.gz: gzip compressed data, from Unix, last modified: Tue Feb 3 12:36:39 2009, max compression /boot/xen/vmlinux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped /boot/xen/initrd.img: gzip compressed data, from Unix, last modified: Wed Feb 4 12:00:01 2009, max compression /boot/xen/bzImage: Linux kernel x86 boot executable RO-rootFS, swap_dev 0x2, Normal VGA [root at note ~]# rpm -q xen-hypervisor xen-hypervisor-3.3.1-3.fc11.i386 [root at note ~]# My bzImage boots well with modified grub to boot it as "kernel" and not using xen-3.3 loader. What I am doing wrong? Can sombody send me kernel.config file for 2.6.29, something similar to old kernel-xen rpm package's config? SAL From kraxel at redhat.com Wed Feb 4 12:29:39 2009 From: kraxel at redhat.com (Gerd Hoffmann) Date: Wed, 04 Feb 2009 13:29:39 +0100 Subject: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: <20090204121628.GI18191@salstar.sk> References: <20090203202447.GU15052@edu.joroinen.fi> <20090204110350.GW15052@edu.joroinen.fi> <20090204121628.GI18191@salstar.sk> Message-ID: <49898A33.1080703@redhat.com> Jan ONDREJ (SAL) wrote: >>> On Tue, Feb 3, 2009 at 6:24 PM, Pasi K?rkk?inen wrote: >>>> Hello! >>>> >>>> For those interested in testing pv_ops dom0 kernels it seems latest Xen >>>> packages in rawhide contain bzImage dom0 kernel support in Xen hypervisor. > > I am trying to compile current 2.6.29 kernel (as described here: > http://wiki.xensource.com/xenwiki/XenParavirtOps), but without success yet. > > When trying to boot ./vmlinux ro ./arch/x86/boot/bzImage (also with > xen-hypervisor-3.3.1-3.fc11) I still get something like this: > > (XEN) *** LOADING DOMAIN 0 *** > (XEN) elf_xen_note_check: ERROR: Will only load images built for the generic > loader or Linux images > > My grub.conf entry: > title Xen TEST > root (hd0,0) > kernel /boot/xen-3.3.gz noreboot > module /boot/xen/vmlinux root=/dev/sda1 ro earlyprintk=xen pci=nomsi > module /boot/xen/initrd.img > [root at note ~]# file /boot/xen-3.3.gz /boot/xen/vmlinux /boot/xen/initrd.img /boot/xen/bzImage > /boot/xen-3.3.gz: gzip compressed data, from Unix, last modified: Tue Feb 3 12:36:39 2009, max compression > /boot/xen/vmlinux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped "stripped". This probably is the problem. > /boot/xen/initrd.img: gzip compressed data, from Unix, last modified: Wed Feb 4 12:00:01 2009, max compression > /boot/xen/bzImage: Linux kernel x86 boot executable RO-rootFS, swap_dev 0x2, Normal VGA Try this one instead of vmlinux (unstripped vmlinux should work too). HTH Gerd From ondrejj at salstar.sk Wed Feb 4 12:35:23 2009 From: ondrejj at salstar.sk (Jan ONDREJ (SAL)) Date: Wed, 4 Feb 2009 13:35:23 +0100 Subject: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: <49898A33.1080703@redhat.com> References: <20090203202447.GU15052@edu.joroinen.fi> <20090204110350.GW15052@edu.joroinen.fi> <20090204121628.GI18191@salstar.sk> <49898A33.1080703@redhat.com> Message-ID: <20090204123523.GL18191@salstar.sk> On Wed, Feb 04, 2009 at 01:29:39PM +0100, Gerd Hoffmann wrote: > Jan ONDREJ (SAL) wrote: > > [root at note ~]# file /boot/xen-3.3.gz /boot/xen/vmlinux /boot/xen/initrd.img /boot/xen/bzImage > > /boot/xen-3.3.gz: gzip compressed data, from Unix, last modified: Tue Feb 3 12:36:39 2009, max compression > > /boot/xen/vmlinux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped > > "stripped". This probably is the problem. > > > /boot/xen/initrd.img: gzip compressed data, from Unix, last modified: Wed Feb 4 12:00:01 2009, max compression > > /boot/xen/bzImage: Linux kernel x86 boot executable RO-rootFS, swap_dev 0x2, Normal VGA > > Try this one instead of vmlinux (unstripped vmlinux should work too). Already tryed both of them. Stripped, unstripped vmlinux, gzip compressed vmlinux, bzImage. Always same problem. SAL From glommer at redhat.com Wed Feb 4 15:15:00 2009 From: glommer at redhat.com (Glauber Costa) Date: Wed, 4 Feb 2009 13:15:00 -0200 Subject: [fedora-virt] QEMU new Package In-Reply-To: <1233736916.4137.45.camel@blaa> References: <20090203201131.GA15314@poweredge.glommer> <1233700452.25222.18.camel@blaa> <20090203224439.GI9735@redhat.com> <1233736916.4137.45.camel@blaa> Message-ID: <20090204151500.GA25812@poweredge.glommer> On Wed, Feb 04, 2009 at 08:41:56AM +0000, Mark McLoughlin wrote: > On Tue, 2009-02-03 at 22:44 +0000, Daniel P. Berrange wrote: > > On Tue, Feb 03, 2009 at 10:34:12PM +0000, Mark McLoughlin wrote: > > > (cc-ed a few people who were interested on irc) > > > > > > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote: > > > > Hi guys. > > > > > > > > I've built a qemu image in here: > > > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > > > > > It contains the basic work to get qemu package updated. Basically, > > > > we're talking about getting the qemu code from svn and creating multiple > > > > packages, so one could grab just the architecture of interest. > > > > Todo, is the creation of a meta-package to grab'em all at once. > > > > > > Okay, so this adds ~30 sub-packages. In retrospect, maybe ajax and co. > > > have a point saying that's a bit excessive :-) > > > > > > One downside to so many sub-packages is that it means the total size of > > > the RPMs is ~15Mb instead of ~10Mb. > > > > > > The on-disk size of the current qemu package is ~50Mb. What most people > > > care about is /usr/bin/qemu (and in future qemu-kvm). Those bits only > > > have a ~3Mb on-disk size. Each other target adds ~1.5Mb. > > > > > > How about splitting it this way: > > > > > > qemu: > > > - /usr/bin/qemu > > > - /usr/bin/qemu-system-x86_64 (only on x86_64, obviously) > > > > Err, qemu-system-x86_64 exists just fine on 32-bit hosts. > > Yeah, what I was getting at was that the qemu package would only contain > an emulator for the native architecture. So, qemu wouldn't contain the > x86_64 emulator on 32 bit. > > That was when I thought /usr/bin/qemu was just a hardlink to the native > system emulator. > > Now that I see that /usr/bin/qemu is always i386 (even on e.g. ppc), I > don't like this idea of the base package containing just the native > emulator so much anymore. > > > > - qemu-kvm > > > > This should go away altogether I hope. Until it does, just > > keeping it whereever the x86 emulators are should be fine. > > Yep. > > > > - qemu-nbd > > > > This one should be separate, since it is generally useful > > even without any of the emulators - eg by Xen, or anyone > > else wishing a nbd client for disk images. > > Agree, but I'd be inclined not to bother until someone actually wants > it. > > > > - docs > > > - BIOSes > > > - keymaps > > > - init script > > > > > > qemu-img > > > - /usr/bin/qemu-img > > > > > > qemu-system: > > > > > > - qemu-system-arm > > > - qemu-system-cris > > > - qemu-system-i386 > > > > What's this for ? 'qemu' is always i386, and that shouldn;t > > be changed because far too much assumes 'qemu' is always the > > i386 binary. > > Right, my mistake - the name was just taken from glommer's proposed > qemu-system-i386 package which would contain /usr/bin/qemu. > > > > - qemu-system-m68k > > > - qemu-system-mips > > > - qemu-system-mips64 > > > - qemu-system-mips64el > > > - qemu-system-mipsel > > > - qemu-system-ppc > > > - qemu-system-ppc64 > > > - qemu-system-ppcemb > > > - qemu-system-sh4 > > > - qemu-system-sh4eb > > > - qemu-system-sparc > > > > Why not group them into related sets. eg, all PPC > > variants in one package, all the 'sh' variants, > > and all the 'mips' variants, and all x86 variants. > > That'd compress the # of sub-RPMS to a small handful > > > > qemu-system-x86 > > qemu-system-mips > > qemu-system-sh > > qemu-system-ppc > > qemu-system-sparc > > qemu-system-68k > > Sounds reasonable enough. > > > > qemu-linux: > > > > > > - qemu-alpha > > > - qemu-arm > > > - qemu-armeb > > > - qemu-cris > > > - qemu-debuginfo > > > - qemu-i386 > > > - qemu-m68k > > > - qemu-mips > > > - qemu-mipsel > > > - qemu-ppc > > > - qemu-ppc64 > > > - qemu-ppc64abi32 > > > - qemu-sh4 > > > - qemu-sh4eb > > > - qemu-sparc > > > - qemu-sparc32plus > > > - qemu-sparc64 > > > - qemu-x86_64 > > > > This seems reasonable - judging by how broken most of these > > are, I find it hard to believe they're used much, so having > > them in one sub-RPM ought to be fine. > > > > > One thing I don't like too much about that is if you do a yum update > > > from the current package you lose all the stuff in qemu-system and > > > qemu-linux. I doubt that would cause anyone trouble in practice, though. > > > > Just keep 'qemu' as a meta-package pulling in all the sub-RPMs. > > > > People who only want the x86 bits will probably going from a starting > > point of having the 'kvm' RPM installed. If we make system-system-x86 > > sub-RPM replace+obsolete 'kvm', then updates from people who just have > > KVM will keep a lightweight install, and those who have the full QEMU > > stack will not be broken either. > > Yeah, sounds good. > > So, in summary: > > qemu-img > - /usr/bin/qemu-img > > qemu-common: > - /usr/bin/qemu-nbd > - docs > - BIOSes > - keymaps > - init script > > qemu-system-x86: > - /usr/bin/qemu > - qemu-system-x86_64 > - /usr/bin/qemu-kvm > > qemu-system-arm: > - qemu-system-arm > > qemu-system-cris: > - qemu-system-cris > > qemu-system-m68k > - qemu-system-m68k > > qemu-system-mips > - qemu-system-mips > - qemu-system-mips64 > - qemu-system-mips64el > - qemu-system-mipsel > > qemu-system-ppc > - qemu-system-ppc > - qemu-system-ppc64 > - qemu-system-ppcemb > > qemu-system-sh > - qemu-system-sh4 > - qemu-system-sh4eb > > qemu-system-sparc > - qemu-system-sparc > > qemu-linux: I believe qemu-user suits better upstream name usage. Other than that, I think this proposal is sound. Also, there has been a proposal by ajax in #fedora-devel to have a "qemu-native" package, that would install native emu/virt for whatever architecture you're running at. What do you guys think of this? From berrange at redhat.com Wed Feb 4 15:17:19 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 4 Feb 2009 15:17:19 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090204151500.GA25812@poweredge.glommer> References: <20090203201131.GA15314@poweredge.glommer> <1233700452.25222.18.camel@blaa> <20090203224439.GI9735@redhat.com> <1233736916.4137.45.camel@blaa> <20090204151500.GA25812@poweredge.glommer> Message-ID: <20090204151719.GD26946@redhat.com> On Wed, Feb 04, 2009 at 01:15:00PM -0200, Glauber Costa wrote: > > So, in summary: > > > > qemu-img > > - /usr/bin/qemu-img > > > > qemu-common: > > - /usr/bin/qemu-nbd > > - docs > > - BIOSes > > - keymaps > > - init script > > > > qemu-system-x86: > > - /usr/bin/qemu > > - qemu-system-x86_64 > > - /usr/bin/qemu-kvm > > > > qemu-system-arm: > > - qemu-system-arm > > > > qemu-system-cris: > > - qemu-system-cris > > > > qemu-system-m68k > > - qemu-system-m68k > > > > qemu-system-mips > > - qemu-system-mips > > - qemu-system-mips64 > > - qemu-system-mips64el > > - qemu-system-mipsel > > > > qemu-system-ppc > > - qemu-system-ppc > > - qemu-system-ppc64 > > - qemu-system-ppcemb > > > > qemu-system-sh > > - qemu-system-sh4 > > - qemu-system-sh4eb > > > > qemu-system-sparc > > - qemu-system-sparc > > > > qemu-linux: > I believe qemu-user suits better upstream name usage. Other than that, > I think this proposal is sound. > > Also, there has been a proposal by ajax in #fedora-devel to have a "qemu-native" > package, that would install native emu/virt for whatever architecture you're running at. > > What do you guys think of this? There's no need for a package for that. Just conditionally add Provides: qemu-native to the appropriate qemu-system-XXX sub-RPM according to the arch you're building on. 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 :| From markmc at redhat.com Wed Feb 4 15:51:56 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 04 Feb 2009 15:51:56 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090204151500.GA25812@poweredge.glommer> References: <20090203201131.GA15314@poweredge.glommer> <1233700452.25222.18.camel@blaa> <20090203224439.GI9735@redhat.com> <1233736916.4137.45.camel@blaa> <20090204151500.GA25812@poweredge.glommer> Message-ID: <1233762716.4137.69.camel@blaa> On Wed, 2009-02-04 at 13:15 -0200, Glauber Costa wrote: > On Wed, Feb 04, 2009 at 08:41:56AM +0000, Mark McLoughlin wrote: > > qemu-linux: > I believe qemu-user suits better upstream name usage. Other than that, > I think this proposal is sound. The reason I suggested qemu-linux is because I think QEMU's existing naming sucks :-) i.e. system/softmmu == "emulate a full machine" and user == "emulate the linux kernel ABI" system vs. linux makes it a little more sense, in my book. > Also, there has been a proposal by ajax in #fedora-devel to have a "qemu-native" > package, that would install native emu/virt for whatever architecture you're running at. > > What do you guys think of this? As long it's just a Provides as danpb suggests, I don't mind ... Cheers, Mark. From dlbewley at lib.ucdavis.edu Wed Feb 4 16:00:55 2009 From: dlbewley at lib.ucdavis.edu (Dale Bewley) Date: Wed, 4 Feb 2009 08:00:55 -0800 (PST) Subject: [fedora-virt] F11 features - sVirt Mandatory Access Control In-Reply-To: <1233739834.4137.50.camel@blaa> Message-ID: <1662107462.2267141233763255702.JavaMail.root@zebra.lib.ucdavis.edu> ----- "Mark McLoughlin" wrote: > The release note could be changed to "Xen Kernel Support" rather than > "Unified Kernel Image" and be moved towards the end of the notes. A > casual user doesn't really even need to know about KVM vs. Xen. Excellent suggestion. That paragraph has not yet been edited since the F10 release. Other than s/10/11/g. From ajax at redhat.com Wed Feb 4 16:08:01 2009 From: ajax at redhat.com (Adam Jackson) Date: Wed, 04 Feb 2009 11:08:01 -0500 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090204151719.GD26946@redhat.com> References: <20090203201131.GA15314@poweredge.glommer> <1233700452.25222.18.camel@blaa> <20090203224439.GI9735@redhat.com> <1233736916.4137.45.camel@blaa> <20090204151500.GA25812@poweredge.glommer> <20090204151719.GD26946@redhat.com> Message-ID: <1233763681.1833.1198.camel@atropine.boston.devel.redhat.com> On Wed, 2009-02-04 at 15:17 +0000, Daniel P. Berrange wrote: > > Also, there has been a proposal by ajax in #fedora-devel to have a "qemu-native" > > package, that would install native emu/virt for whatever architecture you're running at. > > > > What do you guys think of this? > > There's no need for a package for that. Just conditionally add > > Provides: qemu-native > > to the appropriate qemu-system-XXX sub-RPM according to the arch you're > building on. Actually my proposal was to have qemu-native and qemu-everything-else. On the basis that either you just want a vm and the native arch is good enough, or you want a particular arch and therefore clearly have disk to burn. But, I'm no domain expert here. If the typical qemu user is something other than I've envisioned, then feel free to ignore me. - ajax -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From glommer at redhat.com Wed Feb 4 16:23:12 2009 From: glommer at redhat.com (Glauber Costa) Date: Wed, 4 Feb 2009 14:23:12 -0200 Subject: [fedora-virt] QEMU new Package In-Reply-To: <1233762716.4137.69.camel@blaa> References: <20090203201131.GA15314@poweredge.glommer> <1233700452.25222.18.camel@blaa> <20090203224439.GI9735@redhat.com> <1233736916.4137.45.camel@blaa> <20090204151500.GA25812@poweredge.glommer> <1233762716.4137.69.camel@blaa> Message-ID: <20090204162312.GB25812@poweredge.glommer> On Wed, Feb 04, 2009 at 03:51:56PM +0000, Mark McLoughlin wrote: > On Wed, 2009-02-04 at 13:15 -0200, Glauber Costa wrote: > > On Wed, Feb 04, 2009 at 08:41:56AM +0000, Mark McLoughlin wrote: > > > > qemu-linux: > > I believe qemu-user suits better upstream name usage. Other than that, > > I think this proposal is sound. > > The reason I suggested qemu-linux is because I think QEMU's existing > naming sucks :-) > > i.e. system/softmmu == "emulate a full machine" and user == "emulate the > linux kernel ABI" > > system vs. linux makes it a little more sense, in my book. I agree with you 150e^7 %. Another example of naming suckiness on upstream is the fact that "qemu" stands for qemu-system-i386 on whichever platform you're on, even on a rotten potato. However, this is a reason for us to go upstream and suggest name changes. In the mean time, adopting a different name ourselves will just make matters more confusing. > > > Also, there has been a proposal by ajax in #fedora-devel to have a "qemu-native" > > package, that would install native emu/virt for whatever architecture you're running at. > > > > What do you guys think of this? > > As long it's just a Provides as danpb suggests, I don't mind ... I believe this is a good suggestion because of kvm. Users using exclusively kvm will probably want to grab native emulation, whatever it is. And for the record, kvm ppc is completely merged in qemu. From kraxel at redhat.com Wed Feb 4 16:23:02 2009 From: kraxel at redhat.com (Gerd Hoffmann) Date: Wed, 04 Feb 2009 17:23:02 +0100 Subject: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: <20090204123523.GL18191@salstar.sk> References: <20090203202447.GU15052@edu.joroinen.fi> <20090204110350.GW15052@edu.joroinen.fi> <20090204121628.GI18191@salstar.sk> <49898A33.1080703@redhat.com> <20090204123523.GL18191@salstar.sk> Message-ID: <4989C0E6.1060103@redhat.com> Jan ONDREJ (SAL) wrote: > On Wed, Feb 04, 2009 at 01:29:39PM +0100, Gerd Hoffmann wrote: >> Jan ONDREJ (SAL) wrote: >>> [root at note ~]# file /boot/xen-3.3.gz /boot/xen/vmlinux /boot/xen/initrd.img /boot/xen/bzImage >>> /boot/xen-3.3.gz: gzip compressed data, from Unix, last modified: Tue Feb 3 12:36:39 2009, max compression >>> /boot/xen/vmlinux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped >> "stripped". This probably is the problem. >> >>> /boot/xen/initrd.img: gzip compressed data, from Unix, last modified: Wed Feb 4 12:00:01 2009, max compression >>> /boot/xen/bzImage: Linux kernel x86 boot executable RO-rootFS, swap_dev 0x2, Normal VGA >> Try this one instead of vmlinux (unstripped vmlinux should work too). > > Already tryed both of them. Stripped, unstripped vmlinux, gzip compressed > vmlinux, bzImage. Always same problem. Hmm. Works for me. x86_64 box boots up fine (until the not-yet fixed storage issues kick in, see xen-devel). Old i386 laptop has an early kernel crash (probably due to lack of an io-apic, the pv_ops kernel reportly can't deal with that very well). The bootup passes the point where the dom0 domain builder parses the guest kernel though. 32bit config attached. HTH, Gerd -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dot.config URL: From glommer at redhat.com Wed Feb 4 16:29:13 2009 From: glommer at redhat.com (Glauber Costa) Date: Wed, 4 Feb 2009 14:29:13 -0200 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090203225347.GJ9735@redhat.com> References: <20090203201131.GA15314@poweredge.glommer> <20090203225347.GJ9735@redhat.com> Message-ID: <20090204162913.GC25812@poweredge.glommer> On Tue, Feb 03, 2009 at 10:53:47PM +0000, Daniel P. Berrange wrote: > On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote: > > Hi guys. > > > > I've built a qemu image in here: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > It contains the basic work to get qemu package updated. Basically, > > we're talking about getting the qemu code from svn and creating multiple > > packages, so one could grab just the architecture of interest. > > Todo, is the creation of a meta-package to grab'em all at once. > > > > This is also the first step in merging qemu and kvm packages, which > > I'd like to do in two steps. > > > > 1) This one. > > 2) replace qemu-svn with kvm-userspace > > > > The later is not as trivial as it seems. Nobody exercices this path > > usually, and we're likely to find bugs that prevent the build to finish > > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have > > it sorted out. > > > > If no one has any major opposition to the state of things, I intend to > > commit it to CVS tomorrow (with some minor changes), and put it into > > rawhide so we can start having a more serious testing out of it. > > The major blocker here is that it breaks upgrades. ie, upgrade to F11 > and you end up with an install with no emulators present. 'qemu' should > stay as a package which pulls in everything - by Requires on all the > sub-RPMs. I agree with mark that there are too many sub-RPMs here. > I think we should group related archs, so that all x86 related system > emulators are in one sub-RPM, all mips together, all sh together, etc Ok, so what you mean is a meta package "qemu" that just depends on all others for folks that already has qemu installed? It makes sense. Do we plan on carrying it on forever, or dropping it by F12? > > Also, the /etc/init.d/qemu script will need updating to take account > of the fact that not all usermode emulators will be present - it should > only register binary format handlers for those which are actually > installed. According to the current proposal, they will. We're splitting qemu-system into multiple, but qemu-user will have all targets. So all we have to do is install the init script only when installing the user package. From berrange at redhat.com Wed Feb 4 16:28:27 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 4 Feb 2009 16:28:27 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090204162312.GB25812@poweredge.glommer> References: <20090203201131.GA15314@poweredge.glommer> <1233700452.25222.18.camel@blaa> <20090203224439.GI9735@redhat.com> <1233736916.4137.45.camel@blaa> <20090204151500.GA25812@poweredge.glommer> <1233762716.4137.69.camel@blaa> <20090204162312.GB25812@poweredge.glommer> Message-ID: <20090204162827.GG26946@redhat.com> On Wed, Feb 04, 2009 at 02:23:12PM -0200, Glauber Costa wrote: > On Wed, Feb 04, 2009 at 03:51:56PM +0000, Mark McLoughlin wrote: > > On Wed, 2009-02-04 at 13:15 -0200, Glauber Costa wrote: > > > On Wed, Feb 04, 2009 at 08:41:56AM +0000, Mark McLoughlin wrote: > > > > > > qemu-linux: > > > I believe qemu-user suits better upstream name usage. Other than that, > > > I think this proposal is sound. > > > > The reason I suggested qemu-linux is because I think QEMU's existing > > naming sucks :-) > > > > i.e. system/softmmu == "emulate a full machine" and user == "emulate the > > linux kernel ABI" > > > > system vs. linux makes it a little more sense, in my book. > I agree with you 150e^7 %. Another example of naming suckiness on upstream is > the fact that "qemu" stands for qemu-system-i386 on whichever platform you're on, > even on a rotten potato. > > However, this is a reason for us to go upstream and suggest name changes. In the mean > time, adopting a different name ourselves will just make matters more confusing. No, we do *not* want to change the 'qemu' binary. Soo much stuff out there knows & assumes 'qemu' is the i386 binary, and qemu-system-x86_64 is the x86_64 emulator. If this were a brand new project, sure it'd make sense to have 'qemu-system-i386', but at this stage we should not be renaming binaries in wide use just for sake of naming prettiness. > > > Also, there has been a proposal by ajax in #fedora-devel to have a "qemu-native" > > > package, that would install native emu/virt for whatever architecture you're running at. > > > > > > What do you guys think of this? > > > > As long it's just a Provides as danpb suggests, I don't mind ... > I believe this is a good suggestion because of kvm. Users using exclusively > kvm will probably want to grab native emulation, whatever it is. And for the > record, kvm ppc is completely merged in qemu. 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 :| From berrange at redhat.com Wed Feb 4 16:29:06 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 4 Feb 2009 16:29:06 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090204162913.GC25812@poweredge.glommer> References: <20090203201131.GA15314@poweredge.glommer> <20090203225347.GJ9735@redhat.com> <20090204162913.GC25812@poweredge.glommer> Message-ID: <20090204162906.GH26946@redhat.com> On Wed, Feb 04, 2009 at 02:29:13PM -0200, Glauber Costa wrote: > On Tue, Feb 03, 2009 at 10:53:47PM +0000, Daniel P. Berrange wrote: > > On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote: > > > Hi guys. > > > > > > I've built a qemu image in here: > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > > > It contains the basic work to get qemu package updated. Basically, > > > we're talking about getting the qemu code from svn and creating multiple > > > packages, so one could grab just the architecture of interest. > > > Todo, is the creation of a meta-package to grab'em all at once. > > > > > > This is also the first step in merging qemu and kvm packages, which > > > I'd like to do in two steps. > > > > > > 1) This one. > > > 2) replace qemu-svn with kvm-userspace > > > > > > The later is not as trivial as it seems. Nobody exercices this path > > > usually, and we're likely to find bugs that prevent the build to finish > > > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have > > > it sorted out. > > > > > > If no one has any major opposition to the state of things, I intend to > > > commit it to CVS tomorrow (with some minor changes), and put it into > > > rawhide so we can start having a more serious testing out of it. > > > > The major blocker here is that it breaks upgrades. ie, upgrade to F11 > > and you end up with an install with no emulators present. 'qemu' should > > stay as a package which pulls in everything - by Requires on all the > > sub-RPMs. I agree with mark that there are too many sub-RPMs here. > > I think we should group related archs, so that all x86 related system > > emulators are in one sub-RPM, all mips together, all sh together, etc > Ok, so what you mean is a meta package "qemu" that just depends on all others > for folks that already has qemu installed? It makes sense. Do we plan on > carrying it on forever, or dropping it by F12? Plan to keep it indefinitely. > > Also, the /etc/init.d/qemu script will need updating to take account > > of the fact that not all usermode emulators will be present - it should > > only register binary format handlers for those which are actually > > installed. > According to the current proposal, they will. We're splitting qemu-system into > multiple, but qemu-user will have all targets. So all we have to do is install > the init script only when installing the user package. That simplifies things nicely 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 :| From glommer at redhat.com Wed Feb 4 16:33:50 2009 From: glommer at redhat.com (Glauber Costa) Date: Wed, 4 Feb 2009 14:33:50 -0200 Subject: [fedora-virt] QEMU new Package In-Reply-To: <1233763681.1833.1198.camel@atropine.boston.devel.redhat.com> References: <20090203201131.GA15314@poweredge.glommer> <1233700452.25222.18.camel@blaa> <20090203224439.GI9735@redhat.com> <1233736916.4137.45.camel@blaa> <20090204151500.GA25812@poweredge.glommer> <20090204151719.GD26946@redhat.com> <1233763681.1833.1198.camel@atropine.boston.devel.redhat.com> Message-ID: <20090204163350.GD25812@poweredge.glommer> On Wed, Feb 04, 2009 at 11:08:01AM -0500, Adam Jackson wrote: > On Wed, 2009-02-04 at 15:17 +0000, Daniel P. Berrange wrote: > > > > Also, there has been a proposal by ajax in #fedora-devel to have a "qemu-native" > > > package, that would install native emu/virt for whatever architecture you're running at. > > > > > > What do you guys think of this? > > > > There's no need for a package for that. Just conditionally add > > > > Provides: qemu-native > > > > to the appropriate qemu-system-XXX sub-RPM according to the arch you're > > building on. > > Actually my proposal was to have qemu-native and qemu-everything-else. > On the basis that either you just want a vm and the native arch is good > enough, or you want a particular arch and therefore clearly have disk to > burn. Not always having disk to burn is the case. You can easily fit an embedded system in a couple of mb, so the disk image for an arm system, for instance, is likely to require this couple of mb too. Going further, qemu-user-xxx (which is probably a qemu handler to watch porn) needs no extra disk at all, since you'll be just running normal binaries with an emulation layer. > > But, I'm no domain expert here. If the typical qemu user is something > other than I've envisioned, then feel free to ignore me. We feel totally free to ignore you, because the internet is a free country, and we're free men ;-) But your comments are always welcome. From markmc at redhat.com Wed Feb 4 16:30:49 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 04 Feb 2009 16:30:49 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090204162913.GC25812@poweredge.glommer> References: <20090203201131.GA15314@poweredge.glommer> <20090203225347.GJ9735@redhat.com> <20090204162913.GC25812@poweredge.glommer> Message-ID: <1233765049.4137.74.camel@blaa> On Wed, 2009-02-04 at 14:29 -0200, Glauber Costa wrote: > On Tue, Feb 03, 2009 at 10:53:47PM +0000, Daniel P. Berrange wrote: > > On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote: > > > Hi guys. > > > > > > I've built a qemu image in here: > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > > > It contains the basic work to get qemu package updated. Basically, > > > we're talking about getting the qemu code from svn and creating multiple > > > packages, so one could grab just the architecture of interest. > > > Todo, is the creation of a meta-package to grab'em all at once. > > > > > > This is also the first step in merging qemu and kvm packages, which > > > I'd like to do in two steps. > > > > > > 1) This one. > > > 2) replace qemu-svn with kvm-userspace > > > > > > The later is not as trivial as it seems. Nobody exercices this path > > > usually, and we're likely to find bugs that prevent the build to finish > > > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have > > > it sorted out. > > > > > > If no one has any major opposition to the state of things, I intend to > > > commit it to CVS tomorrow (with some minor changes), and put it into > > > rawhide so we can start having a more serious testing out of it. > > > > The major blocker here is that it breaks upgrades. ie, upgrade to F11 > > and you end up with an install with no emulators present. 'qemu' should > > stay as a package which pulls in everything - by Requires on all the > > sub-RPMs. I agree with mark that there are too many sub-RPMs here. > > I think we should group related archs, so that all x86 related system > > emulators are in one sub-RPM, all mips together, all sh together, etc > Ok, so what you mean is a meta package "qemu" that just depends on all others > for folks that already has qemu installed? It makes sense. Do we plan on > carrying it on forever, or dropping it by F12? There's no harm carrying it indefinitely. > > Also, the /etc/init.d/qemu script will need updating to take account > > of the fact that not all usermode emulators will be present - it should > > only register binary format handlers for those which are actually > > installed. > According to the current proposal, they will. We're splitting qemu-system into > multiple, but qemu-user will have all targets. So all we have to do is install > the init script only when installing the user package. Ah, and the initscript only applies to the user targets? That makes perfect sense then. Cheers, Mark. From pasik at iki.fi Wed Feb 4 16:29:57 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Wed, 4 Feb 2009 18:29:57 +0200 Subject: [Fedora-xen] Re: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: <20090204123523.GL18191@salstar.sk> References: <20090203202447.GU15052@edu.joroinen.fi> <20090204110350.GW15052@edu.joroinen.fi> <20090204121628.GI18191@salstar.sk> <49898A33.1080703@redhat.com> <20090204123523.GL18191@salstar.sk> Message-ID: <20090204162957.GZ15052@edu.joroinen.fi> On Wed, Feb 04, 2009 at 01:35:23PM +0100, Jan ONDREJ (SAL) wrote: > On Wed, Feb 04, 2009 at 01:29:39PM +0100, Gerd Hoffmann wrote: > > Jan ONDREJ (SAL) wrote: > > > [root at note ~]# file /boot/xen-3.3.gz /boot/xen/vmlinux /boot/xen/initrd.img /boot/xen/bzImage > > > /boot/xen-3.3.gz: gzip compressed data, from Unix, last modified: Tue Feb 3 12:36:39 2009, max compression > > > /boot/xen/vmlinux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped > > > > "stripped". This probably is the problem. > > > > > /boot/xen/initrd.img: gzip compressed data, from Unix, last modified: Wed Feb 4 12:00:01 2009, max compression > > > /boot/xen/bzImage: Linux kernel x86 boot executable RO-rootFS, swap_dev 0x2, Normal VGA > > > > Try this one instead of vmlinux (unstripped vmlinux should work too). > > Already tryed both of them. Stripped, unstripped vmlinux, gzip compressed > vmlinux, bzImage. Always same problem. > I've been using gzipped vmlinux pv_ops dom0 kernel successfully. I still haven't tried that new bzImage support .. will try that today or tomorrow. -- Pasi From glommer at redhat.com Wed Feb 4 16:35:25 2009 From: glommer at redhat.com (Glauber Costa) Date: Wed, 4 Feb 2009 14:35:25 -0200 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090204162827.GG26946@redhat.com> References: <20090203201131.GA15314@poweredge.glommer> <1233700452.25222.18.camel@blaa> <20090203224439.GI9735@redhat.com> <1233736916.4137.45.camel@blaa> <20090204151500.GA25812@poweredge.glommer> <1233762716.4137.69.camel@blaa> <20090204162312.GB25812@poweredge.glommer> <20090204162827.GG26946@redhat.com> Message-ID: <20090204163525.GE25812@poweredge.glommer> On Wed, Feb 04, 2009 at 04:28:27PM +0000, Daniel P. Berrange wrote: > On Wed, Feb 04, 2009 at 02:23:12PM -0200, Glauber Costa wrote: > > On Wed, Feb 04, 2009 at 03:51:56PM +0000, Mark McLoughlin wrote: > > > On Wed, 2009-02-04 at 13:15 -0200, Glauber Costa wrote: > > > > On Wed, Feb 04, 2009 at 08:41:56AM +0000, Mark McLoughlin wrote: > > > > > > > > qemu-linux: > > > > I believe qemu-user suits better upstream name usage. Other than that, > > > > I think this proposal is sound. > > > > > > The reason I suggested qemu-linux is because I think QEMU's existing > > > naming sucks :-) > > > > > > i.e. system/softmmu == "emulate a full machine" and user == "emulate the > > > linux kernel ABI" > > > > > > system vs. linux makes it a little more sense, in my book. > > I agree with you 150e^7 %. Another example of naming suckiness on upstream is > > the fact that "qemu" stands for qemu-system-i386 on whichever platform you're on, > > even on a rotten potato. > > > > However, this is a reason for us to go upstream and suggest name changes. In the mean > > time, adopting a different name ourselves will just make matters more confusing. > > No, we do *not* want to change the 'qemu' binary. Soo much stuff out > there knows & assumes 'qemu' is the i386 binary, and qemu-system-x86_64 > is the x86_64 emulator. If this were a brand new project, sure it'd > make sense to have 'qemu-system-i386', but at this stage we should not > be renaming binaries in wide use just for sake of naming prettiness. I totally agree. Just saying that renaming things in our packages is even worse. From glommer at redhat.com Wed Feb 4 16:37:18 2009 From: glommer at redhat.com (Glauber Costa) Date: Wed, 4 Feb 2009 14:37:18 -0200 Subject: [fedora-virt] QEMU new Package In-Reply-To: <1233765049.4137.74.camel@blaa> References: <20090203201131.GA15314@poweredge.glommer> <20090203225347.GJ9735@redhat.com> <20090204162913.GC25812@poweredge.glommer> <1233765049.4137.74.camel@blaa> Message-ID: <20090204163718.GF25812@poweredge.glommer> On Wed, Feb 04, 2009 at 04:30:49PM +0000, Mark McLoughlin wrote: > On Wed, 2009-02-04 at 14:29 -0200, Glauber Costa wrote: > > On Tue, Feb 03, 2009 at 10:53:47PM +0000, Daniel P. Berrange wrote: > > > On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote: > > > > Hi guys. > > > > > > > > I've built a qemu image in here: > > > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > > > > > It contains the basic work to get qemu package updated. Basically, > > > > we're talking about getting the qemu code from svn and creating multiple > > > > packages, so one could grab just the architecture of interest. > > > > Todo, is the creation of a meta-package to grab'em all at once. > > > > > > > > This is also the first step in merging qemu and kvm packages, which > > > > I'd like to do in two steps. > > > > > > > > 1) This one. > > > > 2) replace qemu-svn with kvm-userspace > > > > > > > > The later is not as trivial as it seems. Nobody exercices this path > > > > usually, and we're likely to find bugs that prevent the build to finish > > > > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have > > > > it sorted out. > > > > > > > > If no one has any major opposition to the state of things, I intend to > > > > commit it to CVS tomorrow (with some minor changes), and put it into > > > > rawhide so we can start having a more serious testing out of it. > > > > > > The major blocker here is that it breaks upgrades. ie, upgrade to F11 > > > and you end up with an install with no emulators present. 'qemu' should > > > stay as a package which pulls in everything - by Requires on all the > > > sub-RPMs. I agree with mark that there are too many sub-RPMs here. > > > I think we should group related archs, so that all x86 related system > > > emulators are in one sub-RPM, all mips together, all sh together, etc > > Ok, so what you mean is a meta package "qemu" that just depends on all others > > for folks that already has qemu installed? It makes sense. Do we plan on > > carrying it on forever, or dropping it by F12? > > There's no harm carrying it indefinitely. > > > > Also, the /etc/init.d/qemu script will need updating to take account > > > of the fact that not all usermode emulators will be present - it should > > > only register binary format handlers for those which are actually > > > installed. > > According to the current proposal, they will. We're splitting qemu-system into > > multiple, but qemu-user will have all targets. So all we have to do is install > > the init script only when installing the user package. > > Ah, and the initscript only applies to the user targets? That makes > perfect sense then. yeah. This script has only two purposes in life: 1) Allowing people to do ./my-binary-arm, and call the emulator under the hood 2) pursuit of happiness. The later is not negatively affected by our new scheme. From markmc at redhat.com Wed Feb 4 17:43:55 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 04 Feb 2009 17:43:55 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090203201131.GA15314@poweredge.glommer> References: <20090203201131.GA15314@poweredge.glommer> Message-ID: <1233769435.27853.1.camel@blaa> On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote: > Hi guys. > > I've built a qemu image in here: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > It contains the basic work to get qemu package updated. Basically, > we're talking about getting the qemu code from svn ... Another thing to watch out for is the guidelines for numbering pre-release snapshots: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages According to those, I think this should be 0.9.2-0.1.svn6392 rather than 0.9.1-svn6392. Cheers, Mark. From glommer at redhat.com Wed Feb 4 19:09:45 2009 From: glommer at redhat.com (Glauber Costa) Date: Wed, 4 Feb 2009 17:09:45 -0200 Subject: [fedora-virt] QEMU new Package In-Reply-To: <1233769435.27853.1.camel@blaa> References: <20090203201131.GA15314@poweredge.glommer> <1233769435.27853.1.camel@blaa> Message-ID: <20090204190945.GA20150@poweredge.glommer> On Wed, Feb 04, 2009 at 05:43:55PM +0000, Mark McLoughlin wrote: > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote: > > Hi guys. > > > > I've built a qemu image in here: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > It contains the basic work to get qemu package updated. Basically, > > we're talking about getting the qemu code from svn > ... > > Another thing to watch out for is the guidelines for numbering > pre-release snapshots: > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages > > According to those, I think this should be 0.9.2-0.1.svn6392 rather than > 0.9.1-svn6392. Let's let it this way for now. I believe it's not yet certain that the new version will be called 0.9.2, right? From glommer at redhat.com Wed Feb 4 19:23:52 2009 From: glommer at redhat.com (Glauber Costa) Date: Wed, 4 Feb 2009 17:23:52 -0200 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090203225347.GJ9735@redhat.com> References: <20090203201131.GA15314@poweredge.glommer> <20090203225347.GJ9735@redhat.com> Message-ID: <20090204192352.GB20150@poweredge.glommer> On Tue, Feb 03, 2009 at 10:53:47PM +0000, Daniel P. Berrange wrote: > On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote: > > Hi guys. > > > > I've built a qemu image in here: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > It contains the basic work to get qemu package updated. Basically, > > we're talking about getting the qemu code from svn and creating multiple > > packages, so one could grab just the architecture of interest. > > Todo, is the creation of a meta-package to grab'em all at once. > > > > This is also the first step in merging qemu and kvm packages, which > > I'd like to do in two steps. > > > > 1) This one. > > 2) replace qemu-svn with kvm-userspace > > > > The later is not as trivial as it seems. Nobody exercices this path > > usually, and we're likely to find bugs that prevent the build to finish > > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have > > it sorted out. > > > > If no one has any major opposition to the state of things, I intend to > > commit it to CVS tomorrow (with some minor changes), and put it into > > rawhide so we can start having a more serious testing out of it. > > The major blocker here is that it breaks upgrades. ie, upgrade to F11 > and you end up with an install with no emulators present. 'qemu' should > stay as a package which pulls in everything - by Requires on all the > sub-RPMs. I agree with mark that there are too many sub-RPMs here. > I think we should group related archs, so that all x86 related system > emulators are in one sub-RPM, all mips together, all sh together, etc > > Also, the /etc/init.d/qemu script will need updating to take account > of the fact that not all usermode emulators will be present - it should > only register binary format handlers for those which are actually > installed. > > Also, you'll need to have the keymap files in a sub-RPM that all the > qemu-system-X packages can depend on, since the keymap data files are > needed for all the binaries which support SDL & VNC. > Open question: Do we want the requirements to match %{version}-%{release} ? (I believe so) From dan at danny.cz Wed Feb 4 20:55:15 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Wed, 04 Feb 2009 21:55:15 +0100 Subject: [fedora-virt] QEMU new Package In-Reply-To: <1233769435.27853.1.camel@blaa> References: <20090203201131.GA15314@poweredge.glommer> <1233769435.27853.1.camel@blaa> Message-ID: <1233780915.3724.97.camel@eagle.danny.cz> Mark McLoughlin p??e v St 04. 02. 2009 v 17:43 +0000: > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote: > > Hi guys. > > > > I've built a qemu image in here: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > It contains the basic work to get qemu package updated. Basically, > > we're talking about getting the qemu code from svn > ... > > Another thing to watch out for is the guidelines for numbering > pre-release snapshots: > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages > > According to those, I think this should be 0.9.2-0.1.svn6392 rather than > 0.9.1-svn6392. And to be fully compliant it is should be 0.9.2-0.1.YYYYMMDDsvn6392, where YYYYMMDD is the date of the revision 6392. See the "Snapshot packages" paragraph a bit lower on the mentioned page. Dan From glommer at redhat.com Wed Feb 4 22:12:10 2009 From: glommer at redhat.com (Glauber Costa) Date: Wed, 4 Feb 2009 20:12:10 -0200 Subject: [fedora-virt] QEMU new Package In-Reply-To: <1233769435.27853.1.camel@blaa> References: <20090203201131.GA15314@poweredge.glommer> <1233769435.27853.1.camel@blaa> Message-ID: <20090204221210.GD20150@poweredge.glommer> On Wed, Feb 04, 2009 at 05:43:55PM +0000, Mark McLoughlin wrote: > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote: > > Hi guys. > > > > I've built a qemu image in here: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > It contains the basic work to get qemu package updated. Basically, > > we're talking about getting the qemu code from svn > ... > > Another thing to watch out for is the guidelines for numbering > pre-release snapshots: > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages > > According to those, I think this should be 0.9.2-0.1.svn6392 rather than > 0.9.1-svn6392. > > Cheers, > Mark. > I have a new test package in here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1105051 I haven't updated the name yet, but this is easy. Apart from that, the .rpm are useless, as they don't include the firmware images. (we don't want to ship the binary anyway, which was what current qemu were doing). I'll work on it tomorrow. I plan to grab the various pieces needed to compile the firmwares and other binaries, and colocate them in the same srpm as qemu. We can use separate packages if we must, but I don't see a big push for it. We already separate the one which is most likely to be useful for someone else (pxes). But I'm open to suggestions. From berrange at redhat.com Wed Feb 4 22:12:56 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 4 Feb 2009 22:12:56 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090204192352.GB20150@poweredge.glommer> References: <20090203201131.GA15314@poweredge.glommer> <20090203225347.GJ9735@redhat.com> <20090204192352.GB20150@poweredge.glommer> Message-ID: <20090204221256.GA8095@redhat.com> On Wed, Feb 04, 2009 at 05:23:52PM -0200, Glauber Costa wrote: > On Tue, Feb 03, 2009 at 10:53:47PM +0000, Daniel P. Berrange wrote: > > On Tue, Feb 03, 2009 at 06:11:31PM -0200, Glauber Costa wrote: > > > Hi guys. > > > > > > I've built a qemu image in here: > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > > > It contains the basic work to get qemu package updated. Basically, > > > we're talking about getting the qemu code from svn and creating multiple > > > packages, so one could grab just the architecture of interest. > > > Todo, is the creation of a meta-package to grab'em all at once. > > > > > > This is also the first step in merging qemu and kvm packages, which > > > I'd like to do in two steps. > > > > > > 1) This one. > > > 2) replace qemu-svn with kvm-userspace > > > > > > The later is not as trivial as it seems. Nobody exercices this path > > > usually, and we're likely to find bugs that prevent the build to finish > > > (Well, I tested, and there _are_ bugs ;-) ). But I believe we can have > > > it sorted out. > > > > > > If no one has any major opposition to the state of things, I intend to > > > commit it to CVS tomorrow (with some minor changes), and put it into > > > rawhide so we can start having a more serious testing out of it. > > > > The major blocker here is that it breaks upgrades. ie, upgrade to F11 > > and you end up with an install with no emulators present. 'qemu' should > > stay as a package which pulls in everything - by Requires on all the > > sub-RPMs. I agree with mark that there are too many sub-RPMs here. > > I think we should group related archs, so that all x86 related system > > emulators are in one sub-RPM, all mips together, all sh together, etc > > > > Also, the /etc/init.d/qemu script will need updating to take account > > of the fact that not all usermode emulators will be present - it should > > only register binary format handlers for those which are actually > > installed. > > > > Also, you'll need to have the keymap files in a sub-RPM that all the > > qemu-system-X packages can depend on, since the keymap data files are > > needed for all the binaries which support SDL & VNC. > > > Open question: > > Do we want the requirements to match %{version}-%{release} ? Yes. Full V-R Requires lines 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 :| From pasik at iki.fi Thu Feb 5 08:03:58 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Thu, 5 Feb 2009 10:03:58 +0200 Subject: [Fedora-xen] Re: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: <20090204162957.GZ15052@edu.joroinen.fi> References: <20090203202447.GU15052@edu.joroinen.fi> <20090204110350.GW15052@edu.joroinen.fi> <20090204121628.GI18191@salstar.sk> <49898A33.1080703@redhat.com> <20090204123523.GL18191@salstar.sk> <20090204162957.GZ15052@edu.joroinen.fi> Message-ID: <20090205080358.GC15052@edu.joroinen.fi> On Wed, Feb 04, 2009 at 06:29:57PM +0200, Pasi K?rkk?inen wrote: > On Wed, Feb 04, 2009 at 01:35:23PM +0100, Jan ONDREJ (SAL) wrote: > > On Wed, Feb 04, 2009 at 01:29:39PM +0100, Gerd Hoffmann wrote: > > > Jan ONDREJ (SAL) wrote: > > > > [root at note ~]# file /boot/xen-3.3.gz /boot/xen/vmlinux /boot/xen/initrd.img /boot/xen/bzImage > > > > /boot/xen-3.3.gz: gzip compressed data, from Unix, last modified: Tue Feb 3 12:36:39 2009, max compression > > > > /boot/xen/vmlinux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped > > > > > > "stripped". This probably is the problem. > > > > > > > /boot/xen/initrd.img: gzip compressed data, from Unix, last modified: Wed Feb 4 12:00:01 2009, max compression > > > > /boot/xen/bzImage: Linux kernel x86 boot executable RO-rootFS, swap_dev 0x2, Normal VGA > > > > > > Try this one instead of vmlinux (unstripped vmlinux should work too). > > > > Already tryed both of them. Stripped, unstripped vmlinux, gzip compressed > > vmlinux, bzImage. Always same problem. > > > > I've been using gzipped vmlinux pv_ops dom0 kernel successfully. > > I still haven't tried that new bzImage support .. will try that today or tomorrow. > I can confirm that bzImage pv_ops dom0 kernels boot OK with xen 3.3.1-3. I'm running on x86-32 (PAE) and I was using arch/x86/boot/bzImage from 2.6.29-rc3-tip as a dom0 kernel. -- Pasi From markmc at redhat.com Thu Feb 5 09:43:23 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 05 Feb 2009 09:43:23 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090204190945.GA20150@poweredge.glommer> References: <20090203201131.GA15314@poweredge.glommer> <1233769435.27853.1.camel@blaa> <20090204190945.GA20150@poweredge.glommer> Message-ID: <1233827003.6519.4.camel@blaa> On Wed, 2009-02-04 at 17:09 -0200, Glauber Costa wrote: > On Wed, Feb 04, 2009 at 05:43:55PM +0000, Mark McLoughlin wrote: > > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote: > > > Hi guys. > > > > > > I've built a qemu image in here: > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > > > It contains the basic work to get qemu package updated. Basically, > > > we're talking about getting the qemu code from svn > > ... > > > > Another thing to watch out for is the guidelines for numbering > > pre-release snapshots: > > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages > > > > According to those, I think this should be 0.9.2-0.1.svn6392 rather than > > 0.9.1-svn6392. > Let's let it this way for now. Let's follow the guidelines carefully written by people with more packaging experience than us :-) > I believe it's not yet certain that the new version will be called > 0.9.2, right? I think the point is 0.9.2 > 0.9.1, not so much that 0.9.2 will be what the next version will be called. Cheers, Mark. From berrange at redhat.com Thu Feb 5 10:46:09 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 5 Feb 2009 10:46:09 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090204221210.GD20150@poweredge.glommer> References: <20090203201131.GA15314@poweredge.glommer> <1233769435.27853.1.camel@blaa> <20090204221210.GD20150@poweredge.glommer> Message-ID: <20090205104609.GA2759@redhat.com> On Wed, Feb 04, 2009 at 08:12:10PM -0200, Glauber Costa wrote: > On Wed, Feb 04, 2009 at 05:43:55PM +0000, Mark McLoughlin wrote: > > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote: > > > Hi guys. > > > > > > I've built a qemu image in here: > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > > > It contains the basic work to get qemu package updated. Basically, > > > we're talking about getting the qemu code from svn > > ... > > > > Another thing to watch out for is the guidelines for numbering > > pre-release snapshots: > > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages > > > > According to those, I think this should be 0.9.2-0.1.svn6392 rather than > > 0.9.1-svn6392. > > > > Cheers, > > Mark. > > > I have a new test package in here: > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1105051 > > I haven't updated the name yet, but this is easy. > Apart from that, the .rpm are useless, as they don't include the firmware > images. (we don't want to ship the binary anyway, which was what current qemu > were doing). This is going to be harder to address for QEMU than it was with KVM. With KVM we only needed to build a native firmeware. For QEMU you need to build a PPC firmware to go along with the x86 build of the PPC emulator, etc. Not clear how we'd manage this very easily since we don't have cross compilers for every QEMU arch. > I'll work on it tomorrow. I plan to grab the various pieces needed to compile > the firmwares and other binaries, and colocate them in the same srpm as qemu. > > We can use separate packages if we must, but I don't see a big push for it. > We already separate the one which is most likely to be useful for someone else > (pxes). > > But I'm open to suggestions. Can you upload the src.rpm somewhere - when you do a scratch build from the local src.rpm, koji annoyingly does not make it available on the task page. 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 :| From dan at danny.cz Thu Feb 5 10:58:20 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 05 Feb 2009 11:58:20 +0100 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090205104609.GA2759@redhat.com> References: <20090203201131.GA15314@poweredge.glommer> <1233769435.27853.1.camel@blaa> <20090204221210.GD20150@poweredge.glommer> <20090205104609.GA2759@redhat.com> Message-ID: <1233831500.6181.55.camel@eagle.danny.cz> Daniel P. Berrange p??e v ?t 05. 02. 2009 v 10:46 +0000: > On Wed, Feb 04, 2009 at 08:12:10PM -0200, Glauber Costa wrote: > > On Wed, Feb 04, 2009 at 05:43:55PM +0000, Mark McLoughlin wrote: > > > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote: > > > > Hi guys. > > > > > > > > I've built a qemu image in here: > > > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > > > > > It contains the basic work to get qemu package updated. Basically, > > > > we're talking about getting the qemu code from svn > > > ... > > > > > > Another thing to watch out for is the guidelines for numbering > > > pre-release snapshots: > > > > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages > > > > > > According to those, I think this should be 0.9.2-0.1.svn6392 rather than > > > 0.9.1-svn6392. > > > > > > Cheers, > > > Mark. > > > > > I have a new test package in here: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1105051 > > > > I haven't updated the name yet, but this is easy. > > Apart from that, the .rpm are useless, as they don't include the firmware > > images. (we don't want to ship the binary anyway, which was what current qemu > > were doing). > > This is going to be harder to address for QEMU than it was with KVM. > With KVM we only needed to build a native firmeware. For QEMU you > need to build a PPC firmware to go along with the x86 build of the > PPC emulator, etc. Not clear how we'd manage this very easily since > we don't have cross compilers for every QEMU arch. > > > I'll work on it tomorrow. I plan to grab the various pieces needed to compile > > the firmwares and other binaries, and colocate them in the same srpm as qemu. > > > > We can use separate packages if we must, but I don't see a big push for it. > > We already separate the one which is most likely to be useful for someone else > > (pxes). > > > > But I'm open to suggestions. > > Can you upload the src.rpm somewhere - when you do a scratch build > from the local src.rpm, koji annoyingly does not make it available > on the task page. It is available - see the "Descendent Tasks" http://koji.fedoraproject.org/koji/taskinfo?taskID=1105052 http://koji.fedoraproject.org/koji/getfile?taskID=1105052&name=qemu-0.9.1-svn6392.fc11.src.rpm Dan From itamar at ispbrasil.com.br Thu Feb 5 11:02:17 2009 From: itamar at ispbrasil.com.br (Itamar Reis Peixoto) Date: Thu, 5 Feb 2009 09:02:17 -0200 Subject: [Fedora-xen] Re: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: <20090205080358.GC15052@edu.joroinen.fi> References: <20090203202447.GU15052@edu.joroinen.fi> <20090204110350.GW15052@edu.joroinen.fi> <20090204121628.GI18191@salstar.sk> <49898A33.1080703@redhat.com> <20090204123523.GL18191@salstar.sk> <20090204162957.GZ15052@edu.joroinen.fi> <20090205080358.GC15052@edu.joroinen.fi> Message-ID: any chance to someone build a rpm with dom0 available for testing ? > I can confirm that bzImage pv_ops dom0 kernels boot OK with xen 3.3.1-3. > > I'm running on x86-32 (PAE) and I was using arch/x86/boot/bzImage from > 2.6.29-rc3-tip as a dom0 kernel. > > -- Pasi > > _______________________________________________ > Fedora-virt mailing list > Fedora-virt at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-virt > -- ------------ Itamar Reis Peixoto e-mail/msn: itamar at ispbrasil.com.br sip: itamar at ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 From glommer at redhat.com Thu Feb 5 11:08:07 2009 From: glommer at redhat.com (Glauber Costa) Date: Thu, 5 Feb 2009 09:08:07 -0200 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090205104609.GA2759@redhat.com> References: <20090203201131.GA15314@poweredge.glommer> <1233769435.27853.1.camel@blaa> <20090204221210.GD20150@poweredge.glommer> <20090205104609.GA2759@redhat.com> Message-ID: <20090205110807.GA25132@poweredge.glommer> On Thu, Feb 05, 2009 at 10:46:09AM +0000, Daniel P. Berrange wrote: > On Wed, Feb 04, 2009 at 08:12:10PM -0200, Glauber Costa wrote: > > On Wed, Feb 04, 2009 at 05:43:55PM +0000, Mark McLoughlin wrote: > > > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote: > > > > Hi guys. > > > > > > > > I've built a qemu image in here: > > > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > > > > > It contains the basic work to get qemu package updated. Basically, > > > > we're talking about getting the qemu code from svn > > > ... > > > > > > Another thing to watch out for is the guidelines for numbering > > > pre-release snapshots: > > > > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages > > > > > > According to those, I think this should be 0.9.2-0.1.svn6392 rather than > > > 0.9.1-svn6392. > > > > > > Cheers, > > > Mark. > > > > > I have a new test package in here: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1105051 > > > > I haven't updated the name yet, but this is easy. > > Apart from that, the .rpm are useless, as they don't include the firmware > > images. (we don't want to ship the binary anyway, which was what current qemu > > were doing). > > This is going to be harder to address for QEMU than it was with KVM. > With KVM we only needed to build a native firmeware. For QEMU you > need to build a PPC firmware to go along with the x86 build of the > PPC emulator, etc. Not clear how we'd manage this very easily since > we don't have cross compilers for every QEMU arch. Ok, no cross compile, but we do have a pcc build sys, don't we? Because this is the way we do for the pxe roms. If we build on i386, we just build from sources. If we are in another arch, we pick a binary. The difference is that is's not the binary provided by qemu, but the very own we built for i386. From berrange at redhat.com Thu Feb 5 11:07:19 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 5 Feb 2009 11:07:19 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <1233831500.6181.55.camel@eagle.danny.cz> References: <20090203201131.GA15314@poweredge.glommer> <1233769435.27853.1.camel@blaa> <20090204221210.GD20150@poweredge.glommer> <20090205104609.GA2759@redhat.com> <1233831500.6181.55.camel@eagle.danny.cz> Message-ID: <20090205110719.GF2759@redhat.com> On Thu, Feb 05, 2009 at 11:58:20AM +0100, Dan Hor?k wrote: > Daniel P. Berrange p???e v ??t 05. 02. 2009 v 10:46 +0000: > > > > > I'll work on it tomorrow. I plan to grab the various pieces needed to compile > > > the firmwares and other binaries, and colocate them in the same srpm as qemu. > > > > > > We can use separate packages if we must, but I don't see a big push for it. > > > We already separate the one which is most likely to be useful for someone else > > > (pxes). > > > > > > But I'm open to suggestions. > > > > Can you upload the src.rpm somewhere - when you do a scratch build > > from the local src.rpm, koji annoyingly does not make it available > > on the task page. > > It is available - see the "Descendent Tasks" > http://koji.fedoraproject.org/koji/taskinfo?taskID=1105052 Hmm, that's very annoying - its only appearing under the 'ppc' task (which I never look at because PPC is irrelevant) and not appearing under the i386 / x86_64 arch tasks. 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 :| From dan at danny.cz Thu Feb 5 11:11:50 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 05 Feb 2009 12:11:50 +0100 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090205110719.GF2759@redhat.com> References: <20090203201131.GA15314@poweredge.glommer> <1233769435.27853.1.camel@blaa> <20090204221210.GD20150@poweredge.glommer> <20090205104609.GA2759@redhat.com> <1233831500.6181.55.camel@eagle.danny.cz> <20090205110719.GF2759@redhat.com> Message-ID: <1233832310.6181.57.camel@eagle.danny.cz> Daniel P. Berrange p??e v ?t 05. 02. 2009 v 11:07 +0000: > On Thu, Feb 05, 2009 at 11:58:20AM +0100, Dan Hor?k wrote: > > Daniel P. Berrange p???e v ??t 05. 02. 2009 v 10:46 +0000: > > > > > > > I'll work on it tomorrow. I plan to grab the various pieces needed to compile > > > > the firmwares and other binaries, and colocate them in the same srpm as qemu. > > > > > > > > We can use separate packages if we must, but I don't see a big push for it. > > > > We already separate the one which is most likely to be useful for someone else > > > > (pxes). > > > > > > > > But I'm open to suggestions. > > > > > > Can you upload the src.rpm somewhere - when you do a scratch build > > > from the local src.rpm, koji annoyingly does not make it available > > > on the task page. > > > > It is available - see the "Descendent Tasks" > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1105052 > > Hmm, that's very annoying - its only appearing under the 'ppc' task (which > I never look at because PPC is irrelevant) and not appearing under the > i386 / x86_64 arch tasks. It is true that didn't check the i386 or x86_64 tasks, I tried just the first one. Do you want to open a bug against koji or should I? Dan From berrange at redhat.com Thu Feb 5 11:15:48 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 5 Feb 2009 11:15:48 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090205110807.GA25132@poweredge.glommer> References: <20090203201131.GA15314@poweredge.glommer> <1233769435.27853.1.camel@blaa> <20090204221210.GD20150@poweredge.glommer> <20090205104609.GA2759@redhat.com> <20090205110807.GA25132@poweredge.glommer> Message-ID: <20090205111548.GH2759@redhat.com> On Thu, Feb 05, 2009 at 09:08:07AM -0200, Glauber Costa wrote: > On Thu, Feb 05, 2009 at 10:46:09AM +0000, Daniel P. Berrange wrote: > > On Wed, Feb 04, 2009 at 08:12:10PM -0200, Glauber Costa wrote: > > > I haven't updated the name yet, but this is easy. > > > Apart from that, the .rpm are useless, as they don't include the firmware > > > images. (we don't want to ship the binary anyway, which was what current qemu > > > were doing). > > > > This is going to be harder to address for QEMU than it was with KVM. > > With KVM we only needed to build a native firmeware. For QEMU you > > need to build a PPC firmware to go along with the x86 build of the > > PPC emulator, etc. Not clear how we'd manage this very easily since > > we don't have cross compilers for every QEMU arch. > Ok, no cross compile, but we do have a pcc build sys, don't we? > > Because this is the way we do for the pxe roms. If we build on i386, we just build > from sources. If we are in another arch, we pick a binary. The difference is > that is's not the binary provided by qemu, but the very own we built for > i386. Ewww. I just looked at the etherboot.spec file - that's gross :-) So every time you update the RPM build, you have to build twice. Once to get the correct new i386/x86_64 build. And then change the tar.gz with the prebuilt binaries, and build the RPM again, so that PPC gets done correctly ? So we can do x86 and ppc in Fedora with this trick. The sparc BIOS would need us to build in the Sparc secondary arch, and then import it back in to the main arch build system. 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 :| From markmc at redhat.com Thu Feb 5 11:15:54 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Thu, 05 Feb 2009 11:15:54 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090205104609.GA2759@redhat.com> References: <20090203201131.GA15314@poweredge.glommer> <1233769435.27853.1.camel@blaa> <20090204221210.GD20150@poweredge.glommer> <20090205104609.GA2759@redhat.com> Message-ID: <1233832554.6519.17.camel@blaa> On Thu, 2009-02-05 at 10:46 +0000, Daniel P. Berrange wrote: > On Wed, Feb 04, 2009 at 08:12:10PM -0200, Glauber Costa wrote: > > On Wed, Feb 04, 2009 at 05:43:55PM +0000, Mark McLoughlin wrote: > > > On Tue, 2009-02-03 at 18:11 -0200, Glauber Costa wrote: > > > > Hi guys. > > > > > > > > I've built a qemu image in here: > > > > > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1102151 > > > > > > > > It contains the basic work to get qemu package updated. Basically, > > > > we're talking about getting the qemu code from svn > > > ... > > > > > > Another thing to watch out for is the guidelines for numbering > > > pre-release snapshots: > > > > > > http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Pre-Release_packages > > > > > > According to those, I think this should be 0.9.2-0.1.svn6392 rather than > > > 0.9.1-svn6392. > > > > > > Cheers, > > > Mark. > > > > > I have a new test package in here: > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1105051 > > > > I haven't updated the name yet, but this is easy. > > Apart from that, the .rpm are useless, as they don't include the firmware > > images. (we don't want to ship the binary anyway, which was what current qemu > > were doing). > > This is going to be harder to address for QEMU than it was with KVM. > With KVM we only needed to build a native firmeware. For QEMU you > need to build a PPC firmware to go along with the x86 build of the > PPC emulator, etc. Not clear how we'd manage this very easily since > we don't have cross compilers for every QEMU arch. > > > I'll work on it tomorrow. I plan to grab the various pieces needed to compile > > the firmwares and other binaries, and colocate them in the same srpm as qemu. > > > > We can use separate packages if we must, but I don't see a big push for it. > > We already separate the one which is most likely to be useful for someone else > > (pxes). > > > > But I'm open to suggestions. > > Can you upload the src.rpm somewhere - when you do a scratch build > from the local src.rpm, koji annoyingly does not make it available > on the task page. It does, but it's kinda hard to spot it: http://koji.fedoraproject.org/koji/getfile?taskID=1105052&name=qemu-0.9.1-svn6392.fc11.src.rpm Cheers, Mark. From berrange at redhat.com Thu Feb 5 11:20:01 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Thu, 5 Feb 2009 11:20:01 +0000 Subject: [fedora-virt] QEMU new Package In-Reply-To: <1233832310.6181.57.camel@eagle.danny.cz> References: <20090203201131.GA15314@poweredge.glommer> <1233769435.27853.1.camel@blaa> <20090204221210.GD20150@poweredge.glommer> <20090205104609.GA2759@redhat.com> <1233831500.6181.55.camel@eagle.danny.cz> <20090205110719.GF2759@redhat.com> <1233832310.6181.57.camel@eagle.danny.cz> Message-ID: <20090205112001.GI2759@redhat.com> On Thu, Feb 05, 2009 at 12:11:50PM +0100, Dan Hor?k wrote: > Daniel P. Berrange p???e v ??t 05. 02. 2009 v 11:07 +0000: > > On Thu, Feb 05, 2009 at 11:58:20AM +0100, Dan Hor?k wrote: > > > Daniel P. Berrange p???e v ??t 05. 02. 2009 v 10:46 +0000: > > > > > > > > > I'll work on it tomorrow. I plan to grab the various pieces needed to compile > > > > > the firmwares and other binaries, and colocate them in the same srpm as qemu. > > > > > > > > > > We can use separate packages if we must, but I don't see a big push for it. > > > > > We already separate the one which is most likely to be useful for someone else > > > > > (pxes). > > > > > > > > > > But I'm open to suggestions. > > > > > > > > Can you upload the src.rpm somewhere - when you do a scratch build > > > > from the local src.rpm, koji annoyingly does not make it available > > > > on the task page. > > > > > > It is available - see the "Descendent Tasks" > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1105052 > > > > Hmm, that's very annoying - its only appearing under the 'ppc' task (which > > I never look at because PPC is irrelevant) and not appearing under the > > i386 / x86_64 arch tasks. > > It is true that didn't check the i386 or x86_64 tasks, I tried just the > first one. Do you want to open a bug against koji or should I? I'll let you. I would rather have expected the front page "Source: cli-build/1233783416.520371.CKwnmXVw/qemu-0.9.1-svn6392.fc11.src.rpm" to be a hyperlink to the src.rpm 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 :| From dan at danny.cz Thu Feb 5 11:37:32 2009 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Thu, 05 Feb 2009 12:37:32 +0100 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090205112001.GI2759@redhat.com> References: <20090203201131.GA15314@poweredge.glommer> <1233769435.27853.1.camel@blaa> <20090204221210.GD20150@poweredge.glommer> <20090205104609.GA2759@redhat.com> <1233831500.6181.55.camel@eagle.danny.cz> <20090205110719.GF2759@redhat.com> <1233832310.6181.57.camel@eagle.danny.cz> <20090205112001.GI2759@redhat.com> Message-ID: <1233833852.6181.58.camel@eagle.danny.cz> Daniel P. Berrange p??e v ?t 05. 02. 2009 v 11:20 +0000: > On Thu, Feb 05, 2009 at 12:11:50PM +0100, Dan Hor?k wrote: > > Daniel P. Berrange p???e v ??t 05. 02. 2009 v 11:07 +0000: > > > On Thu, Feb 05, 2009 at 11:58:20AM +0100, Dan Hor?k wrote: > > > > Daniel P. Berrange p???e v ??t 05. 02. 2009 v 10:46 +0000: > > > > > > > > > > > I'll work on it tomorrow. I plan to grab the various pieces needed to compile > > > > > > the firmwares and other binaries, and colocate them in the same srpm as qemu. > > > > > > > > > > > > We can use separate packages if we must, but I don't see a big push for it. > > > > > > We already separate the one which is most likely to be useful for someone else > > > > > > (pxes). > > > > > > > > > > > > But I'm open to suggestions. > > > > > > > > > > Can you upload the src.rpm somewhere - when you do a scratch build > > > > > from the local src.rpm, koji annoyingly does not make it available > > > > > on the task page. > > > > > > > > It is available - see the "Descendent Tasks" > > > > http://koji.fedoraproject.org/koji/taskinfo?taskID=1105052 > > > > > > Hmm, that's very annoying - its only appearing under the 'ppc' task (which > > > I never look at because PPC is irrelevant) and not appearing under the > > > i386 / x86_64 arch tasks. > > > > It is true that didn't check the i386 or x86_64 tasks, I tried just the > > first one. Do you want to open a bug against koji or should I? > > I'll let you. > > I would rather have expected the front page > > "Source: cli-build/1233783416.520371.CKwnmXVw/qemu-0.9.1-svn6392.fc11.src.rpm" > > to be a hyperlink to the src.rpm Done as https://fedorahosted.org/koji/ticket/129 Dan From m.a.young at durham.ac.uk Thu Feb 5 12:23:27 2009 From: m.a.young at durham.ac.uk (M A Young) Date: Thu, 5 Feb 2009 12:23:27 +0000 (GMT) Subject: [Fedora-xen] Re: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: References: <20090203202447.GU15052@edu.joroinen.fi> <20090204110350.GW15052@edu.joroinen.fi> <20090204121628.GI18191@salstar.sk> <49898A33.1080703@redhat.com> <20090204123523.GL18191@salstar.sk> <20090204162957.GZ15052@edu.joroinen.fi> <20090205080358.GC15052@edu.joroinen.fi> Message-ID: On Thu, 5 Feb 2009, Itamar Reis Peixoto wrote: > any chance to someone build a rpm with dom0 available for testing ? I am not convinced that dom0 support is really stable enough to do that yet, because some key aspects are broken such as some hard disk support, and the code is still rather a moving target which doesn't always build. Michael Young From ondrejj at salstar.sk Thu Feb 5 12:37:06 2009 From: ondrejj at salstar.sk (Jan ONDREJ (SAL)) Date: Thu, 5 Feb 2009 13:37:06 +0100 Subject: [Fedora-xen] Re: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: References: <20090203202447.GU15052@edu.joroinen.fi> <20090204110350.GW15052@edu.joroinen.fi> <20090204121628.GI18191@salstar.sk> <49898A33.1080703@redhat.com> <20090204123523.GL18191@salstar.sk> <20090204162957.GZ15052@edu.joroinen.fi> <20090205080358.GC15052@edu.joroinen.fi> Message-ID: <20090205123706.GU18191@salstar.sk> On Thu, Feb 05, 2009 at 12:23:27PM +0000, M A Young wrote: > On Thu, 5 Feb 2009, Itamar Reis Peixoto wrote: > >> any chance to someone build a rpm with dom0 available for testing ? I am trying to create one, but without success yet. I have an 2.6.29-rc3-tip kernel with dom0 support, it now can boot using xen-3.3.gz, but immediatelly after boot my fonts are gone. I don't know what to do without console. My cursor is sometimes moving, just I can't control it (may be console and keyboard are not working). Can somebody help me, what I am doing wrong? My last functional compiled kernel was 1.3.XX and it is some years ago. :) > I am not convinced that dom0 support is really stable enough to do that > yet, because some key aspects are broken such as some hard disk support, > and the code is still rather a moving target which doesn't always build. Right. When trying to compile 2.6.29-rc3+xen, I need to turn off xen*frontentds and xen*backend drivers have to be compiled into kernel, not as modules. After this I have a functional kernel, but after booting with xen-3.3.gz, my screen is blank. SAL From glommer at redhat.com Thu Feb 5 12:42:48 2009 From: glommer at redhat.com (Glauber Costa) Date: Thu, 5 Feb 2009 10:42:48 -0200 Subject: [fedora-virt] QEMU new Package In-Reply-To: <20090205111548.GH2759@redhat.com> References: <20090203201131.GA15314@poweredge.glommer> <1233769435.27853.1.camel@blaa> <20090204221210.GD20150@poweredge.glommer> <20090205104609.GA2759@redhat.com> <20090205110807.GA25132@poweredge.glommer> <20090205111548.GH2759@redhat.com> Message-ID: <20090205124248.GB25132@poweredge.glommer> On Thu, Feb 05, 2009 at 11:15:48AM +0000, Daniel P. Berrange wrote: > On Thu, Feb 05, 2009 at 09:08:07AM -0200, Glauber Costa wrote: > > On Thu, Feb 05, 2009 at 10:46:09AM +0000, Daniel P. Berrange wrote: > > > On Wed, Feb 04, 2009 at 08:12:10PM -0200, Glauber Costa wrote: > > > > I haven't updated the name yet, but this is easy. > > > > Apart from that, the .rpm are useless, as they don't include the firmware > > > > images. (we don't want to ship the binary anyway, which was what current qemu > > > > were doing). > > > > > > This is going to be harder to address for QEMU than it was with KVM. > > > With KVM we only needed to build a native firmeware. For QEMU you > > > need to build a PPC firmware to go along with the x86 build of the > > > PPC emulator, etc. Not clear how we'd manage this very easily since > > > we don't have cross compilers for every QEMU arch. > > Ok, no cross compile, but we do have a pcc build sys, don't we? > > > > Because this is the way we do for the pxe roms. If we build on i386, we just build > > from sources. If we are in another arch, we pick a binary. The difference is > > that is's not the binary provided by qemu, but the very own we built for > > i386. > > Ewww. I just looked at the etherboot.spec file - that's gross :-) > > So every time you update the RPM build, you have to build twice. Once > to get the correct new i386/x86_64 build. And then change the tar.gz > with the prebuilt binaries, and build the RPM again, so that PPC gets > done correctly ? > > So we can do x86 and ppc in Fedora with this trick. The sparc BIOS would > need us to build in the Sparc secondary arch, and then import it back in > to the main arch build system. yeah, it's totally gross, but I believe it's the best alternative we have so far. We lack rpm support for a more decent arrangement. However, if this is the case, I'd strongly suggest we do alternate packages. Doing it all inside qemu would severely complicate it. Most of bioses are projects on their own anyway. From pasik at iki.fi Thu Feb 5 14:34:14 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Thu, 5 Feb 2009 16:34:14 +0200 Subject: [Fedora-xen] Re: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: <20090205123706.GU18191@salstar.sk> References: <20090204110350.GW15052@edu.joroinen.fi> <20090204121628.GI18191@salstar.sk> <49898A33.1080703@redhat.com> <20090204123523.GL18191@salstar.sk> <20090204162957.GZ15052@edu.joroinen.fi> <20090205080358.GC15052@edu.joroinen.fi> <20090205123706.GU18191@salstar.sk> Message-ID: <20090205143414.GG15052@edu.joroinen.fi> On Thu, Feb 05, 2009 at 01:37:06PM +0100, Jan ONDREJ (SAL) wrote: > On Thu, Feb 05, 2009 at 12:23:27PM +0000, M A Young wrote: > > On Thu, 5 Feb 2009, Itamar Reis Peixoto wrote: > > > >> any chance to someone build a rpm with dom0 available for testing ? > > I am trying to create one, but without success yet. > > I have an 2.6.29-rc3-tip kernel with dom0 support, it now can boot using > xen-3.3.gz, but immediatelly after boot my fonts are gone. I don't know what > to do without console. My cursor is sometimes moving, just I can't control > it (may be console and keyboard are not working). Can somebody help me, what > I am doing wrong? My last functional compiled kernel was 1.3.XX and it is > some years ago. :) > > > I am not convinced that dom0 support is really stable enough to do that > > yet, because some key aspects are broken such as some hard disk support, > > and the code is still rather a moving target which doesn't always build. > > Right. > > When trying to compile 2.6.29-rc3+xen, I need to turn off xen*frontentds > and xen*backend drivers have to be compiled into kernel, not as modules. > After this I have a functional kernel, but after booting with xen-3.3.gz, my > screen is blank. > I haven't gotten the pv_ops dom0 kernel VGA text console to work at all yet.. I've been using serial console. I guess fixing the console would be the next thing to do after disk problems are fixed:) -- Pasi From pasik at iki.fi Wed Feb 4 16:29:57 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Wed, 4 Feb 2009 18:29:57 +0200 Subject: [Fedora-xen] Re: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: <20090204123523.GL18191@salstar.sk> References: <20090203202447.GU15052@edu.joroinen.fi> <20090204110350.GW15052@edu.joroinen.fi> <20090204121628.GI18191@salstar.sk> <49898A33.1080703@redhat.com> <20090204123523.GL18191@salstar.sk> Message-ID: <20090204162957.GZ15052@edu.joroinen.fi> On Wed, Feb 04, 2009 at 01:35:23PM +0100, Jan ONDREJ (SAL) wrote: > On Wed, Feb 04, 2009 at 01:29:39PM +0100, Gerd Hoffmann wrote: > > Jan ONDREJ (SAL) wrote: > > > [root at note ~]# file /boot/xen-3.3.gz /boot/xen/vmlinux /boot/xen/initrd.img /boot/xen/bzImage > > > /boot/xen-3.3.gz: gzip compressed data, from Unix, last modified: Tue Feb 3 12:36:39 2009, max compression > > > /boot/xen/vmlinux: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped > > > > "stripped". This probably is the problem. > > > > > /boot/xen/initrd.img: gzip compressed data, from Unix, last modified: Wed Feb 4 12:00:01 2009, max compression > > > /boot/xen/bzImage: Linux kernel x86 boot executable RO-rootFS, swap_dev 0x2, Normal VGA > > > > Try this one instead of vmlinux (unstripped vmlinux should work too). > > Already tryed both of them. Stripped, unstripped vmlinux, gzip compressed > vmlinux, bzImage. Always same problem. > I've been using gzipped vmlinux pv_ops dom0 kernel successfully. I still haven't tried that new bzImage support .. will try that today or tomorrow. -- Pasi -- Fedora-xen mailing list Fedora-xen at redhat.com https://www.redhat.com/mailman/listinfo/fedora-xen From m.a.young at durham.ac.uk Fri Feb 6 00:37:42 2009 From: m.a.young at durham.ac.uk (M A Young) Date: Fri, 6 Feb 2009 00:37:42 +0000 (GMT) Subject: [Fedora-xen] Re: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: <20090205143414.GG15052@edu.joroinen.fi> References: <20090204110350.GW15052@edu.joroinen.fi> <20090204121628.GI18191@salstar.sk> <49898A33.1080703@redhat.com> <20090204123523.GL18191@salstar.sk> <20090204162957.GZ15052@edu.joroinen.fi> <20090205080358.GC15052@edu.joroinen.fi> <20090205123706.GU18191@salstar.sk> <20090205143414.GG15052@edu.joroinen.fi> Message-ID: On Thu, 5 Feb 2009, Pasi K?rkk?inen wrote: > On Thu, Feb 05, 2009 at 01:37:06PM +0100, Jan ONDREJ (SAL) wrote: >> When trying to compile 2.6.29-rc3+xen, I need to turn off xen*frontentds >> and xen*backend drivers have to be compiled into kernel, not as modules. >> After this I have a functional kernel, but after booting with xen-3.3.gz, my >> screen is blank. >> > > I haven't gotten the pv_ops dom0 kernel VGA text console to work at all > yet.. > > I've been using serial console. I have the VGA console printing boot messages from the kernel with the configuration title xen test root (hd0,5) kernel /xen-3.3.gz module /vmlinuz-2.6.29-rc3-tip ro root=UUID=00000000-0000-0000-0000-000000000000 single pci=nomsi maxcpus=1 module /initrd-2.6.29-rc3-tip.img though it crashes before it gets as far as a prompt. This is x86_64. However I have another machine that goes blank after the XEN output (though I am not sure I have tried it with precisely the same options) which is an i686. The difference might be nothing to do with the boot options though, and could relate to graphics cards or precisely how plymouth is set up. Michael Young From markmc at redhat.com Fri Feb 6 08:33:26 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 06 Feb 2009 08:33:26 +0000 Subject: [fedora-virt] Xen pv_ops domU :: BUG() in remove_from_page_cache() Message-ID: <1233909206.3673.30.camel@blaa> Hi, 2.6.29-rc3 x86_64 guest on x86_64 RHEL5.3 host: https://bugzilla.redhat.com/484295 kernel BUG at mm/filemap.c:123! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC last sysfs file: /sys/devices/vbd-51712/block/xvda/xvda2/dev CPU 0 Modules linked in: ipv6 xts lrw gf128mul sha256_generic cbc dm_crypt dm_round_robin dm_multipath btrfs zlib_deflate libcrc32c xfs exportfs jfs reiserfs gfs2 msdos linear raid10 raid456 async_xor async_memcpy async_tx xor raid1 raid0 xen_netfront xen_blkfront iscsi_ibft iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ext2 ext4 jbd2 crc16 squashfs pcspkr nfs lockd nfs_acl auth_rpcgss sunrpc vfat fat cramfs Pid: 975, comm: sh Tainted: G B W 2.6.29-0.66.rc3.fc11.x86_64 #1 RIP: e030:[] [] __remove_from_page_cache+0x40/0xde RSP: e02b:ffff88007081f928 EFLAGS: 00010002 RAX: 000000000000000d RBX: ffffe20002e9b900 RCX: 0000000000000005 RDX: ffff88000000ac48 RSI: fffffffffffffff0 RDI: ffff880000009700 RBP: ffff88007081f938 R08: 0000000000000009 R09: ffff88007fc010c8 R10: ffffffff81087cc0 R11: ffff88007fa0b328 R12: ffff88007ba2d160 R13: 000000000000003a R14: 0000000000000002 R15: ffff88007081f9e8 FS: 00007f0a1576d6f0(0000) GS:ffffffff81934000(0000) knlGS:0000000000000000 CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f6308fd5580 CR3: 0000000001001000 CR4: 0000000000000660 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000000 Process sh (pid: 975, threadinfo ffff88007081e000, task ffff880070dda390) Stack: ffff88007ba2d178 ffffe20002e9b900 ffff88007081f958 ffffffff810a8c67 ffffe20002e9b900 000000000000003a ffff88007081f978 ffffffff810b0b27 0000000000000002 ffffe20002e9b900 ffff88007081fa78 ffffffff810b0c2b Call Trace: [] remove_from_page_cache+0x2b/0x38 [] truncate_complete_page+0x4c/0x61 [] truncate_inode_pages_range+0xef/0x36e [] truncate_inode_pages+0xd/0x12 [] dispose_list+0x3b/0xf8 [] invalidate_inodes+0xdc/0xfa [] generic_shutdown_super+0x4a/0xe8 [] kill_block_super+0x22/0x3a [] deactivate_super+0x68/0x7d [] mntput_no_expire+0x10d/0x14e [] __fput+0x18a/0x197 [] fput+0x18/0x1a [] remove_vma+0x4f/0x85 [] exit_mmap+0x11b/0x13d [] mmput+0x45/0xa4 [] exit_mm+0x114/0x120 [] do_exit+0x1da/0x8b4 [] ? lock_acquired+0x29e/0x2ae [] ? get_signal_to_deliver+0x61/0x2b8 [] do_group_exit+0x7f/0xaf [] ? _spin_unlock_irq+0x32/0x37 [] get_signal_to_deliver+0x29a/0x2b8 [] do_notify_resume+0x90/0x8a4 [] ? _spin_unlock_irqrestore+0x40/0x57 [] ? trace_hardirqs_off_caller+0x1f/0xac [] ? _spin_unlock_irqrestore+0x47/0x57 [] ? trace_hardirqs_on_caller+0x1f/0x153 [] ? tty_ldisc_deref+0x69/0x6e [] ? tty_read+0x87/0xba [] ? sysret_signal+0x5/0x109 [] ? trace_hardirqs_on_caller+0x1f/0x153 [] sysret_signal+0x9b/0x109 Code: 24 08 e8 3a ad 0e 00 48 c7 43 18 00 00 00 00 49 ff 8c 24 c8 00 00 00 be 09 00 00 00 48 89 df e8 e9 f3 00 00 8b 43 0c 85 c0 78 04 <0f> 0b eb fe 48 89 df e8 b7 35 03 00 f6 03 10 0f 84 84 00 00 00 RIP [] __remove_from_page_cache+0x40/0xde RSP Cheers, Mark. From pasik at iki.fi Fri Feb 6 11:42:38 2009 From: pasik at iki.fi (Pasi =?iso-8859-1?Q?K=E4rkk=E4inen?=) Date: Fri, 6 Feb 2009 13:42:38 +0200 Subject: [Fedora-xen] Re: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: References: <20090204121628.GI18191@salstar.sk> <49898A33.1080703@redhat.com> <20090204123523.GL18191@salstar.sk> <20090204162957.GZ15052@edu.joroinen.fi> <20090205080358.GC15052@edu.joroinen.fi> <20090205123706.GU18191@salstar.sk> <20090205143414.GG15052@edu.joroinen.fi> Message-ID: <20090206114238.GO15052@edu.joroinen.fi> On Fri, Feb 06, 2009 at 12:37:42AM +0000, M A Young wrote: > On Thu, 5 Feb 2009, Pasi K?rkk?inen wrote: > > >On Thu, Feb 05, 2009 at 01:37:06PM +0100, Jan ONDREJ (SAL) wrote: > >>When trying to compile 2.6.29-rc3+xen, I need to turn off xen*frontentds > >>and xen*backend drivers have to be compiled into kernel, not as modules. > >>After this I have a functional kernel, but after booting with xen-3.3.gz, > >>my > >>screen is blank. > >> > > > >I haven't gotten the pv_ops dom0 kernel VGA text console to work at all > >yet.. > > > >I've been using serial console. > > I have the VGA console printing boot messages from the kernel with the > configuration > > title xen test > root (hd0,5) > kernel /xen-3.3.gz > module /vmlinuz-2.6.29-rc3-tip ro > root=UUID=00000000-0000-0000-0000-000000000000 single pci=nomsi > maxcpus=1 > module /initrd-2.6.29-rc3-tip.img > > though it crashes before it gets as far as a prompt. This is x86_64. > However I have another machine that goes blank after the XEN output > (though I am not sure I have tried it with precisely the same options) > which is an i686. The difference might be nothing to do with the boot > options though, and could relate to graphics cards or precisely how > plymouth is set up. > Yeah, that's my problem too.. VGA text console goes blank when dom0 kernel is booted.. Xen hypervisor messages are displayed OK (before the dom0 kernel). I'm running also 32bit Xen and dom0. -- Pasi From markmc at redhat.com Fri Feb 6 18:41:30 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 06 Feb 2009 18:41:30 +0000 Subject: [fedora-virt] Weekly virt status Message-ID: <1233945690.27709.66.camel@blaa> 2009-03-03 Feature freeze (25 days) 2009-03-10 Beta Freeze (32 days) 2009-04-14 Final freeze (67 days) F11 Alpha, Take 3 ================= The weird anaconda blocker which caused hang while moving to the timezone screen was never figured out, but it turns out that later rawhide didn't have this bug. Truly bizarre: https://bugzilla.redhat.com/482907 Because of this, rel-eng froze Alpha for the third time. After that things got even more messy and even more confusing: http://www.redhat.com/archives/fedora-devel-list/2009-January/msg01844.html Another blocker cropped up, this time VNC installs failing: https://bugzilla.redhat.com/483399 In the end, after a mere two day slip, the installer gods were appeased and Fedora 11 Alpha (blink) shipped to an eagerly waiting public: http://www.redhat.com/archives/fedora-announce-list/2009-February/msg00004.html On the virt side, the "disable kvmclock on machines with unsync TSC" workaround ended up making it in at the last minute: https://bugzilla.redhat.com/475598 Unfortunately, what looks like a pvmmu bug didn't get fixed in time: https://bugzilla.redhat.com/480822 This causes some guest installs on an F11 Alpha host to oops during heavy network activity. FWN === Another edition of FWN, and another excellent virt section: http://fedoraproject.org/wiki/FWN/Issue161#Virtualization Thanks to Dale Bewley. F11 Release Notes ================= Dale Bewley has begun work on the F11 release notes: http://fedoraproject.org/wiki/Documentation_Virtualization_Beat The "Unified Kernel Image" section provided some minior confusion on the fedora-virt list: 'The kernel package in Fedora 11 supports booting as a guest domU, but will not function as a dom0 until such support is provided upstream. The most recent Fedora release with dom0 support is Fedora 8.' To which one user responded: As I write this, I am running F10 on a hardware virt enabled machine ... and have installed F10 and other distros as guests. Hence, the statement above is unclear to me for F10 is running as both dom0 and domU. Am I not reading something right? The confusion here is that folks use the terms "dom0" and domU to refer to Xen, whereas the user in question is actually running KVM. The equivalent terms for KVM tend to just be "KVM host" and "KVM guest". libvirt ======= While on vacation, Daniel Veillard released libvirt 0.6.0: http://www.redhat.com/archives/libvir-list/2009-January/msg00863.html * New features: - thread safety of the API and event handling (Daniel Berrange) - allow QEmu domains to survive daemon restart (Guido Gunther) - extended logging capabilities (Daniel Veillard) - support copy-on-write storage volumes (Daniel Berrange) - support of storage cache control options for QEmu/KVM (Daniel Berrange) Understandably, a number of post-release issues cropped up: https://bugzilla.redhat.com/484199 SELinux issue causing libvirtd launched dnsmasq to fail This causes libvirt virtual networks to fail to start. The fix will involve a small update to libvirt and selinux-policy changes. https://bugzilla.redhat.com/484414 libvir: Remote error : no call waiting for reply with serial 2 Dan Berrange has a fix for this upstream Also, there are reports that if QEMU is too slow starting up, it can fail: http://www.redhat.com/archives/libvir-list/2009-February/msg00143.html A lively update was had as to whether the libvirt-0.6.0 update in F9 and F10 updates-testing should be withdrawn until some of the issues are resolved. The current plan is to just fix the issues ASAP with further updates to libvirt and selinux-policy. F11 Features ============ All F11 virt features are now available under: https://fedoraproject.org/wiki/Category:F11_Virt_Features KVM/QEMU Merge ============== Glauber posted an initial qemu package, and solicited feedback. This package did two things: 1) Updated to a snapshot of QEMU svn and 2) Split the package into multiple sub-package, with a sub-package for each target architecture There was some concern that updating to QEMU svn is not a good idea until it is known that a QEMU release is due soon. By coincidence, Anthony Liguori proposed doing a QEMU release at the end of February: http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00138.html All involved were mightily relieved. The discussion then moved on to a near-bikeshed argument about how to split the package. In the end, it was agreed to go with: - qemu-common, containing core bits - qemu-system-* packages containing emulators for groups of architectures, e.g. qemu-system-x86 - qemu-user, containing the Linux kernel ABI emulators for all architectures - qemu, a meta package which requires all sub-packages for compatibility purposes Further discussion was had on how to handle the building of BIOS images. [Details redacted to avoid scaring the children] The whole thread can be found here: http://www.redhat.com/archives/fedora-virt/2009-February/thread.html#00000 Also related, Eduardo added a kvm-tools sub-package containing kvm_stat and kvmtrace: https://bugzilla.redhat.com/480942 Device Assignment ================= The CONFIG_DMAR issue lumbered on this week. Firstly, Kyle McMartin's patch to make intel_iommu=off the default is now in Andrew Morton's queue for 2.6.29. Progress on fixing the underlying issue is slow, but steady: https://bugzilla.redhat.com/479996 The focus is now on the fact that delaying for 2us after flushing the I/O page tables from the CPU cache appears to resolve the problem. Adar and Bhavesh from VMware are busily debugging the issue on hardware which shows the problem. David Woodhouse and Chris Wright have been working on patches to aid debugging. David has also included Joerg Roedel's CONFIG_DMA_API_DEBUG patches in Fedora rawhide. In other news, a minor circular locking issue was found and fixed: http://www.mail-archive.com/kvm at vger.kernel.org/msg10116.html Also, Weidong Han re-posted several device assignment fixes for QEMU which had fallen through the cracks: http://www.mail-archive.com/kvm at vger.kernel.org/msg10116.html Some offline discussion was had around how to handle resetting PCI devices before and after assignming them to guests. The details are long and involved, but the core of the problem is that devices must be reset before being assigned if they have been previously used in the host. For example, with an e1000e NIC this manifests itself with "TX Unit Hang" errors in the guest. Unfortunately, the preferred method for resetting a PCI device (Function Level Reset, or FLR) is not implemented by many devices. Alternatives include Secondary Bus Reset and PCI PM D-state transitions. Both will need to be implemented in addition to FLR support. Xen Dom0 ======== Some welcome interest was renewed in Xen Dom0 support on the fedora-virt list this week with Gerd Hoffmann's addition of bzImage loading support to the hypervisor: http://www.redhat.com/archives/fedora-virt/2009-February/msg00001.html Several fedora-virt users are now building and testing Dom0 kernels using Jeremy Fitzhardinge's latest patch set. kernel arches ============= Some changes to kernel architectures are on their way: https://fedoraproject.org/wiki/Features/ArchitectureSupport The main user-visible changes would be: * 32-bit x86 would be built for i586 by default. * The x86_64 kernel would be installed on compatible hardware, even when installing a 32-bit OS * The PAE kernel would be installed on other 32-bit hardware, where it is supported The proposal was accepted by FESCo and the kernel changes are already in rawhide. gcc 4.4 ======== gcc-4.4 is coming in F11: https://fedoraproject.org/wiki/Features/gcc4.4 Jakub Jelinek did a test mass-rebuild of rawhide this week: http://www.redhat.com/archives/fedora-devel-list/2009-February/msg00180.html It seemed to go pretty well. No virt packages had any problems. Bugs ==== DOOM-O-METER: 191 open bugs last week, 192 this week. Awww! https://bugzilla.redhat.com/480822 new_slab() oops from alloc_skb() with virtio_net, e1000 and rtl8139 Marcelo jumped on this and began investigating. At first it looked like that it was a SLUB issue. However, the crafty Marcelo came up with a crafty LD_PRELOAD lib for disabling pvmmu for testing. Using Marcelo's hack, James Laska confirmed that the culprit is pvmmu. https://bugzilla.redhat.com/480779 https://bugzilla.redhat.com/483204 Both nVidia users who reported KVM MMU issues tryied to reproduce without nvidia loaded. The first reporter did indeed reproduce without nVidia and Marcelo logged into his machine. The problem turned out to be dodgy RAM though. Take home point - if something funny is going on, try running memtest. https://bugzilla.redhat.com/483648 BUG_ON() in __shrink_dcache_sb() in rawhide x86_64 guest Another oops reported by James Laska. Not yet investigated. https://bugzilla.redhat.com/484364 block-rw-range-check.patch breaks qcow2 Fedora's single not-upstream kvm-userspace patch causes us to fail under kvm-autotest. https://bugzilla.redhat.com/464790 qemu bios images source code not packaged The BIOS images in the qemu package aren't currently built from source. This is fixed in the kvm package, so should be resolved when we merge the two. https://bugzilla.redhat.com/484166 QEmu uses 100% of two assigned cores for XP guest Perhaps the known issue with guest CPU usage accounting? https://bugzilla.redhat.com/467687 https://bugzilla.redhat.com/463298 virbr0 loses it's routing when managed by NetworkManager Reporter can't reproduce after an upgrade to f10, but it seems fairly certain that the problem was something twiddling ip_forward. https://bugzilla.redhat.com/444273 The second request in recent times for libvirt autostart domains to be autoshutdown https://bugzilla.redhat.com/477955 Sound under KVM requires exclusive access to the sound device The debate continues on how to integrate with a user's sound configuration. https://bugzilla.redhat.com/459665 Issue with remote libvirt connections via SSH under virt-manager https://bugzilla.redhat.com/484097 ambiguous dialog Jon McCann noticed a virt-manager dialog: Not Enough Free Space The requested volume capacity will exceed the available pool space when the volume is fully allocated. (4000M requested capacity >2118M available) [No] [Yes] I say "Yes!". Or maybe "No!". No, "Yes!" ... :-) https://bugzilla.redhat.com/484295 xen pv_ops DomU BUG() after alpha install From jeremy at goop.org Sat Feb 7 01:14:15 2009 From: jeremy at goop.org (Jeremy Fitzhardinge) Date: Fri, 06 Feb 2009 17:14:15 -0800 Subject: [fedora-virt] Re: [Xen-devel] Xen pv_ops domU :: BUG() in remove_from_page_cache() In-Reply-To: <1233909206.3673.30.camel@blaa> References: <1233909206.3673.30.camel@blaa> Message-ID: <498CE067.5000902@goop.org> Mark McLoughlin wrote: > Hi, > > 2.6.29-rc3 x86_64 guest on x86_64 RHEL5.3 host: > > https://bugzilla.redhat.com/484295 > > kernel BUG at mm/filemap.c:123! > invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC > This will fix it. I hope. J Subject: x86: don't apply __supported_pte_mask to non-present ptes __supported_pte_mask contains the set of flags we support on the current hardware. We also use bits in the pte for things like logically present ptes with no permissions, and swap entries for swapped out pages. We should only apply __supported_pte_mask to present ptes, because otherwise we may destroy other information being stored in the ptes. Signed-off-by: Jeremy Fitzhardinge --- arch/x86/include/asm/pgtable.h | 26 ++++++++++++++++++++------ arch/x86/include/asm/xen/page.h | 2 +- 2 files changed, 21 insertions(+), 7 deletions(-) =================================================================== --- a/arch/x86/include/asm/pgtable.h +++ b/arch/x86/include/asm/pgtable.h @@ -316,16 +316,30 @@ extern pteval_t __supported_pte_mask; +/* + * Mask out unsupported bits in a present pgprot. Non-present pgprots + * can use those bits for other purposes, so leave them be. + */ +static inline pgprotval_t massage_pgprot(pgprot_t pgprot) +{ + pgprotval_t protval = pgprot_val(pgprot); + + if (protval & _PAGE_PRESENT) + protval &= __supported_pte_mask; + + return protval; +} + static inline pte_t pfn_pte(unsigned long page_nr, pgprot_t pgprot) { - return __pte((((phys_addr_t)page_nr << PAGE_SHIFT) | - pgprot_val(pgprot)) & __supported_pte_mask); + return __pte(((phys_addr_t)page_nr << PAGE_SHIFT) | + massage_pgprot(pgprot)); } static inline pmd_t pfn_pmd(unsigned long page_nr, pgprot_t pgprot) { - return __pmd((((phys_addr_t)page_nr << PAGE_SHIFT) | - pgprot_val(pgprot)) & __supported_pte_mask); + return __pmd(((phys_addr_t)page_nr << PAGE_SHIFT) | + massage_pgprot(pgprot)); } static inline pte_t pte_modify(pte_t pte, pgprot_t newprot) @@ -337,7 +351,7 @@ * the newprot (if present): */ val &= _PAGE_CHG_MASK; - val |= pgprot_val(newprot) & (~_PAGE_CHG_MASK) & __supported_pte_mask; + val |= massage_pgprot(newprot) & ~_PAGE_CHG_MASK; return __pte(val); } @@ -353,7 +367,7 @@ #define pte_pgprot(x) __pgprot(pte_flags(x) & PTE_FLAGS_MASK) -#define canon_pgprot(p) __pgprot(pgprot_val(p) & __supported_pte_mask) +#define canon_pgprot(p) __pgprot(massage_pgprot(p)) static inline int is_new_memtype_allowed(unsigned long flags, unsigned long new_flags) =================================================================== --- a/arch/x86/include/asm/xen/page.h +++ b/arch/x86/include/asm/xen/page.h @@ -137,7 +137,7 @@ pte_t pte; pte.pte = ((phys_addr_t)page_nr << PAGE_SHIFT) | - (pgprot_val(pgprot) & __supported_pte_mask); + massage_pgprot(pgprot); return pte; } From kraxel at redhat.com Mon Feb 9 14:24:59 2009 From: kraxel at redhat.com (Gerd Hoffmann) Date: Mon, 09 Feb 2009 15:24:59 +0100 Subject: [Fedora-xen] Re: [fedora-virt] bzImage dom0 kernel support in latest rawhide Xen packages In-Reply-To: <20090206114238.GO15052@edu.joroinen.fi> References: <20090204121628.GI18191@salstar.sk> <49898A33.1080703@redhat.com> <20090204123523.GL18191@salstar.sk> <20090204162957.GZ15052@edu.joroinen.fi> <20090205080358.GC15052@edu.joroinen.fi> <20090205123706.GU18191@salstar.sk> <20090205143414.GG15052@edu.joroinen.fi> <20090206114238.GO15052@edu.joroinen.fi> Message-ID: <49903CBB.30403@redhat.com> Pasi K?rkk?inen wrote: > Yeah, that's my problem too.. VGA text console goes blank when dom0 kernel is > booted.. Xen hypervisor messages are displayed OK (before the dom0 kernel). > > I'm running also 32bit Xen and dom0. Noticed that the laptop shows dom0 kernel messages when booting xen with "vga=gfx-1024x768x16". Text mode stays blank for me too. cheers, Gerd From glommer at redhat.com Thu Feb 12 15:29:50 2009 From: glommer at redhat.com (Glauber Costa) Date: Thu, 12 Feb 2009 13:29:50 -0200 Subject: [fedora-virt] qemu/kvm status Message-ID: <20090212152950.GB2150@poweredge.glommer> Hello guys I hope you're all doing fine, with joy in your hearts. After a adventurous while, I have updated and QAed a new qemu srpm. I worked mostly on x86 and sparc QA, since they are the ones in which we have to build additional firmware. Speaking of firware, for the very same reason as etherboot[1], I'm proposing some new packages. They are: Bochs bios: http://glommer.fedorapeople.org/bochs-bios-2.3.8-0.1.git36989b0d2.fc11.src.rpm http://koji.fedoraproject.org/koji/taskinfo?taskID=1121809 OpenBIOS: http://glommer.fedorapeople.org/openbios-1.0-0.1.svn450.fc11.src.rpm http://koji.fedoraproject.org/koji/taskinfo?taskID=1119906 VGABIOS: http://glommer.fedorapeople.org/vgabios-0.6-0.1beta.fc11.src.rpm http://koji.fedoraproject.org/koji/taskinfo?taskID=1120633 I'm not shouting the final review yet, since I'd like to reach agreement on whatever matters may arise, in here. The qemu source package can be found at: http://glommer.fedorapeople.org/qemu-0.9.2-0.1.svn6392.fc11.src.rpm The x86 system emulator depends on bochs-bios and vgabios. The sparc system emulator depends on openbios Openbios should be used for powerpc too, but upstream is not yet confident on that. So as I was having troubles building it, I just left them commented for this round. If everybody is okay with that modulo minor comments to the packages, my next plan is: 1) Submmit new packages for review 2) Commit new qemu to CVS 3) Get KVM in the package. I prefer to do this in two steps, since it will get easier to spot anything that might go wrong 4) Have a bottle of wine. [1] Most firmware is compiled for one specific architecture, but should run on qemu whichever your host architecture is. We don't have a cross compiler infra in place, so we have to compile it natively. The easiest would be to pick binaries directly from upstream, which usually provides it. But we have policies that say we have to build everything we ship. So we have a crazy bootstrap process in place, in which we first build natively, and then feed a tar.gz for the other architectures. It means every package should be built at least twice in the process of getting something out of the door. From virtualization at webwombat.com.au Thu Feb 12 23:44:42 2009 From: virtualization at webwombat.com.au (Virtualization) Date: Fri, 13 Feb 2009 10:44:42 +1100 Subject: [fedora-virt] Re: [PATCH] xen: do not set NX bit when making initial pagetables readonly In-Reply-To: <1233342477.27119.1.camel@localhost.localdomain> References: <1233339562-24011-1-git-send-email-Ian.Campbell@citrix.com> <49834D42.9020705@goop.org> <1233342477.27119.1.camel@localhost.localdomain> Message-ID: <1234482282.2968.14.camel@phills901.wwoffice.com.au> Hi list, Thanks for all your efforts in trying to resolve the NX CPU capability issue. Turns out that in our circumstance, IBM xSeries 336 machines had Irwindale? CPUs. Intel documentation says this was one of the first CPUs to have Execute Disable (XD). Herein lies some misunderstanding. NX really means XD that is: "No Execute" is "Execute Disable" in IntelSpeak. Armed with this knowledge I went into the bios and "Enabled Execute Disable". The NX capability is now in the /proc/cpuinfo listing. The F10 kernel works on the F8 host in 64 bit mode. For IBM xSeries 336 owners, Execute Disable was Disabled by default (on delivery). Hope this helps someone out there. Cheers Phill. On Fri, 2009-01-30 at 19:07 +0000, Ian Campbell wrote: > On Fri, 2009-01-30 at 10:56 -0800, Jeremy Fitzhardinge wrote: > > Ian Campbell wrote: > > > __supported_pte_mask has not been correctly configured at this point > > > and Xen prevents us from using the NX bit if the hardware does not > > > support it. Some BIOSes seem to offer the option to disable NX. > > > > > Could we sniff EFER and update __supported_pte_mask accordingly? > > Perhaps, we might also have to handle the various noexec= command line > options? I don't suppose they matter so much in a guest though. > > The equivalent native seems to use _KERNPG_TABLE as well (e.g. > head_64.S) -- is there something later on which comes along and tries to > apply the NX bit to those pages which didn't get it at start of day? > > Ian. > > _______________________________________________ > Fedora-virt mailing list > Fedora-virt at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-virt > From markmc at redhat.com Fri Feb 13 09:50:06 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 13 Feb 2009 09:50:06 +0000 Subject: [fedora-virt] qemu/kvm status In-Reply-To: <20090212152950.GB2150@poweredge.glommer> References: <20090212152950.GB2150@poweredge.glommer> Message-ID: <1234518606.3644.43.camel@blaa> Hi Glauber, I'm glad you left the bottle of wine until last - this work requires a strong stomach! :-) On Thu, 2009-02-12 at 13:29 -0200, Glauber Costa wrote: > Hello guys > > I hope you're all doing fine, with joy in your hearts. > > After a adventurous while, I have updated and QAed a new > qemu srpm. I worked mostly on x86 and sparc QA, since they > are the ones in which we have to build additional firmware. > > Speaking of firware, for the very same reason as etherboot[1], > I'm proposing some new packages. They are: > > Bochs bios: > http://glommer.fedorapeople.org/bochs-bios-2.3.8-0.1.git36989b0d2.fc11.src.rpm > http://koji.fedoraproject.org/koji/taskinfo?taskID=1121809 > > OpenBIOS: > http://glommer.fedorapeople.org/openbios-1.0-0.1.svn450.fc11.src.rpm > http://koji.fedoraproject.org/koji/taskinfo?taskID=1119906 > > VGABIOS: > http://glommer.fedorapeople.org/vgabios-0.6-0.1beta.fc11.src.rpm > http://koji.fedoraproject.org/koji/taskinfo?taskID=1120633 > ... > [1] Most firmware is compiled for one specific architecture, but > should run on qemu whichever your host architecture is. We don't > have a cross compiler infra in place, so we have to compile it natively. > The easiest would be to pick binaries directly from upstream, which > usually provides it. But we have policies that say we have to build > everything we ship. So we have a crazy bootstrap process in place, > in which we first build natively, and then feed a tar.gz for the > other architectures. It means every package should be built at least > twice in the process of getting something out of the door. Okay, let me see if I understand this: 1) You need to fix or update something in the package 2) You make the change and build it in koji 3) The build finishes, you download the binary RPM, unpack with rpm2cpio and: $> cd usr/share $> tar -cvjf etherboot-binaries-$(nvr).tar.bz etherboot/ 4) Update the spec file with the new tarball name, upload the tarball to the sources repo, check in and build in Koji Two suggestions: 1) The second build shouldn't rebuild the binaries on any arch - that way each arch has identical binaries 2) We add a "make update-binaries" the makefile - it would do: $> koji download-build $(make verrel) $> rpm2cpio ... | cpio $> tar -cvjf ... $> grep -v etherboot-binaries sources > sources.tmp $> mv sources.tmp sources $> sed -i -e ... etherboot.spec $> make upload FILES=... Cheers, Mark. From ehabkost at redhat.com Fri Feb 13 12:49:12 2009 From: ehabkost at redhat.com (Eduardo Habkost) Date: Fri, 13 Feb 2009 10:49:12 -0200 Subject: [fedora-virt] qemu/kvm status In-Reply-To: <1234518606.3644.43.camel@blaa> References: <20090212152950.GB2150@poweredge.glommer> <1234518606.3644.43.camel@blaa> Message-ID: <20090213124912.GO5026@blackpad> On Fri, Feb 13, 2009 at 09:50:06AM +0000, Mark McLoughlin wrote: > Hi Glauber, > > I'm glad you left the bottle of wine until last - this work requires a > strong stomach! :-) > > On Thu, 2009-02-12 at 13:29 -0200, Glauber Costa wrote: > > [1] Most firmware is compiled for one specific architecture, but > > should run on qemu whichever your host architecture is. We don't > > have a cross compiler infra in place, so we have to compile it natively. > > The easiest would be to pick binaries directly from upstream, which > > usually provides it. But we have policies that say we have to build > > everything we ship. So we have a crazy bootstrap process in place, > > in which we first build natively, and then feed a tar.gz for the > > other architectures. It means every package should be built at least > > twice in the process of getting something out of the door. > > Okay, let me see if I understand this: > > 1) You need to fix or update something in the package > > 2) You make the change and build it in koji > > 3) The build finishes, you download the binary RPM, unpack with > rpm2cpio and: > > $> cd usr/share > $> tar -cvjf etherboot-binaries-$(nvr).tar.bz etherboot/ > > 4) Update the spec file with the new tarball name, upload the tarball > to the sources repo, check in and build in Koji > > Two suggestions: > > 1) The second build shouldn't rebuild the binaries on any arch - that > way each arch has identical binaries Currently (on etherboot, and I think that's the case on the bios packages made by Glauber), we use prebuilt binaries only on the arches we can't build the binaries. This lets us use exactly the same package for step 2 and 4. But maybe we can change this: - First build: all prebuilt binaries tarballs removed from the spec, only native binaries built (using something like %define only_native 1) - Second build: added the prebuilt binaries from the first build, no binaries actually compiled, but uses only the prebuilt binaries We have a problem with any of the above approaches: we don't want to make the first build a scratch build (we want to keep the build information stored somewhere on Koji), but we don't want this build to be available for the users, as the result is an incomplete package. I am thinking about asking a Koji tag to be created just to store those "intermediate build step" RPMs. What do you think? > > 2) We add a "make update-binaries" the makefile - it would do: > > $> koji download-build $(make verrel) > $> rpm2cpio ... | cpio > $> tar -cvjf ... > $> grep -v etherboot-binaries sources > sources.tmp > $> mv sources.tmp sources > $> sed -i -e ... etherboot.spec > $> make upload FILES=... +1. This should be automated as much as possible. -- Eduardo From glommer at redhat.com Fri Feb 13 12:59:04 2009 From: glommer at redhat.com (Glauber Costa) Date: Fri, 13 Feb 2009 10:59:04 -0200 Subject: [fedora-virt] qemu/kvm status In-Reply-To: <20090213124912.GO5026@blackpad> References: <20090212152950.GB2150@poweredge.glommer> <1234518606.3644.43.camel@blaa> <20090213124912.GO5026@blackpad> Message-ID: <20090213125904.GA9535@poweredge.glommer> On Fri, Feb 13, 2009 at 10:49:12AM -0200, Eduardo Habkost wrote: > On Fri, Feb 13, 2009 at 09:50:06AM +0000, Mark McLoughlin wrote: > > Hi Glauber, > > > > I'm glad you left the bottle of wine until last - this work requires a > > strong stomach! :-) > > > > On Thu, 2009-02-12 at 13:29 -0200, Glauber Costa wrote: > > > > [1] Most firmware is compiled for one specific architecture, but > > > should run on qemu whichever your host architecture is. We don't > > > have a cross compiler infra in place, so we have to compile it natively. > > > The easiest would be to pick binaries directly from upstream, which > > > usually provides it. But we have policies that say we have to build > > > everything we ship. So we have a crazy bootstrap process in place, > > > in which we first build natively, and then feed a tar.gz for the > > > other architectures. It means every package should be built at least > > > twice in the process of getting something out of the door. > > > > Okay, let me see if I understand this: > > > > 1) You need to fix or update something in the package > > > > 2) You make the change and build it in koji > > > > 3) The build finishes, you download the binary RPM, unpack with > > rpm2cpio and: > > > > $> cd usr/share > > $> tar -cvjf etherboot-binaries-$(nvr).tar.bz etherboot/ > > > > 4) Update the spec file with the new tarball name, upload the tarball > > to the sources repo, check in and build in Koji > > > > Two suggestions: > > > > 1) The second build shouldn't rebuild the binaries on any arch - that > > way each arch has identical binaries > > Currently (on etherboot, and I think that's the case on the bios packages > made by Glauber), we use prebuilt binaries only on the arches we can't > build the binaries. This lets us use exactly the same package for step > 2 and 4. But maybe we can change this: > > - First build: all prebuilt binaries tarballs removed from the spec, only > native binaries built (using something like %define only_native 1) > - Second build: added the prebuilt binaries from the first build, > no binaries actually compiled, but uses only the prebuilt binaries > > > We have a problem with any of the above approaches: we don't want to make > the first build a scratch build (we want to keep the build information > stored somewhere on Koji), but we don't want this build to be available > for the users, as the result is an incomplete package. I am thinking > about asking a Koji tag to be created just to store those "intermediate > build step" RPMs. What do you think? > > > > > > 2) We add a "make update-binaries" the makefile - it would do: > > > > $> koji download-build $(make verrel) > > $> rpm2cpio ... | cpio > > $> tar -cvjf ... > > $> grep -v etherboot-binaries sources > sources.tmp > > $> mv sources.tmp sources > > $> sed -i -e ... etherboot.spec > > $> make upload FILES=... > > +1. This should be automated as much as possible. I've talked to some people in #fedora-devel yesterday, for _hours_. It turns out that they're planning on deploying some features in koji by Feb 28th, that _might_ help us a lot. Really, a lot. The idea is that you can have your package built on an architecture exclusively with BuildArch directive. But your package can then have a subpackage with BuildArch: noarch. That way, your package will span all repositories. This seems like the perfect solution to us. I've helped them to proceed with some tests, and it seem to work. So what I'm plannin on doing, is post the rpms for review today, since it is unlikely that they will receive more updates in this mean time. Getting them review and approved is the really important bits. We can set on the ideal solution a bit later. From ehabkost at redhat.com Fri Feb 13 13:02:40 2009 From: ehabkost at redhat.com (Eduardo Habkost) Date: Fri, 13 Feb 2009 11:02:40 -0200 Subject: [fedora-virt] qemu/kvm status In-Reply-To: <20090213125904.GA9535@poweredge.glommer> References: <20090212152950.GB2150@poweredge.glommer> <1234518606.3644.43.camel@blaa> <20090213124912.GO5026@blackpad> <20090213125904.GA9535@poweredge.glommer> Message-ID: <20090213130240.GQ5026@blackpad> On Fri, Feb 13, 2009 at 10:59:04AM -0200, Glauber Costa wrote: > > It turns out that they're planning on deploying some features in koji > by Feb 28th, that _might_ help us a lot. Really, a lot. > > The idea is that you can have your package built on an architecture > exclusively with BuildArch directive. But your package can then have > a subpackage with BuildArch: noarch. That way, your package will span > all repositories. This seems like the perfect solution to us. I've > helped them to proceed with some tests, and it seem to work. So what > I'm plannin on doing, is post the rpms for review today, since it is > unlikely that they will receive more updates in this mean time. That makes sense. From the host system point of view, the BIOS images are data, and should be noarch. I think this will solve our problems. Is Feb 28th still in time to start actually building this stuff on Rawhide without breaking any deadline? > > Getting them review and approved is the really important bits. We can > set on the ideal solution a bit later. -- Eduardo From berrange at redhat.com Fri Feb 13 13:09:53 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 13 Feb 2009 13:09:53 +0000 Subject: [fedora-virt] qemu/kvm status In-Reply-To: <20090213125904.GA9535@poweredge.glommer> References: <20090212152950.GB2150@poweredge.glommer> <1234518606.3644.43.camel@blaa> <20090213124912.GO5026@blackpad> <20090213125904.GA9535@poweredge.glommer> Message-ID: <20090213130953.GA7014@redhat.com> On Fri, Feb 13, 2009 at 10:59:04AM -0200, Glauber Costa wrote: > > We have a problem with any of the above approaches: we don't want to make > > the first build a scratch build (we want to keep the build information > > stored somewhere on Koji), but we don't want this build to be available > > for the users, as the result is an incomplete package. I am thinking > > about asking a Koji tag to be created just to store those "intermediate > > build step" RPMs. What do you think? > > > > > > > > > > 2) We add a "make update-binaries" the makefile - it would do: > > > > > > $> koji download-build $(make verrel) > > > $> rpm2cpio ... | cpio > > > $> tar -cvjf ... > > > $> grep -v etherboot-binaries sources > sources.tmp > > > $> mv sources.tmp sources > > > $> sed -i -e ... etherboot.spec > > > $> make upload FILES=... > > > > +1. This should be automated as much as possible. > I've talked to some people in #fedora-devel yesterday, for _hours_. > > It turns out that they're planning on deploying some features in koji > by Feb 28th, that _might_ help us a lot. Really, a lot. > > The idea is that you can have your package built on an architecture > exclusively with BuildArch directive. But your package can then have > a subpackage with BuildArch: noarch. That way, your package will span > all repositories. This seems like the perfect solution to us. I've > helped them to proceed with some tests, and it seem to work. So what > I'm plannin on doing, is post the rpms for review today, since it is > unlikely that they will receive more updates in this mean time. The main limitation with that approach is the architecture coverage, and the way it relates to secondary architectures. This will only let us easily do x86 & ppc. If we want sparc, arm or ia64 BIOS, the builds would happen in the 2nd arch build ssytem, and the result would not be available in our main Fedora YUM repos for primary archs. If we go with your current approach, we can do the build in the 2nd-ary arch, and then pull the result back into the packages on the primary arches 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 :| From ehabkost at redhat.com Fri Feb 13 13:23:01 2009 From: ehabkost at redhat.com (Eduardo Habkost) Date: Fri, 13 Feb 2009 11:23:01 -0200 Subject: [fedora-virt] qemu/kvm status In-Reply-To: <20090213130953.GA7014@redhat.com> References: <20090212152950.GB2150@poweredge.glommer> <1234518606.3644.43.camel@blaa> <20090213124912.GO5026@blackpad> <20090213125904.GA9535@poweredge.glommer> <20090213130953.GA7014@redhat.com> Message-ID: <20090213132300.GR5026@blackpad> On Fri, Feb 13, 2009 at 01:09:53PM +0000, Daniel P. Berrange wrote: > On Fri, Feb 13, 2009 at 10:59:04AM -0200, Glauber Costa wrote: > > > We have a problem with any of the above approaches: we don't want to make > > > the first build a scratch build (we want to keep the build information > > > stored somewhere on Koji), but we don't want this build to be available > > > for the users, as the result is an incomplete package. I am thinking > > > about asking a Koji tag to be created just to store those "intermediate > > > build step" RPMs. What do you think? > > > > > > > > > > > > > > 2) We add a "make update-binaries" the makefile - it would do: > > > > > > > > $> koji download-build $(make verrel) > > > > $> rpm2cpio ... | cpio > > > > $> tar -cvjf ... > > > > $> grep -v etherboot-binaries sources > sources.tmp > > > > $> mv sources.tmp sources > > > > $> sed -i -e ... etherboot.spec > > > > $> make upload FILES=... > > > > > > +1. This should be automated as much as possible. > > I've talked to some people in #fedora-devel yesterday, for _hours_. > > > > It turns out that they're planning on deploying some features in koji > > by Feb 28th, that _might_ help us a lot. Really, a lot. > > > > The idea is that you can have your package built on an architecture > > exclusively with BuildArch directive. But your package can then have > > a subpackage with BuildArch: noarch. That way, your package will span > > all repositories. This seems like the perfect solution to us. I've > > helped them to proceed with some tests, and it seem to work. So what > > I'm plannin on doing, is post the rpms for review today, since it is > > unlikely that they will receive more updates in this mean time. > > The main limitation with that approach is the architecture coverage, > and the way it relates to secondary architectures. This will only > let us easily do x86 & ppc. If we want sparc, arm or ia64 BIOS, the > builds would happen in the 2nd arch build ssytem, and the result > would not be available in our main Fedora YUM repos for primary > archs. If we go with your current approach, we can do the build in > the 2nd-ary arch, and then pull the result back into the packages > on the primary arches I don't know if I understood correctly. This means that the new feature could solve our problems, but it won't solve all of them because some arches where we need some binaries to be built are second-class citzens on the build system? -- Eduardo From berrange at redhat.com Fri Feb 13 13:31:13 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Fri, 13 Feb 2009 13:31:13 +0000 Subject: [fedora-virt] qemu/kvm status In-Reply-To: <20090213132300.GR5026@blackpad> References: <20090212152950.GB2150@poweredge.glommer> <1234518606.3644.43.camel@blaa> <20090213124912.GO5026@blackpad> <20090213125904.GA9535@poweredge.glommer> <20090213130953.GA7014@redhat.com> <20090213132300.GR5026@blackpad> Message-ID: <20090213133113.GB7014@redhat.com> On Fri, Feb 13, 2009 at 11:23:01AM -0200, Eduardo Habkost wrote: > On Fri, Feb 13, 2009 at 01:09:53PM +0000, Daniel P. Berrange wrote: > > On Fri, Feb 13, 2009 at 10:59:04AM -0200, Glauber Costa wrote: > > > > We have a problem with any of the above approaches: we don't want to make > > > > the first build a scratch build (we want to keep the build information > > > > stored somewhere on Koji), but we don't want this build to be available > > > > for the users, as the result is an incomplete package. I am thinking > > > > about asking a Koji tag to be created just to store those "intermediate > > > > build step" RPMs. What do you think? > > > > > > > > > > > > > > > > > > 2) We add a "make update-binaries" the makefile - it would do: > > > > > > > > > > $> koji download-build $(make verrel) > > > > > $> rpm2cpio ... | cpio > > > > > $> tar -cvjf ... > > > > > $> grep -v etherboot-binaries sources > sources.tmp > > > > > $> mv sources.tmp sources > > > > > $> sed -i -e ... etherboot.spec > > > > > $> make upload FILES=... > > > > > > > > +1. This should be automated as much as possible. > > > I've talked to some people in #fedora-devel yesterday, for _hours_. > > > > > > It turns out that they're planning on deploying some features in koji > > > by Feb 28th, that _might_ help us a lot. Really, a lot. > > > > > > The idea is that you can have your package built on an architecture > > > exclusively with BuildArch directive. But your package can then have > > > a subpackage with BuildArch: noarch. That way, your package will span > > > all repositories. This seems like the perfect solution to us. I've > > > helped them to proceed with some tests, and it seem to work. So what > > > I'm plannin on doing, is post the rpms for review today, since it is > > > unlikely that they will receive more updates in this mean time. > > > > The main limitation with that approach is the architecture coverage, > > and the way it relates to secondary architectures. This will only > > let us easily do x86 & ppc. If we want sparc, arm or ia64 BIOS, the > > builds would happen in the 2nd arch build ssytem, and the result > > would not be available in our main Fedora YUM repos for primary > > archs. If we go with your current approach, we can do the build in > > the 2nd-ary arch, and then pull the result back into the packages > > on the primary arches > > I don't know if I understood correctly. This means that the new feature > could solve our problems, but it won't solve all of them because some > arches where we need some binaries to be built are second-class citzens > on the build system? Yes, that is essentially it. The 2nd-ary architectures have completely separate build system, and separate YUM repository composes. They're basically a downstream distro, that just gets triggered whenever the primary arch builds. Similarly the sparc 2ndary arch wouldn't have access to the '-noarch' x86 firmware we'd build. So for a complete solutuon I think the manual double build + tar.gz of just build blobs is probably the only way we'll get full coverage for all the QEMU arches. 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 :| From markmc at redhat.com Fri Feb 13 13:44:42 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 13 Feb 2009 13:44:42 +0000 Subject: [fedora-virt] qemu/kvm status In-Reply-To: <20090213124912.GO5026@blackpad> References: <20090212152950.GB2150@poweredge.glommer> <1234518606.3644.43.camel@blaa> <20090213124912.GO5026@blackpad> Message-ID: <1234532682.3644.58.camel@blaa> On Fri, 2009-02-13 at 10:49 -0200, Eduardo Habkost wrote: > - First build: all prebuilt binaries tarballs removed from the spec, > only > native binaries built (using something like %define only_native 1) > - Second build: added the prebuilt binaries from the first build, > no binaries actually compiled, but uses only the prebuilt binaries Yes, that's what I was thinking. > We have a problem with any of the above approaches: we don't want to make > the first build a scratch build (we want to keep the build information > stored somewhere on Koji), Agreed. > but we don't want this build to be available for the users, as the > result is an incomplete package. If you automate it so that the builds happen one after the other, it's going to be highly unlikely that they e.g. get pulled in by a rawhide compose. > I am thinking > about asking a Koji tag to be created just to store those "intermediate > build step" RPMs. What do you think? Perhaps, I'd only worry about it if we ever actually hit problems, though. Cheers, Mark. From markmc at redhat.com Fri Feb 13 13:46:49 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 13 Feb 2009 13:46:49 +0000 Subject: [fedora-virt] qemu/kvm status In-Reply-To: <20090213125904.GA9535@poweredge.glommer> References: <20090212152950.GB2150@poweredge.glommer> <1234518606.3644.43.camel@blaa> <20090213124912.GO5026@blackpad> <20090213125904.GA9535@poweredge.glommer> Message-ID: <1234532809.3644.60.camel@blaa> On Fri, 2009-02-13 at 10:59 -0200, Glauber Costa wrote: > The idea is that you can have your package built on an architecture > exclusively with BuildArch directive. But your package can then have > a subpackage with BuildArch: noarch. That way, your package will span > all repositories. This seems like the perfect solution to us. Yep, that would be ideal ... as long as people don't take to throw things at us for shipping arch specific binaries in a noarch package :-) Seriously, it sounds like it should work really well. > I've > helped them to proceed with some tests, and it seem to work. So what > I'm plannin on doing, is post the rpms for review today, since it is > unlikely that they will receive more updates in this mean time. > > Getting them review and approved is the really important bits. We can > set on the ideal solution a bit later. Yep, agree. Cheers, Mark. From glommer at redhat.com Fri Feb 13 13:59:36 2009 From: glommer at redhat.com (Glauber Costa) Date: Fri, 13 Feb 2009 11:59:36 -0200 Subject: [fedora-virt] qemu/kvm status In-Reply-To: <20090213130953.GA7014@redhat.com> References: <20090212152950.GB2150@poweredge.glommer> <1234518606.3644.43.camel@blaa> <20090213124912.GO5026@blackpad> <20090213125904.GA9535@poweredge.glommer> <20090213130953.GA7014@redhat.com> Message-ID: <20090213135936.GB9535@poweredge.glommer> On Fri, Feb 13, 2009 at 01:09:53PM +0000, Daniel P. Berrange wrote: > On Fri, Feb 13, 2009 at 10:59:04AM -0200, Glauber Costa wrote: > > > We have a problem with any of the above approaches: we don't want to make > > > the first build a scratch build (we want to keep the build information > > > stored somewhere on Koji), but we don't want this build to be available > > > for the users, as the result is an incomplete package. I am thinking > > > about asking a Koji tag to be created just to store those "intermediate > > > build step" RPMs. What do you think? > > > > > > > > > > > > > > 2) We add a "make update-binaries" the makefile - it would do: > > > > > > > > $> koji download-build $(make verrel) > > > > $> rpm2cpio ... | cpio > > > > $> tar -cvjf ... > > > > $> grep -v etherboot-binaries sources > sources.tmp > > > > $> mv sources.tmp sources > > > > $> sed -i -e ... etherboot.spec > > > > $> make upload FILES=... > > > > > > +1. This should be automated as much as possible. > > I've talked to some people in #fedora-devel yesterday, for _hours_. > > > > It turns out that they're planning on deploying some features in koji > > by Feb 28th, that _might_ help us a lot. Really, a lot. > > > > The idea is that you can have your package built on an architecture > > exclusively with BuildArch directive. But your package can then have > > a subpackage with BuildArch: noarch. That way, your package will span > > all repositories. This seems like the perfect solution to us. I've > > helped them to proceed with some tests, and it seem to work. So what > > I'm plannin on doing, is post the rpms for review today, since it is > > unlikely that they will receive more updates in this mean time. > > The main limitation with that approach is the architecture coverage, > and the way it relates to secondary architectures. This will only > let us easily do x86 & ppc. If we want sparc, arm or ia64 BIOS, the > builds would happen in the 2nd arch build ssytem, and the result > would not be available in our main Fedora YUM repos for primary > archs. If we go with your current approach, we can do the build in > the 2nd-ary arch, and then pull the result back into the packages > on the primary arches qemu currently does not have any kind of issue with arm. for ia64, there's no qemu, just kvm. So if we need, we'll just build locally. The only real issue is sparc, and in this case, yeah, bummer, but we can still use the binaries approach. Still leaves us with etherboot, bochs-bios and vga-bios. There are three packages in which we can do a much better job. Can't see why hold them because of the sparc package. > > 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 :| From glommer at redhat.com Fri Feb 13 14:53:15 2009 From: glommer at redhat.com (Glauber Costa) Date: Fri, 13 Feb 2009 12:53:15 -0200 Subject: [fedora-virt] qemu/kvm status In-Reply-To: <1234532809.3644.60.camel@blaa> References: <20090212152950.GB2150@poweredge.glommer> <1234518606.3644.43.camel@blaa> <20090213124912.GO5026@blackpad> <20090213125904.GA9535@poweredge.glommer> <1234532809.3644.60.camel@blaa> Message-ID: <20090213145315.GC9535@poweredge.glommer> On Fri, Feb 13, 2009 at 01:46:49PM +0000, Mark McLoughlin wrote: > On Fri, 2009-02-13 at 10:59 -0200, Glauber Costa wrote: > > > The idea is that you can have your package built on an architecture > > exclusively with BuildArch directive. But your package can then have > > a subpackage with BuildArch: noarch. That way, your package will span > > all repositories. This seems like the perfect solution to us. > > Yep, that would be ideal ... as long as people don't take to throw > things at us for shipping arch specific binaries in a noarch package :-) > > Seriously, it sounds like it should work really well. > > > I've > > helped them to proceed with some tests, and it seem to work. So what > > I'm plannin on doing, is post the rpms for review today, since it is > > unlikely that they will receive more updates in this mean time. > > > > Getting them review and approved is the really important bits. We can > > set on the ideal solution a bit later. > > Yep, agree. Please people: https://bugzilla.redhat.com/show_bug.cgi?id=485417 https://bugzilla.redhat.com/show_bug.cgi?id=485418 https://bugzilla.redhat.com/show_bug.cgi?id=485420 You can help me out in this enterprise by reviewing the aforementioned BZs. From markmc at redhat.com Fri Feb 13 18:52:37 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 13 Feb 2009 18:52:37 +0000 Subject: [fedora-virt] Fedora virt status Message-ID: <1234551157.23746.95.camel@blaa> 2009-03-03 Feature freeze (18 days) 2009-03-10 Beta Freeze (25 days) 2009-04-14 Final freeze (60 days) Fedora Weekly News ================== The latest instalment of Fedora Weekly News is out, again with a detailed virt section: http://fedoraproject.org/wiki/FWN/Issue162#Virtualization Thanks to Dale Bewley. QEMU/KVM Merge ============== Glauber has been working hard towards merging the qemu and kvm packages. This week most of the effort involved producing packages for bochs-bios, openbios and vgabios. See this mail for more details: http://www.redhat.com/archives/fedora-virt/2009-February/msg00064.html The really nasty part - which Eduardo Hobkost ealier worked through with the etherboot package - is that although the BIOS binaries need to be built on a specific platform, they need to be available for install on all architectures. For example, Bochs is built on x86, but if you run qemu-system-x86_64 on ppc you need it there too. As an interim measure, all these packages will be first built on the required architecture, then the packager will download the new build, pack the images in a tarball and then re-build the package with this tarball. The second build will package the pre-built binaries on all arches, rather than building from source. In future, koji/rpm will support packages with ExclusiveArch that produce noarch packages. So, e.g. Bochs will be built only on x86 and the result will be a noarch package. See also: https://fedoraproject.org/wiki/Features/NoarchSubpackages The pacakge reviews for the three new packages are here: https://bugzilla.redhat.com/485417 https://bugzilla.redhat.com/485418 https://bugzilla.redhat.com/485420 PCI Device Assignment ===================== The offline discussion around device resetting, unbinding and filtering finally made it on-list here: http://marc.info/?l=kvm&m=123454366317045 The upshot is that some further kernel work is required before device assignment will be fully usable in Fedora. David Woodhouse's work continued on resolving the DMAR issues seen on some machines with intel_iommu=on: http://bugzilla.kernel.org/show_bug.cgi?id=12578 https://bugzilla.redhat.com/479996 David's first patch fixes a problem where one platform (Mobile 4 Series Chipset). The problem is that this chipset claims to not need explicit write buffer flushing, when it does in fact need it. David's patch just ignores the RWBF hint on that platform. This should fix the issues seen with Lenovo X200 and the Dell Latitude E6400. Another problem was found with the iwlwifi driver where the device is writing to buffers that the driver marks as read-only. David has added a fix for this issue to rawhide: https://bugzilla.redhat.com/485139 Shared Network Interface ======================== David Lutterkort updated libvir-list with his progress: http://www.redhat.com/archives/libvir-list/2009-February/msg00228.html After talking with Dan Williams, who is working in NetworkManager, it is clear that the network interface functionality for libvirt is also useful for NM and would help them with handling system-wide interface configuration. To accomodate that, I will implement network interface configuration in a separate library (inspiringly called 'netcf', until somebody thinks of something catchier) and add public API to libvirt that will use netcf to do the actual work. The F11 Feature page has also been updated: https://fedoraproject.org/wiki/Features/Shared_Network_Interface sVirt ===== Dan Walsh posted his thoughts on the sVirt patch set to libvir-list: http://www.redhat.com/archives/libvir-list/2009-February/msg00144.html It appears the patch is in good shape already and could be merged very soon. Dan Berrange replied with: I've reviewed all the submissions James has posted for comments so far, and am pretty happy with the way it now integrates with libvirt. If yourself & James are happy with what they're doing from a SELinux / security model point of view, then there's no reason they shouldn't be posted for final merge now. kvmclock and !constant_tsc ========================== The fix to disable kvmclock on hosts with no constant_tsc has no been pushed to Fedora 10: https://admin.fedoraproject.org/updates/kernel-2.6.27.15-170.2.19.fc10 Upstream, Avi has queued up the workaround for 2.6.29 here: http://git.kernel.org/?p=linux/kernel/git/avi/kvm.git;a=commit;h=f160ca75 and the real fix is queued for 2.6.30 here: http://git.kernel.org/?p=linux/kernel/git/avi/kvm.git;a=commit;h=48aa74b8 Worryingly, Levente Farkas noted that he has constant_tsc and is still seeing hangs which go away with clocksource=acpi_pm. Further investigation of this is required. https://bugzilla.redhat.com/475598 PVMMU ===== The issue with pvmmu and CONFIG_SLAB_DEBUG was resolved this week: https://bugzilla.redhat.com/480822 pvmmu causes net driver oops during guest install (new_slab) Marcelo came up with a guest kernel fix for pvmmu (only batch user pte updates), built in koji and James Laska ran some test installs using it. Unfortunately, James couldn't reproduce with latest rawhide and, obviously, also didn't see the issue with Marcelo's patch. Marcelo posted his patch upstream and some discussion with Jeremy Fitzhardinge yielded a patch to add a missing flush_lazy_mmu_mode() call to change_page_attr(): http://patchwork.kernel.org/patch/6531/ This patch has since been merged into Linus's tree for 2.6.29. libvirt 0.6.0 ============= Dan Berrange pushed an libvirt-0.6.0-2 with the following fixes: - Fix libvirtd --timeout usage - Fix RPC call problems and QEMU startup handling (rhbz #484414) - Fix unowned directories (rhbz #483442) Further issues with this release include: https://bugzilla.redhat.com/484199 AVC denied errors when starting KVM guest https://bugzilla.redhat.com/484555 SELinux issue causing libvirtd launched dnsmasq to fail Dan Berrange pointed out the selinux-policy changes needed. Miroslav Grepl and Dan Walsh made the changes in selinux-policy-3.5.13-45.fc10 which has been pushed to F10 updates-testing. https://bugzilla.redhat.com/484553 libvirtd segfault in libdbus after starting kvm guest Strangely, it proved to be very difficult to get a good trace of the segfault. In the end, the issue turned out to be nasty D-Bus/PolicyKit related segfault in libvirtd which hasn't been resolved yet. https://bugzilla.redhat.com/484649 Starting kvm guest sometimes fails - qemu taking too long? Guido Gunther committed a patch to fix this in upstream CVS. https://bugzilla.redhat.com/484552 libnuma: Warning: /sys not mounted or no numa system. Bogus warning being printed at library load time because libvirt now uses libnuma and libnuma was incorrectly complaining about missing sysfs files on no-numa systems. Neil Horman fixed in numactl-2.0.2-3. virt-manager ============ Cole merged the VM 'Overview' tab into the 'Hardware' tab and renamed it to 'Details'. He included some screenshots in his patch posting: http://www.redhat.com/archives/et-mgmt-tools/2009-February/msg00029.html Cole also built a new package in rawhide which uses PolicyKit instead of consolehelper. Also, this bug gives some insight into plans for virt-manager: https://bugzilla.redhat.com/459665 root consolehelper breaks remote ssh virt-manager/libvirtd connections Cole explains that this will be fixed when virt-manager no longer runs as root. David Cartwright points out this useful wiki page: http://virt-manager.et.redhat.com/page/RemoteSSH KVM === Marcelo has begun using patchwork to manage patches posted to the KVM list: http://patchwork.kernel.org/project/kvm/list/ Too many patches isn't a bad complaint for a project to have, right? Avi appears to have tagged kvm-84rc1 in git, so it looks like a new release is on the way. Don't tell anyone I told you! :-) Package Reviews =============== Rich Jones took it upon himself to complete the merge reviews for libvirt and gnome-applet-vm which had sat idle for 18 months: https://bugzilla.redhat.com/226055 https://bugzilla.redhat.com/225811 That's the spirit! Cole Robinson also took ownership of gnome-applet-vm from the original author, Karel Zak, in the process. Since package reviews are sometimes useful to refer back to, we've collected together links to all the package reviews for virt related packages here: https://fedoraproject.org/wiki/Virtualization_package_reviews Xen Dom0 ======== Michael Young posted a test kernel RPM containing Dom0 support: http://www.redhat.com/archives/fedora-xen/2009-February/msg00014.html Some discussion on how complete the current dom0 patchset is. Gerd's summary of the current situation is: If it goes well .30 boots as dom0 kernel. I don't expect much of the backend infrastructure makes it into .30 though (i.e. you need patches to actually run guests). At this point the changes needed might be non-invasive enough that it might be reasonable to carry them as patches in the fedora kernel. Michael is not to be deterred, though, and is preparing to start pushing these packages through Koji. Completely unrelated, Brad Smith brings attention to a common complaint that "virsh start -c" is needed to allow users to easily get to BIOS/pygrub screen at boot: https://bugzilla.redhat.com/468457 Xen and the Art of the NX Bit ============================= Phill on the fedora-virt points out that the No Execute (NX) bit is called the Execute Disable (XD) bit in Intel documentation: http://www.redhat.com/archives/fedora-virt/2009-February/msg00065.html By enabling NX, he was able to resolve his F10 guest boot failure: https://bugzilla.redhat.com/480880 Ian Campbell posted a patch upstream to fix the issue, but it looks like it may not have been merged yet. Bugs ==== DOOM-O-METER: 192 open bugs last week, 193 this week. Hrmph! https://bugzilla.redhat.com/478976 https://bugzilla.redhat.com/463765 https://bugzilla.redhat.com/471000 qemu-kvm not working with evdev giving wrong key mappings Some confusion about whether this is QEMU or evdev's fault, which Dan Berrange cleared up with: Yes, this *IS* a QEMU/KVM bug. It has hardcoded the assumption that there is a 1-to-1 mapping of scancodes to keycodes. This just happens to be true of the 'kbd' X driver, this is not true in general, thus QEMU breaks with evdev. QEMU must be fixed. https://bugzilla.redhat.com/484364 https://bugzilla.redhat.com/485148 block-rw-range-check.patch breaks qcow Two issues were found with our single out of tree patch for KVM. Eduardo, the hero that he is, promptly fixed both. https://bugzilla.redhat.com/484097 ambiguous dialog Guido Gunther supplied a patch and after consulting with the GNOME HIG posted a second, better patch. https://bugzilla.redhat.com/484599 Qemu monitor "system_powerdown" command does not work https://bugzilla.redhat.com/484295 F11 alpha boots ugly (after install) on xen paravirt Jeremy Fitzhardinge has fixed upstream. Fix is in 2.6.29-rc4.git4 https://bugzilla.redhat.com/469837 RFE: Support usb tablet in graphical setup via qemu Xorg has been fixed to properly handle USB tablets. We would like to be able to use USB tables by default for Fedora guests, but some work needs to be done to check that they are configured in absolute mode by default, rather than relative mode. From markmc at redhat.com Fri Feb 20 19:18:57 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 20 Feb 2009 19:18:57 +0000 Subject: [fedora-virt] Fedora virt status Message-ID: <1235157537.3927.56.camel@blaa> 2009-03-03 Feature freeze (11 days) 2009-03-10 Beta Freeze (18 days) 2009-04-14 Final freeze (53 days) A short report this week, since I was travelling. libvirt 0.6.0 ============= Dan Berrange fixed the nasty D-Bus threading related segfault introduced in libvirt 0.6.0: https://bugzilla.redhat.com/484553 http://www.redhat.com/archives/libvir-list/2009-February/msg00357.html He then pushed a new libvirt-0.6.0 update to fix the last remaining known issues with the 0.6.0 update in F9/F10: * Wed Feb 18 2009 Daniel P. Berrange - 0.6.0-4.fc11 - Fix QEMU startup timeout/race (rhbz #484649) - Setup DBus threading. Don't allow dbus to call _exit / change SIGPIPE (rhbz #484553) - Fix timeout when autostarting session daemon sVirt ===== Dan Walsh posted the latest sVirt patch to libvir-list for review: http://www.redhat.com/archives/libvir-list/2009-February/msg00343.html He also followed that up with a patch to python-virtinst to make it assign security labels to guests: http://www.redhat.com/archives/libvir-list/2009-February/msg00372.html VT-d ==== David Woodhouse submitted the rwbuf quirk patch to Linus: https://lists.linux-foundation.org/pipermail/iommu/2009-February/001117.html The patch made it into rawhide, closing out: https://bugzilla.redhat.com/479996 David also made intel_iommu=on the default again in rawhide: * Sat Feb 14 2009 David Woodhouse - Enable DMAR by default again now that it works In the upstream bug report there are reports of a DMAR warning from the VGA controller on Lenovo x200: http://bugzilla.kernel.org/show_bug.cgi?id=12578 [ 0.216043] DMAR: Forcing write-buffer flush capability [ 0.928007] DMAR:[DMA Write] Request device [00:02.0] fault addr feff5e000 [ 0.928007] DMAR:[fault reason 05] PTE Write access is not set 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) Bhavesh points out that no further ill effects are noticed after the warning. Adar also points out some issues related to ixgbe on Dell Precision T5400. PCI Device Assignment ===================== There was some follow-up to the discussion about device unbinding, resetting and filtering: http://marc.info/?l=kvm&m=123454366317045 Chris Wright posted a patch for "remove_id": http://patchwork.kernel.org/patch/7210/ Adar reports more issues with his Dell Precision T5400. kvmclock ======== The patch to disable kvmclock on machines which don't have constant_tsc has been merged upstream for 2.6.29 and the patch has been dropped from rawhide. QEMU/KVM Merge ============== Glauber continued his work on BIOS packages: https://bugzilla.redhat.com/485418 Review Request: vgabios - vga option rom for bochs/qemu Turns out that this is buildable on all arches with dev86. https://bugzilla.redhat.com/485420 Review Request: openbios - Open Source implementation of IEEE 1275-1994 Some discussion whether fcode is needed to build, it appears not. https://bugzilla.redhat.com/485417 Review Request: bochs-bios - bios implementation from the bochs project Some discussion about whether it would be possible to build on all arches with dev86, but it turns out gcc is needed for some bits. block-rw-range-check.patch ========================== Eduardo posted a new version of Fedora's only non-upstreamed QEMU patch, the notorious block-rw-range-check.patch: https://bugzilla.redhat.com/486429 An EPEL bug was filed reporting that QEMu snapshots are also broken by the patch: https://bugzilla.redhat.com/486429 Eduardo reports that this is still an issue with his latest patches. Xen Dom0 ======== Michael Young reports on his progress building dom0 enabled kernel packages http://www.redhat.com/archives/fedora-xen/2009-February/msg00031.html Mass Rebuild ============ A mass rebuild of Fedora 11 is coming soon: http://www.redhat.com/archives/fedora-devel-list/2009-February/msg01083.html These are always the best fun. Expect sparks. Bugs ==== DOOM-O-METER: 193 open bugs last week, 188 this week. Woohoo! https://bugzilla.redhat.com/485564 Help broken when authenticated through userhelper Another virt-manager/consolehelper bug. Our use of consolehelper is going away soon, so Cole just closed out the bug and marked it as a dup of #459665. https://bugzilla.redhat.com/484986 grub-install fails on virtio disk https://bugzilla.redhat.com/480253 virt-clone fails for clone between storage types https://bugzilla.redhat.com/486112 Qemu should not be using pulseaudio when run as root. Some discussion of issues around privileged instances of QEMU using pulseaudio and the implications for SELinux based confinement of guests. https://bugzilla.redhat.com/244787 incorrect default keymaps Some discussion around dropping the -keymap argument to QEMU since the guests can now send scancodes rather than keysyms. https://bugzilla.redhat.com/486575 Ignores 'target dev=...' attribute in network devices libvirt doesn't allow using an explicit vnetXX for a tap device name. From markmc at redhat.com Mon Feb 23 09:07:43 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 23 Feb 2009 09:07:43 +0000 Subject: [fedora-virt] etherboot failure [was Re: [fedora-virt-maint] Fedora rawhide rebuild in mock status 2009-02-20 x86_64] In-Reply-To: <20090222031325.GA16375@mock.linuxdev.us.dell.com> References: <20090222031325.GA16375@mock.linuxdev.us.dell.com> Message-ID: <1235380063.31426.25.camel@blaa> On Sat, 2009-02-21 at 21:13 -0600, Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for x86_64 > based on rawhide as of Friday Feb 20, 2009. > > Most packages were actually built as of the F11 Alpha cut on or around > Feb 1. Any newer packages in rawhide as of Feb 20 were then pulled in > and rebuilt, and any previously-failed packages were also rebuilt, so > I believe this list to be current and correct. I did have a couple > servers fail during the builds, so it is possible that at most 8 of > these are not true failures, but a result of builders crashing. Don't > pin your hopes on that though. :-) > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ ... > etherboot-5.4.4-8.fc11 (build/make) ehabkost,glommer,virtmaint http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/x86_64/etherboot-5.4.4-8.fc11.src.rpm/result/mock.log ERROR: Bad build req: No Package Found for glibc32. Exiting. Cheers, Mark. From markmc at redhat.com Mon Feb 23 09:07:51 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 23 Feb 2009 09:07:51 +0000 Subject: [fedora-virt] ruby-libvirt failure [was Re: [fedora-virt-maint] Fedora rawhide rebuild in mock status 2009-02-20 i386] In-Reply-To: <20090222031412.GA16588@mock.linuxdev.us.dell.com> References: <20090222031412.GA16588@mock.linuxdev.us.dell.com> Message-ID: <1235380071.31426.26.camel@blaa> On Sat, 2009-02-21 at 21:14 -0600, Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for i386 > based on rawhide as of Friday Feb 20, 2009. > > Most packages were actually built as of the F11 Alpha cut on or around > Feb 1. Any newer packages in rawhide as of Feb 20 were then pulled in > and rebuilt, and any previously-failed packages were also rebuilt, so > I believe this list to be current and correct. I did have a couple > servers fail during the builds, so it is possible that at most 8 of > these are not true failures, but a result of builders crashing. Don't > pin your hopes on that though. :-) > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ ... > ruby-libvirt-0.1.0-2.fc11 (build/make) lutter,stahnma,clalance,virtmaint http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/i386/ruby-libvirt-0.1.0-2.fc11.src.rpm/result/build.log Loaded suite /usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake/rake_test_loader Started . libvir: Test error : Domain not found . . ./tests/tc_connect.rb:165: [BUG] Segmentation fault ruby 1.8.6 (2008-08-11) [i386-linux] rake aborted! Command failed with status (): [/usr/bin/ruby -Ilib:ext/libvirt "/usr/lib/...] (See full trace by running task with --trace) Cheers, Mark. From markmc at redhat.com Mon Feb 23 09:07:57 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 23 Feb 2009 09:07:57 +0000 Subject: [fedora-virt] gnome-applet-vm failure [was Re: [fedora-virt-maint] Fedora rawhide rebuild in mock status 2009-02-20 i386] In-Reply-To: <20090222031412.GA16588@mock.linuxdev.us.dell.com> References: <20090222031412.GA16588@mock.linuxdev.us.dell.com> Message-ID: <1235380077.31426.27.camel@blaa> On Sat, 2009-02-21 at 21:14 -0600, Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for i386 > based on rawhide as of Friday Feb 20, 2009. > > Most packages were actually built as of the F11 Alpha cut on or around > Feb 1. Any newer packages in rawhide as of Feb 20 were then pulled in > and rebuilt, and any previously-failed packages were also rebuilt, so > I believe this list to be current and correct. I did have a couple > servers fail during the builds, so it is possible that at most 8 of > these are not true failures, but a result of builders crashing. Don't > pin your hopes on that though. :-) > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ ... > gnome-applet-vm-0.2.0-2.fc9 (build/make) crobinso,virtmaint http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/i386/gnome-applet-vm-0.2.0-2.fc9.src.rpm/result/build.log gcc -DHAVE_CONFIG_H -I. -I.. -I. -I. -include ../config.h -DG_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DORBIT2=1 -pthread -I/usr/include/panel-2.0 -I/usr/include/gconf/2 -I/usr/include/gtk-2.0 -I/usr/include/libbonoboui-2.0 -I/usr/include/orbit-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libxml2 -I/usr/include/libbonobo-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/gail-1.0 -I/usr/include/libart-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/libxml2 -DVM_ICONDIR=\"/usr/share/pixmaps/vm-applet\" -DVM_VIRTMANAGER=\"/usr/bin/virt-manager\" -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -MT vm_applet-applet.o -MD -MP -MF .deps/vm_applet-applet.Tpo -c -o vm_applet-applet.o `test -f 'applet.c' || echo './'`applet.c applet.c:25:35: error: libgnomeui/gnome-help.h: No such file or directory Cheers, Mark. From markmc at redhat.com Mon Feb 23 09:08:00 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 23 Feb 2009 09:08:00 +0000 Subject: [fedora-virt] xen failure [was Re: [fedora-virt-maint] Fedora rawhide rebuild in mock status 2009-02-20 i386] In-Reply-To: <20090222031412.GA16588@mock.linuxdev.us.dell.com> References: <20090222031412.GA16588@mock.linuxdev.us.dell.com> Message-ID: <1235380080.31426.28.camel@blaa> On Sat, 2009-02-21 at 21:14 -0600, Matt Domsch wrote: > Fedora Rawhide-in-Mock Build Results for i386 > based on rawhide as of Friday Feb 20, 2009. > > Most packages were actually built as of the F11 Alpha cut on or around > Feb 1. Any newer packages in rawhide as of Feb 20 were then pulled in > and rebuilt, and any previously-failed packages were also rebuilt, so > I believe this list to be current and correct. I did have a couple > servers fail during the builds, so it is possible that at most 8 of > these are not true failures, but a result of builders crashing. Don't > pin your hopes on that though. :-) > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > ... > xen-3.3.1-3.fc11 (build/make) xen-maint,berrange,kraxel,virtmaint http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/i386/xen-3.3.1-3.fc11.src.rpm/result/build.log gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic -fasynchronous-unwind-tables -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -DNDEBUG -nostdinc -fno-builtin -fno-common -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/builddir/build/BUILD/xen-3.3.1/xen/include -I/builddir/build/BUILD/xen-3.3.1/xen/include/asm-x86/mach-generic -I/builddir/build/BUILD/xen-3.3.1/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -g -D__XEN__ -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -DNDEBUG -nostdinc -fno-builtin -fno-common -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/builddir/build/BUILD/xen-3.3.1/xen/include -I/builddir/build/BUILD/xen-3.3.1/xen/include/asm-x86/mach-generic -I/builddir/build/BUILD/xen-3.3.1/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -g -D__XEN__ -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -DNDEBUG -nostdinc -fno-builtin -fno-common -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/builddir/build/BUILD/xen-3.3.1/xen/include -I/builddir/build/BUILD/xen-3.3.1/xen/include/asm-x86/mach-generic -I/builddir/build/BUILD/xen-3.3.1/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -g -D__XEN__ -O2 -fomit-frame-pointer -m32 -march=i686 -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -DNDEBUG -nostdinc -fno-builtin -fno-common -iwithprefix include -Werror -Wno-pointer-arith -pipe -I/builddir/build/BUILD/xen-3.3.1/xen/include -I/builddir/build/BUILD/xen-3.3.1/xen/include/asm-x86/mach-generic -I/builddir/build/BUILD/xen-3.3.1/xen/include/asm-x86/mach-default -msoft-float -fno-stack-protector -g -D__XEN__ -c vpic.c -o vpic.o vpic.c: Assembler messages: vpic.c:58: Error: bad register name `%sil' make[5]: Leaving directory `/builddir/build/BUILD/xen-3.3.1/xen/arch/x86/hvm' Cheers, Mark. From berrange at redhat.com Tue Feb 24 10:39:18 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 24 Feb 2009 10:39:18 +0000 Subject: [fedora-virt] F11 sensible mouse pointer movement Message-ID: <20090224103918.GB23323@redhat.com> Just done some experimentation with USB tablet in Fedora 11 guests. It turns out we were just one tiny step away from it working correctly. Indeed, same applies for F10 and we didn't realize :-( In the guest, edit the HAL file /usr/share/hal/fdi/policy/10osvendor/10-x11-input.fdi just adding evdev Now shutdown the guest, and use virsh edit to add Now start the guest. The USB tablet will automatically configure and provide 1-for-1 mouse motion tracking with no pointer grab required Added 2 bugs to track this work so we get it done for F11 beta HAL https://bugzilla.redhat.com/show_bug.cgi?id=487025 virtinst https://bugzilla.redhat.com/show_bug.cgi?id=487028 You can try out the FDI change just fine on F10 if you're so inclined Regards, 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 :| From kraxel at redhat.com Tue Feb 24 11:35:26 2009 From: kraxel at redhat.com (Gerd Hoffmann) Date: Tue, 24 Feb 2009 12:35:26 +0100 Subject: [fedora-virt] Re: xen failure [was Re: [fedora-virt-maint] Fedora rawhide rebuild in mock status 2009-02-20 i386] In-Reply-To: <1235380080.31426.28.camel@blaa> References: <20090222031412.GA16588@mock.linuxdev.us.dell.com> <1235380080.31426.28.camel@blaa> Message-ID: <49A3DB7E.8020402@redhat.com> Mark McLoughlin wrote: > vpic.c: Assembler messages: > vpic.c:58: Error: bad register name `%sil' Fixed. cheers, Gerd From m.a.young at durham.ac.uk Tue Feb 24 19:01:20 2009 From: m.a.young at durham.ac.uk (M A Young) Date: Tue, 24 Feb 2009 19:01:20 +0000 (GMT) Subject: [fedora-virt] Dom0 kernels Message-ID: I have built a new set of kernel packages based on fedora rawhide kernels and the xen/dom0/hackery branch of Jeremy's git repository ( http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=summary ). This batch (kernel-2.6.29-0.114.2.6.rc6.fc11) is available via the koji build system at http://koji.fedoraproject.org/koji/taskinfo?taskID=1149500 These are really for development and debugging purposes only, as I am still having problems getting them to boot, but others have reported more success at getting kernels based on this git repository working, so you might be lucky. Note to install these packages on Fedora 10 you will need to have rpm-4.6.0-1.fc10 installed (currently in updates-testing but it should be available in updates soon) because of the change to SHA-256 file digest hashing in recent Fedora 11 builds. Michael Young From kraxel at redhat.com Tue Feb 24 21:03:30 2009 From: kraxel at redhat.com (Gerd Hoffmann) Date: Tue, 24 Feb 2009 22:03:30 +0100 Subject: [fedora-virt] Dom0 kernels In-Reply-To: References: Message-ID: <49A460A2.1060401@redhat.com> M A Young wrote: > I have built a new set of kernel packages based on fedora rawhide > kernels and the xen/dom0/hackery branch of Jeremy's git repository ( > http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=summary ). > This batch (kernel-2.6.29-0.114.2.6.rc6.fc11) is available via the > koji build system at > http://koji.fedoraproject.org/koji/taskinfo?taskID=1149500 > > These are really for development and debugging purposes only, as I am > still having problems getting them to boot, but others have reported > more success at getting kernels based on this git repository > working, so you might be lucky Try "pci=nomsi", msi support for xen isn't there yet. Last week a major bug in IO-APIC setup has been fixed and the kernels run quite stable on modern hardware now. My old, apic-less i386 laptop still doesn't boot though. cheers, Gerd From m.a.young at durham.ac.uk Tue Feb 24 21:46:48 2009 From: m.a.young at durham.ac.uk (M A Young) Date: Tue, 24 Feb 2009 21:46:48 +0000 (GMT) Subject: [fedora-virt] Dom0 kernels In-Reply-To: <49A460A2.1060401@redhat.com> References: <49A460A2.1060401@redhat.com> Message-ID: On Tue, 24 Feb 2009, Gerd Hoffmann wrote: > Try "pci=nomsi", msi support for xen isn't there yet. Last week a major > bug in IO-APIC setup has been fixed and the kernels run quite stable on > modern hardware now. My old, apic-less i386 laptop still doesn't boot > though. That particular kernel has CONFIG_PCI_MSI turned off at build, and I think the most recent git updates disable it within the kernel. My problem at the moment is that it doesn't seem to see the disks, so it never gets past the initrd. I also sometimes get IRQ related tracebacks. Michael Young From dlbewley at lib.ucdavis.edu Wed Feb 25 06:23:55 2009 From: dlbewley at lib.ucdavis.edu (Dale Bewley) Date: Tue, 24 Feb 2009 22:23:55 -0800 (PST) Subject: [fedora-virt] Accepted F11 Virt Features In-Reply-To: <1144624494.396301235542916109.JavaMail.root@zebra.lib.ucdavis.edu> Message-ID: <2138505843.396451235543035038.JavaMail.root@zebra.lib.ucdavis.edu> Howdy, I was touching up the virt release[1] notes a little bit. There are currently 5 virtualization related features[2] for F11: * KVM_PCI_Device_Assignment * KVM_and_QEMU_merge * Shared Network Interface * SVirt Mandatory Access Control * Virtualization VNC Authentication Only KVM PCI Device Assignment has been accepted[3] so far. The feature freeze is coming up in one week[4] (March 3rd). I assume if they are not listed as accepted at that time they shan't be included, barring fesco exception. Would the owners of the above features care to chime in about their (un)likelihood of inclusion in F11, or give em a little shove towards "acceptance"? [1] http://fedoraproject.org/wiki/Docs/Beats/Virtualization [2] http://fedoraproject.org/wiki/Category:F11_Virt_Features [3] http://fedoraproject.org/wiki/Releases/11/FeatureList [4] http://fedoraproject.org/wiki/Releases/11/Schedule -- Dale Bewley - Unix Administrator - Shields Library - UC Davis GPG: 0xB098A0F3 0D5A 9AEB 43F4 F84C 7EFD 1753 064D 2583 B098 A0F3 From markmc at redhat.com Wed Feb 25 11:14:13 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 25 Feb 2009 11:14:13 +0000 Subject: [fedora-virt] Accepted F11 Virt Features In-Reply-To: <2138505843.396451235543035038.JavaMail.root@zebra.lib.ucdavis.edu> References: <2138505843.396451235543035038.JavaMail.root@zebra.lib.ucdavis.edu> Message-ID: <1235560453.3663.63.camel@blaa> On Tue, 2009-02-24 at 22:23 -0800, Dale Bewley wrote: > Howdy, > I was touching up the virt release[1] notes a little bit. There are > currently 5 virtualization related features[2] for F11: Here's a quick take on the current status of these: > * KVM_PCI_Device_Assignment - VT-d is enabled by default again in the kernel, KVM support seems to work well - libvirt patches posted upstream yesterday - Cole is going to look at using the new libvirt APIs to allow NIC assignment in virt-manager and virt-install > * KVM_and_QEMU_merge - Glauber has done awesome work to update QEMU to latest upstream, split out sub-packages and create BIOS packages - The rumour mill has it that there will be a QEMU release at the end of this week or start of next week - Unclear as to whether we have time to switch to building QEMU from the kvm-userspace tarball; there may yet be dragons lurking there > * Shared Network Interface - David Lutterkort is working hard on the netcf library and is still relatively optimistic about getting it into F11 > * SVirt Mandatory Access Control - Dan Walsh has been working to get the patch merged into libvirt and add support in virtinst - Looks likely this will make F11 > * Virtualization VNC Authentication - Dan Berrange posted his patches to qemu-devel a week or two ago; unclear as to the current status > Only KVM PCI Device Assignment has been accepted[3] so far. The > feature freeze is coming up in one week[4] (March 3rd). I assume if > they are not listed as accepted at that time they shan't be included, > barring fesco exception. > > Would the owners of the above features care to chime in about their > (un)likelihood of inclusion in F11, or give em a little shove towards > "acceptance"? Yep - that absolutely needs to be done very soon. Glauber, Dan (Walsh) and David could you read: https://fedoraproject.org/wiki/Features/Policy then update your page and add it to the FeatureReadyForWrangler category. At that point it will be queued up for FESCo review. FESCo meet on Fridays AFAIR. (Dan Berrange - I fixed VNCAuth to really be in ReadyForWrangler :-) Cheers, Mark. From markmc at redhat.com Wed Feb 25 14:35:48 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 25 Feb 2009 14:35:48 +0000 Subject: [fedora-virt] [Fwd: Fedora Test Day - CrashCatcher] Message-ID: <1235572548.5095.2.camel@blaa> Hey, Wondering if some folks fancy joining the test day tomorrow and e.g. making sure that CrashCatcher catches segfaults in qemu-kvm, libvirtd, virt-manager, virt-viewer etc .? Cheers, Mark. -------------- next part -------------- An embedded message was scrubbed... From: James Laska Subject: Fedora Test Day - CrashCatcher Date: Wed, 25 Feb 2009 09:30:07 -0500 Size: 5157 URL: From markmc at redhat.com Wed Feb 25 15:49:49 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 25 Feb 2009 15:49:49 +0000 Subject: [fedora-virt] Accepted F11 Virt Features In-Reply-To: <2138505843.396451235543035038.JavaMail.root@zebra.lib.ucdavis.edu> References: <2138505843.396451235543035038.JavaMail.root@zebra.lib.ucdavis.edu> Message-ID: <1235576989.5095.19.camel@blaa> Hi, I'm not sure it's clear to anyone why we have this feature approval and feature freeze process, so I thought I'd point to some wiki pages with the background. See below. IMHO this boils down to communication: - we want people to know in advance what new virt features we're adding in F11 - if we miss the feature freeze with any of those features we should be planning realistically whether to continue pushing for F11 or whether to punt to F12 because it won't have had time to stabilise it for the F11 release - if we feel that we can include it post freeze and stabilise it in time, we should ask for an exception (a second opinion, basically) from rel-eng confirming that that's a sane plan - it's only right to keep rel-eng in the loop; they are the ones with a global view of the Fedora release. I've found them very sane in the past when considering exceptions Anyway, the bits from the wiki: https://fedoraproject.org/wiki/Features/Policy/Background The value of having features defined up front is many-fold: * Everyone has an idea of what everyone else is working on. This provides the opportunity for feedback and suggestions for improvement. * You get people interested--perhaps even helping out * You get some idea of areas that are going to need testing so that testers can build up experience and knowledge about the area * You generate excitement around what's being worked on * You avoid surprises at the end * Public accountability to do what we say we are going to do * Easier Release Notes creation for new features--everything needed is on the individual feature pages. * Ability to list out a set of features to be picked up or when talking to the media/press. Fedora ambassadors and any promotional efforts would find a feature list useful. http://fedoraproject.org/wiki/ReleaseEngineering/FeatureFreezePolicy As of the feature freeze for a release, no new features or major version bumps are allowed for packages already in the Fedora collection ... Note that ignoring the freeze process and introducing new features anyway will lead to your package being reverted and a reduction of the chances of an exception being made. Cheers, Mark. From lutter at redhat.com Wed Feb 25 16:15:05 2009 From: lutter at redhat.com (David Lutterkort) Date: Wed, 25 Feb 2009 16:15:05 +0000 Subject: [fedora-virt] Accepted F11 Virt Features In-Reply-To: <1235560453.3663.63.camel@blaa> References: <2138505843.396451235543035038.JavaMail.root@zebra.lib.ucdavis.edu> <1235560453.3663.63.camel@blaa> Message-ID: <1235578505.13984.0.camel@avon.watzmann.net> On Wed, 2009-02-25 at 11:14 +0000, Mark McLoughlin wrote: > Glauber, Dan (Walsh) and David could you read: > > https://fedoraproject.org/wiki/Features/Policy > > then update your page and add it to the FeatureReadyForWrangler > category. At that point it will be queued up for FESCo review. FESCo > meet on Fridays AFAIR. Done. David From markmc at redhat.com Wed Feb 25 21:15:26 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 25 Feb 2009 21:15:26 +0000 Subject: [fedora-virt] Fedora virt status Message-ID: <1235596526.19157.63.camel@blaa> 2009-03-03 Feature freeze (6 days) 2009-03-10 Beta Freeze (13 days) 2009-04-14 Final freeze (48 days) An early report this week because I'm about to disappear for three weeks. Just before the feature/beta freeze ... nice timing, I know! :-) F11 Features ============ Dale Bewley provides a timely reminder that all but one of the F11 virt features have not yet been approved by FESCo: http://www.redhat.com/archives/fedora-virt/2009-February/msg00088.html FWN === This weeks Fedora Weekly News is out with another great virtualization section: https://fedoraproject.org/wiki/FWN/Issue164#Virtualization Tablet Pointer ============== Dan Berrange did some experimentation with making Fedora be able to sanely handle a tablet pointer without extra configuration and filed these two bugs: https://bugzilla.redhat.com/487025 Add a HAL FDI file for the QEMU tablet device https://bugzilla.redhat.com/487028 Default to using the table in python-virtinst for F11 guests: The idea here is that if we use the tablet pointer with F11 guest by default it will fix the screwiness with mouse pointers in guests by using absolute pointer positioning rather than relative positioning. High Resolution in QEMU ======================= In order to use a higher resolution when running Fedora on qemu/kvm, we're planning on using the PCI subvendor ID to allow the Xorg cirrus driver to detect that it's a QEMU emulated card and use 1024x768. Dan Berrange filed two bugs to track this: https://bugzilla.redhat.com/487118 Need to add subsystem vendor ID for kvm/qemu cirrus card https://bugzilla.redhat.com/251264 xorg should use 1024x768 for kvm/qemu cirrus card Device Assignment ================= Several libvirt patch sets were posted to add device dettach, re-attach and reset support: http://www.redhat.com/archives/libvir-list/2009-February/msg00393.html http://www.redhat.com/archives/libvir-list/2009-February/msg00438.html http://www.redhat.com/archives/libvir-list/2009-February/msg00441.html Also, Chris Wright posted the patch for "remove_id" in sysfs: http://marc.info/?l=kvm&m=123545476703098 https://bugzilla.redhat.com/487103 QEMU ==== Rumour has it that there may be an upstream release Real Soon Now. The package reviews for the three new BIOS packages are still in progress: https://bugzilla.redhat.com/485417 https://bugzilla.redhat.com/485418 https://bugzilla.redhat.com/485420 Installer Debugging =================== A bug was filed about headless installs: https://bugzilla.redhat.com/487136 KVM Having problem In fedora 10 With no-gui This prompted a new tip to be added to: https://fedoraproject.org/wiki/Reporting_virtualization_bugs#virt-install In order to gain access to a serial console during the install, you can use -x "console=ttyS0". Using a serial console combined with a VNC install can be very useful for debugging e.g. --nographics -x "console=ttyS0 vnc". Perhaps it might make sense for Fedora to use any available serial console if there is no graphics card? Probably not, though, since you have no idea whether anything is connected to the other end of the serial line - on a bare-metal headless server, such a policy would have us pointlessly driving unused serial lines. kvm-84 ====== The recently released kvm-84 has hit rawhide. Avi's release announcement is here: http://marc.info/?l=kvm&m=123465878918472 Tom London reports that qemu-kvm segaults for him when using the SDL graphics frontend. It appears the issue may be related to SDL's use of SSE/MMX instructions for bit blitting. https://bugzilla.redhat.com/487018 Segfault with kvm-84-1.fc11.x86_64.rpm (SDL related) libvirt-0.6.0 ============= libvirt-0.6.0-3.fc10 was pushed to f10-updates-testing this week. Another issue with libvirt-0.6.0 was reported: https://bugzilla.redhat.com/487013 virsh setvcpus hangs with libvirt-0.6.0 This turns out to be a recursive locking bug introduced by the major threading changes in the release. Busted Installs =============== Jeff Garzik reports that he sees x86_64 F10 installs hangs at "installing bootloader" under KVM: https://bugzilla.redhat.com/474116 This problem went away when he used 1Gb RAM instead of 512Mb. There is already another similar, but not identical bug, detailing an issue with x86_64 installs on 512Mb: https://bugzilla.redhat.com/480826 Fabian Deutsch also reports some F11 alpha installer issues under KVM. The first looks like a generic anaconda bug that also existed in F10: https://bugzilla.redhat.com/476433 The second seems to be an anaconda hang during a LiveCD install: https://bugzilla.redhat.com/484721 Neither of Fabian's issues look related to known pvmmu related crash in F11 alpha: https://bugzilla.redhat.com/480822 However, Mark Bidewell reported an issue with F11 Alpha installs to kvm at vger and this did turn out to likely be pvmmu related: http://marc.info/?l=kvm&m=123548745416389 Also, James Laska previously reported a kernel oops during install that may well be yet another pvmmu related issue: https://bugzilla.redhat.com/483648 Marcelo's pvmmu fix first made it in 2.6.26-rc5.git, so hopefully the world has been a better place since then. Rawhide Rebuild Failures ======================== Matt Domsch rebuilt all of rawhide in mock and found that etherboot, ruby-libvirt, gnome-applet-vm and xen failed to build: http://www.redhat.com/archives/fedora-virt/2009-February/msg00079.html http://www.redhat.com/archives/fedora-virt/2009-February/msg00080.html http://www.redhat.com/archives/fedora-virt/2009-February/msg00081.html http://www.redhat.com/archives/fedora-virt/2009-February/msg00082.html Xen dom0 ======== Michael Young completed the first dom0 build in Koji: http://www.redhat.com/archives/fedora-virt/2009-February/msg00085.html These are really for development and debugging purposes only, as I am still having problems getting them to boot, but others have reported more success at getting kernels based on this git repository working, so you might be lucky. Michael found an interesting issue where recently built F11 RPMs wouldn't install on F10 because F11 RPMs use SHA-256 checksums. F10 updates now contains a version of RPM which can handle these checksums. https://bugzilla.redhat.com/487140 Packages built with rpm-4.6.0-8.fc11 won't install on Fedora 10 x86_64 Xen DomU ======== Some discussion on fedora-kernel-list about the need to fix anaconda to install kernel-PAE on any machine which supports PAE: http://www.redhat.com/archives/fedora-kernel-list/2009-February/msg00079.html Michael Young also reported a lockdep warning during DomU boot which Jeremy has fixed in his Dom0 tree: https://bugzilla.redhat.com/487324 kernel/lockdep.c warning in xen guest boot dmesg Bugs ==== DOOM-O-METER: 188 open bugs last week, 192 this week. Baa! https://bugzilla.redhat.com/487190 virt-manager has hardcoded Requires: PolicyKit-gnome Does virt-manager really require PolicyKit-gnome? The KDE spin doesn't ship it. Looks like PolicyKit was fixed in 0.7 to allow us to only require PolicyKit itself. https://bugzilla.redhat.com/467687 Virtual network won't work until restart It appears that ip_forward was being set to zero because the NetworkManager and libvirtd services were incorrectly ordered. The "reporting virt bugs" wiki page has some details on how to diagnose the problem in future: https://fedoraproject.org/wiki/Reporting_virtualization_bugs#Networking From berrange at redhat.com Wed Feb 25 23:04:34 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 25 Feb 2009 23:04:34 +0000 Subject: [fedora-virt] Fedora virt status In-Reply-To: <1235596526.19157.63.camel@blaa> References: <1235596526.19157.63.camel@blaa> Message-ID: <20090225230434.GD11057@redhat.com> On Wed, Feb 25, 2009 at 09:15:26PM +0000, Mark McLoughlin wrote: > Installer Debugging > =================== > > A bug was filed about headless installs: > > https://bugzilla.redhat.com/487136 > KVM Having problem In fedora 10 With no-gui > > This prompted a new tip to be added to: > > https://fedoraproject.org/wiki/Reporting_virtualization_bugs#virt-install > > In order to gain access to a serial console during the install, > you can use -x "console=ttyS0". Using a serial console combined > with a VNC install can be very useful for debugging e.g. > --nographics -x "console=ttyS0 vnc". > > Perhaps it might make sense for Fedora to use any available serial > console if there is no graphics card? Probably not, though, since you > have no idea whether anything is connected to the other end of the > serial line - on a bare-metal headless server, such a policy would > have us pointlessly driving unused serial lines. Latest KVM has a new 'virtio console' PCI device present. We just need to hook this upto libirt's XML, to get an always available PV console for all KVM guests without messing around with serial ports. Just need to check Fedora guests have a config /etc/event/hvc0 so the agetty is started on it out of the box. 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 :| From m.a.young at durham.ac.uk Thu Feb 26 00:41:19 2009 From: m.a.young at durham.ac.uk (M A Young) Date: Thu, 26 Feb 2009 00:41:19 +0000 (GMT) Subject: [fedora-virt] Re: Dom0 kernels In-Reply-To: References: Message-ID: On Tue, 24 Feb 2009, M A Young wrote: > I have built a new set of kernel packages based on fedora rawhide kernels and > the xen/dom0/hackery branch of Jeremy's git repository > ( http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=summary ). > This batch (kernel-2.6.29-0.114.2.6.rc6.fc11) is available via the koji build > system at > http://koji.fedoraproject.org/koji/taskinfo?taskID=1149500 And I have now done an update (kernel-2.6.29-0.114.2.8.rc6.fc11) which is available via http://koji.fedoraproject.org/koji/taskinfo?taskID=1178436 > These are really for development and debugging purposes only, as I am still > having problems getting them to boot, but others have reported more success > at getting kernels based on this git repository working, so you might be > lucky. This one does allow one of my machines to boot in single user mode (which is all I have really tested so far), though I am sure there are still plenty of other bugs to find. > Note to install these packages on Fedora 10 you will need to have > rpm-4.6.0-1.fc10 installed (currently in updates-testing but it should be > available in updates soon) because of the change to SHA-256 file digest > hashing in recent Fedora 11 builds. Michael Young From ehabkost at redhat.com Thu Feb 26 18:19:03 2009 From: ehabkost at redhat.com (Eduardo Habkost) Date: Thu, 26 Feb 2009 15:19:03 -0300 Subject: [fedora-virt] etherboot failure [was Re: [fedora-virt-maint] Fedora rawhide rebuild in mock status 2009-02-20 x86_64] In-Reply-To: <1235380063.31426.25.camel@blaa> References: <20090222031325.GA16375@mock.linuxdev.us.dell.com> <1235380063.31426.25.camel@blaa> Message-ID: <20090226181903.GA15621@blackpad> On Mon, Feb 23, 2009 at 09:07:43AM +0000, Mark McLoughlin wrote: > On Sat, 2009-02-21 at 21:13 -0600, Matt Domsch wrote: > > Fedora Rawhide-in-Mock Build Results for x86_64 > > based on rawhide as of Friday Feb 20, 2009. > > > > Most packages were actually built as of the F11 Alpha cut on or around > > Feb 1. Any newer packages in rawhide as of Feb 20 were then pulled in > > and rebuilt, and any previously-failed packages were also rebuilt, so > > I believe this list to be current and correct. I did have a couple > > servers fail during the builds, so it is possible that at most 8 of > > these are not true failures, but a result of builders crashing. Don't > > pin your hopes on that though. :-) > > > > Full logs at http://linux.dell.com/files/fedora/FixBuildRequires/ > ... > > etherboot-5.4.4-8.fc11 (build/make) ehabkost,glommer,virtmaint > > http://linux.dell.com/files/fedora/FixBuildRequires/mock-results/x86_64/etherboot-5.4.4-8.fc11.src.rpm/result/mock.log > > ERROR: Bad build req: No Package Found for glibc32. Exiting. I suppose this is not an issue anymore? I see etherboot-5.4.4-9.fc11 as built, on Koji. -- Eduardo From clalance at redhat.com Fri Feb 27 19:01:51 2009 From: clalance at redhat.com (Chris Lalancette) Date: Fri, 27 Feb 2009 20:01:51 +0100 Subject: [fedora-virt] FESCo F-11 Virt features meeting Message-ID: <49A8389F.5020405@redhat.com> All, I attended the F-11 FESCo meeting on Friday (Feb 27). They talked about 4 Virt related features: sVirt - https://fedoraproject.org/wiki/Features/SVirt_Mandatory_Access_Control - Approved. They like the feature, but worried about getting the support into the Fedora package on time. They also asked about SELinux support with virt + LVM partitions, as well as sVirt support with LVM, but I didn't know. VirtVNCAuth - https://fedoraproject.org/wiki/Features/VirtVNCAuth - Approved. They said that the "how to test" section on the Feature page needs to be filled out better SharedNetworkInterface - https://fedoraproject.org/wiki/Features/Shared_Network_Interface - Deferred to F-12. Not enough of the bits are in place to make this feature "testable by users" by Tuesday. VirtImprovedConsole - https://fedoraproject.org/wiki/Features/VirtImprovedConsole - Approved. They want to see the release notes on the feature page filled in. -- Chris Lalancette From dlbewley at lib.ucdavis.edu Sat Feb 28 17:39:38 2009 From: dlbewley at lib.ucdavis.edu (Dale Bewley) Date: Sat, 28 Feb 2009 09:39:38 -0800 (PST) Subject: [fedora-virt] FESCo F-11 Virt features meeting In-Reply-To: <1928197141.523051235842773584.JavaMail.root@zebra.lib.ucdavis.edu> Message-ID: <1310012804.523071235842778681.JavaMail.root@zebra.lib.ucdavis.edu> ----- "Chris Lalancette" wrote: > All, > I attended the F-11 FESCo meeting on Friday (Feb 27). They > talked about 4 > Virt related features: I've started to summarize the outcome for the Monday issue of FWN as follows. At this time, the list of features approved for inclusion in Fedora 11 are: * http://fedoraproject.org/wiki/Features/KVM_PCI_Device_Assignment * http://fedoraproject.org/wiki/Features/SVirt_Mandatory_Access_Control * http://fedoraproject.org/wiki/Features/VirtImprovedConsole * http://fedoraproject.org/wiki/Features/VirtVNCAuth Deferred to F12 was: * http://fedoraproject.org/wiki/Features/Shared_Network_Interface Not addressed in the meeting was: * http://fedoraproject.org/wiki/Features/KVM_and_QEMU_merge The KVM QEMU feature page is listed as FeaturePageIncomplete. It was very briefly mentioned. "glommer what about kvm and qemu merge?" "notting glommer: doesn't appear to be in the ready for fesco list" -- Dale Bewley - Unix Administrator - Shields Library - UC Davis GPG: 0xB098A0F3 0D5A 9AEB 43F4 F84C 7EFD 1753 064D 2583 B098 A0F3 From berrange at redhat.com Sat Feb 28 18:14:22 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Sat, 28 Feb 2009 18:14:22 +0000 Subject: [fedora-virt] FESCo F-11 Virt features meeting In-Reply-To: <1310012804.523071235842778681.JavaMail.root@zebra.lib.ucdavis.edu> References: <1928197141.523051235842773584.JavaMail.root@zebra.lib.ucdavis.edu> <1310012804.523071235842778681.JavaMail.root@zebra.lib.ucdavis.edu> Message-ID: <20090228181422.GA19324@redhat.com> On Sat, Feb 28, 2009 at 09:39:38AM -0800, Dale Bewley wrote: > ----- "Chris Lalancette" wrote: > > All, > > I attended the F-11 FESCo meeting on Friday (Feb 27). They > > talked about 4 > > Virt related features: > > I've started to summarize the outcome for the Monday issue of FWN as follows. > > At this time, the list of features approved for inclusion in Fedora 11 are: > * http://fedoraproject.org/wiki/Features/KVM_PCI_Device_Assignment > * http://fedoraproject.org/wiki/Features/SVirt_Mandatory_Access_Control > * http://fedoraproject.org/wiki/Features/VirtImprovedConsole > * http://fedoraproject.org/wiki/Features/VirtVNCAuth > > Deferred to F12 was: > * http://fedoraproject.org/wiki/Features/Shared_Network_Interface > > Not addressed in the meeting was: > * http://fedoraproject.org/wiki/Features/KVM_and_QEMU_merge FYI, we've decided that this is almost certainly F12 material. The QEMU upstream release will be so close to the feature freeze, that we don't want to risk causing KVM regressions by trying to then merge the two. Hopefully come F12, more of the KVM bits will be in QEMU mainline, so work we need todo to merge would be minimal 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 :|