virt April 2009

virt@lists.fedoraproject.org

33 participants
72 discussions

Re: [fedora-virt] ANNOUNCE: Augeas support added to libguestfs
by Richard W.M. Jones 20 Apr '09

20 Apr '09

On Mon, Apr 20, 2009 at 07:55:56PM +0200, Ján ONDREJ (SAL) wrote: > I'm sorry, this is not a problem. But I don't know why, always 2 initramfs* > directories are created: > > drwxr-xr-x 3 ondrejj ondrejj 4096 Apr 20 19:52 initramfs/ > drwxr-xr-x 3 ondrejj ondrejj 4096 Apr 20 19:52 initramfs?/ > > Then fakeroot fails. What versions of fakeroot, Fedora, febootstrap etc are you using? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw

1 0

Fedora virt status
by Mark McLoughlin 20 Apr '09

20 Apr '09

2009-05-12 Compose & Stage Release Candidate (22 days) The final days of F11 development are upon us. Again, please take a look at the tracker bugs for the F11 release. The F11VirtTarget tracker, in particular, has a bunch of interesting bugs to look at: https://bugzilla.redhat.com/showdependencytree.cgi?id=F11VirtBlocker&hide_r… https://bugzilla.redhat.com/showdependencytree.cgi?id=F11VirtTarget&hide_re… Fedora 11 ========= F11 Snapshot 1 was released: http://www.redhat.com/archives/fedora-announce-list/2009-April/msg00004.html Followed by the F11 tree branching and then freezing: http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00892.html >From now on, any fixes committed to the F-11 branch are built into dist-f11-updates-candidate. Package maintainers must explicitly request release engineering to tag their build into dist-f11 by opening a ticket here: https://fedorahosted.org/rel-eng/newticket The F11 Preview release will be composed early this week and released on 2009-04-28. This is the last release before the final release is composed. FWN === Daley Bewley's virtualization section in Fedora Weekly News continues: http://fedoraproject.org/wiki/FWN/Issue171#Virtualization F9/F10 Updates ============== Following on from the recent discussions around our future processes and policies wrt. Fedora updates, we decided to unpush libvirt-0.6.1 from F9 and F10 updates testing: http://www.redhat.com/archives/fedora-virt/2009-April/msg00136.html Fedora Virt Experience ====================== Some discussion around creating a beginner's guide to Fedora Virtualization raised an interesting question. Just what is the "Fedora Virtualization Experience" that we're aiming for here? http://www.redhat.com/archives/fedora-virt/2009-April/msg00049.html This question is actually an important one - it should guide us in deciding what to document, what to test and what kind of features do we care most about. The answer may be obvious to some, but we don't actually have it written down anywhere. virt-manager Roadmap ==================== On the subject of writing things down, Cole Robinson has put together an excellent roadmap for the next releases of virt-manager: http://virt-manager.org/page/Roadmap F12 Features ============ The Fedora 12 feature process has already begun in earnest, with some F12 features already approved. Us virt folks need to get our skates on! One interesting F12 feature is "debuginfo FS" - using a FUSE mount of WebDAV file share to do away with the need for explicitly installing debuginfo RPMs: https://fedoraproject.org/wiki/Features/DebuginfoFS Everybody say yay for "just works" libguestfs ========== Rich Jones continued with his fast progress on libguestfs and kept his blog updated with his progress: http://rwmj.wordpress.com/2009/04/20/libguestfs-fun-with-tar/ http://rwmj.wordpress.com/2009/04/20/generating-code/ http://rwmj.wordpress.com/2009/04/16/libguestfs-100-released-and-ruby-bindi… http://rwmj.wordpress.com/2009/04/15/use-libguestfs-to-view-devices-and-fil… http://rwmj.wordpress.com/2009/04/13/libguestfs-python-bindings/ http://rwmj.wordpress.com/2009/04/12/libguestfs-08-now-with-fewer-bugs/ Rich is a Sponsor ================= Rich also succeeded in his bid to be made a Fedora sponsor: http://www.redhat.com/archives/fedora-devel-list/2009-April/msg00845.html http://bpepple.fedorapeople.org/fesco/FESCo-2009-04-10.html Unforunately, no-one had an objections to his request. That's hardly any fun, now is it? :-) Xen Dom0 ======== Michael Young pushed another build of the Dom0 kernels, just time with "xendom0" in the release field to make them more easily identifiable. http://www.redhat.com/archives/fedora-virt/2009-April/msg00106.html Slow Installs ============= On the subject of just working - or rather just not working - Mike Hinz persisted with his questions on the fedora-virt list about slow F11 installs until people realized there really was a problem. It appears that anaconda, when running under KVM, doesn't see the install media as a valid source of packages: https://bugzilla.redhat.com/490266 Is My Guest Using KVM? ====================== During that same discussion, it became clear that figuring out whether a given running guest is actually using KVM is something people commonly want to do when diagnosing problems. Unfortunately, we don't have a great answer for this - our best attempt is now documented here: https://fedoraproject.org/wiki/Reporting_virtualization_bugs#Is_My_Guest_Us… Bugs ==== DOOM-O-METER: 184 bugs last week, 178 this week. More progress ... https://bugzilla.redhat.com/494376 qemu-kvm -vga std fails because of ROM space increase patch THe patch to increase the space available to option ROMs broke 'qemu-kvm -vga std'. Glauber proposed a simple fix upstream which, following discussion, ended up being a more significant re-work of the code. We've gone with the simple patch for F11. https://bugzilla.redhat.com/495299 Text console problem with qemu-kvm cirrus/SDL Seems text console was broken with rawhide KVM. Looks like it may have been an issue with the SDL backend. https://bugzilla.redhat.com/491981 Integer wraparound creating a large disk image in VPC format Kevin Wolf resolved this issue upstream by refusing to create a vpc disk greater than 127Gb. https://bugzilla.redhat.com/494075 openbios bug causes qemu-system-ppc "invalid/unsupported opcode" failure Pavel Roskin re-built the bios image on F10 and that fixed the issue for him. This may well be a compiler issue. Upstream folks have been asked to take a look. https://bugzilla.redhat.com/486112 Qemu should not be using pulseaudio when run as root. Dan Berrange explains how libvirt needs a way to stop pulseaudio from auto-spawning a daemon for root. https://bugzilla.redhat.com/494739 KVM isn't used by qemu launched by Virtual Machine Manager Root cause turned out to be a simple %ifarch thinko in qemu.spec. This prevented kvm.ko from being loaded by qemu-system-x86_64 %post on x86_64. https://bugzilla.redhat.com/491625 Unable to run RHEL-5 Xen within KVM guest Marcelo tracked down and fixed upstream the needed irq fixes in order for xen to run in kvm, and then backported to the F11 kernel. https://bugzilla.redhat.com/496250 libvirtd/qemu-kvm appears to want to write .iso file (throws "write" AVC on install of F11_Spin1) It appears that qemu will always try and open a .iso for writing which was resulting in an SELinux warning. We need to fix qemu, but for now we've supressed the warning with dontaudit. https://bugzilla.redhat.com/496627 qemu-kvm es1370 sound card emulation segfault https://bugzilla.redhat.com/496642 qemu qcow2 image corruption Some people have experienced qcow2 image corruption - especially in the form of windows registry corruption. Thankfully, this was fixed upstream last week and the fix has been pulled in for F11. https://bugzilla.redhat.com/496298 F11 Beta :: under KVM anaconda does not seem to find installation DVD for package install Thanks to some persistence on the part of Mike Hinz on fedora-virt-list, we discovered that the F11 beta DVD installer wasn't actually using the packages on the DVD. This only happens under KVM, not on bare-metal. https://bugzilla.redhat.com/492082 anaconda "unitialized drive" warning is a little too terrifying This issue rumbles on with anaconda and libvirt developers both insisting that it's too hard to fix. https://bugzilla.redhat.com/495977 SELinux is preventing libvirtd (virtd_t) "signull" virtd_t Dan Walsh promptly fixed. https://bugzilla.redhat.com/496340 Creating guests where the .iso image is on a NFS share doesn't work anymore https://bugzilla.redhat.com/496442 selinux targeted policy blocks qemu-kvm access to USB storage devices Looks like libvirt needs to re-label USB devices https://bugzilla.redhat.com/496092 libvirt runs qemu with '-drive fmt=' rather than '-drive format=' libvirt was using an invalid command line parameter to specify a disks format. Not explicitly specifying the disk format is insecure, but this is now fixed for F11. https://bugzilla.redhat.com/491913 adding a new cd-rom device to a KVM guest fails in libvirt with obscure error Turns out we don't support IDE cdrom hotplug, so the only bug here is the obscure error message that libvirt returns. https://bugzilla.redhat.com/492523 xen pvops kernels won't boot on processors without the NX bit The fix for this was merged upstream in 2.6.30-rc2 and has been backported to F-11 in 2.6.29.1-101.fc11. https://bugzilla.redhat.com/493103 Network periodically hangs during install of xen guest It sounds like xen guest installs might be failing during package install because of a networking issue. Other reports of success or failure reproducing this would be very helpful. https://bugzilla.redhat.com/495128 "New VM" dialog box misspells "operating" as "opertaing" Simple typo in a highly visible string in latest virt-manager. https://bugzilla.redhat.com/447449 vm_applet doesn't see running VMs Once you start a VM, it disappears from the list even though the UI is clearly designed to handle running VMs.

2 1

ANNOUNCE: Augeas support added to libguestfs
by Richard W.M. Jones 20 Apr '09

20 Apr '09

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 ><fs> aug-init / 0 ><fs> aug-match /augeas/* /augeas/root /augeas/save /augeas/files ><fs> aug-match /files//error ><fs> aug-match /augeas//error ><fs> aug-match /augeas/root/* ><fs> 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 ><fs> aug-match /files/etc/hosts/* /files/etc/hosts/comment[1] /files/etc/hosts/comment[2] /files/etc/hosts/1 /files/etc/hosts/2 ><fs> 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 ><fs> aug-get /files/etc/hosts/comment[1] Do not remove the following line, or various programs ><fs> help aug-insert aug-insert - insert a sibling Augeas node aug-insert <path> <label> <before> Create a new sibling "label" for "path", inserting it into the tree before or after "path" (depending on the boolean flag "before"). "path" must match exactly one existing node in the tree, and "label" must be a label, ie. not contain "/", "*" or end with a bracketed index "[N]". ><fs> aug-insert /files/etc/hosts/comment[2] comment false ><fs> aug-match /files/etc/hosts/* /files/etc/hosts/comment[1] /files/etc/hosts/comment[2] /files/etc/hosts/comment[3] /files/etc/hosts/1 /files/etc/hosts/2 ><fs> aug-set /files/etc/hosts/comment[3] HELLO ><fs> aug-save ><fs> cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. # HELLO 127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6 ><fs> help Command Description help display a list of commands or help on a command quit quit guestfish alloc allocate an image add-cdrom add a CD-ROM disk image to examine add-drive add an image to examine or modify aug-close close the current Augeas handle aug-defnode define an Augeas node aug-defvar define an Augeas variable aug-get look up the value of an Augeas path aug-init create a new Augeas handle aug-insert insert a sibling Augeas node aug-load load files into the tree aug-match return Augeas nodes which match path aug-mv move Augeas node aug-rm remove an Augeas path aug-save write all pending Augeas changes to disk aug-set set Augeas path to value cat list the contents of a file config add qemu parameters get-autosync get autosync mode get-path get the search path get-verbose get verbose mode kill-subprocess kill the qemu subprocess launch launch the qemu subprocess list-devices list the block devices list-partitions list the partitions ll list the files in a directory (long format) ls list the files in a directory lvs list the LVM logical volumes (LVs) lvs-full list the LVM logical volumes (LVs) mount mount a guest disk at a position in the filesystem pvs list the LVM physical volumes (PVs) pvs-full list the LVM physical volumes (PVs) read-lines read file as lines set-autosync set autosync mode set-path set the search path set-verbose set verbose mode sync sync disks, writes are flushed through to the disk image touch update file timestamps or create a new file vgs list the LVM volume groups (VGs) vgs-full list the LVM volume groups (VGs) Use -h <cmd> / help <cmd> to show detailed help for a command. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top

3 21

can i scale the VM install window to see it all?
by Robert P. J. Day 20 Apr '09

20 Apr '09

i've tried several combinations but i can't see how to keep my VM install session in a separate window and still see it all (including the all-important "NEXT" "CANCEL" buttons at the bottom). i can always full screen the install session, but i'd really prefer to keep it in a separate window on my 1280x800 display and somehow scale it so i can still see the entire thing. thoughts? 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 ========================================================================

2 1

Improving release / update process for virt packages
by Daniel P. Berrange 19 Apr '09

19 Apr '09

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 :|

3 5

how can i verify that HW extensions are being used?
by Robert P. J. Day 17 Apr '09

17 Apr '09

apparently, i made one lame-brained move yesterday that almost certainly caused my VM to run thigh-suckingly slowly. following the linux KVM FAQ, i wanted to configure KVM so i could run it as a non-root user. to that end, i * created a "kvm" group, * added my user account to the kvm group, and * added the rules file /etc/udev/rules.d/60-kvm.rules: KERNEL=="kvm", GROUP="kvm" i re-initialized udev with: # udevadm control --reload-rules (right?) unloaded my kvm modules (kvm and kvm_amd), reloaded them and, sure enough, my new /dev/kvm device file had a group affiliation of kvm. excellent, i thought, and away i went ... with still painfully slow performance, until i realized that i was still in my original desktop session which *wasn't* considered part of the kvm group. so a quick logout, log back in and things were much better. *that's* the sort of thing i'm trying to document as i write all of this up -- those slight oversights which no one bothers to mention that eventually bite you in the butt. in any event, back to my original question -- what could i have checked that would have told me, no, you are *not* taking advantage of the AMD-V HW virt extensions? after all, my modules were loaded, /dev/kvm existed, it clearly had the right group, but (and correct me if i'm wrong) i was obviously not getting the benefit of HVM because my desktop session wasn't considered part of the "kvm" group. thoughts? rday -- p.s. my plan is, starting from scratch, to document every step in installing f11 x86_64 under f11 x86_64, and end up with a recipe that just plain *works*. has this been done already? URL? ======================================================================== 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 ========================================================================

7 27

qemu versus qemu-kvm?
by Robert P. J. Day 17 Apr '09

17 Apr '09

just so i understand the distinction, the qemu-system-x86 package comes with both executables /usr/bin/{qemu,qemu-kvm}. as i read it, the "qemu" executable is the original, non-KVM version which still works but only in terms of full software emulation (as it always has), while qemu-kvm is the fork of qemu that adds KVM functionality, is that correct? and if that's correct, what happens if qemu-kvm is invoked but recognizes that there is no HW virt assist? does it fall back to invoking qemu? or does it contain the full qemu functionality so it had no need to ever use qemu? put another way, if i want to run virtualization on a system that has HW virt assist, do i have any need to hang onto the "qemu" executable for any reason? 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 ========================================================================

1 0

"YOU WILL LOSE ALL DATA ON THIS DRIVE", but the drive is wrong.
by Robert P. J. Day 17 Apr '09

17 Apr '09

from earlier, i'm test installing a f11 beta x86_64 guest on a f11 beta x86_64 host, and i got to the warning dialog: Error processing drive sda. Maybe it needs to be reinitialized. YOU WILL LOSE ALL DATA ON THIS DRIVE! i can see from this BZ report: https://bugzilla.redhat.com/show_bug.cgi?id=492082 i'm assuming, from what i read there, that this is a normal event and that, for a new (blank) disk image, one should do the initialization, right? my only concern is that *my* warning refers to drive "sda" whereas, if i click on the "Details" tab of this VM that i'm creating, it refers to a target device of "hda". should those two device file designators not match? because given that my host hard drive has the name "sda", i'm just a wee bit reluctant to click "Initialize" when it seems that virt-manager is confused about what its own hard drive is. 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 ========================================================================

4 9

typo in "man virsh"?
by Robert P. J. Day 16 Apr '09

16 Apr '09

"This can usually be done using the command service start libvirtd ." should that maybe say "service libvirtd start"? should i bugzilla? 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 ========================================================================

2 1

installing f11 x86_64 inside f11 x86_64 is *cripplingly* slow
by Robert P. J. Day 16 Apr '09

16 Apr '09

i'm sure it's something i'm doing wrong, but it's taking *forever* to install an f11 x86_64 guest on f11 x86_64. i gave this VM 1 CPU, 1G of RAM and 10G of hard disk. i seem to have VM extensions enabled on this AMD 64-bit system (kvm_amd loaded, /dev/kvm exists). but this is going astonishingly slowly. it took, literally, *minutes* just to format the two filesystems. right now, it's sitting at the first SW install screen, where it's been for the last 10 minutes, even though the VMM reports that that VM is using 49% CPU. should i expect this kind of performance? because, as it stands, this is completely unusable. so i'm assuming i'm doing something wrong, and i'm open to suggestions. 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 ========================================================================

5 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

virt April 2009