qemu discuss - Mar 2007 - Survey of what''s missing/broken in qemu for Solaris hosts

There''s been quite a lot of activity on the qemu-devel and this list in
the last 60 days
with the release of qemu-0.9.0, the GPL''ing of the kqemu, and
Martin''s unified kqemu
package. and 0.9.0 qemu for x86/64 

I also found out that the savevm feature is now  only availabe in the qcow2
image format.
I had used savevm features in earlier releases of qemu (0.7.0, 0.8.2) However,
the new
feature I have used successfully during a Solaris  Express B58 install, and then
saw it fail
at 98% and I had forgotten to use the debug  binary so the core dump is
worthless and
the image file was toast.... <grr>

Currently in 0.9.0-CVS, and awaiting CVS are the following patches for
Solaris/QEMU.

1) Sittichai Palingsong''s TAP patch, using the modified tun driver and
new bridge module
at http://www.whiteboard.ne.jp/~admin2/tuntap.  This tap module will replace any
previous tun module that you have (ie blastwave or self compiled).  The author
updated
the packages a couple of days ago after I found a bug in the bridge code that
wouldn''t
allow an e1000g0 interface be used as a bridge. That is now fixed.

I am working on a set of scripts (using sudo) and a wrapper (currently setuid
root, hoping
to move it RBAC) to make doing tap and bridging easier, and plan on doing a
write up of
how to use these new features (It''s pretty cool to have QEMU guest get
a real DHCP
address from your network''s DHCP server)

2) OSS sound support for Solaris.  A trivial patch since QEMU already supports
OSS, but there
was no way enable it prior to now.  This will probably be important as
I''m seeing a bunch of

sdl: SDL_SemWait for sdl_callback failed
sdl: Reason: sem_wait() failed

messages when using stock Solaris audio.  (I''m using
Blastwave''s SDL, but may package up
the latest 1.2.11 code to see if it performs any better, or at least fixes the
pletheora of
error mesages I''m seeing when not using OSS sound.)

Known issues:

1) Compiling clean out of 0.9.0 - There are a couple of patch-lets that have
been submitted
to CVS. Some accepted, some not, but we''re getting close to Qemu
compiling out of
the box on Solaris 10/11.  I have a small patch for Solaris 9, and Solaris 8 is
not something
I have resources to follow up on, especially with the libm problems.

2) Solaris Sparc - there is a keymapping issue which I just found where the
normal
Ctrl-Alt-2 doesn''t take you into the QEMU monitor.  This is probably
related to keymaps
or how SDL is handling keys but I''m just spinning up on it.  
I''ve found today that I can
get those functions by the following:

Ctrl-Alt-SoundUP - Qemu Monitor (normally Ctrl-Alt-2)  [SoundUp is next to the
power button]
Ctrl-Alt-Again - Back to graphics (normally Ctrl-Alt-1)
Ctrl-Alt-F1 - Serial0 Console        (normally Ctrl-Alt-3)
Ctrl-Alt-F2 - Parallel0 Console      (normally Ctrl-Alt-4)

3) USB support.  I have no idea where this is for Solaris.  There is some
experiemental code
for Linux and Windows hosts for proxying USB devices to a qemu guest, and I
imagine that
something like this could be done.  I don''t really have any USB devices
that I can''t
already use (USB Disks/Flash) with QEMU, and I know jack about USB otherwise.

4) Sparc support - There is still no support for running Solaris/Sparc in a QEMU
guest.
There are a fair number of OpenBoot/Bios issues that have not been squashed, but
as far as I can tell, you can run a Linux and possibly BSD Sparc based OS.   The
V8/V8plus
support is pretty complete as far as I can tell, and I think the V9 has started
but there hasn''t
been much work on it lately.

So what else is missing, broken, or otherwise not documented so that the
features can
be used, or  what are you using QEMU on Solaris for these days?

Thanks

Ben
--
This message posted from opensolaris.org

On Fri, Mar 02, 2007 at 05:01:30PM -0800, Ben Taylor
wrote:
> There''s been quite a lot of activity on the qemu-devel and this
list in the last 60 days
> with the release of qemu-0.9.0, the GPL''ing of the kqemu, and
Martin''s unified kqemu
> package. and 0.9.0 qemu for x86/64 
> 
> I also found out that the savevm feature is now  only availabe in the qcow2
image format.
> I had used savevm features in earlier releases of qemu (0.7.0, 0.8.2)
However, the new
> feature I have used successfully during a Solaris  Express B58 install, and
then saw it fail
> at 98% and I had forgotten to use the debug  binary so the core dump is
worthless and
> the image file was toast.... <grr>
I''ve been using the savevm feature, but it takes dismayingly long to
save
and restore a VM image.  Is this something that might be integratable with
ZFS snapshots to get a constant time snapshot and restore?
> Currently in 0.9.0-CVS, and awaiting CVS are the following patches for
Solaris/QEMU.
> 
> 1) Sittichai Palingsong''s TAP patch, using the modified tun driver
and new bridge module
> at http://www.whiteboard.ne.jp/~admin2/tuntap.  This tap module will
replace any
> previous tun module that you have (ie blastwave or self compiled).  The
author updated
> the packages a couple of days ago after I found a bug in the bridge code
that wouldn''t
> allow an e1000g0 interface be used as a bridge. That is now fixed.
> 
> I am working on a set of scripts (using sudo) and a wrapper (currently
setuid root, hoping
> to move it RBAC) to make doing tap and bridging easier, and plan on doing a
write up of
> how to use these new features (It''s pretty cool to have QEMU guest
get a real DHCP
> address from your network''s DHCP server)
Very much looking forward to it!
> So what else is missing, broken, or otherwise not documented so that the
features can
> be used, or  what are you using QEMU on Solaris for these days?
I have noticed, but have not investigated, that QEMU seems to be broken
post-dboot:  it seems that it wants to boot the 64-bit kernel, even
though the virtual GRUB should be detecting a 32-bit (virtual) CPU.  (The
dboot project extended GRUB with a new $ISADIR variable, that is somehow
erroneously being set to amd64 in the 32-bit QEMU case.)  One can work
around this by manually editing out the "amd64"; if you
don''t, and if
you''re running 32-bit QEMU, it will die (or rather, reset) horribly.

For whatever it''s worth:  I''m very interested in running
Solaris as
both a QEMU guest and a QEMU host, using QEMU to perform regression testing
of system-level (and network-level) functionality.  So it''s great to
see
that there''s been so much activity on this list!

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc

> I have noticed, but have not investigated, that QEMU seems to be broken
> post-dboot:  it seems that it wants to boot the 64-bit kernel, even
> though the virtual GRUB should be detecting a 32-bit (virtual) CPU.  (The
> dboot project extended GRUB with a new $ISADIR variable, that is somehow
> erroneously being set to amd64 in the 32-bit QEMU case.)
Hmm, using 32-bit qemu binaries, it boots into the 32-bit kernel for me when I
use
the $QEMU_HOME/bin/qemu binary, and it boots into the 64-bit kernel when I use
$QEMU_HOME/bin/qemu-system-x86_64.

In this test I didn''t used the kqemu module.  qemu was compiled from
CVS.
Host is a current Nevada box, using an amd64 X2 socket AM2 cpu.

Guest is a snv_55b install, bfu''ed to opensolaris 2007-03-02.

So, at least with this combination, I''m unable to reproduce the
issue...
--
This message posted from opensolaris.org

> > I have noticed, but have not investigated, that QEMU seems to be
broken
> > post-dboot:  it seems that it wants to boot the 64-bit kernel, even
> > though the virtual GRUB should be detecting a 32-bit (virtual) CPU. 
(The
> > dboot project extended GRUB with a new $ISADIR variable, that is
somehow
> > erroneously being set to amd64 in the 32-bit QEMU case.)
> 
> Hmm, using 32-bit qemu binaries, it boots into the 32-bit kernel for me
when I use
> the $QEMU_HOME/bin/qemu binary, and it boots into the 64-bit kernel when I
use
> $QEMU_HOME/bin/qemu-system-x86_64.
> 
> In this test I didn''t used the kqemu module.  qemu was compiled
from CVS.
> Host is a current Nevada box, using an amd64 X2 socket AM2 cpu.
> 
> Guest is a snv_55b install, bfu''ed to opensolaris 2007-03-02.
> 
> So, at least with this combination, I''m unable to reproduce the
issue...
I''ve now repeated these tests with kqemu installed:

- 32-bit kernel booted, qemu binary: boots into 32-bit Solaris kernel
- 64-bit kernel booted, qemu-system-x86_64 binary: boots into 64-bit
  Solaris kernel

Still not reproducible...
--
This message posted from opensolaris.org

On Mon, Mar 05, 2007 at 10:09:33AM -0800, J?rgen Keil
wrote:
> > > I have noticed, but have not investigated, that QEMU seems to be
broken
> > > post-dboot:  it seems that it wants to boot the 64-bit kernel,
even
> > > though the virtual GRUB should be detecting a 32-bit (virtual)
CPU.  (The
> > > dboot project extended GRUB with a new $ISADIR variable, that is
somehow
> > > erroneously being set to amd64 in the 32-bit QEMU case.)
> > 
> > Hmm, using 32-bit qemu binaries, it boots into the 32-bit kernel for
me when I use
> > the $QEMU_HOME/bin/qemu binary, and it boots into the 64-bit kernel
when I use
> > $QEMU_HOME/bin/qemu-system-x86_64.
> > 
> > In this test I didn''t used the kqemu module.  qemu was
compiled from CVS.
> > Host is a current Nevada box, using an amd64 X2 socket AM2 cpu.
> > 
> > Guest is a snv_55b install, bfu''ed to opensolaris 2007-03-02.
> > 
> > So, at least with this combination, I''m unable to reproduce
the issue...
> 
> I''ve now repeated these tests with kqemu installed:
> 
> - 32-bit kernel booted, qemu binary: boots into 32-bit Solaris kernel
> - 64-bit kernel booted, qemu-system-x86_64 binary: boots into 64-bit
>   Solaris kernel
> 
> Still not reproducible...
It was only broken for me attempting on freshly installed post-dboot bits,
so BFU''ing post-dboot may not reproduce the problem.  But this
isn''t stock
ON, so there might be a problem on my end; I''ll reattempt the
experiment
sometime this week...

Also:  is the qemu-system-x86_64 considered ready for prime time?  I would
much rather use that if it''s considered to be beyond the experimental
phase...

	- Bryan

--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development.       http://blogs.sun.com/bmc

> Also:  is the qemu-system-x86_64 considered ready for prime time?  I would
> much rather use that if it''s considered to be beyond the
experimental
> phase...
Works OK for me.  It is able to boot a 64-bit snv_55 (+ bfu) into 
the JDS GUI, and runs firefox, staroffice 8, ... just fine.
--
This message posted from opensolaris.org

J?rgen Keil wrote:
>>Also:  is the qemu-system-x86_64 considered ready for prime time?  I
would
>>much rather use that if it''s considered to be beyond the
experimental
>>phase...
>>    
>>
>
>Works OK for me.  It is able to boot a 64-bit snv_55 (+ bfu) into 
>the JDS GUI, and runs firefox, staroffice 8, ... just fine.
>  
>
Juergen, Ben, all,

thanks for all your good work recently.
This week is qemu-prime-time once again.
There is still the new 0.9.0 based new SUNWqemu package we plan to 
release, that is OVERDUE meanwhile.
I have new disks attached to my sparc based machines and can finally 
generate 100% clean sparc packages again (clean fresh installs of 
Solaris 8, 9, 10FCS, 10_U3 and build58).
Plus the additional companion packages mentioned last week.

I will send you pre-release versions and info as soon as I have things 
ready for testing and of course do i have to keep up with the (your) 
most recent developments.
I have time for qemu starting Wednesday evening   :-)

Till then.

Any criticism and ideas are welcome.

BTW, I had a chat to Simon yesterday, regarding the odd Project 
<--versus--> Community thing, see yourself his kind response and 
recommendation:

MB>> I''m one of the project leaders over at 
http://opensolaris.org/os/project/qemu/leaders/.
MB>> My original question had been, why nobody of us (SUNWqemu 
maintainers) is listed for the qemu related work under 
http://poll.opensolaris.org/.
MB>> Not at all: Whether as core-contributor, or not.
MB>> I mean qemu is not a trivial thing and we are maintaining the 
SUNWqemu package.
MB>> It is just not 100% clear to me, why the qemu related work
doesn''t
count.

SP> It does count, but the bootstrap membership rules are built on  
"Communities".
SP> I am sure this will change quickly once th enew OGB is  in place.

MB>>
MB>> My second question would be, if this has to do with the odd 
Community versus Project thing, or if it is just an error / a bug, 
nobody has reported
MB>> so far.
MB>> Juergen Keil is also closely working together with our qemu team.

SP> Yup, it''s community vs project. It''s nothing personal -
write to
the  OGB straight away as I outline above.


--->>  I would like to see you, the qemu community, which allegedly 
ISN''T A COMMUNITY??!!??
I would like to see you sending complaints to cab-discuss  (which 
actually should be called ogb-discuss since February 12th).

Thanks You.

p.s. Leo Reiter just suggested to send me his set of patches for qemu 
and kqemu.
I didn''t have any time back then and didn''t stay in touch with
him.
Leo, can you hear this?
Could you please send me your work?
Or - even better - just send your diffs to list(s).


--
Bye,
Martin
underperformer[T.M.]

Martin Bochnig wrote:
>
> SP> Yup, it''s community vs project. It''s nothing
personal - write to
> the  OGB straight away as I outline above.
>
Juergen Keil should definitely be listed as qemu- CORE contributor plus 
as one of the qemu project leaders.
And of course Eric Lowe, Ben Taylor and Sittichai Palanisong, and 
whoever I forgot to mention.
Plus a number of non-core contributers.
>
> --->>  I would like to see you, the qemu community, which allegedly 
> ISN''T A COMMUNITY??!!??
> I would like to see you sending complaints to cab-discuss  (which 
> actually should be called ogb-discuss since February 12th).
>
> Thanks You.
>
> p.s. Leo Reiter just suggested to send me his set of patches for qemu 
> and kqemu.

err, I meant "once suggested", not "just suggested".

> Martin Bochnig wrote:
> 
> >
> > SP> Yup, it''s community vs project. It''s nothing
> personal - write to 
> > the  OGB straight away as I outline above.
> >
> 
> Juergen Keil should definitely be listed as qemu-
> CORE contributor plus 
> as one of the qemu project leaders.
+1

I heartily encourage Juergen to be added as a project leader
on Qemu for OpenSolaris.

Without Juergen, there is no doubt in my mind that a lot of the hard
problems we have had in the qemu solaris port would have not been
fixed as quickly, and without such great discussion about what the
bug is (not to mention, that there probably wouldn''t have been a port
to solaris for qemu without the work he did back in 2004).

Ben
--
This message posted from opensolaris.org

>I heartily encourage Juergen to be added as a project leader
>on Qemu for OpenSolaris.
Agreed -- I have added Juergen as a project leader.

- Eric
--
This message posted from opensolaris.org