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 ========================================================================
Hi Robert,
On Wed, 2009-04-08 at 08:50 -0400, Robert P. J. Day wrote:
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.
Interestingly, a lot of what you're documenting here is quite the opposite to what we want "Fedora virtualization experience" to be e.g.:
- Users shouldn't necessarily need to know what QEMU is - using virt-manager and virsh more or less makes what hypervisor is underneath not terribly important
- We'd recommend people do "yum install Virtualization" rather than manually installing individual RPMs
- We don't see "user emulation mode" as being very important - I'd really be very surprised if many people use it
- We think virt-manager is a much more useful tool for most people than qemu-launcher
Cheers, Mark.
On Thu, 9 Apr 2009, Mark McLoughlin wrote:
Hi Robert,
On Wed, 2009-04-08 at 08:50 -0400, Robert P. J. Day wrote:
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.
Interestingly, a lot of what you're documenting here is quite the opposite to what we want "Fedora virtualization experience" to be e.g.:
Users shouldn't necessarily need to know what QEMU is - using virt-manager and virsh more or less makes what hypervisor is underneath not terribly important
We'd recommend people do "yum install Virtualization" rather than manually installing individual RPMs
We don't see "user emulation mode" as being very important - I'd really be very surprised if many people use it
We think virt-manager is a much more useful tool for most people than qemu-launcher
i actually think you're right, i'm using my wiki as a scratchpad and will almost certainly rethink things and toss stuff as i realize i'm going in the wrong direction.
on the other hand, while it's nice to have a graphical front-end for things like this to hide the underlying complexity, there have been a number of times where i've wanted to see what was going on "under the hood," as it were. particularly when i'm debugging.
i may very well end up deciding that this wasn't the right way to approach this and toss the whole thing. i just like to have at least a minimal understanding of how things work behind the scenes. but your point is well taken.
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 ========================================================================
On Thu, Apr 09, 2009 at 01:17:07PM -0400, Robert P. J. Day wrote:
- We think virt-manager is a much more useful tool for most people than qemu-launcher
i actually think you're right, i'm using my wiki as a scratchpad and will almost certainly rethink things and toss stuff as i realize i'm going in the wrong direction.
on the other hand, while it's nice to have a graphical front-end for things like this to hide the underlying complexity, there have been a number of times where i've wanted to see what was going on "under the hood," as it were. particularly when i'm debugging.
FYI, there is a lot of debugging support in libvirt & virt-manager available to end users.
- libvirt logs all QEMU command lines in /var/log/libvirt/qemu/$NAME.log where $NAME is the name of the guest.
- virt-manager creates logs of all important things it does in $HOME/.virt-manager/virt-manager.log
- virt-install creates logs in $HOME/.virtinst/virt-install.log
- With both virt-intsall and virt-manger you can get even more debugging, but setting the environment variable
LIBVIRT_DEBUG=1
before starting them http://libvirt.org/logging.html
- You can debug libvirtd daemon itself, with the log settings in /etc/libvirt/libvirtd.conf
- The virsh tool is quite useful for debugging too. In particular if you want to see what is supported on host - kvm vs qemu the run virsh capabilities
- virt-df allows looking at guest disk usage - virt-top allows monitoring of guest performance & I/O rates
Since virsh, virt-manager, virt-install, virt-viewer, virt-df & virt-top are all built ontop of the libvirt library, they will all co-operate with each other and show the same state / debug information. So you get the flexibilty of graphical tools like virt-manager, and can still easily use low level command line tools like virsh / virt-install at the same time. And of course they all work for Xen too, and OpenVZ, LXC and coming soon VirtualBox.... qemu-launcher simply doesn't come close
Regards, Daniel
On Thu, 2009-04-09 at 19:03 +0100, Daniel P. Berrange wrote:
FYI, there is a lot of debugging support in libvirt & virt-manager available to end users.
libvirt logs all QEMU command lines in /var/log/libvirt/qemu/$NAME.log where $NAME is the name of the guest.
virt-manager creates logs of all important things it does in $HOME/.virt-manager/virt-manager.log
virt-install creates logs in $HOME/.virtinst/virt-install.log
With both virt-intsall and virt-manger you can get even more debugging, but setting the environment variable
LIBVIRT_DEBUG=1
before starting them http://libvirt.org/logging.html
You can debug libvirtd daemon itself, with the log settings in /etc/libvirt/libvirtd.conf
The virsh tool is quite useful for debugging too. In particular if you want to see what is supported on host - kvm vs qemu the run virsh capabilities
I've added all of the above to:
https://fedoraproject.org/wiki/Reporting_virtualization_bugs
feel free to hack apart.
Cheers, Mark.
Robert P. J. Day wrote:
On Thu, 9 Apr 2009, Mark McLoughlin wrote:
Hi Robert,
On Wed, 2009-04-08 at 08:50 -0400, Robert P. J. Day wrote:
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.
Interestingly, a lot of what you're documenting here is quite the opposite to what we want "Fedora virtualization experience" to be e.g.:
Users shouldn't necessarily need to know what QEMU is - using virt-manager and virsh more or less makes what hypervisor is underneath not terribly important
We'd recommend people do "yum install Virtualization" rather than manually installing individual RPMs
We don't see "user emulation mode" as being very important - I'd really be very surprised if many people use it
We think virt-manager is a much more useful tool for most people than qemu-launcher
i actually think you're right, i'm using my wiki as a scratchpad and will almost certainly rethink things and toss stuff as i realize i'm going in the wrong direction.
on the other hand, while it's nice to have a graphical front-end for things like this to hide the underlying complexity, there have been a number of times where i've wanted to see what was going on "under the hood," as it were. particularly when i'm debugging.
i may very well end up deciding that this wasn't the right way to approach this and toss the whole thing. i just like to have at least a minimal understanding of how things work behind the scenes. but your point is well taken.
Thanks, the behind the scenes is important. For some people the canned tools are fine, while others hit the limitations right away, wanting to use some feature which the GUI author felt was not important.
On Thu, 9 Apr 2009, Mark McLoughlin wrote:
- We'd recommend people do "yum install Virtualization" rather than manually installing individual RPMs
a reasonable suggestion, but the current definition of that group looks a bit strange on f11 beta:
$ yum groupinfo Virtualization Loaded plugins: downloadonly, refresh-packagekit Setting up Group Process
Group: Virtualization Description: These packages provide a virtualization environment. Mandatory Packages: python-virtinst Default Packages: qemu-system-ppc qemu-system-x86 virt-manager virt-viewer Optional Packages: gnome-applet-vm virt-top
is there some reason that qemu-system-ppc is considered a "Default" package? after all, there's a *pile* of qemu-system-<arch> files -- arm, cris, mips, etc. what's so special about ppc? just curious.
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 ========================================================================
On Thu, Apr 09, 2009 at 01:25:52PM -0400, Robert P. J. Day wrote:
On Thu, 9 Apr 2009, Mark McLoughlin wrote:
- We'd recommend people do "yum install Virtualization" rather than manually installing individual RPMs
a reasonable suggestion, but the current definition of that group looks a bit strange on f11 beta:
$ yum groupinfo Virtualization Loaded plugins: downloadonly, refresh-packagekit Setting up Group Process
Group: Virtualization Description: These packages provide a virtualization environment. Mandatory Packages: python-virtinst Default Packages: qemu-system-ppc qemu-system-x86 virt-manager virt-viewer Optional Packages: gnome-applet-vm virt-top
is there some reason that qemu-system-ppc is considered a "Default" package? after all, there's a *pile* of qemu-system-<arch> files -- arm, cris, mips, etc. what's so special about ppc? just curious.
There's kvm support on ppc ;-)
so of course, if you are installing it on a x86 box, it does not matter, but I just didn't want to fill the comps file with ifarchs definitions. (I don't even know if that is possible). Later on, I thought that just using "kvm" and making qemu-system-x86 and qemu-system-ppc provide it conditionally, would be a better alternative. But since the package is not that big, I left it that way. Can change it upon request.
On Mon, 2009-04-13 at 13:46 -0300, Glauber Costa wrote:
so of course, if you are installing it on a x86 box, it does not matter, but I just didn't want to fill the comps file with ifarchs definitions. (I don't even know if that is possible). Later on, I thought that just using "kvm" and making qemu-system-x86 and qemu-system-ppc provide it conditionally, would be a better alternative.
That sounds like a good plan (maybe 'qemu-kvm' instead of 'kvm'?) - installing qemu-system-ppc on x86 is very strange, and if it's easy to fix ...
Cheers, Mark.
Mark McLoughlin wrote:
Hi Robert,
On Wed, 2009-04-08 at 08:50 -0400, Robert P. J. Day wrote:
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.
Interestingly, a lot of what you're documenting here is quite the opposite to what we want "Fedora virtualization experience" to be e.g.:
- Users shouldn't necessarily need to know what QEMU is - using virt-manager and virsh more or less makes what hypervisor is underneath not terribly important
The problem is that all these tools are designed to hide the details from the casual user, but they wind up making use of the details difficult or impossible for someone who is trying to actually use some of the nifty features in KVM (as an example).
We'd recommend people do "yum install Virtualization" rather than manually installing individual RPMs
We don't see "user emulation mode" as being very important - I'd really be very surprised if many people use it
We think virt-manager is a much more useful tool for most people than qemu-launcher
It's only useful if what you want to do is have a human at a console launch and control virtual operations which are define at the time the human is doing the control. That's not always the case in a more complex environment, where it's sometimes desirable to do things from scripts or programs without a human in the loop.
On Fri, Apr 10, 2009 at 12:03 AM, Bill Davidsen davidsen@tmr.com wrote:
doing the control. That's not always the case in a more complex environment, where it's sometimes desirable to do things from scripts or programs without a human in the loop.
So, presumably, you use utilise virsh in that case?
Or at least complain a little, with an example, so that it can be extended to help you.
Cheers, Anand
Anand Kumria wrote:
On Fri, Apr 10, 2009 at 12:03 AM, Bill Davidsen davidsen@tmr.com wrote:
doing the control. That's not always the case in a more complex environment, where it's sometimes desirable to do things from scripts or programs without a human in the loop.
So, presumably, you use utilise virsh in that case?
Think qemu-kvm from command line... started by a script, on demand, including qemu-img for an individual machine based on a common machine image.
Or at least complain a little, with an example, so that it can be extended to help you.
As long as the command line interface is available, I have nothing to complain of, my usage just tends to include a bunch of on-demand totally unplanned needs. :-(
On Thu, 2009-04-09 at 19:03 -0400, Bill Davidsen wrote:
- Users shouldn't necessarily need to know what QEMU is - using virt-manager and virsh more or less makes what hypervisor is underneath not terribly important
The problem is that all these tools are designed to hide the details from the casual user, but they wind up making use of the details difficult or impossible for someone who is trying to actually use some of the nifty features in KVM (as an example).
What "nifty features" can you not use ?
IMHO, using qemu via libvirt is the only reasonable thing to suggest to new users of virtualization.
Sure, some people may already be used to qemu's incredibly obtuse command line arguments and may not feel that libvirt gives them anything they don't already have.
But if you're new to virtualization, then libvirt, virsh, virt-install, virt-manager etc. are the only way to go - and what Robert is writing is an introductory guide for new users.
Cheers, Mark.
On Tue, Apr 14, 2009 at 1:32 AM, Mark McLoughlin markmc@redhat.com wrote:
What "nifty features" can you not use ?
I'm still fairly new to virtualization on Fedora. I started using virt-manager some months ago, but was frustrated that I couldn't seem to configure virt-manager so I could get a resolution higher than something tiny (800x600?) in the guest. I asked about that on this list and was told that I would have to pass -std-vga to kvm to get a higher resolution. I have never been able to figure out how to do that with virt-manager, so I transitioned over to running qemu-kvm from the command line. If somebody can solve that for me, I'll go back to virt-manager.
On Tue, 2009-04-14 at 08:13 -0600, Jerry James wrote:
On Tue, Apr 14, 2009 at 1:32 AM, Mark McLoughlin markmc@redhat.com wrote:
What "nifty features" can you not use ?
I'm still fairly new to virtualization on Fedora. I started using virt-manager some months ago, but was frustrated that I couldn't seem to configure virt-manager so I could get a resolution higher than something tiny (800x600?) in the guest. I asked about that on this list and was told that I would have to pass -std-vga to kvm to get a higher resolution. I have never been able to figure out how to do that with virt-manager, so I transitioned over to running qemu-kvm from the command line. If somebody can solve that for me, I'll go back to virt-manager.
https://fedoraproject.org/wiki/Features/VirtImprovedConsole
'-vga cirrus' is the default; in F11 the emulated cirrus card uses a specific PCI vendor ID which the F11 xorg driver in the guest will recognise and use 1024x768 resolution.
Cheers, Mark.
On Tue, Apr 14, 2009 at 8:58 AM, Mark McLoughlin markmc@redhat.com wrote:
https://fedoraproject.org/wiki/Features/VirtImprovedConsole
'-vga cirrus' is the default; in F11 the emulated cirrus card uses a specific PCI vendor ID which the F11 xorg driver in the guest will recognise and use 1024x768 resolution.
Cheers, Mark.
Oh, nice. Yet another reason to grab that shiny new F11 the second it's available. :-) Thanks!
On Thu, Apr 9, 2009 at 6:07 PM, Mark McLoughlin markmc@redhat.com wrote:
- We don't see "user emulation mode" as being very important - I'd really be very surprised if many people use it
You must have data on the size of the set of machines with hardware assisted virtualisation by now.
Yes, the set is growing but the set of machines without is currently much larger.
The demand is, quite obviously, there as the demand for Xen dom0 support should show. Either that, or people started with Xen (because of non HW assisted virtualisation) and are reluctant to migrate away from it.
Anand
On Fri, 2009-04-10 at 12:51 +0100, Anand Kumria wrote:
On Thu, Apr 9, 2009 at 6:07 PM, Mark McLoughlin markmc@redhat.com wrote:
- We don't see "user emulation mode" as being very important - I'd really be very surprised if many people use it
You must have data on the size of the set of machines with hardware assisted virtualisation by now.
"user emulation mode" is where qemu is emulates linux's system call interface.
You're confusing that with qemu-system-x86 (non hardware assisted x86 machine emulation) vs. qemu-kvm (hardware assisted x86 machine emulation).
Cheers, Mark.
-
Anand Kumria -
Bill Davidsen -
Daniel P. Berrange -
Glauber Costa -
Jerry James -
Mark McLoughlin -
Robert P. J. Day