From dlbewley at lib.ucdavis.edu Wed Apr 1 06:48:02 2009 From: dlbewley at lib.ucdavis.edu (Dale Bewley) Date: Tue, 31 Mar 2009 23:48:02 -0700 Subject: [fedora-virt] f11 virt release notes freezing Message-ID: <1238568482.29645.68.camel@seitan.home.bewley.net> I've been busy at my day job and not paying close enough attention to Fedora 11 docs deadlines. Apparently the window for changes essentially closes Wednesday (today).[1] The notes are essentially in place. I don't think there are any gaping holes, but I should have prompted for feedback much sooner. If you could apply any love to the release notes[2] it would be appreciated. = QEMU / KVM = It is noted that QEMU and KVM are merging as a package, but I've also separately listed the fact that QEMU is now 0.10.0 and KVM is now 84. With the merge, might it be confusing or inaccurate to mention a distinct new version of KVM? I'll admit to being somewhat fuzzy on where/how that line is drawn. I see[3] QEMU 0.10.0 in rawhide, but not 0.10.1, so I adjusted the version in the relnotes. I copied the feature list from the 0.10.0 release announcement. If you'd care to suggest deletes or enhancements of the list please do. The KVM changelog since 74 (version at initial F10 release) is quite long and not easily digestible by me at this late hour. Would anyone care to offer some highlights or fill them into the wiki? Or, again, should those be folded into QEMU? = Libvirt = I previously copied the list of changes from the releases, but did not try to prune them down. It may be fine. = The Current Outline = 1 Virtualization * 1.1 Improved VNC Authentication for Virtual Machine Management * 1.2 Improved Graphical Console for Virtual Machines * 1.3 KVM PCI Device Assignment * 1.4 KVM and QEMU merge * 1.5 SVirt Mandatory Access Control * 1.6 Other Improvements * 1.6.1 QEMU Updated to 0.10.0 * 1.6.2 KVM Updated to 84 * 1.6.3 libvirt Updated to 0.6.1 * 1.6.4 virt-manager Updated to 0.7.0 * 1.6.5 virtinst Updated to 0.400.3 * 1.6.6 Xen Updated to 3.3.1 * 1.7 Xen Kernel Support Thanks for any edits or suggestions you can offer. [1] http://www.redhat.com/archives/fedora-docs-list/2009-March/msg00232.html [2] http://fedoraproject.org/wiki/Documentation_Virtualization_Beat [3] http://fedoraproject.org/wiki/User:Dale#Packages From markmc at redhat.com Wed Apr 1 11:55:34 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Wed, 01 Apr 2009 12:55:34 +0100 Subject: [fedora-virt] f11 virt release notes freezing In-Reply-To: <1238568482.29645.68.camel@seitan.home.bewley.net> References: <1238568482.29645.68.camel@seitan.home.bewley.net> Message-ID: <1238586934.24659.15.camel@blaa> Hi Dale, On Tue, 2009-03-31 at 23:48 -0700, Dale Bewley wrote: > I've been busy at my day job and not paying close enough attention to > Fedora 11 docs deadlines. Apparently the window for changes essentially > closes Wednesday (today).[1] > > The notes are essentially in place. I don't think there are any gaping > holes, but I should have prompted for feedback much sooner. If you could > apply any love to the release notes[2] it would be appreciated. Yep, I think they look in good shape. > = QEMU / KVM = > It is noted that QEMU and KVM are merging as a package, but I've also > separately listed the fact that QEMU is now 0.10.0 and KVM is now 84. > > With the merge, might it be confusing or inaccurate to mention a > distinct new version of KVM? I'll admit to being somewhat fuzzy on > where/how that line is drawn. > > I see[3] QEMU 0.10.0 in rawhide, but not 0.10.1, so I adjusted the > version in the relnotes. I copied the feature list from the 0.10.0 > release announcement. If you'd care to suggest deletes or enhancements > of the list please do. Yes, this is a very confusing - not least because it's going to change before the release. What we plan on shipping is a version of kvm-userspace which is based off the qemu-0.10.x branch. So - F11 will have qemu-0.10.1 at the very least. > The KVM changelog since 74 (version at initial F10 release) is quite > long and not easily digestible by me at this late hour. Would anyone > care to offer some highlights or fill them into the wiki? Or, again, > should those be folded into QEMU? Pointing at the kvm ChangeLog is probably the best you can do, really. There's added confusion there too - the kvm release changelog covers both userspace and kernel space, and we don't ship a specific kernel kvm version ... we ship whatever is in Linus releases. > = Libvirt = > I previously copied the list of changes from the releases, but did not > try to prune them down. It may be fine. Pruning it down a little might be good - e.g. "gnulib updates" doesn't tell people anything useful. Not a big deal, though. Cheers, Mark. From loganjerry at gmail.com Wed Apr 1 18:10:27 2009 From: loganjerry at gmail.com (Jerry James) Date: Wed, 1 Apr 2009 12:10:27 -0600 Subject: [fedora-virt] Release mouse pointer but not keyboard focus Message-ID: <870180fe0904011110l4c757ccax91367d6dd4ee5309@mail.gmail.com> I have a small collection of virtual machines on a Fedora 10 x86_64 host. I created them with virt-manager. On occasion, when I release the pointer with Ctrl-Alt, the mouse pointer is released, but the keyboard focus is not. So I can click in other host windows, but anything I type continues to go to the virtual window that last had focus. Has anybody else seen this? I've seen it in a Fedora Rawhide guest on one host, and in a CentOS 5.3 guest on a different host (both hosts are F-10 x86_64). I'd file a bug, but I'm not sure what component is causing the problem. Thanks, -- Jerry James http://loganjerry.googlepages.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From berrange at redhat.com Wed Apr 1 18:24:46 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 1 Apr 2009 19:24:46 +0100 Subject: [fedora-virt] Release mouse pointer but not keyboard focus In-Reply-To: <870180fe0904011110l4c757ccax91367d6dd4ee5309@mail.gmail.com> References: <870180fe0904011110l4c757ccax91367d6dd4ee5309@mail.gmail.com> Message-ID: <20090401182446.GA14683@redhat.com> On Wed, Apr 01, 2009 at 12:10:27PM -0600, Jerry James wrote: > I have a small collection of virtual machines on a Fedora 10 x86_64 host. I > created them with virt-manager. On occasion, when I release the pointer > with Ctrl-Alt, the mouse pointer is released, but the keyboard focus is > not. So I can click in other host windows, but anything I type continues to > go to the virtual window that last had focus. > > Has anybody else seen this? I've seen it in a Fedora Rawhide guest on one > host, and in a CentOS 5.3 guest on a different host (both hosts are F-10 > x86_64). I'd file a bug, but I'm not sure what component is causing the > problem. Thanks, Its gtk-vnc, and updated builds are already in rawhide, and Fedora 10/9 updates-testing repos 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 giallu at gmail.com Thu Apr 2 06:41:46 2009 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 2 Apr 2009 08:41:46 +0200 Subject: [fedora-virt] Copy & paste Message-ID: Is there a way to copy&paste to/from a virtual machine? -- Gianluca Sforna http://morefedora.blogspot.com http://www.linkedin.com/in/gianlucasforna From dlaor at redhat.com Thu Apr 2 11:39:25 2009 From: dlaor at redhat.com (Dor Laor) Date: Thu, 02 Apr 2009 14:39:25 +0300 Subject: [fedora-virt] Copy & paste In-Reply-To: References: Message-ID: <49D4A3ED.6000507@redhat.com> Gianluca Sforna wrote: > Is there a way to copy&paste to/from a virtual machine? > > Currently not :( The plan is to use vmchannel pci device to pass the info from guest-host. From markmc at redhat.com Fri Apr 3 12:41:22 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 03 Apr 2009 13:41:22 +0100 Subject: [fedora-virt] Fedora virtualization status report Message-ID: <1238762482.2510.34.camel@blaa> The F11 final development freeze is getting very close: 2009-04-14 Final freeze (12 days) There's a huge pile of bug-fixing and polish work to do in that time. If you're looking to help out, there's no better place to start than the F11VirtBlocker/F11VirtTarget tracker bugs: https://bugzilla.redhat.com/showdependencytree.cgi?id=F11VirtBlocker&hide_resolved=1 https://bugzilla.redhat.com/showdependencytree.cgi?id=F11VirtTarget&hide_resolved=1 F11 Beta Release ================ The Fedora 11 Beta was announced last week: http://www.redhat.com/archives/fedora-announce-list/2009-March/msg00012.html Please do take the time to try it out and file bugs! Fedora Weekly News ================== Another week, another FWN issue with a virtualization section from Dale Bewley: http://fedoraproject.org/wiki/FWN/Issue169#Virtualization F11 QEMU ======== There has been confusion all round on what version of QEMU will be included in the Fedora 11 release. The confusion stems from the fact that qemu is now being built from a kvm-userspace tarball, not the recently release qemu-0.10.1 tarball. The plan for F11 is to release with an official kvm-userspace tarball released from the upstream stable branch which is based on qemu-0.10.x. However, since upstream KVM hasn't made that release quite yet, rawhide contains a snapshot of the upstream stable branch of kvm-userspace. The upstream stable branch was only created this week, and Glauber promptly went ahead and replaced the snapshot of the development branch in rawhide with a snapshot of the stable branch. He also needed to backport the VNC SASL patches and some gcc build fixes. Everyone should keep an eye out for regressions! In other news, FESCo rubber-stamped the kvm/qemu merge feature for F11: https://fedoraproject.org/wiki/Features/KVM_and_QEMU_merge This just means the feature will now be pimped in the release notes. On the bugs front, the GCC bug affecting qemu was fixed this week: https://bugzilla.redhat.com/490512 segfault in stw_kernel when qemu is run https://bugzilla.redhat.com/490509 GCC register allocation wrongly using ebp The gcc bug has been fixed, so qemu should be fixed since qemu-0.10-0.12.kvm20090323git.fc11 Also: https://bugzilla.redhat.com/457979 Update QEMU to use gPXE roms for iSCSI boot support Glauber posted a patch upstream to allow enough ROM space for gPXE. The fix was accepted upstream and Glauber cherry-picked it into rawhide. https://bugzilla.redhat.com/471000 QEMU processes input from arrow keys incorrectly glommer backported the evdev patch to F-10 qemu-kvm and pushed to updates-testing. Please test and update its karma! https://bugzilla.redhat.com/492075 qemu package missing debuginfo for qemu-img Glauber's patch upstream prompted a configure --disable-strip option to be added. Latest rawhide qemu is building with this option and we have debuginfo back again. F11 Translations ================ The Fedora i18n team created a bunch of bugs against virt-manager, virt-df, virt-mem and virt-top to allow them to submit translations for Fedora 11: https://bugzilla.redhat.com/493795 (virt-manager) https://bugzilla.redhat.com/493797 (virt-df) https://bugzilla.redhat.com/493798 (virt-mem) https://bugzilla.redhat.com/493799 (virt-top) Fedora 12 Development ===================== Some people are mighty impatient and already eager to start working towards Fedora 12. To that end, Jesse announced that maintainers can request their packaged be branched for F12: http://www.redhat.com/archives/fedora-devel-list/2009-March/msg02029.html The kernel guys have started building the 2.6.30-rc0 kernels and they can be downloaded from Koji. Again, the virt features already planned for F12 are listed here: https://fedoraproject.org/wiki/Category:F12_Virt_Features Shared Network Interface ======================== In a similar vein, Laine Stump and David Lutterkort have been pushing ahead with the network interface configuration support that's planned for libvirt in Fedora 12. Laine posted an API proposal to libvir-list: http://www.redhat.com/archives/libvir-list/2009-March/thread.html#00397 More details on the F12 feature can be found here: https://fedoraproject.org/wiki/Features/Shared_Network_Interface libvirt Release Schedule ======================== Daniel Veillard posted his plans for the next libvirt release and this prompted a healthy discussion on libvirt's release process and schedule. Among the options being discussed are monthly releases, feature freezes and stable releases: http://www.redhat.com/archives/libvir-list/2009-March/thread.html#00425 Related is the question of whether every new release of libvirt (and other virt packets) should be pushed to stable Fedora releases. More on this soon. libguestfs ========== Rich Jones posted a blog about a new project he is working on to create an API to allow accessing and modifing guest images. True to form, Rich's idea is firmly in the crazy-but-might-just-work category: http://rwmj.wordpress.com/2009/04/01/libguestfs-access-and-modify-virtual-machine-disk-images/ ... Now step aside for a minute and think about virtual machine disk images. From the host, they look like files or partitions, but they contain a partition table, partitions, perhaps LVM, a variety of filesystems like ext3 or NTFS or btrfs, and the whole lot might be wrapped in a tricky container such as qcow2. For virt-df we actually wrote new code that can decode a lot of this, but it?s a massive effort to keep up with changes in the formats. What we need to use is the Linux kernel code directly. The way I?m going to do this is to boot a Linux kernel. A small, you might say ?minimal? Linux distro, with a bit of userspace. The whole thing runs inside a qemu container, and we talk from a small library to the userspace inside qemu, giving it instructions like ?edit this file?, ?run this program?, ?install this device driver?. Xen Dom0 ======== Michael Young continued updating his test kernels and posted a URL for yum repo: http://fedorapeople.org/~myoung/dom0/ Pasi K?rkk?inen reports that CONFIG_HIGHPTE is broken on some machines and Michael has disabled this in his latest build. Upstream, Jeremy Fitzhardinge pushed the dom0 changes directly to Linus, which seems to have got Ingo all riled up: http://lkml.org/lkml/2009/3/31/362 It looks like Linus may have just ignored the pull request. Time will tell. Bugs ==== DOOM-O-METER: 185 bugs last week, 192 this week. Bah! (On a side note - this metric includes NEEDINFO bugs; we should probably do a run through to clean those up) https://bugzilla.redhat.com/490266 virtio_net tx stall with segmentation offload Guest->remote GSO failure with 2.6.29 host, but not 2.6.27. Herbert's fix was pulled into rawhide from upstream. https://bugzilla.redhat.com/492082 anaconda "unitialized drive" warning is a little too terrifying Further discussion on anaconda's "YOU WILL LOSE ALL DATA" warning. The current suggestion is that virtinst should add an empty partition table to the disks it creates. https://bugzilla.redhat.com/492523 [Fedora Xen]: pvops kernels won't boot on processors without the NX bit https://bugzilla.redhat.com/480880 f10 x86_64 xen guests fail to boot on f8 host (NX issue) Chis Lalance investigated the pv_ops NX issue some more and poked upstream into action. It looks like Chuck Ebbert is going to include the fix from upstream for F11. https://bugzilla.redhat.com/478734 selinux blocks kvm network configuration script (e.g. /etc/qemu-ifup) Some configurations currently require an /etc/qemu-ifup script, but this is blocked by SELinux. Plan is to support these configurations in libvirt directly. https://bugzilla.redhat.com/492829 virt-manager console should only scale console when maximised or fullscreen https://bugzilla.redhat.com/469830 RFE: Let details view remember the View->Scale display state Resolved by the "Graphical Console Scaling" preference. https://bugzilla.redhat.com/493692 Creating new VM; SELinux prevents opening iso image of install media Sounds like an sVirt related problem. https://bugzilla.redhat.com/493256 network install gives "Permission denied: '/var/lib/libvirt/boot/virtinst-.treeinfo.XIYNd_" An F10 bug with latest virt-manager. Another SELinux issue? https://bugzilla.redhat.com/493258 "Disk is already in use by another guest!" Latest virt-manager warning that another guest is using disk image, when the previous guest has been deleted. https://bugzilla.redhat.com/493408 Can't use API to create virtual floppy drive with correct device name Issue with providing floppy drives to guests using virt-install. Fix is upstream and looks easy to cherry-pick into rawhide. https://bugzilla.redhat.com/493414 Windows installs require manual reboot in the middle During an install using virt-install, Windows is seen to shut down rather than reboot. May be a generic KVM reboot issue with Windows. https://bugzilla.redhat.com/492523 xen pvops kernels won't boot on processors without the NX bit What looks like a fix for this issue is in Jeremy's queue From markmc at redhat.com Fri Apr 3 17:33:30 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Fri, 03 Apr 2009 18:33:30 +0100 Subject: [fedora-virt] Using kvm-autotest to test Fedora KVM Message-ID: <1238780010.2510.54.camel@blaa> Hi, Upstream KVM developers are working hard on a suite of regression tests for KVM. It would be hugely helpful if people could run kvm-autotest on their own machines to try and catch as many KVM issues as possible. I've written up some notes here: https://fedoraproject.org/wiki/Testing_KVM_with_kvm_autotest I've just run this myself on rawhide using qemu-0.10-5.fc11 and it succeeded. Cheers, Mark. From berrange at redhat.com Mon Apr 6 14:41:18 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Mon, 6 Apr 2009 15:41:18 +0100 Subject: [fedora-virt] Improving release / update process for virt packages Message-ID: <20090406144118.GB18640@redhat.com> This mail is a braindump of some ideas we've been kicking around to try and improve the way we push new releases of upstream virt packages to Fedora. We want to try and improve the quality of stable Fedora branches, and also improve testing of rawhide. Taking libvirt as an example, currently new libvirt upstream releases get immediately built and pushed to both - Fedora rawhide - Fedora stable updates-testing Depending on the development phase rawhide is in, we get somewhere between 'zero' and 'lots' of feedback for new builds in rawhide. Typically before rawhide beta, we get near zero feedback, and from beta onwards we get alot of feedback. We typically always get significant feedback when the new builds are pushed to updates-testing. The obvious problem with what we do for libvirt at the moment, is that we are introducing major new features into the stable release stream here. This risks destabalizing the stable Fedora streams, and also compromises our 'Feature' process because stuff we're pushing for Fedora 11 appears in Fedora 9 / 10 before F11 even comes out. I think it would be desirable to get the stable Fedora releases onto a pretty strong bugfix only policy, but we can only do that if we figure out a way to get more people testing the stuff we're pushing for rawhide. There simply isn't enough testing of rawhide prior to beta point. The bug reports / testing from the stable update-testing repo far exceeds the feedback we get from rawhide users. We can keep telling people that rawhide is supposed to be functional enough for daily use, but frankly history shows otherwise and I don't see any sign of this ever changing. Things like the mass rebuild, rpm upgrade, xorg <-> kernel interface are inevitably changing and cause instability. Personally I do pretty much all of my day-to-day libvirt work on a stable Fedora 9 / 10 distro, only ever using rawhide if there is a specific thing I can't get in F9/10 packages. There are many people who wish to test new virtualization pieces. They do not wish to have to debug changed RPM, or changed Xorg or changed kernel packages, and the rest of rawhide at the same time. While it is true that problems with rawhide can be resolved when they occur, it is still a significant waste of time. If I'm interested in testing virt, I only expect to have to debug virt packages, not the entire OS. What we need is a way to expose new virtualization features to people running the current latest stable Fedora release stream. So if they are interested in testing the new features, they can update to those packages without having to include & debug the rest of rawhide. Debian distros have this sort of idea in the 'backports' stream which gives optional early access to new app releases, separate from the normal updates and unstable streams. This is distro wide though. We currently have people doing various adhoc personal repos from scratch builds, so my suggestion is that formalize this under the umbrella of the Fedora Virtualization SIG. Specifically, to provide a 'virt-preview' YUM repo for the most recent stable stream (ie F10, but not F9). In the designated virtualization package set, anytime we do a build of a new release for rawhide, we would also do a build for the 'preview' stream. We would explicitly not do these builds for the 'updates' repos, at least not without a very significant period of testing & positive feedback. To allow us to do builds in both the preview stream, and updates stream, which are not scratch builds, this would unfortunately require another CVS branch. We'd also need an NEVR that satisfies - Newer than current stable stream NEVR - Older than the new build in rawhide - Allows for newer build to be later made in 'updates' repo One simple option is to have - CVS branch of F-10-VIRT_PREVIEW - Release field for all builds in F-10VIRT-PREVIEW must have leading 0 The leading 0, allows us to later do a build in the main F-10 stable branch with newer NEVR, without risking that it then become newer than the rawhide build. A convenient Makefile rule in the 'devel' branch could automate the initial work of copying the contents of devel/ to F-10-VIRT-PREVIEW and setting the N-E-V-R to suitable value. A few manual changes might be needed, but hopefully not much before the maintainer could do a build in koji. There would then need to be a way to build a YUM repo from all builds in the F-10-VIRT-PREVIEW branch. It should automatically take all the latest builds from the branch - we want it to be a mini rawhide of just virt packages, not use the updates infrastructure. If we could get Fedora infrastructure support for the branching that would be great, but we could easily do this with a private branch like (private-F-10-VIRT-PREVIEW) and a cron job to build the YUM repo and publish in a well-known location, eg http://virtmaint.fedorapeople.org/ So in summary - All new upstream releases built in rawhide - New upstream releases also built in stable preview branch if possible - Only bugfixes built in stable updates/updates-testing branch - In exceptional circumstances, rebase for preview branch can be built to updates/updates-testing after alot of positive testing This would - Ensure users of stable Fedora release have high confidence in quality of the updates/updates-testing stream - Allow users to trivially test new upstream rebases while staying on the stable distro stream - Improve testing coverage of major new rawhide features without using the stable release stream users as guinea pigs 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 rpjday at crashcourse.ca Mon Apr 6 14:58:15 2009 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Mon, 6 Apr 2009 10:58:15 -0400 (EDT) Subject: [fedora-virt] is there a more newbie-level mailing list for fedora virt? Message-ID: i ask since i'm probably doing a virtualization seminar at a local linux fest later this year, and i'd like to gear it towards beginners. i realize that there is abundant online documentation on this topic, but it's just not geared for people who are starting out. for example, if one reads the online 'Getting started with virtualization" here: https://fedoraproject.org/wiki/Getting_started_with_virtualization the second paragraph reads as follows: "Xen supports para-virtualized guests as well as fully virtualized guests with para-virtualized drivers. Para-virtualization is faster than full virtualization but does not work with non-Linux operating systems or Linux operating system without the Xen kernel extensions. Xen fully virtualized are slower than KVM fully virtualized guests." i'm sorry, but that's not for beginners. it just isn't. so is there a forum where i can chat with folks about putting together something really and truly designed for an audience who might be linux-savvy but need to be walked into virtualization slowly and gently? rday p.s. i was planning on recording my thoughts here: http://www.crashcourse.ca/wiki/index.php/Virtualization_on_Fedora but i'm more than happy to help with something officially fedora if it's more attuned to what i'm trying to do. ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ======================================================================== From markmc at redhat.com Mon Apr 6 17:04:30 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 06 Apr 2009 18:04:30 +0100 Subject: [fedora-virt] Improving release / update process for virt packages In-Reply-To: <20090406144118.GB18640@redhat.com> References: <20090406144118.GB18640@redhat.com> Message-ID: <1239037470.16273.47.camel@blaa> On Mon, 2009-04-06 at 15:41 +0100, Daniel P. Berrange wrote: > This mail is a braindump of some ideas we've been kicking around to > try and improve the way we push new releases of upstream virt > packages to Fedora. We want to try and improve the quality of stable > Fedora branches, and also improve testing of rawhide. Totally agree with the conclusions here. > Taking libvirt as an example, currently new libvirt upstream releases > get immediately built and pushed to both > > - Fedora rawhide > - Fedora stable updates-testing > > Depending on the development phase rawhide is in, we get somewhere > between 'zero' and 'lots' of feedback for new builds in rawhide. > Typically before rawhide beta, we get near zero feedback, and from > beta onwards we get alot of feedback. I don't think "near zero" is quite accurate - there's been a fair bit of bugzilla activity on virt bits since the Alpha. One example is that Fedora rel-eng and QA seem to be doing lots of installs testing using KVM and filing bugs when it's broken. Sure, not everyone runs rawhide, but we still need to do what we can to help make it less broken. > We typically always get significant feedback when the new builds are > pushed to updates-testing. Personally, I see updates-testing as a "last chance QA" - i.e. it's only for package updates that we really do believe are ready for stable updates. updates-testing is a distro-wide thing, so I expect most people who enable it aren't specifically interested in testing virt, but they are interested in being the last line of defence for updates before they hit stable. When libvirt-0.6.0 hit my laptop through updates-testing and was significantly broken, my reaction was along the lines of "wait, I didn't sign up for this!" - I suspect other people in that situation might disable updates-testing as a result. That damages not only testing of virt packages, but testing of the whole distro. I think it was after that update that I wrote these guidelines and had it approved by FESCo: https://fedoraproject.org/wiki/PackageMaintainers/Package_update_guidelines > The obvious problem with what we do for libvirt at the moment, is > that we are introducing major new features into the stable release > stream here. This risks destabalizing the stable Fedora streams, > and also compromises our 'Feature' process because stuff we're > pushing for Fedora 11 appears in Fedora 9 / 10 before F11 even comes > out. Yeah - that is another aspect. How could we pimp feature X in the F11 release notes if it is pushed to F9 updates even before F11 GA? And another thing is pushing new features to updates doesn't mean we've thought about whether the feature will work or not. I saw a bug report today of PXE booting not working with latest virt-manager in F9 updates-testing because the virtio PXE ROM isn't available on F9. That just wasn't an issue with the original F9 version. > I think it would be desirable to get the stable Fedora releases onto a > pretty strong bugfix only policy, but we can only do that if we figure > out a way to get more people testing the stuff we're pushing for rawhide. > There simply isn't enough testing of rawhide prior to beta point. The > bug reports / testing from the stable update-testing repo far exceeds > the feedback we get from rawhide users. > > We can keep telling people that rawhide is supposed to be functional > enough for daily use, but frankly history shows otherwise and I don't > see any sign of this ever changing. Things like the mass rebuild, > rpm upgrade, xorg <-> kernel interface are inevitably changing and > cause instability. Personally I do pretty much all of my day-to-day > libvirt work on a stable Fedora 9 / 10 distro, only ever using rawhide > if there is a specific thing I can't get in F9/10 packages. I agree that it's not wise to use rawhide as your everyday machine, especially early in the release cycle, but i do believe a significant majority of the people seriously involved in Fedora have up-to-date rawhide running on another machine and use this for their Fedora development. > There are many people who wish to test new virtualization pieces. They > do not wish to have to debug changed RPM, or changed Xorg or changed > kernel packages, and the rest of rawhide at the same time. While it is > true that problems with rawhide can be resolved when they occur, it is > still a significant waste of time. If I'm interested in testing virt, > I only expect to have to debug virt packages, not the entire OS. > > What we need is a way to expose new virtualization features to people > running the current latest stable Fedora release stream. So if they > are interested in testing the new features, they can update to those > packages without having to include & debug the rest of rawhide. > > Debian distros have this sort of idea in the 'backports' stream which > gives optional early access to new app releases, separate from the > normal updates and unstable streams. This is distro wide though. > > We currently have people doing various adhoc personal repos from scratch > builds, so my suggestion is that formalize this under the umbrella of the > Fedora Virtualization SIG. Specifically, to provide a 'virt-preview' YUM > repo for the most recent stable stream (ie F10, but not F9). > > In the designated virtualization package set, anytime we do a build of a > new release for rawhide, we would also do a build for the 'preview' stream. I think this would be hugely useful to people interested in the latest virt bits, but without a testing machine for running rawhide. How about "virt-hide" ? :) > We would explicitly not do these builds for the 'updates' repos, at least > not without a very significant period of testing & positive feedback. > > To allow us to do builds in both the preview stream, and updates stream, > which are not scratch builds, this would unfortunately require another > CVS branch. We'd also need an NEVR that satisfies > > - Newer than current stable stream NEVR > - Older than the new build in rawhide > - Allows for newer build to be later made in 'updates' repo > > One simple option is to have > > - CVS branch of F-10-VIRT_PREVIEW > - Release field for all builds in F-10VIRT-PREVIEW must have leading 0 > > The leading 0, allows us to later do a build in the main F-10 stable > branch with newer NEVR, without risking that it then become newer > than the rawhide build. > > A convenient Makefile rule in the 'devel' branch could automate the > initial work of copying the contents of devel/ to F-10-VIRT-PREVIEW > and setting the N-E-V-R to suitable value. A few manual changes > might be needed, but hopefully not much before the maintainer could > do a build in koji. Another way would be to create a new CVS branch of 'devel' for each build - that way you wouldn't have to sync 'devel' into the preview branch each time. It should be possible to script tweaking the release field and anything depending on the distro version could be conditionalised in the spec file in 'devel'. > There would then need to be a way to build a YUM repo from all builds > in the F-10-VIRT-PREVIEW branch. It should automatically take all the > latest builds from the branch - we want it to be a mini rawhide of > just virt packages, not use the updates infrastructure. > > If we could get Fedora infrastructure support for the branching that > would be great, but we could easily do this with a private branch like > (private-F-10-VIRT-PREVIEW) and a cron job to build the YUM repo and > publish in a well-known location, eg http://virtmaint.fedorapeople.org/ Yep, I think we should do it that way first - if it works out well, we can lobby rel-eng to generalize the concept for other areas of the distro too. > So in summary > > - All new upstream releases built in rawhide > - New upstream releases also built in stable preview branch if possible > - Only bugfixes built in stable updates/updates-testing branch > - In exceptional circumstances, rebase for preview branch can be > built to updates/updates-testing after alot of positive testing > > This would > > - Ensure users of stable Fedora release have high confidence in > quality of the updates/updates-testing stream > - Allow users to trivially test new upstream rebases while > staying on the stable distro stream > - Improve testing coverage of major new rawhide features without using > the stable release stream users as guinea pigs Excellent! Cheers, Mark. From markmc at redhat.com Mon Apr 6 17:10:38 2009 From: markmc at redhat.com (Mark McLoughlin) Date: Mon, 06 Apr 2009 18:10:38 +0100 Subject: [fedora-virt] is there a more newbie-level mailing list for fedora virt? In-Reply-To: References: Message-ID: <1239037838.16273.55.camel@blaa> (More or less repeating what I said offlist) On Mon, 2009-04-06 at 10:58 -0400, Robert P. J. Day wrote: > i ask since i'm probably doing a virtualization seminar at a local > linux fest later this year, and i'd like to gear it towards beginners. > i realize that there is abundant online documentation on this topic, > but it's just not geared for people who are starting out. > > for example, if one reads the online 'Getting started with > virtualization" here: > > https://fedoraproject.org/wiki/Getting_started_with_virtualization > > the second paragraph reads as follows: > > "Xen supports para-virtualized guests as well as fully virtualized > guests with para-virtualized drivers. Para-virtualization is faster > than full virtualization but does not work with non-Linux operating > systems or Linux operating system without the Xen kernel extensions. > Xen fully virtualized are slower than KVM fully virtualized guests." Absolutely, I think the current page is a really poor intro - I'd love to see it turn into a nice and gentle page e.g. walking people through virt-manager and what some of the terminology means. > i'm sorry, but that's not for beginners. it just isn't. so is > there a forum where i can chat with folks about putting together > something really and truly designed for an audience who might be > linux-savvy but need to be walked into virtualization slowly and > gently? #virt on irc.oftc.net would be a good place. Honestly, though, best thing is to just get started writing and post drafts here for people to pick apart :-) (You don't need to ask for permission to edit the wiki pages either - any bit of help getting in shape is hugely appreciated) Cheers, Mark. From davidsen at tmr.com Mon Apr 6 19:45:36 2009 From: davidsen at tmr.com (Bill Davidsen) Date: Mon, 06 Apr 2009 15:45:36 -0400 Subject: [fedora-virt] Losing mouse focus Message-ID: <49DA5BE0.5000802@tmr.com> I have asked this on both Fedora and KVM lists, and I get back a mix of "it's you, I don't have the problem" and "mee, too" responses, so sorry if you saw this elsewhere. I have been running little machines using KVM from command line. Lots of little machines, CentOS, FC9, 10, and now 11. I run them on machine like i6600, e9400, and Athlon dual core, using FC9, FC10, and FC6 with recent kernel and KVM. Since I see the problem on multiple places I assume it isn't unique. The problem is that I lose mouse (but not keyboard) focus, running in a window or full screen. I will be typing, mail or documentation, and all of a sudden while the keyboard input going where it should, there's another mouse pointer, and it's not bound to the VM I'm using. The VM mouse cursor just sits there... I don't see any fixes listed anywhere, using "nomodeset" was suggested, but it didn't help. This was mildly annoying when I was testing, now that I'm running many production images it's unproductive. Any thoughts or pointers? -- bill davidsen CTO TMR Associates, Inc "You are disgraced professional losers. And by the way, give us our money back." - Representative Earl Pomeroy, Democrat of North Dakota on the A.I.G. executives who were paid bonuses after a federal bailout. From b_whelan at mistral.co.uk Tue Apr 7 09:43:49 2009 From: b_whelan at mistral.co.uk (Brendan Whelan) Date: Tue, 07 Apr 2009 10:43:49 +0100 Subject: [fedora-virt] Losing mouse focus In-Reply-To: <49DA5BE0.5000802@tmr.com> References: <49DA5BE0.5000802@tmr.com> Message-ID: <49DB2055.3030705@mistral.co.uk> Bill, I had the same problem and received the following from Daniel Berrange On Wed, Mar 18, 2009 at 08:53:02AM +0000, Brendan Whelan wrote: > > I am new to using virtualization and, after some effort, I have created > > and then cloned a virtual image on a laptop with an Intel P8400 > > processor using Fedora 10. > > Unfortunately, when I run the cloned image I don't have proper cursor > > control, even after pressing ctrl-alt. Any suggestions? > There was a bug in GTK-VNC for mouse grab handling. I've hust pushed an update to the stable repos so it should show up in a couple of days You want gtk-vnc-0.3.8-2.fc10 As of Fedora 11, the mouse will work perfectly without any grab being needed https://fedoraproject.org/wiki/Features/VirtImprovedConsole Daniel I waited a few days and did a yum update on my Fedora 10 system and the problem went away. Hope this helps. Brendan -------------------------------------------------------------------- Bill Davidsen wrote: > I have asked this on both Fedora and KVM lists, and I get back a mix > of "it's you, I don't have the problem" and "mee, too" responses, so > sorry if you saw this elsewhere. > > I have been running little machines using KVM from command line. Lots > of little machines, CentOS, FC9, 10, and now 11. I run them on machine > like i6600, e9400, and Athlon dual core, using FC9, FC10, and FC6 with > recent kernel and KVM. Since I see the problem on multiple places I > assume it isn't unique. > > The problem is that I lose mouse (but not keyboard) focus, running in > a window or full screen. I will be typing, mail or documentation, and > all of a sudden while the keyboard input going where it should, > there's another mouse pointer, and it's not bound to the VM I'm using. > The VM mouse cursor just sits there... > > I don't see any fixes listed anywhere, using "nomodeset" was > suggested, but it didn't help. This was mildly annoying when I was > testing, now that I'm running many production images it's > unproductive. Any thoughts or pointers? > From berrange at redhat.com Tue Apr 7 09:50:38 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 7 Apr 2009 10:50:38 +0100 Subject: [fedora-virt] Losing mouse focus In-Reply-To: <49DB2055.3030705@mistral.co.uk> References: <49DA5BE0.5000802@tmr.com> <49DB2055.3030705@mistral.co.uk> Message-ID: <20090407095038.GG8651@redhat.com> On Tue, Apr 07, 2009 at 10:43:49AM +0100, Brendan Whelan wrote: > Bill, > > I had the same problem and received the following from Daniel Berrange > > On Wed, Mar 18, 2009 at 08:53:02AM +0000, Brendan Whelan wrote: > > >> I am new to using virtualization and, after some effort, I have created > >> and then cloned a virtual image on a laptop with an Intel P8400 > >> processor using Fedora 10. > >> Unfortunately, when I run the cloned image I don't have proper cursor > >> control, even after pressing ctrl-alt. Any suggestions? > > > There was a bug in GTK-VNC for mouse grab handling. I've hust pushed an > update to the stable repos so it should show up in a couple of days > You want > > gtk-vnc-0.3.8-2.fc10 That should have got 90% of the way there, but I found another annoying problem, so you really want gtk-0.3.8-3.fc10 currently in update-testing! One day this will eventually all work correctly ;-) 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 rpjday at crashcourse.ca Tue Apr 7 12:23:53 2009 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Tue, 7 Apr 2009 08:23:53 -0400 (EDT) Subject: [fedora-virt] clarifying the fedoraproject wiki "qemu/kvm" features page Message-ID: i'd like to clarify a couple things here, if i might: https://fedoraproject.org/wiki/Features/KVM_and_QEMU_merge first, given that that page refers to being 100% done WRT f11, should it represent *exactly* what i see on my current f11 beta system? as in, no outstanding issues? next, under "Detailed Description", point 5: "The kvm package is obsoleted by qemu-kvm." can i assume that "qemu-kvm" is a typo as there appears to be no such package? what *should* that say? perhaps "qemu-kvm-tools?" i have a few more questions about the merging of qemu and kvm but i'm going to have to think about those for a few more minutes. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ======================================================================== From glommer at redhat.com Tue Apr 7 13:03:10 2009 From: glommer at redhat.com (Glauber Costa) Date: Tue, 7 Apr 2009 10:03:10 -0300 Subject: [fedora-virt] clarifying the fedoraproject wiki "qemu/kvm" features page In-Reply-To: References: Message-ID: <20090407130310.GA16795@poweredge.glommer> On Tue, Apr 07, 2009 at 08:23:53AM -0400, Robert P. J. Day wrote: > > i'd like to clarify a couple things here, if i might: > > https://fedoraproject.org/wiki/Features/KVM_and_QEMU_merge > > first, given that that page refers to being 100% done WRT f11, > should it represent *exactly* what i see on my current f11 beta > system? as in, no outstanding issues? modulo bugs. > > next, under "Detailed Description", point 5: > > "The kvm package is obsoleted by qemu-kvm." yes, thanks. It should be qemu, and its subpackages. We ended up putting kvm inside of qemu-system-x86, which better reflects our future expectancies. > > can i assume that "qemu-kvm" is a typo as there appears to be no such > package? what *should* that say? perhaps "qemu-kvm-tools?" qemu-system-x86 > > i have a few more questions about the merging of qemu and kvm but > i'm going to have to think about those for a few more minutes. whenever you think, be my guest ;) From rpjday at crashcourse.ca Tue Apr 7 13:18:18 2009 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Tue, 7 Apr 2009 09:18:18 -0400 (EDT) Subject: [fedora-virt] clarifying the fedoraproject wiki "qemu/kvm" features page In-Reply-To: <20090407130310.GA16795@poweredge.glommer> References: <20090407130310.GA16795@poweredge.glommer> Message-ID: On Tue, 7 Apr 2009, Glauber Costa wrote: > On Tue, Apr 07, 2009 at 08:23:53AM -0400, Robert P. J. Day wrote: > > next, under "Detailed Description", point 5: > > > > "The kvm package is obsoleted by qemu-kvm." > yes, thanks. It should be qemu, and its subpackages. We ended up > putting kvm inside of qemu-system-x86, which better reflects our > future expectancies. > > can i assume that "qemu-kvm" is a typo as there appears to be no > > such package? what *should* that say? perhaps "qemu-kvm-tools?" > qemu-system-x86 sorry, that's still a bit confusing as those two comments seem to contradict one another. how should that sentence read, then? rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ======================================================================== From rpjday at crashcourse.ca Tue Apr 7 13:32:15 2009 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Tue, 7 Apr 2009 09:32:15 -0400 (EDT) Subject: [fedora-virt] clarifying the fedoraproject wiki "qemu/kvm" features page In-Reply-To: <20090407130310.GA16795@poweredge.glommer> References: <20090407130310.GA16795@poweredge.glommer> Message-ID: On Tue, 7 Apr 2009, Glauber Costa wrote: > On Tue, Apr 07, 2009 at 08:23:53AM -0400, Robert P. J. Day wrote: > > > > i'd like to clarify a couple things here, if i might: > > > > https://fedoraproject.org/wiki/Features/KVM_and_QEMU_merge > > > > first, given that that page refers to being 100% done WRT f11, > > should it represent *exactly* what i see on my current f11 beta > > system? as in, no outstanding issues? > modulo bugs. > > > > next, under "Detailed Description", point 5: > > > > "The kvm package is obsoleted by qemu-kvm." > yes, thanks. It should be qemu, and its subpackages. We ended up putting kvm > inside of qemu-system-x86, which better reflects our future expectancies. > > > > > can i assume that "qemu-kvm" is a typo as there appears to be no such > > package? what *should* that say? perhaps "qemu-kvm-tools?" > qemu-system-x86 ok, just saw the updated web page, thanks. rday -- ======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry: Have classroom, will lecture. http://crashcourse.ca Waterloo, Ontario, CANADA ======================================================================== From davidsen at tmr.com Tue Apr 7 17:16:18 2009 From: davidsen at tmr.com (Bill Davidsen) Date: Tue, 07 Apr 2009 13:16:18 -0400 Subject: [fedora-virt] clarifying the fedoraproject wiki "qemu/kvm" features page In-Reply-To: References: Message-ID: <49DB8A62.2070500@tmr.com> Robert P. J. Day wrote: > i'd like to clarify a couple things here, if i might: > > https://fedoraproject.org/wiki/Features/KVM_and_QEMU_merge > > first, given that that page refers to being 100% done WRT f11, > should it represent *exactly* what i see on my current f11 beta > system? as in, no outstanding issues? > > next, under "Detailed Description", point 5: > > "The kvm package is obsoleted by qemu-kvm." > > can i assume that "qemu-kvm" is a typo as there appears to be no such > package? what *should* that say? perhaps "qemu-kvm-tools?" > > i have a few more questions about the merging of qemu and kvm but > i'm going to have to think about those for a few more minutes. > Could it have been made more obscure? So now we have to install three qemu packages and three bios packages instead of qemu and kvm? That's convenient! And what of the firmware for non-x86 machines, will that be packaged in individual little bits as well? Love the software, but the packaging appears inconvenient. -- bill davidsen CTO TMR Associates, Inc "You are disgraced professional losers. And by the way, give us our money back." - Representative Earl Pomeroy, Democrat of North Dakota on the A.I.G. executives who were paid bonuses after a federal bailout. From berrange at redhat.com Tue Apr 7 17:23:40 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Tue, 7 Apr 2009 18:23:40 +0100 Subject: [fedora-virt] clarifying the fedoraproject wiki "qemu/kvm" features page In-Reply-To: <49DB8A62.2070500@tmr.com> References: <49DB8A62.2070500@tmr.com> Message-ID: <20090407172340.GK8651@redhat.com> On Tue, Apr 07, 2009 at 01:16:18PM -0400, Bill Davidsen wrote: > Robert P. J. Day wrote: > > i'd like to clarify a couple things here, if i might: > > > >https://fedoraproject.org/wiki/Features/KVM_and_QEMU_merge > > > > first, given that that page refers to being 100% done WRT f11, > >should it represent *exactly* what i see on my current f11 beta > >system? as in, no outstanding issues? > > > > next, under "Detailed Description", point 5: > > > > "The kvm package is obsoleted by qemu-kvm." > > > >can i assume that "qemu-kvm" is a typo as there appears to be no such > >package? what *should* that say? perhaps "qemu-kvm-tools?" > > > > i have a few more questions about the merging of qemu and kvm but > >i'm going to have to think about those for a few more minutes. > > > > Could it have been made more obscure? So now we have to install three > qemu packages and three bios packages instead of qemu and kvm? That's just a package management tooling problem. If you use yum, or PackageKit, life is improved because you only have to install *1* package per architecture you want: yum install qemu-system-x86 which pulls in all the other bits via dependancies. No one is seriously expecting people to go around doing 'rpm -ivh ' on individual RPMs anymore as its just a complete waste of time 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 davidsen at tmr.com Tue Apr 7 17:23:33 2009 From: davidsen at tmr.com (Bill Davidsen) Date: Tue, 07 Apr 2009 13:23:33 -0400 Subject: [fedora-virt] Losing mouse focus In-Reply-To: <20090407095038.GG8651@redhat.com> References: <49DA5BE0.5000802@tmr.com> <49DB2055.3030705@mistral.co.uk> <20090407095038.GG8651@redhat.com> Message-ID: <49DB8C15.9020006@tmr.com> Daniel P. Berrange wrote: > On Tue, Apr 07, 2009 at 10:43:49AM +0100, Brendan Whelan wrote: > >> Bill, >> >> I had the same problem and received the following from Daniel Berrange >> >> On Wed, Mar 18, 2009 at 08:53:02AM +0000, Brendan Whelan wrote: >> >> >>>> I am new to using virtualization and, after some effort, I have created >>>> and then cloned a virtual image on a laptop with an Intel P8400 >>>> processor using Fedora 10. >>>> Unfortunately, when I run the cloned image I don't have proper cursor >>>> control, even after pressing ctrl-alt. Any suggestions? >>>> >>> >>> >> There was a bug in GTK-VNC for mouse grab handling. I've hust pushed an >> update to the stable repos so it should show up in a couple of days >> You want >> >> gtk-vnc-0.3.8-2.fc10 >> > > That should have got 90% of the way there, but I found another annoying > problem, so you really want gtk-0.3.8-3.fc10 currently in update-testing! > > One day this will eventually all work correctly ;-) > I didn't even have gtk-vnc loaded, and it seems to have no effect, presumable because the command line run uses SDL. Ex: qemu-kvm -m 1200 -std-vga -hda fc11beta.img or similar. I played with vnc a few months ago, and it made no difference. I would really prefer to avoid having the extra layer if I can avoid it. -- bill davidsen CTO TMR Associates, Inc "You are disgraced professional losers. And by the way, give us our money back." - Representative Earl Pomeroy, Democrat of North Dakota on the A.I.G. executives who were paid bonuses after a federal bailout. From glommer at redhat.com Tue Apr 7 17:38:18 2009 From: glommer at redhat.com (Glauber Costa) Date: Tue, 7 Apr 2009 14:38:18 -0300 Subject: [fedora-virt] clarifying the fedoraproject wiki "qemu/kvm" features page In-Reply-To: <20090407172340.GK8651@redhat.com> References: <49DB8A62.2070500@tmr.com> <20090407172340.GK8651@redhat.com> Message-ID: <20090407173818.GC16795@poweredge.glommer> On Tue, Apr 07, 2009 at 06:23:40PM +0100, Daniel P. Berrange wrote: > On Tue, Apr 07, 2009 at 01:16:18PM -0400, Bill Davidsen wrote: > > Robert P. J. Day wrote: > > > i'd like to clarify a couple things here, if i might: > > > > > >https://fedoraproject.org/wiki/Features/KVM_and_QEMU_merge > > > > > > first, given that that page refers to being 100% done WRT f11, > > >should it represent *exactly* what i see on my current f11 beta > > >system? as in, no outstanding issues? > > > > > > next, under "Detailed Description", point 5: > > > > > > "The kvm package is obsoleted by qemu-kvm." > > > > > >can i assume that "qemu-kvm" is a typo as there appears to be no such > > >package? what *should* that say? perhaps "qemu-kvm-tools?" > > > > > > i have a few more questions about the merging of qemu and kvm but > > >i'm going to have to think about those for a few more minutes. > > > > > > > Could it have been made more obscure? So now we have to install three > > qemu packages and three bios packages instead of qemu and kvm? > > That's just a package management tooling problem. > > If you use yum, or PackageKit, life is improved because you only have > to install *1* package per architecture you want: > > yum install qemu-system-x86 > > > which pulls in all the other bits via dependancies. No one is seriously > expecting people to go around doing 'rpm -ivh ' on individual RPMs anymore > as its just a complete waste of time It is also expected to happen automatically via comp groups if you want to install "Virtualization". Upgrade from F10 -> F11 is also expected to work out of the box (please report any bugs!) For qemu, it has the nice side effect of not pulling firmwares and binaries for architectures emulators you don't want. It does not introduce a init script for qemu linux user emulator if you are just using system emulator. So despite of your concern that Dan already addressed, I believe the situation improved quite a bit as a whole. From rpjday at crashcourse.ca Tue Apr 7 18:44:45 2009 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Tue, 7 Apr 2009 14:44:45 -0400 (EDT) Subject: [fedora-virt] remaining userspace kvm packages? Message-ID: given that, in userspace in f11, kvm has been folded into qemu (or is it the other way around?), what's left in userspace related to kvm that someone might need to install manually? AFAICT, there's qemu-kvm-tools for debugging and diagnostics, and not a lot more. is that about right? everything else kvm-related pretty much comes with your qemu install. rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. http://crashcourse.ca http://www.linkedin.com/in/rpjday ======================================================================== From glommer at redhat.com Tue Apr 7 19:35:08 2009 From: glommer at redhat.com (Glauber Costa) Date: Tue, 7 Apr 2009 16:35:08 -0300 Subject: [fedora-virt] remaining userspace kvm packages? In-Reply-To: References: Message-ID: <20090407193508.GD16795@poweredge.glommer> On Tue, Apr 07, 2009 at 02:44:45PM -0400, Robert P. J. Day wrote: > > given that, in userspace in f11, kvm has been folded into qemu (or > is it the other way around?), what's left in userspace related to kvm > that someone might need to install manually? it does not really matter. But we're currently building qemu from kvm-userspace source. But they are largely the same. > AFAICT, there's qemu-kvm-tools for debugging and diagnostics, and > not a lot more. is that about right? everything else kvm-related > pretty much comes with your qemu install. right. There's just this package. Humm.... guess we could have a qemu-tools that include this + qemu-img ? From rpjday at crashcourse.ca Wed Apr 8 08:28:21 2009 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 8 Apr 2009 04:28:21 -0400 (EDT) Subject: [fedora-virt] qemu+kvm obsoletes kqemu? Message-ID: (just another in a long list of trivial questions) since there is no available kqemu package for f11, i'm assuming that bundling qemu and kvm makes a separate kqemu package redundant, is that correct? rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. http://crashcourse.ca http://www.linkedin.com/in/rpjday ======================================================================== From rpjday at crashcourse.ca Wed Apr 8 09:38:32 2009 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 8 Apr 2009 05:38:32 -0400 (EDT) Subject: [fedora-virt] remaining userspace kvm packages? In-Reply-To: <20090407193508.GD16795@poweredge.glommer> References: <20090407193508.GD16795@poweredge.glommer> Message-ID: On Tue, 7 Apr 2009, Glauber Costa wrote: > On Tue, Apr 07, 2009 at 02:44:45PM -0400, Robert P. J. Day wrote: > > AFAICT, there's qemu-kvm-tools for debugging and diagnostics, > > and not a lot more. is that about right? everything else > > kvm-related pretty much comes with your qemu install. > right. There's just this package. Humm.... guess we could have a > qemu-tools that include this + qemu-img ? i'm not sure that's necessary, i just think there needs to be a clear list of what's installable and the corresponding dependencies, qemu-wise. i took a quick look at the output from "yum search qemu" on f11 and, from that, it looks like the following: * if you want simple system emulation for a single architecture, then: # yum install qemu-system- {arch=arm,mips,ppc,...} * if you want user-mode emulation for *any* architecture, then you need to separately: # yum install qemu-user * if you want to manipulate disk images, then: # yum install qemu-img * if you want to install *all* of the above as a meta-package, including system emulation for all supported architectures, then: # yum install qemu * if you want a graphical qemu front-end: # yum install qemu-launcher * if you want KVM debugging and diagnostic tools: # yum install qemu-kvm-tools did i miss anything? if i were new to qemu in f11, that's pretty much all i'd want to know -- what's available and what i need for what i'm trying to do. and, no, i'm not done with dumb questions yet. you only wish. rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. http://crashcourse.ca http://www.linkedin.com/in/rpjday ======================================================================== From rpjday at crashcourse.ca Wed Apr 8 10:16:13 2009 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 8 Apr 2009 06:16:13 -0400 (EDT) Subject: [fedora-virt] does "qemu-launcher" really need "qemu" as a dependency? Message-ID: for the sake of anal-retentive and pedantic testing, i decided to remove a random qemu system emulation package (in this case, qemu-system-arm) with: # yum remove qemu-system-arm and the result was to remove qemu-launcher as well. was that really necessary? does qemu-launcher really need the entire "qemu" meta package as a dependency? rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. http://crashcourse.ca http://www.linkedin.com/in/rpjday ======================================================================== From berrange at redhat.com Wed Apr 8 10:33:46 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 8 Apr 2009 11:33:46 +0100 Subject: [fedora-virt] qemu+kvm obsoletes kqemu? In-Reply-To: References: Message-ID: <20090408103346.GM18076@redhat.com> On Wed, Apr 08, 2009 at 04:28:21AM -0400, Robert P. J. Day wrote: > > (just another in a long list of trivial questions) > > since there is no available kqemu package for f11, i'm assuming that > bundling qemu and kvm makes a separate kqemu package redundant, is > that correct? There has never been a 'kqemu' package for Fedora. The kernel module is not in the standard upstream kernels, and is unmaintained by the QEMU developers with no sign of anyone caring enough to work on it That said our 'qemu-system-x86_64' / 'qemu' binaries should have kqemu support turned on should you happen to want to build the kernel modules yourself. It is effectively dead technology, and crashy & unreliable so I can't really recommend anyone try it. 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 rpjday at crashcourse.ca Wed Apr 8 10:37:55 2009 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 8 Apr 2009 06:37:55 -0400 (EDT) Subject: [fedora-virt] qemu+kvm obsoletes kqemu? In-Reply-To: <20090408103346.GM18076@redhat.com> References: <20090408103346.GM18076@redhat.com> Message-ID: On Wed, 8 Apr 2009, Daniel P. Berrange wrote: > On Wed, Apr 08, 2009 at 04:28:21AM -0400, Robert P. J. Day wrote: > > > > (just another in a long list of trivial questions) > > > > since there is no available kqemu package for f11, i'm assuming > > that bundling qemu and kvm makes a separate kqemu package > > redundant, is that correct? > > There has never been a 'kqemu' package for Fedora. The kernel module > is not in the standard upstream kernels, and is unmaintained by the > QEMU developers with no sign of anyone caring enough to work on it > > That said our 'qemu-system-x86_64' / 'qemu' binaries should have > kqemu support turned on should you happen to want to build the > kernel modules yourself. It is effectively dead technology, and > crashy & unreliable so I can't really recommend anyone try it. actually, that's all i needed to know. as i mentioned earlier, i'm just trying to document a lot of this for my own benefit and for a potential virt seminar i want to give later this year, so if anyone who's familiar with that module from an earlier distro asks about it, i can just say, ignore it under f11. thanks. rday p.s. there *have* been unofficial packages for fedora: http://atrpms.net/dist/f10/kqemu/ but it's easier to just say don't go there. -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. http://crashcourse.ca http://www.linkedin.com/in/rpjday ======================================================================== From berrange at redhat.com Wed Apr 8 10:39:38 2009 From: berrange at redhat.com (Daniel P. Berrange) Date: Wed, 8 Apr 2009 11:39:38 +0100 Subject: [fedora-virt] does "qemu-launcher" really need "qemu" as a dependency? In-Reply-To: References: Message-ID: <20090408103938.GO18076@redhat.com> On Wed, Apr 08, 2009 at 06:16:13AM -0400, Robert P. J. Day wrote: > > for the sake of anal-retentive and pedantic testing, i decided to > remove a random qemu system emulation package (in this case, > qemu-system-arm) with: > > # yum remove qemu-system-arm > > and the result was to remove qemu-launcher as well. was that really > necessary? does qemu-launcher really need the entire "qemu" meta > package as a dependency? Not sure really. NB, 'qemu-launcher' is not part of the qemu source package, so we've not touched it at all in recent qemu RPM refactoring. It is a completely separate project, so best to file a BZ against the qemu-launcher component, unless the maintainer happens to be lurking on this list.... 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 wildfire at progsoc.org Wed Apr 8 10:44:36 2009 From: wildfire at progsoc.org (Anand Kumria) Date: Wed, 8 Apr 2009 11:44:36 +0100 Subject: [fedora-virt] qemu+kvm obsoletes kqemu? In-Reply-To: <20090408103346.GM18076@redhat.com> References: <20090408103346.GM18076@redhat.com> Message-ID: <971f65790904080344i798e42d8r1547ef84b55b9be0@mail.gmail.com> On Wed, Apr 8, 2009 at 11:33 AM, Daniel P. Berrange wrote: > > That said our 'qemu-system-x86_64' / 'qemu' binaries should have > kqemu support turned on should you happen to want to build the > kernel modules yourself. It is effectively dead technology, and > crashy & unreliable so I can't really recommend anyone try it. > And the KVM module replaces it, anyway, AIUI. Correct? Anand From clalance at redhat.com Wed Apr 8 10:49:05 2009 From: clalance at redhat.com (Chris Lalancette) Date: Wed, 08 Apr 2009 12:49:05 +0200 Subject: [fedora-virt] qemu+kvm obsoletes kqemu? In-Reply-To: <971f65790904080344i798e42d8r1547ef84b55b9be0@mail.gmail.com> References: <20090408103346.GM18076@redhat.com> <971f65790904080344i798e42d8r1547ef84b55b9be0@mail.gmail.com> Message-ID: <49DC8121.3070104@redhat.com> Anand Kumria wrote: > On Wed, Apr 8, 2009 at 11:33 AM, Daniel P. Berrange wrote: >> That said our 'qemu-system-x86_64' / 'qemu' binaries should have >> kqemu support turned on should you happen to want to build the >> kernel modules yourself. It is effectively dead technology, and >> crashy & unreliable so I can't really recommend anyone try it. >> > > And the KVM module replaces it, anyway, AIUI. > > Correct? Not exactly, no. Functionally, they do the same thing; that is, they "accelerate" QEMU. However, kqemu works on machines without virtualization extensions (VMX or SVM), while those technologies are required for KVM to work. That being said, going forward, there are less and less machines that don't have those extensions, and of course KVM has an active and healthy development community, while kqemu has essentially none. -- Chris Lalancette From rpjday at crashcourse.ca Wed Apr 8 10:49:19 2009 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 8 Apr 2009 06:49:19 -0400 (EDT) Subject: [fedora-virt] does "qemu-launcher" really need "qemu" as a dependency? In-Reply-To: <20090408103938.GO18076@redhat.com> References: <20090408103938.GO18076@redhat.com> Message-ID: On Wed, 8 Apr 2009, Daniel P. Berrange wrote: > On Wed, Apr 08, 2009 at 06:16:13AM -0400, Robert P. J. Day wrote: > > > > for the sake of anal-retentive and pedantic testing, i decided > > to remove a random qemu system emulation package (in this case, > > qemu-system-arm) with: > > > > # yum remove qemu-system-arm > > > > and the result was to remove qemu-launcher as well. was that > > really necessary? does qemu-launcher really need the entire > > "qemu" meta package as a dependency? > > Not sure really. NB, 'qemu-launcher' is not part of the qemu source > package, so we've not touched it at all in recent qemu RPM > refactoring. It is a completely separate project, so best to file a > BZ against the qemu-launcher component, unless the maintainer > happens to be lurking on this list.... https://bugzilla.redhat.com/show_bug.cgi?id=494846 rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. http://crashcourse.ca http://www.linkedin.com/in/rpjday ======================================================================== From rpjday at crashcourse.ca Wed Apr 8 12:50:34 2009 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 8 Apr 2009 08:50:34 -0400 (EDT) Subject: [fedora-virt] qemu user emulation test package, and is GUEST_BASE broken? Message-ID: moving on, i'm continuing to document QEMU on f11 here: http://www.crashcourse.ca/wiki/index.php/QEMU_on_Fedora_11 and i have (unsurprisingly) a couple of questions. when i first started playing with QEMU a while back, i found the user emulation test tarball here: http://www.nongnu.org/qemu/linux-user-test-0.3.tar.gz really handy to see what worked and what didn't. is there any chance of bundling up something like that and turning it into another fedora QEMU package? maybe "qemu-user-tests" or something like that, if there are no licensing restrictions? i think a number of beginners would find that useful. (the test script in that tarball, "qemu-linux-user.sh", could be simplified tremendously, of course.) and, more technically, the following attempt to test user emulation for ARM (and ARMEB) using that test tarball fails thusly (running as a non-root user): $ qemu-arm -L gnemul/qemu-arm arm/ls mmap: Permission denied. $ apparently, this is because ARM tries to mmap to *very* low memory, and the /proc/sys/vm/mmap_min_addr file is, by default, set to 65536. the alleged solution is explained here: http://archive.netbsd.se/?ml=qemu-devel&a=2008-04&t=7231855 to set the environment variable GUEST_BASE to 65536. now, that might have worked once upon a time, but it doesn't seem to work now. on the other hand, if you have root access, you can just: # echo 0 > /proc/sys/vm/mmap_min_addr and things suddenly work just fine. should GUEST_BASE work? or is one reduced to needing root access to change that setting on a global basis? and once i know the answer, i'll add it to my wiki page. cuz that's just the kind of guy i am. :-) rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. http://crashcourse.ca http://www.linkedin.com/in/rpjday ======================================================================== From jlaska at redhat.com Wed Apr 8 14:08:03 2009 From: jlaska at redhat.com (James Laska) Date: Wed, 08 Apr 2009 14:08:03 +0000 Subject: [fedora-virt] clarifying the fedoraproject wiki "qemu/kvm" features page In-Reply-To: <20090407173818.GC16795@poweredge.glommer> References: <49DB8A62.2070500@tmr.com> <20090407172340.GK8651@redhat.com> <20090407173818.GC16795@poweredge.glommer> Message-ID: <1239199683.3196.108.camel@flatline.devel.redhat.com> On Tue, 2009-04-07 at 14:38 -0300, Glauber Costa wrote: > On Tue, Apr 07, 2009 at 06:23:40PM +0100, Daniel P. Berrange wrote: > > On Tue, Apr 07, 2009 at 01:16:18PM -0400, Bill Davidsen wrote: > > > Robert P. J. Day wrote: > > > > i'd like to clarify a couple things here, if i might: > > > > > > > >https://fedoraproject.org/wiki/Features/KVM_and_QEMU_merge > > > > > > > > first, given that that page refers to being 100% done WRT f11, > > > >should it represent *exactly* what i see on my current f11 beta > > > >system? as in, no outstanding issues? > > > > > > > > next, under "Detailed Description", point 5: > > > > > > > > "The kvm package is obsoleted by qemu-kvm." > > > > > > > >can i assume that "qemu-kvm" is a typo as there appears to be no such > > > >package? what *should* that say? perhaps "qemu-kvm-tools?" > > > > > > > > i have a few more questions about the merging of qemu and kvm but > > > >i'm going to have to think about those for a few more minutes. > > > > > > > > > > Could it have been made more obscure? So now we have to install three > > > qemu packages and three bios packages instead of qemu and kvm? > > > > That's just a package management tooling problem. > > > > If you use yum, or PackageKit, life is improved because you only have > > to install *1* package per architecture you want: > > > > yum install qemu-system-x86 > > > > > > which pulls in all the other bits via dependancies. No one is seriously > > expecting people to go around doing 'rpm -ivh ' on individual RPMs anymore > > as its just a complete waste of time > It is also expected to happen automatically via comp groups if you want to > install "Virtualization". Upgrade from F10 -> F11 is also expected to work > out of the box (please report any bugs!) > > For qemu, it has the nice side effect of not pulling firmwares and binaries > for architectures emulators you don't want. > > It does not introduce a init script for qemu linux user emulator if you are > just using system emulator. > > So despite of your concern that Dan already addressed, I believe the situation > improved quite a bit as a whole. The items listed above are certainly benefits! One question around the packaging. While I haven't tested yet, I'm curious about the upgrade path from F-10 to F-11. Whenever package names change we sometimes introduce gaps in the package set for upgrades. Typically, we resolve these gaps with %obsoletes and % provides. Thanks, James -------------- 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 fedora at leemhuis.info Wed Apr 8 14:21:14 2009 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 08 Apr 2009 16:21:14 +0200 Subject: [fedora-virt] qemu+kvm obsoletes kqemu? In-Reply-To: References: <20090408103346.GM18076@redhat.com> Message-ID: <49DCB2DA.9010700@leemhuis.info> On 08.04.2009 12:37, Robert P. J. Day wrote: > p.s. there *have* been unofficial packages for fedora: > > http://atrpms.net/dist/f10/kqemu/ FYI, RPM Fusion has (a)kmod-kqemu as well. > but it's easier to just say don't go there. I tend to agreee, nevertheless , there are lots of Intels CPUs that don't have VT and we don't have Xen in Fedora, so for some use-cases on Desktops it might be nice (albeit VirtualBox might be the better solution in a lot of those cases). CU knurd From glommer at redhat.com Wed Apr 8 15:02:12 2009 From: glommer at redhat.com (Glauber Costa) Date: Wed, 8 Apr 2009 12:02:12 -0300 Subject: [fedora-virt] remaining userspace kvm packages? In-Reply-To: References: <20090407193508.GD16795@poweredge.glommer> Message-ID: <20090408150212.GB25323@poweredge.glommer> On Wed, Apr 08, 2009 at 05:38:32AM -0400, Robert P. J. Day wrote: > On Tue, 7 Apr 2009, Glauber Costa wrote: > > > On Tue, Apr 07, 2009 at 02:44:45PM -0400, Robert P. J. Day wrote: > > > > AFAICT, there's qemu-kvm-tools for debugging and diagnostics, > > > and not a lot more. is that about right? everything else > > > kvm-related pretty much comes with your qemu install. > > > right. There's just this package. Humm.... guess we could have a > > qemu-tools that include this + qemu-img ? > > i'm not sure that's necessary, i just think there needs to be a > clear list of what's installable and the corresponding dependencies, > qemu-wise. i took a quick look at the output from "yum search qemu" > on f11 and, from that, it looks like the following: > > * if you want simple system emulation for a single architecture, > then: > > # yum install qemu-system- {arch=arm,mips,ppc,...} > > * if you want user-mode emulation for *any* architecture, then you > need to separately: > > # yum install qemu-user > > * if you want to manipulate disk images, then: > > # yum install qemu-img > > * if you want to install *all* of the above as a meta-package, > including system emulation for all supported architectures, then: > > # yum install qemu > > * if you want a graphical qemu front-end: > > # yum install qemu-launcher > > * if you want KVM debugging and diagnostic tools: > > # yum install qemu-kvm-tools > > did i miss anything? if i were new to qemu in f11, that's pretty > much all i'd want to know -- what's available and what i need for what > i'm trying to do. That appears to be correct. > > and, no, i'm not done with dumb questions yet. you only wish. I don't wish that ;-) From rpjday at crashcourse.ca Wed Apr 8 17:31:57 2009 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 8 Apr 2009 13:31:57 -0400 (EDT) Subject: [fedora-virt] qemu+kvm obsoletes kqemu? In-Reply-To: <49DCB2DA.9010700@leemhuis.info> References: <20090408103346.GM18076@redhat.com> <49DCB2DA.9010700@leemhuis.info> Message-ID: On Wed, 8 Apr 2009, Thorsten Leemhuis wrote: > On 08.04.2009 12:37, Robert P. J. Day wrote: > > > p.s. there *have* been unofficial packages for fedora: > > > > http://atrpms.net/dist/f10/kqemu/ > > FYI, RPM Fusion has (a)kmod-kqemu as well. > > > but it's easier to just say don't go there. > > I tend to agreee, nevertheless , there are lots of Intels CPUs that > don't have VT and we don't have Xen in Fedora, so for some use-cases > on Desktops it might be nice (albeit VirtualBox might be the better > solution in a lot of those cases). so, just to clarify this (which i am wont to do relentlessly), if you already have HW virtualization support (VT, AMD-V), kqemu is utterly pointless. on the other hand, if you *don't* have HW virt support, kqemu will allegedly speed things up but it isn't, strictly speaking, necessary. in cases like that, it makes a difference only in speed, not in functionality. is that about right? waitaminnit ... i'm not sure i believe me. rday -- ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Linked In: http://www.linkedin.com/in/rpjday Twitter: http://twitter.com/rpjday ======================================================================== From glommer at redhat.com Wed Apr 8 17:45:02 2009 From: glommer at redhat.com (Glauber Costa) Date: Wed, 8 Apr 2009 14:45:02 -0300 Subject: [fedora-virt] qemu+kvm obsoletes kqemu? In-Reply-To: References: <20090408103346.GM18076@redhat.com> <49DCB2DA.9010700@leemhuis.info> Message-ID: <20090408174502.GC25323@poweredge.glommer> On Wed, Apr 08, 2009 at 01:31:57PM -0400, Robert P. J. Day wrote: > On Wed, 8 Apr 2009, Thorsten Leemhuis wrote: > > > On 08.04.2009 12:37, Robert P. J. Day wrote: > > > > > p.s. there *have* been unofficial packages for fedora: > > > > > > http://atrpms.net/dist/f10/kqemu/ > > > > FYI, RPM Fusion has (a)kmod-kqemu as well. > > > > > but it's easier to just say don't go there. > > > > I tend to agreee, nevertheless , there are lots of Intels CPUs that > > don't have VT and we don't have Xen in Fedora, so for some use-cases > > on Desktops it might be nice (albeit VirtualBox might be the better > > solution in a lot of those cases). > > so, just to clarify this (which i am wont to do relentlessly), if > you already have HW virtualization support (VT, AMD-V), kqemu is > utterly pointless. on the other hand, if you *don't* have HW virt > support, kqemu will allegedly speed things up but it isn't, strictly > speaking, necessary. in cases like that, it makes a difference only > in speed, not in functionality. is that about right? just a tiny consideration: kqemu will do all that, _if_ it works. As chris already mentioned, is does not get active development in a while. But you're right in the big pic. It won't provide any extra functionality besides speed. From rpjday at crashcourse.ca Wed Apr 8 20:05:41 2009 From: rpjday at crashcourse.ca (Robert P. J. Day) Date: Wed, 8 Apr 2009 16:05:41 -0400 (EDT) Subject: [fedora-virt] how can i see if the running kernel has kvm support? Message-ID: i'm curious as to how to examine a running kernel to see what it has in the way of kvm support. i can see that "make menuconfig" gives me the options: KVM (KVM) KVM for Intel (KVM_INTEL) KVM for AMD (KVM_AMD) first question: technically, i can select generic KVM support without selecting either INTEL or AMD support. can i assume that that's a pointless thing to do? the help text for CONFIG_KVM does seem to suggest that you really need to additionally select a processor module to make any sense; i was just wondering if there's some obscure scenario where having only that generic KVM support had any value. next, regardless of whether kvm support is built-in or whether it's modular and the modules have been loaded, is there some indication -- say under /proc or /sys -- that shows the current state of kvm support in the kernel? if i had the config file for the running kernel, i could of course look at that, but let's assume that i have no such thing, and that kvm support is built-in so i can't even check for, say, /sys/module/kvm. is there a userspace way to probe and determine kvm support? rday p.s. just to be clear, kvm support in the kernel doesn't count if that kernel is running on a system without HW virt support, for which kvm support obviously has no value since it can't be used. in a case like that, i'd like to get the answer that there is *no* support. ======================================================================== Robert P. J. Day Waterloo, Ontario, CANADA Linux Consulting, Training and Annoying Kernel Pedantry. Web page: http://crashcourse.ca Linked In: http://www.linkedin.com/in/rpjday Twitter: http://twitter.com/rpjday ======================================================================== From glommer at redhat.com Wed Apr 8 20:26:16 2009 From: glommer at redhat.com (Glauber Costa) Date: Wed, 8 Apr 2009 17:26:16 -0300 Subject: [fedora-virt] how can i see if the running kernel has kvm support? In-Reply-To: References: Message-ID: <20090408202616.GF25323@poweredge.glommer> On Wed, Apr 08, 2009 at 04:05:41PM -0400, Robert P. J. Day wrote: > > i'm curious as to how to examine a running kernel to see what it has > in the way of kvm support. > > i can see that "make menuconfig" gives me the options: > > KVM (KVM) > KVM for Intel (KVM_INTEL) > KVM for AMD (KVM_AMD) > > first question: technically, i can select generic KVM support without > selecting either INTEL or AMD support. can i assume that that's a > pointless thing to do? the help text for CONFIG_KVM does seem to > suggest that you really need to additionally select a processor module > to make any sense; i was just wondering if there's some obscure > scenario where having only that generic KVM support had any value. No. You always need one of the two variants. > > next, regardless of whether kvm support is built-in or whether it's > modular and the modules have been loaded, is there some indication -- > say under /proc or /sys -- that shows the current state of kvm support > in the kernel? plenty. You'll have a /dev/kvm, for instance. > > if i had the config file for the running kernel, i could of course > look at that, but let's assume that i have no such thing, and that kvm > support is built-in so i can't even check for, say, /sys/module/kvm. > is there a userspace way to probe and determine kvm support? check for the existence of /dev/kvm > > rday > > p.s. just to be clear, kvm support in the kernel doesn't count if > that kernel is running on a system without HW virt support, for which > kvm support obviously has no value since it can't be used. in a case > like that, i'd like to get the answer that there is *no* support. for that, you'll probably need a mixture of checking processor flags + the aforementioned method From ehabkost at redhat.com Wed Apr 8 20:24:07 2009 From: ehabkost at redhat.com (Eduardo Habkost) Date: Wed, 8 Apr 2009 17:24:07 -0300 Subject: [fedora-virt] how can i see if the running kernel has kvm support? In-Reply-To: References: Message-ID: <20090408202407.GP3695@blackpad> On Wed, Apr 08, 2009 at 04:05:41PM -0400, Robert P. J. Day wrote: > > i'm curious as to how to examine a running kernel to see what it has > in the way of kvm support. > > i can see that "make menuconfig" gives me the options: > > KVM (KVM) > KVM for Intel (KVM_INTEL) > KVM for AMD (KVM_AMD) > > first question: technically, i can select generic KVM support without > selecting either INTEL or AMD support. can i assume that that's a > pointless thing to do? the help text for CONFIG_KVM does seem to > suggest that you really need to additionally select a processor module > to make any sense; i was just wondering if there's some obscure > scenario where having only that generic KVM support had any value. Yes, it is meaningless to select only KVM without any processor support. You will just waste memory. > > next, regardless of whether kvm support is built-in or whether it's > modular and the modules have been loaded, is there some indication -- > say under /proc or /sys -- that shows the current state of kvm support > in the kernel? > > if i had the config file for the running kernel, i could of course > look at that, but let's assume that i have no such thing, and that kvm > support is built-in so i can't even check for, say, /sys/module/kvm. > is there a userspace way to probe and determine kvm support? > You can try looking at /sys/class/misc/kvm. Inside qemu, you can run the "info kvm" monitor command to make sure kvm support is really working on your qemu instance. > rday > > p.s. just to be clear, kvm support in the kernel doesn't count if > that kernel is running on a system without HW virt support, for which > kvm support obviously has no value since it can't be used. in a case > like that, i'd like to get the answer that there is *no* support. The kvm modules fail to load if there is no hardware support, so if you have /sys/class/misc/kvm, you should have hardware virt support working. -- Eduardo From davidsen at tmr.com Wed Apr 8 21:24:36 2009 From: davidsen at tmr.com (Bill Davidsen) Date: Wed, 08 Apr 2009 17:24:36 -0400 Subject: [fedora-virt] qemu+kvm obsoletes kqemu? In-Reply-To: References: <20090408103346.GM18076@redhat.com> <49DCB2DA.9010700@leemhuis.info> Message-ID: <49DD1614.7070801@tmr.com> Robert P. J. Day wrote: > On Wed, 8 Apr 2009, Thorsten Leemhuis wrote: > > >> On 08.04.2009 12:37, Robert P. J. Day wrote: >> >> >>> p.s. there *have* been unofficial packages for fedora: >>> >>> http://atrpms.net/dist/f10/kqemu/ >>> >> FYI, RPM Fusion has (a)kmod-kqemu as well. >> >> >>> but it's easier to just say don't go there. >>> >> I tend to agreee, nevertheless , there are lots of Intels CPUs that >> don't have VT and we don't have Xen in Fedora, so for some use-cases >> on Desktops it might be nice (albeit VirtualBox might be the better >> solution in a lot of those cases). >> > > so, just to clarify this (which i am wont to do relentlessly), if > you already have HW virtualization support (VT, AMD-V), kqemu is > utterly pointless. on the other hand, if you *don't* have HW virt > support, kqemu will allegedly speed things up but it isn't, strictly > speaking, necessary. in cases like that, it makes a difference only > in speed, not in functionality. is that about right? > The difference in speed is the difference between "interesting only as a proof of concept" and "about 20-30% slower than native mode" if I read the reports and my notes correctly from back when kqemu was new. The difference in functionality is the difference between useful and interesting, so for many machines it matters. Of course you can go to a distribution which supports xen and do it that way, I guess. Is there kqemu for x86_64? I see all these ultra-cheap Celeron based machines with 64 bit but no VM, and it would be great to be able to run a few small servers on such a machine. -- bill davidsen CTO TMR Associates, Inc "You are disgraced professional losers. And by the way, give us our money back." - Representative Earl Pomeroy, Democrat of North Dakota on the A.I.G. executives who were paid bonuses after a federal bailout. From mike.hinz at yr20.com Wed Apr 8 21:52:11 2009 From: mike.hinz at yr20.com (mike.hinz at yr20.com) Date: Wed, 8 Apr 2009 16:52:11 -0500 (CDT) Subject: [fedora-virt] question - installation speed F11 Beta VM on F11 Beta physical Message-ID: <1239227531.783421856@192.168.1.71> Hi, I have an F11 Beta server, fully updated to the latest and greatest from rawhide. I've noticed that whenever I try to install F11 beta in a VM, it installs really, really slowly, may 2 orders of magnitude slower than on the phyical machine. The physical server is a single processor quad-core Xeon with 8GB of RAM. I've set the VM to have 4GB RAM w/2 cpus. It appears that the installation seems to be occcuring from the network versus the DVD. Why would this be and how can I speed up this incredibly slow process? Thanks in advance for any help on this! Regards, Mike Hinz President YR20 1718 Fry Road, Suite 440 Houston, TX 77084 mike.hinz at yr20.com 832-225-1293 (o) 713-594-3095 (m) 832-550-2657 (f) From rjones at redhat.com Thu Apr 9 12:34:29 2009 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 9 Apr 2009 13:34:29 +0100 Subject: [fedora-virt] ANNOUNCE: Augeas support added to libguestfs Message-ID: <20090409123429.GA23861@amd.home.annexia.org> Augeas, meet libguestfs. Libguestfs is a library I'm writing which lets you examine and modify virtual machine disk images, so you can perform sysadmin tasks on virtual machines without needing to bring them up or log into them. As of a few minutes ago, libguestfs now supports Augeas, so you can use Augeas to edit configuration files within the virtual machine. You will need the git version of libguestfs to get this at the moment, or it will appear in version 0.7 when I release it. http://et.redhat.com/~rjones/libguestfs/ http://git.et.redhat.com/?p=libguestfs.git;a=summary Here's an example session using the shell tool, editing the /etc/hosts file from a RHEL 5.2 virtual machine: $ guestfish -a RHEL52PV32.img -m /dev/VolGroup00/LogVol00 Welcome to guestfish, the libguestfs filesystem interactive shell for editing virtual machine filesystems. Type: 'help' for help with commands 'quit' to quit the shell > aug-init / 0 > aug-match /augeas/* /augeas/root /augeas/save /augeas/files > aug-match /files//error > aug-match /augeas//error > aug-match /augeas/root/* > aug-match /files/etc/* /files/etc/ldap.conf /files/etc/aliases /files/etc/yum.repos.d /files/etc/yum.conf /files/etc/sysconfig /files/etc/default /files/etc/inittab /files/etc/sysctl.conf /files/etc/hosts /files/etc/pam.d /files/etc/logrotate.d /files/etc/samba /files/etc/xinetd.conf /files/etc/xinetd.d /files/etc/fstab /files/etc/ssh /files/etc/exports > aug-match /files/etc/hosts/* /files/etc/hosts/comment[1] /files/etc/hosts/comment[2] /files/etc/hosts/1 /files/etc/hosts/2 > cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 > aug-get /files/etc/hosts/comment[1] Do not remove the following line, or various programs > help aug-insert aug-insert - insert a sibling Augeas node aug-insert