[Qemu-devel] bug reports and suggestions

[Qemu-devel] bug reports and suggestions

[Don Kitchen]

First some suggestions for what they're worth...



$ qemu-img info someimage
image: someimage
file format: qcow
virtual size: 75G (80026361856 bytes)
disk size: 304K

For files with a backing file, has anyone thought about having it print out
the name of the backing file? Particularly this would be helpful to edit in
the case the backing file is relocated. I'm afraid I have been unable to
locate the correct code for this.

Next, it seems the *one* thing QEMU lacks that you-know-who does correctly
is networking, specifically bridged mode. I know about creating a tap device
and sticking it into a bridge (really hasn't worked for me, but that's the
subject for a different day.) I realize that it's a complicated issue
requiring kernel modules, etc, and exponentially more complicated with
cross platform, but I wonder if anyone has considered trying to tie into
the vmware-player's kernel modules and use them? There has to be some sort
of de-facto API for interaction between the modules and the player. Too
rife with IP problems?

And let me express my appreciation both to Fabrice and everyone else who
contributes. In many other emulators it seems like everything is like, Gee,
I wish this had the features that <loud voice> VMWARE </loud> has, but with
QEMU it seems like for everything but network it's Gee, I wish vmware did
that like QEMU. I read the stuff people contribute, stuff like fixing for
cdrom to be moved around, null block writes auto ignored, all great and
welcome stuff, not to mention a built-in vnc server out of the blue, wow.





Now on to the bug reports...Sorry it's in only one email, I thought best
not to blitz many different emails.





If I am starting QEMU on a second X server on another VT using this:
xinit qemu ... -full-screen -- :1
(In this case I am booting windows 2000) and I switch back to :0 *before*
Windoze switches from the splash screen to the light blue background (ie
still booting) X server :1 crashes with the following error:
BadValue (integer parameter out of range for operation)

Could someone else test this? I suspect that Qemu is involved somehow since
it depends on what is happening inside the guest machine. I have not had an
opportunity to test this on any hosts but FC3. Oh yeah, did I mention too
bad VMWARE is all but useless this way?


Next, relating to Image size:

I am creating a large image (320G):
qemu-img create -f raw big.img 312571224

but it's only recognized as being 137 GB. By my calculation there are
exactly 37 significant bits. Is this a limitation of the BIOS or qemu?
The only stuff I've found is about an old 2 GB limit. 

What it should be: 

Disk /dev/hda: 320.0 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1        1200     9638968+  83  Linux
/dev/hda2            1201        1260      481950   82  Linux swap / Solaris
/dev/hda3            1261       38913   302447722+  83  Linux


What it is: 

Disk /dev/hda: 137.4 GB, 137438953472 bytes
255 heads, 63 sectors/track, 16709 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1        1200     9638968+  83  Linux
/dev/hda2            1201        1260      481950   82  Linux swap / Solaris
/dev/hda3            1261       38913   302447722+  83  Linux



Next, relating to the "invisible wall" problem. Sorry I didn't get around to
writing this report earlier, but I have a Mar 25 CVS compile which does not
have this problem and an Apr 21 compile which does. I remember talk about
the tablet stuff about that time but hope this adds a little data to the
issue.


Thanks all for reading.

Re: [Qemu-devel] bug reports and suggestions

[Oliver Gerlich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Don Kitchen schrieb:
> Next, it seems the *one* thing QEMU lacks that you-know-who does correctly
> is networking, specifically bridged mode. I know about creating a tap device
> and sticking it into a bridge (really hasn't worked for me, but that's the
> subject for a different day.) I realize that it's a complicated issue
> requiring kernel modules, etc, and exponentially more complicated with
> cross platform, but I wonder if anyone has considered trying to tie into
> the vmware-player's kernel modules and use them? There has to be some sort
> of de-facto API for interaction between the modules and the player. Too
> rife with IP problems?

Someone wrote a kernel module some months ago which exposes some special
kernel function via /proc ... IIUC this was intended to allow easier
networking... Does anyone know more about it (or did anyone understand
my confusing description ;) ?

Another interesting thing concerning networking: I use a little script
to set up a bridge between eth0 and tap0; but I have give the new bridge
interface (eg. br0) an IP address and such stuff, because eth0 doesn't
work. This is with Linux 2.6, but I read that with Linux 2.4 it was not
necessary to configure br0, as eth0 would still be accessible. Does
anyone know why this changed? I think it would be much easier if an
interface used in a bridge was still usable.

Thanks,
Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEW9vwTFOM6DcNJ6cRApc8AJ9qYCEBHJqu/TsWilH5ztnx+PF8wACffVTp
2AbeG8IcGxMz3lO1BUeZ3gY=
=a4mn
-----END PGP SIGNATURE-----

[Qemu-devel] Re: bug reports and suggestions

[Anthony Liguori]

On Sat, 06 May 2006 01:12:50 +0200, Oliver Gerlich wrote:

> Another interesting thing concerning networking: I use a little script to
> set up a bridge between eth0 and tap0; but I have give the new bridge
> interface (eg. br0) an IP address and such stuff, because eth0 doesn't
> work. This is with Linux 2.6, but I read that with Linux 2.4 it was not
> necessary to configure br0, as eth0 would still be accessible. Does anyone
> know why this changed? I think it would be much easier if an interface
> used in a bridge was still usable.

My networking script creates a bridge (initially with no physical device
attached).  My qemu-ifup always attaches the tap device to a bridge
specified by an environmental variable.  I can then manage these bridges
outside of qemu.

So far, I've added support for three "operations" on these bridges.  The
bridge is initially consider a private virtual lan.  You can then either
NAT the virtual lan or bridge the lan to a physical interface.  When
NAT'ing or using a private lan, it also launches a DHCPD instance to
provide local DHCP services.

So far, this is the best I've been able to come up with in terms of a
usuable method of managing virtual networking.  I've included a pointer to
the script (although please note, it probably won't work on any system
other than my own) for reference.

I really think that to do this properly would require another full project
(especially since there's so much overlap between Xen/qemu in this area).

http://qemu.codemonkey.ws/vlan-config

Regards,

Anthony Liguori

> Thanks,
> Oliver
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> 
> iD8DBQFEW9vwTFOM6DcNJ6cRApc8AJ9qYCEBHJqu/TsWilH5ztnx+PF8wACffVTp
> 2AbeG8IcGxMz3lO1BUeZ3gY=
> =a4mn
> -----END PGP SIGNATURE-----

Re: [Qemu-devel] Re: bug reports and suggestions

[wangji]

On Sunday 07 May 2006 01:03, Anthony Liguori wrote:
> On Sat, 06 May 2006 01:12:50 +0200, Oliver Gerlich wrote:
> > Another interesting thing concerning networking: I use a little script to
> > set up a bridge between eth0 and tap0; but I have give the new bridge
> > interface (eg. br0) an IP address and such stuff, because eth0 doesn't
> > work. This is with Linux 2.6, but I read that with Linux 2.4 it was not
> > necessary to configure br0, as eth0 would still be accessible. Does
> > anyone know why this changed? I think it would be much easier if an
> > interface used in a bridge was still usable.
>
> My networking script creates a bridge (initially with no physical device
> attached).  My qemu-ifup always attaches the tap device to a bridge
> specified by an environmental variable.  I can then manage these bridges
> outside of qemu.
>
> So far, I've added support for three "operations" on these bridges.  The
> bridge is initially consider a private virtual lan.  You can then either
> NAT the virtual lan or bridge the lan to a physical interface.  When
> NAT'ing or using a private lan, it also launches a DHCPD instance to
> provide local DHCP services.
>
> So far, this is the best I've been able to come up with in terms of a
> usuable method of managing virtual networking.  I've included a pointer to
> the script (although please note, it probably won't work on any system
> other than my own) for reference.
>
> I really think that to do this properly would require another full project
> (especially since there's so much overlap between Xen/qemu in this area).
>
> http://qemu.codemonkey.ws/vlan-config
>
> Regards,
>
> Anthony Liguori
>
> > Thanks,
> > Oliver
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.2.2 (GNU/Linux)
> >
> > iD8DBQFEW9vwTFOM6DcNJ6cRApc8AJ9qYCEBHJqu/TsWilH5ztnx+PF8wACffVTp
> > 2AbeG8IcGxMz3lO1BUeZ3gY=
> > =a4mn
> > -----END PGP SIGNATURE-----
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
hi anthony,
I 'm developing exercices for a livecd scratchboxToolkit,could you give some  
examples of how to use your vlan-config,so I can try and apply here !
for info:
I have put many toolchains armeb ,mipsel-openwrt,ppc  and a livecd
ready to use ,switching among those 5 toolchains. (scratchbox base-1.0.2)

http://uit.opf.slu.cz/Members/wangji        infos ,details
 
http://mirror.opf.slu.cz/scratchbox/    for toolchains and iso-image

Re: [Qemu-devel] bug reports and suggestions

[Jim C. Brown]

On Sat, May 06, 2006 at 01:12:50AM +0200, Oliver Gerlich wrote:
> Don Kitchen schrieb:
> > Next, it seems the *one* thing QEMU lacks that you-know-who does correctly
> > is networking, specifically bridged mode. I know about creating a tap device
> > and sticking it into a bridge (really hasn't worked for me, but that's the
> > subject for a different day.) I realize that it's a complicated issue
> > requiring kernel modules, etc, and exponentially more complicated with
> > cross platform, but I wonder if anyone has considered trying to tie into
> > the vmware-player's kernel modules and use them? There has to be some sort
> > of de-facto API for interaction between the modules and the player. Too
> > rife with IP problems?
> 
> Someone wrote a kernel module some months ago which exposes some special
> kernel function via /proc ... IIUC this was intended to allow easier
> networking... Does anyone know more about it (or did anyone understand
> my confusing description ;) ?

I'm the author.

It is called vde-inject, and it requires vdeqemu to work atm (though adding
native support in qemu itself is trivial).

Currently I'm working on a version that doesn't require a kernel module to
do this - it will have the limitation of only supporting tcp/ip packets when
talking between host/guest.

> 
> Another interesting thing concerning networking: I use a little script
> to set up a bridge between eth0 and tap0; but I have give the new bridge
> interface (eg. br0) an IP address and such stuff, because eth0 doesn't
> work. This is with Linux 2.6, but I read that with Linux 2.4 it was not
> necessary to configure br0, as eth0 would still be accessible. Does
> anyone know why this changed? I think it would be much easier if an
> interface used in a bridge was still usable.

eth0 is still usable. It is just slightly cleaner to use br0 directly.

> 
> Thanks,
> Oliver
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
> 
> iD8DBQFEW9vwTFOM6DcNJ6cRApc8AJ9qYCEBHJqu/TsWilH5ztnx+PF8wACffVTp
> 2AbeG8IcGxMz3lO1BUeZ3gY=
> =a4mn
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] bug reports and suggestions

[Oliver Gerlich]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jim C. Brown schrieb:
> On Sat, May 06, 2006 at 01:12:50AM +0200, Oliver Gerlich wrote:
> 
>>Don Kitchen schrieb:
>>
>>>Next, it seems the *one* thing QEMU lacks that you-know-who does correctly
>>>is networking, specifically bridged mode. I know about creating a tap device
>>>and sticking it into a bridge (really hasn't worked for me, but that's the
>>>subject for a different day.) I realize that it's a complicated issue
>>>requiring kernel modules, etc, and exponentially more complicated with
>>>cross platform, but I wonder if anyone has considered trying to tie into
>>>the vmware-player's kernel modules and use them? There has to be some sort
>>>of de-facto API for interaction between the modules and the player. Too
>>>rife with IP problems?
>>
>>Someone wrote a kernel module some months ago which exposes some special
>>kernel function via /proc ... IIUC this was intended to allow easier
>>networking... Does anyone know more about it (or did anyone understand
>>my confusing description ;) ?
> 
> 
> I'm the author.
> 
> It is called vde-inject, and it requires vdeqemu to work atm (though adding
> native support in qemu itself is trivial).

Thanks! That's the module I meant :)

> Currently I'm working on a version that doesn't require a kernel module to
> do this - it will have the limitation of only supporting tcp/ip packets when
> talking between host/guest.

Are you sure that limitation is not too "heavy"? How would eg. UDP, ICMP
or Multicast DNS work with the non-kernel-solution? And wouldn't an
ethernet-level emulation be cleaner and also easier to explain to other
users?

>>Another interesting thing concerning networking: I use a little script
>>to set up a bridge between eth0 and tap0; but I have give the new bridge
>>interface (eg. br0) an IP address and such stuff, because eth0 doesn't
>>work. This is with Linux 2.6, but I read that with Linux 2.4 it was not
>>necessary to configure br0, as eth0 would still be accessible. Does
>>anyone know why this changed? I think it would be much easier if an
>>interface used in a bridge was still usable.
> 
> 
> eth0 is still usable. It is just slightly cleaner to use br0 directly.

This is what I tried:

brctl addbr br0
brctl addif br0 eth0

After this, a ping to the IP of eth0 (192.168.0.10) still worked. But a
ping to the gateway (192.168.0.1) didn't. Running `ifconfig br0 up`
didn't help either. Do you have a hint how to make this work?


Thanks,
Oliver
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFEX3pLTFOM6DcNJ6cRAsTuAKCvN0b68WV/dFsznXWhv+tfaxvZZgCfdYLp
VKEpNiUYKchHgRswHIL/BGo=
=cTW3
-----END PGP SIGNATURE-----

Re: [Qemu-devel] bug reports and suggestions

[Jim C. Brown]

On Mon, May 08, 2006 at 07:05:19PM +0200, Oliver Gerlich wrote:
> > Currently I'm working on a version that doesn't require a kernel module to
> > do this - it will have the limitation of only supporting tcp/ip packets when
> > talking between host/guest.
> 
> Are you sure that limitation is not too "heavy"? How would eg. UDP, ICMP
> or Multicast DNS work with the non-kernel-solution? And wouldn't an
> ethernet-level emulation be cleaner and also easier to explain to other
> users?

Bleh, sorry, I meant IP. It will theoretically support UDP, ICMP, etc
(as long as it's encapsulated within an IP packet  it should work). I'm
primarily testing with TCP/IP.

Ethernet-level emulation is significantly cleaner but it will not work without
either kernel patches or a kernel module. I'm looking for a 100% user space
solution.

> 
> >>Another interesting thing concerning networking: I use a little script
> >>to set up a bridge between eth0 and tap0; but I have give the new bridge
> >>interface (eg. br0) an IP address and such stuff, because eth0 doesn't
> >>work. This is with Linux 2.6, but I read that with Linux 2.4 it was not
> >>necessary to configure br0, as eth0 would still be accessible. Does
> >>anyone know why this changed? I think it would be much easier if an
> >>interface used in a bridge was still usable.
> > 
> > 
> > eth0 is still usable. It is just slightly cleaner to use br0 directly.
> 
> This is what I tried:
> 
> brctl addbr br0
> brctl addif br0 eth0
> 
> After this, a ping to the IP of eth0 (192.168.0.10) still worked. But a
> ping to the gateway (192.168.0.1) didn't. Running `ifconfig br0 up`
> didn't help either. Do you have a hint how to make this work?
> 

What do your routing tables look like right before and right after you
run those two commands?

> 
> Thanks,
> Oliver
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.3 (GNU/Linux)
> 
> iD8DBQFEX3pLTFOM6DcNJ6cRAsTuAKCvN0b68WV/dFsznXWhv+tfaxvZZgCfdYLp
> VKEpNiUYKchHgRswHIL/BGo=
> =cTW3
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

[Qemu-devel] Re: bug reports and suggestions

[Anthony Liguori]

On Fri, 05 May 2006 14:51:28 -0700, Don Kitchen wrote:

> Next, it seems the *one* thing QEMU lacks that you-know-who does correctly
> is networking, specifically bridged mode. I know about creating a tap
> device and sticking it into a bridge (really hasn't worked for me, but
> that's the subject for a different day.)

I use bridging with qemu so I can attest that it works quite well once you
get it to work.

We face a similar problem in Xen.  The solution we've come up with is a
*very* complicated script that attempts to reconfigure your networking
setup.  The problem with this general approach is that how networking is
configured is *very* distro-specific.  In Xen, we attempt to be generic
but in reality, it only works on a very specific set of distros that we
frequently test on.

VMware faces the same problem (of course).  Networking doesn't tend to
work well at all unless you're on a supported distro.

What's really needed is the NetworkManager equivalent for network
configuration.  That is, something that has backends for all of the
popular distros that can provide a consistent interface to reconfiguring
networking.

Of course, it all falls apart if you do crazy things locally (like using
insane iptables rules) but it would help for the majority of users.

Regards,

Anthony Liguori

Re: [Qemu-devel] bug reports and suggestions

[Jim C. Brown]

[-- Attachment #1: Type: text/plain, Size: 2986 bytes --]

On Fri, May 05, 2006 at 02:51:28PM -0700, Don Kitchen wrote:
> $ qemu-img info someimage
> image: someimage
> file format: qcow
> virtual size: 75G (80026361856 bytes)
> disk size: 304K
> 
> For files with a backing file, has anyone thought about having it print out
> the name of the backing file? Particularly this would be helpful to edit in
> the case the backing file is relocated. I'm afraid I have been unable to
> locate the correct code for this.

Patch attached here.

> 
> Next, it seems the *one* thing QEMU lacks that you-know-who does correctly
> is networking, specifically bridged mode. I know about creating a tap device
> and sticking it into a bridge (really hasn't worked for me, but that's the
> subject for a different day.) I realize that it's a complicated issue
> requiring kernel modules, etc, and exponentially more complicated with
> cross platform, but I wonder if anyone has considered trying to tie into
> the vmware-player's kernel modules and use them? There has to be some sort
> of de-facto API for interaction between the modules and the player. Too
> rife with IP problems?

I'm not sure if vmware-player's modules are documented well enough (assuming
they are at all) to do this.

I already have an open source kernel module that does this, but it has its own
problems.

> Now on to the bug reports...Sorry it's in only one email, I thought best
> not to blitz many different emails.

Uusually  that is the best  way to get help. ;)

> 
> If I am starting QEMU on a second X server on another VT using this:
> xinit qemu ... -full-screen -- :1
> (In this case I am booting windows 2000) and I switch back to :0 *before*
> Windoze switches from the splash screen to the light blue background (ie
> still booting) X server :1 crashes with the following error:
> BadValue (integer parameter out of range for operation)

The X server crashes?

Are you  running  Xnest or Xgl or something on :1 ?

If its qemu thats crashing with BadValue .. it might be a bug in SDL's
fullscreen mode.

> 
> Next, relating to Image size:
> 
> I am creating a large image (320G):
> qemu-img create -f raw big.img 312571224
> 
> but it's only recognized as being 137 GB. By my calculation there are
> exactly 37 significant bits. Is this a limitation of the BIOS or qemu?
> The only stuff I've found is about an old 2 GB limit. 
> 

It is a limit of qemu. IIRC it was a limit of the ATA code (it didn't
use 48-bit addressing), though I saw a patch on this list that fixed that.
Not sure what happened to it.

http://support.octek.com.au/FAQ/faq_0113.htm

> Next, relating to the "invisible wall" problem. Sorry I didn't get around to
> writing this report earlier, but I have a Mar 25 CVS compile which does not
> have this problem and an Apr 21 compile which does. I remember talk about
> the tablet stuff about that time but hope this adds a little data to the
> issue.
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

[-- Attachment #2: qemu-img.c.patch --]
[-- Type: text/plain, Size: 725 bytes --]

--- qemu-img.c.orig	Mon May  8 12:00:03 2006
+++ qemu-img.c	Mon May  8 12:05:58 2006
@@ -22,6 +22,7 @@
  * THE SOFTWARE.
  */
 #include "vl.h"
+#include "block_int.h"
 
 void *get_mmap_addr(unsigned long size)
 {
@@ -665,10 +666,12 @@
     printf("image: %s\n"
            "file format: %s\n"
            "virtual size: %s (%lld bytes)\n"
-           "disk size: %s\n",
+           "disk size: %s\n"
+           "base image: %s\n",
            filename, fmt_name, size_buf, 
            (long long) (total_sectors * 512),
-           dsize_buf);
+           dsize_buf,
+	   (bs->backing_file[0] != '\0') ? bs->backing_file : "none");
     if (bdrv_is_encrypted(bs))
         printf("encrypted: yes\n");
     bdrv_delete(bs);