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