David Abrahams wrote: > I normally launch my kvm VM from the command line with "-redir tcp:3389:3389" > but have been unable to find a way to set up virt-manager to launch it the same > way. Ditto for other qemu options such as "-soundhw all". Is there a way? Not directly in the config. Usual trick is to create a wrapper script like this (for a serial console in that case) ... [root@xeni f8-32]# cat /root/bin/qemu-serial #!/bin/sh exec /usr/bin/qemu-kvm "$@" -serial telnet::9999,server,nowait,nodelay ... then edit the xml config to make the <emulator> tag point to the wrapper script instead of /usr/bin/qemu-kvm.

Hmm, maybe the emulator tag should get a args attribute, so one can do that kind of stuff without wrapper scripts, like this: <domain type='kvm'> [ ... ] <devices> <emulator args="-redir ...">/usr/bin/qemu-kvm</emulator> [ ... ]

The usual ones should be supported by libvirt directly of course. Serial console is in cvs meanwhile, I've seen also sound support patches. But for unusual configurations and debugging purposes it would be quite handy to have the additional args directly in the config and not hidden somewhere in a separate script ... comments?

We explicitly do not support passing arbitrary arguments to QEMU.

Adding features that are enabled with #ifdef HAVE_DEVELOPMENT would be a good thing.

On Thu, 15 May 2008, Gerd Hoffmann wrote: > Stefan de Konink wrote: >> Adding features that are enabled with #ifdef HAVE_DEVELOPMENT would be a >> good thing. > No. Compile time options are evil, most of the time. I wanna use the > standard fedora libvirt package for my work (except when hacking libvirt > itself, obviously). "Oh, you can do foo, but you have to recompile with > --enable-foo first." is a non-starter. If you are a developer and want to develop something, I think it a great thing to have a developement package or distro. If you want to have the same features as others, you are no more than a user and want something stable.

Daniel P. Berrange wrote: > We explicitly do not support passing arbitrary arguments to QEMU. Supporting and implementing are two different things IMHO. It is pretty clear that *supporting* such a configuration is impossible and that running it on production systems is a really bad idea for the reasons outlined. Nevertheless being able to pass random additional arguments to $emulator is required for any serious development work. I *hate* to having to create a wrapper script each time I need to pass in additional parameters, and I'd *love* to see libvirt being a bit more developer friendly.

On Thu, May 15, 2008 at 02:34:20PM +0200, Gerd Hoffmann wrote: > Daniel P. Berrange wrote: > > > We explicitly do not support passing arbitrary arguments to QEMU. > > Supporting and implementing are two different things IMHO. > > It is pretty clear that *supporting* such a configuration is impossible > and that running it on production systems is a really bad idea for the > reasons outlined. We can say that all we like, but the reality is 'we ship it, we support it'. Users are going to file bugs if things break & are going to want them fixed In RHEL we ship Xen with SDL support for framebuffer, even though our tools only 'support' VNC. We still have multiple bugs file against SDL and we have to fix them. Users don't distinguish, they just use all the features you provide them and expect them all to work. > Nevertheless being able to pass random additional arguments to $emulator > is required for any serious development work. I *hate* to having to > create a wrapper script each time I need to pass in additional > parameters, and I'd *love* to see libvirt being a bit more developer > friendly. Historically we've not had very complete coverage of QEMU args, but we've been adding alot of new functionality recently so the need for extra args is reducing all the time. We recently added serial, parallel, sound and drive support. USB is the next on the list at which point we basically have coverage of all the important options we should reasonably expect. Creating wrapper scripts for experimentation is not that difficult.

> is required for any serious development work. I *hate* to having to > create a wrapper script each time I need to pass in additional > parameters, and I'd *love* to see libvirt being a bit more developer > friendly. Historically we've not had very complete coverage of QEMU args, but we've been adding alot of new functionality recently so the need for extra args is reducing all the time. We recently added serial, parallel, sound and drive support. USB is the next on the list at which point we basically have coverage of all the important options we should reasonably expect.

Creating wrapper scripts for experimentation is not that difficult.