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. _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
