qemu user emulation test package, and is GUEST_BASE broken?

[Robert P. J. Day]

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

[Mark McLoughlin]

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.

[Robert P. J. Day]

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

[Daniel P. Berrange]

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

[Mark McLoughlin]

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.

[Bill Davidsen]

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.

-- 
bill davidsen <davidsen(a)tmr.com&gt;
  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.

[Robert P. J. Day]

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

[Glauber Costa]

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.

[Mark McLoughlin]

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.

[Bill Davidsen]

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.

-- 
bill davidsen <davidsen(a)tmr.com&gt;
  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.

[Anand Kumria]

On Fri, Apr 10, 2009 at 12:03 AM, Bill Davidsen <davidsen(a)tmr.com&gt; 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

[Bill Davidsen]

Anand Kumria wrote:
>  On Fri, Apr 10, 2009 at 12:03 AM, Bill Davidsen
> <davidsen(a)tmr.com&gt; 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. :-(

-- 
bill davidsen <davidsen(a)tmr.com&gt;
  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.

[Mark McLoughlin]

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.

[Jerry James]

On Tue, Apr 14, 2009 at 1:32 AM, Mark McLoughlin <markmc(a)redhat.com&gt; 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.
-- 
Jerry James
http://loganjerry.googlepages.com/
http://jjames.fedorapeople.org/

[Mark McLoughlin]

On Tue, 2009-04-14 at 08:13 -0600, Jerry James wrote:
>  On Tue, Apr 14, 2009 at 1:32 AM, Mark McLoughlin
> <markmc(a)redhat.com&gt; 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.

[Jerry James]

On Tue, Apr 14, 2009 at 8:58 AM, Mark McLoughlin <markmc(a)redhat.com&gt; 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!
-- 
Jerry James
http://loganjerry.googlepages.com/
http://jjames.fedorapeople.org/

[Anand Kumria]

On Thu, Apr 9, 2009 at 6:07 PM, Mark McLoughlin <markmc(a)redhat.com&gt; 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

[Mark McLoughlin]

On Fri, 2009-04-10 at 12:51 +0100, Anand Kumria wrote:
>  On Thu, Apr 9, 2009 at 6:07 PM, Mark McLoughlin
> <markmc(a)redhat.com&gt; 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.