[Qemu-devel] Feature requests

[Qemu-devel] Feature requests

[David Roberts]

Hi,

Here's a list of features that I feel would be useful for QEMU to have at some 
stage. Feel free to critique any of them.
- proper restoration of usb with savevm/loadvm
- integrated clipboard sharing - i.e. without network dependencies
- drag'n'drop support - i.e. dragging a file onto the qemu window copies it to 
the active guest window
- 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
- an option in qemu-img to change an image's reference to it's base image
- an option to use relative paths when referencing base images - so a 
collection of images is not affected when moved to another directory/machine

-- 
David Roberts :)
http://kavenc.sf.net/

Re: [Qemu-devel] Feature requests

[Johannes Schindelin]

Hi,

On Fri, 24 Nov 2006, David Roberts wrote:

> - 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".

> - 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.

> - 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?

> - 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?

> - 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".

Ciao,
Dscho

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?

Re: [Qemu-devel] Feature requests

[David Roberts]

> > - 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/