[libvirt] how to pass qemu options?
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? TIA, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
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? cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/
on Thu May 15 2008, Gerd Hoffmann <kraxel-AT-redhat.com> wrote:
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.
I thought of that, but was hoping there was a cleaner approach.
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> [ ... ]
Yes, please.
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?
Yesplease, please. :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, May 15, 2008 at 09:10:31AM +0200, Gerd Hoffmann wrote:
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 ...
We explicitly do not support passing arbitrary arguments to QEMU. The libvirt XML format has to be portable & have clearly defined semantics. Adding QEMU specifics args clearly violates that requirement. Furthermore we cannot guarentee the behaviour of QEMU when adding extra arguments, since one arg may change / override the behaviour of another. We've hit this problem in the past with -nographics overriding the monitor device setup & thus breaking our control of QEMU. There's similar issues with the various ways to specify disks overriding each other While you are free to define a wrapper around QEMU to pass extra args, be aware that this is completely unsupportable & we can make no guarentees that your wrapper will continue to run with the same semantics in future libvirt releases. Regards, Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
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. libvirt & tools should make my life easier, not harder. That includes my development work, because using that stuff on a daily base will improve the quality alot. If I stop using libvirt for xenner development because it is easier to get the job done without we all lose. cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/
On Thu, 15 May 2008, Gerd Hoffmann wrote:
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.
libvirt & tools should make my life easier, not harder. That includes my development work, because using that stuff on a daily base will improve the quality alot. If I stop using libvirt for xenner development because it is easier to get the job done without we all lose.
I support this idea. And also want to point out that as far as I can see now in the documentation, libvirt isn't the holy grail that is semantically correct everywhere from the start (examples: relation between storage pools and the actual domains, statistics of network interfaces by domains, etc.) Adding features that are enabled with #ifdef HAVE_DEVELOPMENT would be a good thing. Also handeling things that are imported in libvirt as 'relative' pointers, and never having to refer to something os/distro specific would be a great starting point. Stefan
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. cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/
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. Stefan
Stefan de Konink wrote:
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.
Rubbish. Just because I'm a developer it doesn't mean I want unstable software. And that users don't need debugging features is wrong too. Think bug reports: Asking some user which reports a bug to flip some config bit to enable debug logging usually works fine. Asking them to rebuild the app to compile in debug logging usually doesn't fly. cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/
On Thu, 15 May 2008, Gerd Hoffmann wrote:
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.
Rubbish. Just because I'm a developer it doesn't mean I want unstable software.
Daniel doesn't seem to want to go in to a direction that the semantics of XML go away for userland code. That sounds acceptable for me as end user code. If the features you propose are in this package it is basically ignoring the semantics, what is fine probably but not as out of the box behavior. Compile switches or startup switches it is all the same ballpark to me: it is not exposed by default.
And that users don't need debugging features is wrong too. Think bug reports: Asking some user which reports a bug to flip some config bit to enable debug logging usually works fine. Asking them to rebuild the app to compile in debug logging usually doesn't fly.
What has debugging todo with enabling config parameters? In my humble opinion, what we both want is easy prototyping without hacking in C straight away right? Now I must admit that for the last three hacks resulted in two pretty decent pieces of code, but I was satisfied before with the great dynamic ability of Xen and its 'scripts' directory. Proposed that here, and that was a big no-no. Stefan
on Thu May 15 2008, Gerd Hoffmann <kraxel-AT-redhat.com> 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.
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.
Making it friendlier to those like me who want to transition existing VMs into a libvirt-managed environment would be nice, too. Eventually I might figure out how to do what I need without those extra options, but for now, I just need the system to work. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
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. Regards, Daniel. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
on Thu May 15 2008, "Daniel P. Berrange" <berrange-AT-redhat.com> wrote:
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.
I'm using the TCP redirection option "-redir ..." to do seamless RDP securely. Unimportant? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, May 15, 2008 at 10:05:58AM -0400, David Abrahams wrote:
on Thu May 15 2008, "Daniel P. Berrange" <berrange-AT-redhat.com> wrote:
On Thu, May 15, 2008 at 02:34:20PM +0200, Gerd Hoffmann wrote:
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.
I'm using the TCP redirection option "-redir ..." to do seamless RDP securely. Unimportant?
The -redir option only works with user mode SLIRP networking which is unreliable & unstable at best, and has very serious flaws on 64-bit platforms. We are aiming to provide the ability to run QEMU unprivileged without using the user mode SLIRP networking junk for networking. The only seriously usable networking options are briding or the libvirt NAT based networking Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
Daniel P. Berrange wrote:
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.
Maybe for normal users. Certainly not for developers. I need stuff like raising debug level for more verbose logs, enable experimental features while working on them and similar stuff. Nothing which I'd expect libvirt to support directly.
Creating wrapper scripts for experimentation is not that difficult.
But it is quite inconvenient. And it also proves that you can't prevent users from passing additional args to qemu, thereby creating unsupported configurations. So what was the point in refusing <emulator args="-foo">...</emulator> support? cheers, Gerd -- http://kraxel.fedorapeople.org/xenner/
On Thu, May 15, 2008 at 08:55:25PM +0200, Gerd Hoffmann wrote:
Daniel P. Berrange wrote:
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.
Maybe for normal users. Certainly not for developers. I need stuff like raising debug level for more verbose logs, enable experimental features while working on them and similar stuff. Nothing which I'd expect libvirt to support directly.
Creating wrapper scripts for experimentation is not that difficult.
But it is quite inconvenient.
And it also proves that you can't prevent users from passing additional args to qemu, thereby creating unsupported configurations. So what was the point in refusing <emulator args="-foo">...</emulator> support?
There is a vast difference between having to go *outside* the API to add extra args, vs supporting it directly in the XML format. Dan. -- |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
participants (4)
-
Daniel P. Berrange -
David Abrahams -
Gerd Hoffmann -
Stefan de Konink