From: David Roberts <dvdr18@gmail.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Feature requests
Date: Sat, 25 Nov 2006 11:12:03 +1000 [thread overview]
Message-ID: <200611251112.04223.dvdr18@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.63.0611250126190.30004@wbgn013.biozentrum.uni-wuerzburg.de>
> > - proper restoration of usb with savevm/loadvm
>
> It sounds sane. But if you think about _real_ hardware, being connected to
> the host physically, and being used inside the guest, it suddenly sounds a
> strange request. At least in this broad hand-waving form of "usb".
Yes, sorry for being too broad- I was referring mainly to emulated hardware
such as the tablet.
> > - integrated clipboard sharing - i.e. without network dependencies
>
> This is not really something QEmu can do without supporting
> modules/extensions/dlls for _every_ guest os. Again, this is a very, very
> broad request which can never be satisfied fully.
>
> > - drag'n'drop support - i.e. dragging a file onto the qemu window copies
> > it to the active guest window
>
> Exactly the same comment applies here, too.
Yes, I realise that it would recquire tools for guest OS's. However, I feel
these are reasonably important features for integration between guest/host,
and could be something for the project to look into at some stage.
> > - video capture - probably not vital as there are other ways to do this,
> > it would just be easier if it was an option in the qemu monitor
>
> Why don't you just use any vnc recorder?
Yes, as I said, there are other ways to do this, but it would be a nice
feature - probably not a high priority.
> > - an option in qemu-img to change an image's reference to it's base image
>
> I don't know. I never needed that. What purpose do you need it for?
As Don Kitchen said:
delta1.img and delta2.img are both based on /root/base1.img. The
directory's getting crowded, so you want to move base1.img into
/root/qemu/base1.img. But once you do that, delta1 and delta2 can't find
it. So how is it possible to have a relocated base1.img without merging
either delta1 or delta2, which are mutually exclusive?
> > - an option to use relative paths when referencing base images - so a
> > collection of images is not affected when moved to another
> > directory/machine
>
> I think this is meant as a basic safety valve to avoid "pilot errors".
If I shift a group of images, I have no other way to change the reference
unless the previous issue is addressed, so basically I'm stuck with leaving
the images where I created them.
> P.S.: when I read your mail first, my instant reaction was: and what would
> _I_ get out of the deal if I did just one of these?
Sorry? I'm just making suggestions, I'm not trying to strike a "deal" with
anyone.
--
David Roberts :)
http://kavenc.sf.net/
prev parent reply other threads:[~2006-11-25 1:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-24 6:15 [Qemu-devel] Feature requests David Roberts
2006-11-25 0:31 ` Johannes Schindelin
2006-11-25 1:12 ` David Roberts [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200611251112.04223.dvdr18@gmail.com \
--to=dvdr18@gmail.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).