Re: [fedora-virt] ANNOUNCE: Augeas support added to libguestfs
by Richard W.M. Jones
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
15 years
Fedora virt status
by Mark McLoughlin
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...
https://bugzilla.redhat.com/showdependencytree.cgi?id=F11VirtTarget&hide_...
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-bin...
http://rwmj.wordpress.com/2009/04/15/use-libguestfs-to-view-devices-and-f...
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_...
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.
15 years
ANNOUNCE: Augeas support added to libguestfs
by Richard W.M. Jones
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
15 years
can i scale the VM install window to see it all?
by Robert P. J. Day
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
========================================================================
15 years
Improving release / update process for virt packages
by Daniel P. Berrange
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 :|
15 years
how can i verify that HW extensions are being used?
by Robert P. J. Day
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
========================================================================
15 years
qemu versus qemu-kvm?
by Robert P. J. Day
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
========================================================================
15 years
"YOU WILL LOSE ALL DATA ON THIS DRIVE", but the drive is wrong.
by Robert P. J. Day
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
========================================================================
15 years
typo in "man virsh"?
by Robert P. J. Day
"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
========================================================================
15 years
installing f11 x86_64 inside f11 x86_64 is *cripplingly* slow
by Robert P. J. Day
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
========================================================================
15 years