Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
On 04/05/2010 12:53 AM, Paul Brook wrote: Surprising as there are ~10 descriptors being polled, so ~1200 polls per second. Maybe epoll will help here. I'm not sure where you get 1200 from. select will be called once per host wakeup. i.e. if the USB controller is enabled then 1k times per second due to the frame tick. That was 125 interrupts/sec x 10 fds ('poll' here was the per-file callback in the kernel, not the select call). With your numbers, it's more like 10k polls/sec which can be eliminated. Are you sure there are actually 10 descriptors being polled? Remember that the nfds argument is the value of the largest fd in the set (+1), not the number of descriptors in the set. I was estimating from the strace parsed output, the real number is 7. So the kernel calls 7k callbacks/sec only to return with a timeout. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
> > My guess is that the overhead you're seeing is entirely from the USB host > > adapter having to wake up and check the transport descriptor lists. This > > will only result in the guest being woken if a device actually responds > > (as mentioned above it should not). > > A quick profile on the host side doesn't show this. Instead, I see a > lot of select() overhead. This actually confirms my hypothesis. After fixing the UHCI bug the guest is completely idle, but the host still needs to wake up at 1ms intervals to do UHCI emulation. I can believe that the most visible part of this is the select() syscall. > Surprising as there are ~10 descriptors being > polled, so ~1200 polls per second. Maybe epoll will help here. I'm not sure where you get 1200 from. select will be called once per host wakeup. i.e. if the USB controller is enabled then 1k times per second due to the frame tick. Are you sure there are actually 10 descriptors being polled? Remember that the nfds argument is the value of the largest fd in the set (+1), not the number of descriptors in the set. Paul -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
> > The USB HID devices implement the SET_IDLE command, so the polling > > interval will have no real effect on performance. > > On a Linux guest (F12), I see 125 USB interrupts per second with no > mouse movement, so something is broken (on the guest or host). Turns out to be a a bug in the UHCI emulation. It should only raise an interrupt if the transfer actually completes (i.e. the active bit is set to zero). Fixed by 5bd2c0d7. I was testing with an OHCI controller, which does not have this bug. Paul -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
On 04/04/2010 05:25 PM, Paul Brook wrote: Looks like the tablet is set to 100 Hz polling rate. We may be able to get away with 30 Hz or even less (ep_bInterval, in ms, in hw/usb-wacom.c). Changing the USB tablet polling interval from 10ms to 100ms in both hw/usb-wacom.c and hw/usb-hid.c made no difference except the an increase in bInterval shown in lsusb -v in the guest and the hint of jerky mouse movement I expected from setting this value so high. A similar change to the polling interval for the keyboard and mouse also made no difference to their performance impact. The USB HID devices implement the SET_IDLE command, so the polling interval will have no real effect on performance. On a Linux guest (F12), I see 125 USB interrupts per second with no mouse movement, so something is broken (on the guest or host). My guess is that the overhead you're seeing is entirely from the USB host adapter having to wake up and check the transport descriptor lists. This will only result in the guest being woken if a device actually responds (as mentioned above it should not). A quick profile on the host side doesn't show this. Instead, I see a lot of select() overhead. Surprising as there are ~10 descriptors being polled, so ~1200 polls per second. Maybe epoll will help here. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
> > Looks like the tablet is set to 100 Hz polling rate. We may be able > > to get away with 30 Hz or even less (ep_bInterval, in ms, in > > hw/usb-wacom.c). > > Changing the USB tablet polling interval from 10ms to 100ms in both > hw/usb-wacom.c and hw/usb-hid.c made no difference except the an increase > in bInterval shown in lsusb -v in the guest and the hint of jerky mouse > movement I expected from setting this value so high. A similar change to > the polling interval for the keyboard and mouse also made no difference to > their performance impact. The USB HID devices implement the SET_IDLE command, so the polling interval will have no real effect on performance. My guess is that the overhead you're seeing is entirely from the USB host adapter having to wake up and check the transport descriptor lists. This will only result in the guest being woken if a device actually responds (as mentioned above it should not). >Taking the FRAME_TIMER_FREQ down to 100 in hw/usb-uhci.c does seem to reduce >the CPU load quite a bit, but at the expense of making the USB tablet (and >presumably all other USB devices) very laggy. The guest USB driver explicitly decides which devices to poll each frame. Slowing down the frame rate will effectively change the polling period by the same factor. e.g. the HID device requests a polling rate of 10ms, you slowed down frame rate by 10x, so you're efectively only polling every 100ms. If you want a quick and nasty hack then you can probably make the device wake up less often, and process multiple frames every wakeup. However this is probably going to do bad things (at best extremely poor performance) when using actual USB devices. Fixing this properly is hard because the transport descriptor lists are stores in system RAM, and polled by the host adapter. The first step is to read the whole table of descriptors, and calculate when the next event is due. However the guest will not explicitly notify the HBA when these tables are modified, so you also need some sort of MMU trap to trigger recalculation. This only gets you down to the base polling interval requested by the device. Increasing this interval causes significant user visible latency, so increasing it is not an option. The guest is also likely to distribute polling events evenly, further reducing the effective sleep interval. To fix this you need additional APIs so that a device can report when an endpoint will become unblocked, rather than just waiting to be polled and NAKing the request. Paul -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
High CPU use of -usbdevice tablet (was Re: KVM usability)
Avi Kivity writes: > On 03/02/2010 11:34 AM, Jernej Simončič wrote: > >On Tuesday, March 2, 2010, 9:21:18, Chris Webb wrote: > > > >>I remember about a year ago, someone asserting on the list that -usbdevice > >>tablet was very CPU intensive even when not in use, and should be avoided if > >>mouse support wasn't needed, e.g. on non-graphical VMs. Was that actually a > >>significant hit, and is it still true today? > >It would appear that this is still the case, at least on slower hosts > >- on Atom Z530 (1,6GHz), the XP VM uses ~30% CPU when idle with > >-usbdevice tablet, but only ~4% without it. However, on a faster host > >(Core2 Quad 2,66GHz), there's practically no difference (Vista x64 VM > >uses ~1% CPU when idle regardless of -usbdevice tablet). > > Looks like the tablet is set to 100 Hz polling rate. We may be able > to get away with 30 Hz or even less (ep_bInterval, in ms, in > hw/usb-wacom.c). Hi Avi. Sorry for the very late follow-up, but I decided to experiment with this. The cpu impact of the usb tablet device shows up fairly clearly on a crude test on my (relatively low-spec) desktop. Running an idle Fedora 11 livecd on qemu-kvm 0.12.3, top shows around 0.1% of my cpu in use, but this increases to roughly 5% when specifying -usbdevice tablet, and more detailed examination with perf record/report suggests about a factor of thirty too. It's actually a more general symptom with USB or at least HID devices by the look of things: although -usb doesn't increase CPU use on its own, the same increase in load can also be triggered by -usbdevice keyboard or mouse. However, running with all three of -usbdevice mouse, keyboard and tablet doesn't increase load any more than just one of these. Changing the USB tablet polling interval from 10ms to 100ms in both hw/usb-wacom.c and hw/usb-hid.c made no difference except the an increase in bInterval shown in lsusb -v in the guest and the hint of jerky mouse movement I expected from setting this value so high. A similar change to the polling interval for the keyboard and mouse also made no difference to their performance impact. Taking the FRAME_TIMER_FREQ down to 100 in hw/usb-uhci.c does seem to reduce the CPU load quite a bit, but at the expense of making the USB tablet (and presumably all other USB devices) very laggy. Could there be some bug here that causes the usb hid devices to wake qemu at the maximum rate possible (FRAME_TIMER_FREQ?) rather than the configured polling interval? Best wishes, Chris. PS Vmmouse works fine as an absolute pointing device in the place of -usbdevice tablet without the performance impact, but this isn't supported out of the box with typical linux live CDs (e.g. Fedora 11 and 12 or Knoppix) so unfortunately it's probably less suitable as a default configuration to expose to end-users. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/09/2010 07:27 PM, Anthony Liguori wrote: Perhaps a json representation of things. We already have the parser. Please no :-) We have a config format, QemuOpts ties nicely into it as does qdev. We just need to represent machine information via QemuOpts and tie -m to manipulating the memory assigned to a machine. IOW, instead of: (machine_init)(ram_addr_t ram_size, const char *boot_device, const char *kernel_filename, const char *kernel_cmdline, const char *initrd_filename, const char *cpu_model) It should be: (machine_init)(QemuOpts *opts); Then we can have a [machine] section in the config where we describe all of these things. Looks good. One day we'll read VHDL descriptions of the device model from the machine config file and tcg them to host native code, and qemu will be pure infrastructure with zero details. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/09/2010 11:11 AM, Avi Kivity wrote: On 03/09/2010 04:57 PM, Anthony Liguori wrote: On 03/09/2010 08:52 AM, Avi Kivity wrote: On 03/09/2010 04:50 PM, Anthony Liguori wrote: It's all in the openSUSE build service. The direct access URL (login required FWIW) is here: https://build.opensuse.org/package/view_file?file=kvm-qemu-default-memsize.patch&package=kvm&project=Virtualization It merely changes DEFAULT_RAM_SIZE in vl.c from 128 to 384 for the "kvm" package. We should attempt to do three things with default ram size: 1) bump it up to a more reasonable number 2) make it specified in the global default config 3) make sure we can provide compatibility support for older machine types It's really sad, the amount of code needed to change a number. We don't do enough via a config. If we did, we could just have a 0.12 config version that got frozen over time. So really, if we can make the mem readable by global config, and we can have machine specific configs, it would simplify the problem in the future so that we just had to bump a number. Perhaps a json representation of things. We already have the parser. Please no :-) We have a config format, QemuOpts ties nicely into it as does qdev. We just need to represent machine information via QemuOpts and tie -m to manipulating the memory assigned to a machine. IOW, instead of: (machine_init)(ram_addr_t ram_size, const char *boot_device, const char *kernel_filename, const char *kernel_cmdline, const char *initrd_filename, const char *cpu_model) It should be: (machine_init)(QemuOpts *opts); Then we can have a [machine] section in the config where we describe all of these things. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/09/2010 04:57 PM, Anthony Liguori wrote: On 03/09/2010 08:52 AM, Avi Kivity wrote: On 03/09/2010 04:50 PM, Anthony Liguori wrote: It's all in the openSUSE build service. The direct access URL (login required FWIW) is here: https://build.opensuse.org/package/view_file?file=kvm-qemu-default-memsize.patch&package=kvm&project=Virtualization It merely changes DEFAULT_RAM_SIZE in vl.c from 128 to 384 for the "kvm" package. We should attempt to do three things with default ram size: 1) bump it up to a more reasonable number 2) make it specified in the global default config 3) make sure we can provide compatibility support for older machine types It's really sad, the amount of code needed to change a number. We don't do enough via a config. If we did, we could just have a 0.12 config version that got frozen over time. So really, if we can make the mem readable by global config, and we can have machine specific configs, it would simplify the problem in the future so that we just had to bump a number. Perhaps a json representation of things. We already have the parser. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/09/2010 08:52 AM, Avi Kivity wrote: On 03/09/2010 04:50 PM, Anthony Liguori wrote: It's all in the openSUSE build service. The direct access URL (login required FWIW) is here: https://build.opensuse.org/package/view_file?file=kvm-qemu-default-memsize.patch&package=kvm&project=Virtualization It merely changes DEFAULT_RAM_SIZE in vl.c from 128 to 384 for the "kvm" package. We should attempt to do three things with default ram size: 1) bump it up to a more reasonable number 2) make it specified in the global default config 3) make sure we can provide compatibility support for older machine types It's really sad, the amount of code needed to change a number. We don't do enough via a config. If we did, we could just have a 0.12 config version that got frozen over time. So really, if we can make the mem readable by global config, and we can have machine specific configs, it would simplify the problem in the future so that we just had to bump a number. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/09/2010 04:49 PM, Anthony Liguori wrote: On 03/09/2010 07:32 AM, Avi Kivity wrote: On 03/02/2010 04:36 AM, Anthony Liguori wrote: I keep a patch in the SUSE version for quite some time now that bumps the default to 384 for qemu-kvm. That was the first "round" number where an openSUSE installation worked. If someone works up a patch and tests at least a couple types of guests to confirm that they all install with that number, I'd be happy to apply it (although we need some trickery to support older pc versions). We should avoid changing defaults. I disagree. IMHO, the defaults should represent our best suggestion for any given release. The compatibility machines make it very easier for a user to fix on a particular version of a machine type. Agreed, should have said, avoid changing defaults without taking care of backwards compatibility. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/09/2010 04:50 PM, Anthony Liguori wrote: It's all in the openSUSE build service. The direct access URL (login required FWIW) is here: https://build.opensuse.org/package/view_file?file=kvm-qemu-default-memsize.patch&package=kvm&project=Virtualization It merely changes DEFAULT_RAM_SIZE in vl.c from 128 to 384 for the "kvm" package. We should attempt to do three things with default ram size: 1) bump it up to a more reasonable number 2) make it specified in the global default config 3) make sure we can provide compatibility support for older machine types It's really sad, the amount of code needed to change a number. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/09/2010 08:38 AM, Alexander Graf wrote: On 09.03.2010, at 15:32, Dustin Kirkland wrote: On Tue, 2010-03-09 at 15:32 +0200, Avi Kivity wrote: On 03/02/2010 04:36 AM, Anthony Liguori wrote: I keep a patch in the SUSE version for quite some time now that bumps the default to 384 for qemu-kvm. That was the first "round" number where an openSUSE installation worked. If someone works up a patch and tests at least a couple types of guests to confirm that they all install with that number, I'd be happy to apply it (although we need some trickery to support older pc versions). We should avoid changing defaults. I don't think in this case it matters, since everyone specifies -m anyway, but as a general rule changing defaults = breakage for the unwary. At least make the default part of the machine type to preserve compatibility. In that case, Alex, where can I find your +384M patch, because I'd like to carry the same one in Ubuntu... It's all in the openSUSE build service. The direct access URL (login required FWIW) is here: https://build.opensuse.org/package/view_file?file=kvm-qemu-default-memsize.patch&package=kvm&project=Virtualization It merely changes DEFAULT_RAM_SIZE in vl.c from 128 to 384 for the "kvm" package. We should attempt to do three things with default ram size: 1) bump it up to a more reasonable number 2) make it specified in the global default config 3) make sure we can provide compatibility support for older machine types Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/09/2010 07:32 AM, Avi Kivity wrote: On 03/02/2010 04:36 AM, Anthony Liguori wrote: I keep a patch in the SUSE version for quite some time now that bumps the default to 384 for qemu-kvm. That was the first "round" number where an openSUSE installation worked. If someone works up a patch and tests at least a couple types of guests to confirm that they all install with that number, I'd be happy to apply it (although we need some trickery to support older pc versions). We should avoid changing defaults. I disagree. IMHO, the defaults should represent our best suggestion for any given release. The compatibility machines make it very easier for a user to fix on a particular version of a machine type. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 09.03.2010, at 15:32, Dustin Kirkland wrote: > On Tue, 2010-03-09 at 15:32 +0200, Avi Kivity wrote: >> On 03/02/2010 04:36 AM, Anthony Liguori wrote: I keep a patch in the SUSE version for quite some time now that bumps the default to 384 for qemu-kvm. That was the first "round" number where an openSUSE installation worked. >>> >>> If someone works up a patch and tests at least a couple types of >>> guests to confirm that they all install with that number, I'd be happy >>> to apply it (although we need some trickery to support older pc >>> versions). >> >> We should avoid changing defaults. I don't think in this case it >> matters, since everyone specifies -m anyway, but as a general rule >> changing defaults = breakage for the unwary. At least make the default >> part of the machine type to preserve compatibility. > > In that case, Alex, where can I find your +384M patch, because I'd like > to carry the same one in Ubuntu... It's all in the openSUSE build service. The direct access URL (login required FWIW) is here: https://build.opensuse.org/package/view_file?file=kvm-qemu-default-memsize.patch&package=kvm&project=Virtualization It merely changes DEFAULT_RAM_SIZE in vl.c from 128 to 384 for the "kvm" package. Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On Tue, 2010-03-09 at 15:32 +0200, Avi Kivity wrote: > On 03/02/2010 04:36 AM, Anthony Liguori wrote: > >> I keep a patch in the SUSE version for quite some time now that bumps > >> the default to 384 for qemu-kvm. That was the first "round" number > >> where an openSUSE installation worked. > > > > If someone works up a patch and tests at least a couple types of > > guests to confirm that they all install with that number, I'd be happy > > to apply it (although we need some trickery to support older pc > > versions). > > We should avoid changing defaults. I don't think in this case it > matters, since everyone specifies -m anyway, but as a general rule > changing defaults = breakage for the unwary. At least make the default > part of the machine type to preserve compatibility. In that case, Alex, where can I find your +384M patch, because I'd like to carry the same one in Ubuntu... Dustin signature.asc Description: This is a digitally signed message part
Re: KVM usability
On 03/02/2010 04:36 AM, Anthony Liguori wrote: I keep a patch in the SUSE version for quite some time now that bumps the default to 384 for qemu-kvm. That was the first "round" number where an openSUSE installation worked. If someone works up a patch and tests at least a couple types of guests to confirm that they all install with that number, I'd be happy to apply it (although we need some trickery to support older pc versions). We should avoid changing defaults. I don't think in this case it matters, since everyone specifies -m anyway, but as a general rule changing defaults = breakage for the unwary. At least make the default part of the machine type to preserve compatibility. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/07/2010 08:53 PM, Arnaldo Carvalho de Melo wrote: Do you really think that more kernel developers would use perf more frequently if it had some GUI? Not much. Is perf's target kernel developers exclusively? Who are we writing this kernel for? No, we aren't writing this tool only for kernel developers exclusively, but that wasn't my question, it was badly formulated, sorry, I shouldn't have included "kernel" in it :-\ In this case, I will reformulate my answer. Very much. Even for kernel developers there are advantages in a GUI, namely that features are easily discovered, the amount of information is easily controlled, and in that you can interact (not redo everything from scratch every time you want to change something). The difference between a curses based tool and a true GUI are minimal for this audience. Ok, I agree with you about easier discoverability of features, path shortened from report to annotate to starting the editor right at the line where some event of interest happened, Another path is browse some function, start profiling, see perf data fill up in the margin. Or, jump to callers. etc. You need an integrated browser for that (or an emacs perf mode). will try to keep the routines not much coupled with ncurses, but definetely ncurses will be the first step. Great. ncurses is certainly much easier to experiment with and will likely provide useful experience. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
Em Sun, Mar 07, 2010 at 08:15:40PM +0200, Avi Kivity escreveu: > On 03/07/2010 08:01 PM, Arnaldo Carvalho de Melo wrote: > >Em Sun, Mar 07, 2010 at 11:35:31AM +0200, Avi Kivity escreveu: > >>perf really is wonderful, but to be really competitive, and usable to > >>more developers, it needs to be in a graphical environment. I want > >>'perf report' output to start out collapsed and drill down by clicking > >>on a tree widget. Clicking on a function name opens its definition. > >>'perf annotate' should display annotations on my editor window, not in a > >>pager. I should be able to check events on a list, not using 'perf > >>list'. > >Do you really think that more kernel developers would use perf more > >frequently if it had some GUI? > > Not much. Is perf's target kernel developers exclusively? Who are > we writing this kernel for? No, we aren't writing this tool only for kernel developers exclusively, but that wasn't my question, it was badly formulated, sorry, I shouldn't have included "kernel" in it :-\ > No wonder everything is benchmarked using kbuild. > > >I plan to work on a ncurses tool combining aspects of the existing perf > >tools, integrating them more, like you suggest above, but even having > >worked on a pygtk tool that is close to the kernel [1], I'm unsure if > >doing it using gtk or QT would be something that would entice more > >developers to use it. > > Even for kernel developers there are advantages in a GUI, namely > that features are easily discovered, the amount of information is > easily controlled, and in that you can interact (not redo everything > from scratch every time you want to change something). The > difference between a curses based tool and a true GUI are minimal > for this audience. Ok, I agree with you about easier discoverability of features, path shortened from report to annotate to starting the editor right at the line where some event of interest happened, will try to keep the routines not much coupled with ncurses, but definetely ncurses will be the first step. - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
* Pekka Enberg wrote: > That said, AFAICT, it should be pretty simple to implement a shark-like UI > with GTK as current perf code is pretty good fit for that. I've pondered > about doing that myself but quite frankly, I don't see any big gains in > that. There's a perf events based GUI: sysprof. It's not integrated into tools/perf/ (it's using the syscall) and we'd welcome it integrated as 'perf view' or 'perf gui' - just like we'd welcome a new from-scratch GUI frontend as well. The latter would have the advantage of growing gradually and naturally - so if you feel like implementing it, please do not hesitate ;-) I had a good hard look at the perf GUI situation a few months ago and GTK looks like the best fit. Even if it's simple initially it would clearly show us the exact demand of GUI versus TUI. I.e. if you are right and it doesnt matter, it will stay simple, if Avi is right and it matters then people will use it as a base and improve it. A win-win scenario. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/02/2010 02:30 AM, Ingo Molnar wrote: * Anthony Liguori wrote: On 03/01/2010 02:56 PM, Ingo Molnar wrote: Here's our experience with tools/perf/. Hosting the project in the kernel proper helped its quality immensely: - It's much easier to synchronize new features on the kernel side and on the user-space side. The two go hand in hand - they are often implemented in the same patch. Kernel features and qemu features usually don't have a great amount of intersect. All of the problems you've described are strictly in the qemu space. IMO that's a bug, not a feature. There should be a lot more interaction between kvm-qemu and KVM: for example Qemu should have a feature to install paravirt drivers in the guest, this would be helped by living in the kernel repo. The paravirt drivers are completely disassociated from kvm. You can run a virtio driver with qemu but without kvm (or even with virtualbox, without either qemu or kvm). For Linux, installing drivers automatically in older guests is impossible due to Documentation/stable_api_nonsense.txt and unnecessary in newer Linux (same reason). For non-Linux, this feature certainly makes sense, but I don't see how putting qemu in tools/kvm helps it much. - It's released together with the kernel, which gives a periodic 3 months release frequency. Not too slow, not too fast. qemu release range in length from 3-6 months depending on distribution schedules. They are very regular. The Linux kernel is released every 3 months, +- one week. Our experience is that even 6 months would be (way) too painful for distros. It would also be horrible for internal synchronization. That's not an issue with qemu, nor do I think that six months would hurt distros any. In any case, we respond to feedback (which we happen to generate in the first place). - Code quality requirements are that of the kernel's. No muck allowed and it's not hard to explain what kind of code is preferred. Code quality is subjective. We have a different coding style. That's somewhat of a problem when for example a KVM kernel-space developer crosses into Qemu code and back. Two separate styles, etc. I certainly remember a 'culture clash' when going from the kernel into Qemu and back. Different principles, different culture. It's better to standardize. That sounds like a trivial thing. - Tool breakage bisection is a breeze: there's never any mismatch between tools/perf and the kernel counterpart. With a separate package we'd have more complex test and bisection scenarios. KVM has a backwards compatible ABI so there's no such thing as mismatch between user and kernel space. perf too is ABI compatible (between releases) - still bisection is a lot easier because the evolution of a particular feature can be bisected back to. Btw., KVM certainly ha ABI breakages around 2.6.16(?) when it was added, even of released versions. Also, within a development version you sure sometimes iterate a new ABI component, right? With a time-coherent repository both intentional and unintentional breakages and variations can be bisected back to as they happened. This is an unconditional advantage and i made use of it numerous times. Try old qemu on new kernel. If it works, bisect qemu. If it fails, bisect the kernel. If you're lucky it is qemu that was broken, so no kernel rebuilds and reboots. Since qemu is much larger than kvm, it is more likely to have introduced the problem, so the bisect goes faster. You could argue that any project should be in the kernel for these reasons. I see no reason why something as like KVM should be part of the kernel and udev shouldn't be. Yes, you are quite correct: udev has been argued to be a prime candidate for tools/. (and some other kernel utilities as well) From a design POV all 'system/kernel utilities', which make little sense without the kernel and are license compatible can (and arguably should) move there. Obviously there's no pressure to do so - it's only an opportunity. Only a small part of qemu, especially the desktop oriented qemu that you seem to want, actually interfaces with kvm. Mostly it involves emulating hardware, issuing I/O, talking to management layers, presenting a user interface, etc. It's not a system/kernel utility. etc. In the KVM context this was obviously only a suggestion though. If i were hacking on kvm-qemu i wouldnt hesitate for a moment to do it: the project has very close ties to kernel-KVM and repo level unification would create various synergies - but you are hacking on it, not me ;-) If i were doing it i'd probably start with a cleaned up and stripped down version of Qemu, to make it eligible for mainline kernel inclusion. You should try it. I think you'll find that it's not as obvious thing to do as you think it is. A few years ago I looked into
Re: KVM usability
On 02/27/2010 07:25 PM, Ingo Molnar wrote: * Zachary Amsden wrote: [...] Second, it's not over-modularized. The modules are the individual components of the architecture. How would you propose to put it differently. They really can't naturally combine. And with the code quality of qemu in general being problematic by Linux kernel standards, it's not natural to move the device emulation directly into the kernel module. So this is why we are where we are today. I'm not talking about moving it into a kernel _module_ - albeit that alone is a worthwile thing to do for any performance sensitive hw component. Moving qemu into the kernel is preposterous. It's a huge code base (even a stripped down version) with many external dependencies. You're converting a guest crash into a host crash, and a simple binary update into a reboot. What makes sense is identifying the performance critical bits and creating generally useful kernel interfaces that can be used to speed them up, or kvm-specific kernel accelerations. Example include preadv/pwritev (generic) and vhost-net (specific). I was talking about the option of a clean, stripped down Qemu base hosted in the kernel proper, in linux/tools/kvm/ or so. If i were running a virtualization effort it would be the first place i'd consider to put my tooling into. It would be a no-brainer: most of the devs come from the KVM side, and KVM itself makes little sense without Qemu, and Qemu makes little sense without KVM these days. (and i know about the non-KVM and non-x86 roots of Qemu - still, it's not a significant piece of usage today) It's true that qemu development is dominated these days by kvm development. If the qemu community was dysfunctional (as it once was) then it makes sense to fork it. But it isn't, so it doesn't. Note also that kvm is not x86 only. Third, it's the maintainers upstream who are in charge of KVM quality as a whole - when you are talking about upstream code quality, and the package maintainers who are in charge of KVM quality as a whole - when you are talking about a distro. This is nothing new - it's just a statement of decentralization. It's certainly nothing new. Nor was the suckage of CVS newup until Git came along and changed the game on a fundamental basis. Bitkeeper deserves some credit here. Suckage is there to be fought all the time. Send patches, not flames. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/07/2010 05:14 PM, Luca Barbieri wrote: perf really is wonderful, but to be really competitive, and usable to more developers, it needs to be in a graphical environment. I want 'perf report' output to start out collapsed and drill down by clicking on a tree widget. Clicking on a function name opens its definition. 'perf annotate' should display annotations on my editor window, not in a pager. I should be able to check events on a list, not using 'perf list'. Is something like that suitable for tools/perf/? I think you'll find the intersection of kernel developers and GUI developers to be fairly small. The latest versions of Gnome Sysprof use perf and provide a GTK+ tree interface for the profiling output. However, they are not configurable at all and don't support anything but call graph profiling, unless they added more features very recently. It would be nice to extend sysprof into a more capable tool, and one that can read perf output files and do so when launched from the command line. Looks like a step in the right direction. I don't think this belong in tools/, though. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/07/2010 08:01 PM, Arnaldo Carvalho de Melo wrote: Em Sun, Mar 07, 2010 at 11:35:31AM +0200, Avi Kivity escreveu: perf really is wonderful, but to be really competitive, and usable to more developers, it needs to be in a graphical environment. I want 'perf report' output to start out collapsed and drill down by clicking on a tree widget. Clicking on a function name opens its definition. 'perf annotate' should display annotations on my editor window, not in a pager. I should be able to check events on a list, not using 'perf list'. Do you really think that more kernel developers would use perf more frequently if it had some GUI? Not much. Is perf's target kernel developers exclusively? Who are we writing this kernel for? No wonder everything is benchmarked using kbuild. I plan to work on a ncurses tool combining aspects of the existing perf tools, integrating them more, like you suggest above, but even having worked on a pygtk tool that is close to the kernel [1], I'm unsure if doing it using gtk or QT would be something that would entice more developers to use it. Even for kernel developers there are advantages in a GUI, namely that features are easily discovered, the amount of information is easily controlled, and in that you can interact (not redo everything from scratch every time you want to change something). The difference between a curses based tool and a true GUI are minimal for this audience. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
Em Sun, Mar 07, 2010 at 11:35:31AM +0200, Avi Kivity escreveu: > perf really is wonderful, but to be really competitive, and usable to > more developers, it needs to be in a graphical environment. I want > 'perf report' output to start out collapsed and drill down by clicking > on a tree widget. Clicking on a function name opens its definition. > 'perf annotate' should display annotations on my editor window, not in a > pager. I should be able to check events on a list, not using 'perf > list'. Do you really think that more kernel developers would use perf more frequently if it had some GUI? I plan to work on a ncurses tool combining aspects of the existing perf tools, integrating them more, like you suggest above, but even having worked on a pygtk tool that is close to the kernel [1], I'm unsure if doing it using gtk or QT would be something that would entice more developers to use it. - Arnaldo [1] http://www.osadl.org/Single-View.111+M52212cb1379.0.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
> perf really is wonderful, but to be really competitive, and usable to more > developers, it needs to be in a graphical environment. I want 'perf report' > output to start out collapsed and drill down by clicking on a tree widget. > Clicking on a function name opens its definition. 'perf annotate' should > display annotations on my editor window, not in a pager. I should be able > to check events on a list, not using 'perf list'. > > Is something like that suitable for tools/perf/? I think you'll find the > intersection of kernel developers and GUI developers to be fairly small. The latest versions of Gnome Sysprof use perf and provide a GTK+ tree interface for the profiling output. However, they are not configurable at all and don't support anything but call graph profiling, unless they added more features very recently. It would be nice to extend sysprof into a more capable tool, and one that can read perf output files and do so when launched from the command line. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/03/2010 05:42 PM, Ross Boylan wrote: Of course this is itself still far from optimal as a user experiance. We really want it to be fully configured to any resolution as easily as the user would do with a real graphics card& monitor. Is there some obstacle to getting the virtual monitor to provide configuration info when it's queried? That seems like the most direct solution. That was my conclusion as well. All that's missing is something to code it up. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/02/2010 11:34 AM, Jernej Simončič wrote: On Tuesday, March 2, 2010, 9:21:18, Chris Webb wrote: I remember about a year ago, someone asserting on the list that -usbdevice tablet was very CPU intensive even when not in use, and should be avoided if mouse support wasn't needed, e.g. on non-graphical VMs. Was that actually a significant hit, and is it still true today? It would appear that this is still the case, at least on slower hosts - on Atom Z530 (1,6GHz), the XP VM uses ~30% CPU when idle with -usbdevice tablet, but only ~4% without it. However, on a faster host (Core2 Quad 2,66GHz), there's practically no difference (Vista x64 VM uses ~1% CPU when idle regardless of -usbdevice tablet). Looks like the tablet is set to 100 Hz polling rate. We may be able to get away with 30 Hz or even less (ep_bInterval, in ms, in hw/usb-wacom.c). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/01/2010 05:14 PM, Anthony Liguori wrote: - Graphics performance is awful even with the 640x480 miniature version. During bootup I can see it drawing single characters. This is a Core2 2.8GHz. That's a bug. Please report it. Graphics performance isn't great, but it should not be that bad. (This is in grub, right?) That's not fixable in kvm. In 4-bit vga mode you cannot allow the guest to access emulated VRAM directly (since each access has side effects). A Core 2 will only do about 250K emulations per second, so screen redraws take about 3 seconds. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/07/2010 11:56 AM, Pekka Enberg wrote: Hi Avi, (slightly off-topic) On Sun, Mar 7, 2010 at 11:35 AM, Avi Kivity wrote: perf really is wonderful, but to be really competitive, and usable to more developers, it needs to be in a graphical environment. I want 'perf report' output to start out collapsed and drill down by clicking on a tree widget. Clicking on a function name opens its definition. 'perf annotate' should display annotations on my editor window, not in a pager. I should be able to check events on a list, not using 'perf list'. People keep bringing this up but I don't quite agree. Mac OS X has "shark" which is pretty much what you describe above. However, having used both, I prefer perf's simple UI for two reasons: it's much easier to automate perf commands and text-based reports are superior for sharing results (and keeping track of results when doing performance optimizations). Yes, you (and me as well). But most people are quite unlike new and me. There's a reason GUIs dominate today, and there are even a few kernel developers that don't use mutt for reading email. Even for command-line-happy people, GUIs still have an advantage in that it is much easier to discover features by exploring the UI vs. reading manual pages. That said, AFAICT, it should be pretty simple to implement a shark-like UI with GTK as current perf code is pretty good fit for that. I've pondered about doing that myself but quite frankly, I don't see any big gains in that. Because you are only interested in your own itches (which is perfectly legitimate, but will keep perf's userbase down). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
Hi Avi, (slightly off-topic) On Sun, Mar 7, 2010 at 11:35 AM, Avi Kivity wrote: > perf really is wonderful, but to be really competitive, and usable to more > developers, it needs to be in a graphical environment. I want 'perf report' > output to start out collapsed and drill down by clicking on a tree widget. > Clicking on a function name opens its definition. 'perf annotate' should > display annotations on my editor window, not in a pager. I should be able > to check events on a list, not using 'perf list'. People keep bringing this up but I don't quite agree. Mac OS X has "shark" which is pretty much what you describe above. However, having used both, I prefer perf's simple UI for two reasons: it's much easier to automate perf commands and text-based reports are superior for sharing results (and keeping track of results when doing performance optimizations). That said, AFAICT, it should be pretty simple to implement a shark-like UI with GTK as current perf code is pretty good fit for that. I've pondered about doing that myself but quite frankly, I don't see any big gains in that. Pekka -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/02/2010 12:30 PM, Ingo Molnar wrote: * Ingo Molnar wrote: Here's our experience with tools/perf/. Hosting the project in the kernel proper helped its quality immensely: - It's much easier to synchronize new features on the kernel side and on the user-space side. The two go hand in hand - they are often implemented in the same patch. Just look at an example from today, a perf+KVM feature patch posted by Yanmin Zhang: http://www.mail-archive.com/kvm@vger.kernel.org/msg29770.html That single patch implements the following "perf kvm" commands: perf kvm top perf kvm record perf kvm report perf kvm diff Both the kernel-space and the user-space changes are in that single patch. Anyone who'd like to try it out can apply it and get an updated kernel plus updated tooling and can start profiling KVM guests straight away. You just check out the kernel, apply the patch and that's it - you can go. It doesnt get any more convenient than that to do development. Such kind of a unified repository is a powerful concept, and we make use of those aspects of tools/perf/ every day. You could only pry it out of our cold, dead fingers ;-) perf really is wonderful, but to be really competitive, and usable to more developers, it needs to be in a graphical environment. I want 'perf report' output to start out collapsed and drill down by clicking on a tree widget. Clicking on a function name opens its definition. 'perf annotate' should display annotations on my editor window, not in a pager. I should be able to check events on a list, not using 'perf list'. Is something like that suitable for tools/perf/? I think you'll find the intersection of kernel developers and GUI developers to be fairly small. Btw., this is one of the things that FreeBSD does right - and i believe it is one of the technical concepts behind Apple's success as well. Apple, with a tenth's of Linux's effective R&D budget can consistently out-develop Linux. I think that's in part due to there not being a strict chinese wall between the Apple kernel, libraries and applications - it's one coherent project where everyone is well-connected to each piece, with no artificial project-cultural boundaries and barriers. People can and do move between those areas of the larger "Apple" project to achieve their goals - regardless of how many components need touching for a given area of interest. IMHO we should learn from that - while we are good in many areas there's always aspects of Linux that can be improved. But i digress. Folding everything into the kernel tree is one way to approach it; IMO it is completely unreasonable. The kernel is a very small part of a complete system. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/02/2010 04:29 PM, Ingo Molnar wrote: I guess the first step would be to move away from the 'lets support lots of crappy virtualization solutions at once, poorly' model, and pick one good combo (i'd go for Qemu+KVM) and turn it into a heck of an all-around solution. Then all the other combos will catch up as well. (or will wither away) Should desktop integration be GNOME or KDE based? IMO this should be addressed via a plugin system so that we can have a well integrated single process VM, without choosing one or the other. Also, the qemu community doesn't really have serious graphics design expertise; best to leave that to people who won't make it a total disaster. ( Sidenote: i also looked at the VirtualBox kernel driver. Oh my ... i really shouldnt have! They should migrate to the KVM kernel-side code ASAP ... ) They can't, if they want to continue to support hardware without virtualization extensions. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
"H. Peter Anvin" writes: > On 03/04/2010 12:13 PM, Zachary Amsden wrote: >> >> These are all basic things that are left completely undefined by qemu's >> lack of a top-level configuration file, and it's an inexcusable disgrace. >> > > There is a top-level configuration file for Qemu, at least in the > development tree. It's optional, still, but it's there now. It covers much but not all of the command line. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/04/2010 12:13 PM, Zachary Amsden wrote: > > These are all basic things that are left completely undefined by qemu's > lack of a top-level configuration file, and it's an inexcusable disgrace. > There is a top-level configuration file for Qemu, at least in the development tree. It's optional, still, but it's there now. -hpa -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/04/2010 02:13 PM, Zachary Amsden wrote: The biggest problem with virt-manager isn't virt-manager, it's that it is trying to do a nearly intractable task. Because a qemu virtual machine is not a machine at all, just a disk image without the proper metadata to track the important properties of the machine, like what revision of PCI chipset, how many disk controllers the thing is using, what kind of graphics card, etc. These are all basic things that are left completely undefined by qemu's lack of a top-level configuration file, and it's an inexcusable disgrace. So virt-manager or any other management tool has the burden of creating and maintaining a bunch of metadata around this workhorse tool called qemu and invoking libvirt to figure out which set of 100,000 blasted command line options to pass on. That's why it falls short of expectations at times, not because virt-manager is crap, but because there is no well defined, well designed infrastructure for it to manage and the ad-hoc solution here is total crap. And this is why we're doing QMP and qdev. It's long overdue infrastructure. It's not just the problem that you describe though. virt-manager is limited by what libvirt provides and today libvirt does not expose nearly enough qemu features for virt-manager to even attempt to solve the problem on it's own. Regards, Anthony Liguori Zach -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/04/2010 10:00 AM, Lucas Meneghel Rodrigues wrote: On Tue, 2010-03-02 at 11:11 +0100, Peter Zijlstra wrote: On Mon, 2010-03-01 at 09:14 -0600, Anthony Liguori wrote: The real question to ask is, why are you using qemu directly instead of using virt-manager? Because I suspect Ingo, like me, is a command line user, launching a gui to start kvm when there is a kvm command around just sounds daft. Also, I just installed and tried it, virt-manager is a total piece of shit, That statement is far from being fair. I use virt-manager quite a lot, since I want to keep track of what's going on on KVM virtualization for end users in Fedora. What's shipped with Fedora 12 is pretty decent in many regards, but as in any other software there's plenty of room for improvements. The biggest problem with virt-manager isn't virt-manager, it's that it is trying to do a nearly intractable task. Because a qemu virtual machine is not a machine at all, just a disk image without the proper metadata to track the important properties of the machine, like what revision of PCI chipset, how many disk controllers the thing is using, what kind of graphics card, etc. These are all basic things that are left completely undefined by qemu's lack of a top-level configuration file, and it's an inexcusable disgrace. So virt-manager or any other management tool has the burden of creating and maintaining a bunch of metadata around this workhorse tool called qemu and invoking libvirt to figure out which set of 100,000 blasted command line options to pass on. That's why it falls short of expectations at times, not because virt-manager is crap, but because there is no well defined, well designed infrastructure for it to manage and the ad-hoc solution here is total crap. Zach -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On Tue, 2010-03-02 at 11:11 +0100, Peter Zijlstra wrote: > On Mon, 2010-03-01 at 09:14 -0600, Anthony Liguori wrote: > > The real > > question to ask is, why are you using qemu directly instead of using > > virt-manager? > > Because I suspect Ingo, like me, is a command line user, launching a gui > to start kvm when there is a kvm command around just sounds daft. > > Also, I just installed and tried it, virt-manager is a total piece of > shit, That statement is far from being fair. I use virt-manager quite a lot, since I want to keep track of what's going on on KVM virtualization for end users in Fedora. What's shipped with Fedora 12 is pretty decent in many regards, but as in any other software there's plenty of room for improvements. > I wouldn't even know how to begin telling it how to start my > freshly baked kernel with serial console on stdio and some block image I > just created from the gentoo stage3 tarball. Fair enough, it is convoluted to do what you want using virt-manager (although possible), but mainly because this wasn't a use case for it. You can't expect the application designers to support every single type of work flow under the sun. > That is, after 5 minutes clicking I have no idea how to even launch an > ISO with the thing, I prefer reading the kvm manpage over using some > mouse only gui crap like that. For the 1st thing you wanted to do, I agree that it was cumbersome. But to create a VM and make it boot an ISO available on your hard drive it *is* trivial. There's a wizard to do it, because it's the main use case of the thing. If you want to point out problems on virt-manager that is fine, and the developers will do what is possible to address problems, insults are not necessary. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On Wed, 2010-03-03 at 08:55 +, Daniel P. Berrange wrote: > On Tue, Mar 02, 2010 at 06:57:54PM -0800, Ross Boylan wrote: > > On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote: > > > > > > > * desktop is 1024 x 720 > > > > > > > > > > 1024x768 and this is what the default is today anyway. > > That was not my experience, as reported in my post a few days ago > > ("800x600 max resolution"), nor is it the experience reported in the > > message that kicked off this thread. > > > > I have been able to get a higher resolution, but it was far from > > automatic. > > It depends on the guest OS version. QEMU exposes a cirrus logic card by > defualt, QEMU docs recommend -std vga for higher resolutions; I used that. > and given the lack of vsync/hsync info, the Xorg driver will > pick 800x600 as the default resolution in absence of any Xorg.conf About > 6 months or so back, we got Xorg guys to add a code to the Xorg cirrus > driver that looked for the QEMU PCI subsystem ID and if found, defaults > to 1024x768 instead. So presumably that logic wouldn't have kicked in. I had xorg 7.5 on Debian squeeze as the guest. > Of course this is itself still far from optimal > as a user experiance. We really want it to be fully configured to any > resolution as easily as the user would do with a real graphics card & > monitor. Is there some obstacle to getting the virtual monitor to provide configuration info when it's queried? That seems like the most direct solution. Ross -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On Tue, Mar 02, 2010 at 06:57:54PM -0800, Ross Boylan wrote: > On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote: > > > > > * desktop is 1024 x 720 > > > > > > > 1024x768 and this is what the default is today anyway. > That was not my experience, as reported in my post a few days ago > ("800x600 max resolution"), nor is it the experience reported in the > message that kicked off this thread. > > I have been able to get a higher resolution, but it was far from > automatic. It depends on the guest OS version. QEMU exposes a cirrus logic card by defualt, and given the lack of vsync/hsync info, the Xorg driver will pick 800x600 as the default resolution in absence of any Xorg.conf About 6 months or so back, we got Xorg guys to add a code to the Xorg cirrus driver that looked for the QEMU PCI subsystem ID and if found, defaults to 1024x768 instead. Of course this is itself still far from optimal as a user experiance. We really want it to be fully configured to any resolution as easily as the user would do with a real graphics card & monitor. Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote: > > > * desktop is 1024 x 720 > > > > 1024x768 and this is what the default is today anyway. That was not my experience, as reported in my post a few days ago ("800x600 max resolution"), nor is it the experience reported in the message that kicked off this thread. I have been able to get a higher resolution, but it was far from automatic. I believe the root cause is the failure of the virtual monitor to respond to or provide EDID (?) to tell the kernel available screen resolutions, sync values, and similar information. I recall seeing an open bug on this, not sure if it was kvm or qemu. I also recall it had been open for a fairly long time. Ross -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/02/10 15:56, Daniel P. Berrange wrote: Glad to hear that. Are these bits in F12 virt-preview already? I believe so. /me goes fetch updates to check it out. Migrating >from another tool like VMWare is a much harder than just importing the disk image, since you have to update the drivers inside the guest, likely reconfigure several config files, etc, etc. There is work on a full v2v tool to automate this task, for both Linux& Windows guests. I meant migrating from another qemu management tool, be it some other gui tool or self-baked shell scripts or something else. That's pretty much what the 'disk import' could deal with, unless we wanted to provide a way to read the config files from those other qemu mgmt tools directly on a case-by-case basis What I'll expect: At minimum a way to create a virtual machine without the auto-started installation, with no or minimal hardware plugged in, so I can configure it the way I want via "add hardware", then boot it. Better would be some dialog to shortcut the "add hardware" clicking for the most common stuff, i.e. a single dialog box asking for disk image, nic type, mac address, sound card, serial console. I guess this is roughly what the "disk import" feature will do for me. Analyzing the guest image, trying to figure what nic, disk and mac address it expects and pre-filling the dialog box with the results would be really great. I suspect that is alot of work for little gains, but hey, maybe the v2v tool has most of the bits needed for that anyway, so we can get that nevertheless. cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On Tue, Mar 02, 2010 at 03:52:52PM +0100, Gerd Hoffmann wrote: > On 03/02/10 15:37, Daniel P. Berrange wrote: > >On Tue, Mar 02, 2010 at 03:22:07PM +0100, Gerd Hoffmann wrote: > >>On 03/02/10 14:37, Nikolai K. Bochev wrote: > >>>I don't see where this argument is leading to. So far there are > >>>arguments that qemu/kvm sucks as a desktop virtualization, now > >>>suddenly the gui tools are shitty and everything should be done cli , > >>>because there's no man pages for virt-manager. Explain. > >> > >>Lets face it: virt-manager has a big bunch of problems. For starters > >>there is no (gui) way to create a virtual machine other than installing > >>one from a iso image or via pxe. So if you downloaded a disk image and > >>want to boot it -> no cookie for you. Likewise if you have a bunch of > >>already installed guests and want to migrate from $othertool to > >>virt-manager you can't do that easily. > > > >The ability to import existing KVM disk images is available in the > >latest release of virt-manager, targetted for Fedora 13. > > Glad to hear that. Are these bits in F12 virt-preview already? I believe so. > >Migrating > >from another tool like VMWare is a much harder than just importing > >the disk image, since you have to update the drivers inside the guest, > >likely reconfigure several config files, etc, etc. There is work on > >a full v2v tool to automate this task, for both Linux& Windows guests. > > I meant migrating from another qemu management tool, be it some other > gui tool or self-baked shell scripts or something else. That's pretty much what the 'disk import' could deal with, unless we wanted to provide a way to read the config files from those other qemu mgmt tools directly on a case-by-case basis Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On Tue, Mar 2, 2010 at 2:21 AM, Chris Webb wrote: > I remember about a year ago, someone asserting on the list that -usbdevice > tablet was very CPU intensive even when not in use, and should be avoided if > mouse support wasn't needed, e.g. on non-graphical VMs. Was that actually a > significant hit, and is it still true today? I don't notice a difference from a functional standpoint. :-Dustin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/02/10 15:37, Daniel P. Berrange wrote: On Tue, Mar 02, 2010 at 03:22:07PM +0100, Gerd Hoffmann wrote: On 03/02/10 14:37, Nikolai K. Bochev wrote: I don't see where this argument is leading to. So far there are arguments that qemu/kvm sucks as a desktop virtualization, now suddenly the gui tools are shitty and everything should be done cli , because there's no man pages for virt-manager. Explain. Lets face it: virt-manager has a big bunch of problems. For starters there is no (gui) way to create a virtual machine other than installing one from a iso image or via pxe. So if you downloaded a disk image and want to boot it -> no cookie for you. Likewise if you have a bunch of already installed guests and want to migrate from $othertool to virt-manager you can't do that easily. The ability to import existing KVM disk images is available in the latest release of virt-manager, targetted for Fedora 13. Glad to hear that. Are these bits in F12 virt-preview already? Migrating from another tool like VMWare is a much harder than just importing the disk image, since you have to update the drivers inside the guest, likely reconfigure several config files, etc, etc. There is work on a full v2v tool to automate this task, for both Linux& Windows guests. I meant migrating from another qemu management tool, be it some other gui tool or self-baked shell scripts or something else. Migrating from other virtualization products is harder of course. cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On Tue, Mar 02, 2010 at 03:22:07PM +0100, Gerd Hoffmann wrote: > On 03/02/10 14:37, Nikolai K. Bochev wrote: > >I don't see where this argument is leading to. So far there are > >arguments that qemu/kvm sucks as a desktop virtualization, now > >suddenly the gui tools are shitty and everything should be done cli , > >because there's no man pages for virt-manager. Explain. > > Lets face it: virt-manager has a big bunch of problems. For starters > there is no (gui) way to create a virtual machine other than installing > one from a iso image or via pxe. So if you downloaded a disk image and > want to boot it -> no cookie for you. Likewise if you have a bunch of > already installed guests and want to migrate from $othertool to > virt-manager you can't do that easily. The ability to import existing KVM disk images is available in the latest release of virt-manager, targetted for Fedora 13. Migrating from another tool like VMWare is a much harder than just importing the disk image, since you have to update the drivers inside the guest, likely reconfigure several config files, etc, etc. There is work on a full v2v tool to automate this task, for both Linux & Windows guests. Regards, Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
* Gerd Hoffmann wrote: > On 03/02/10 14:37, Nikolai K. Bochev wrote: > >I don't see where this argument is leading to. So far there are > >arguments that qemu/kvm sucks as a desktop virtualization, now > >suddenly the gui tools are shitty and everything should be done cli , > >because there's no man pages for virt-manager. Explain. > > Lets face it: virt-manager has a big bunch of problems. For > starters there is no (gui) way to create a virtual machine other > than installing one from a iso image or via pxe. So if you > downloaded a disk image and want to boot it -> no cookie for you. > Likewise if you have a bunch of already installed guests and want to > migrate from $othertool to virt-manager you can't do that easily. > > virt-manager builds on top of libvirt, so you always have the option > to use other tools (virsh command line shell for example) to get > something done which virt-manager doesn't provide a gui for. > libvirt can handle everything Peter asked for without problems. It > still sucks though. The whole point of a GUI is that you do *not* > have to go to libvirt.org to figure how to tweak the virtual machine > config xml using "virsh edit $vmname". >From the short exposure i had to the VirtualBox GUI, that app certainly looks usable. I was able to create & manage a virtual machine without any hassle, and everything Just Worked (tm). The various GUI controls for suspending/snapshotting/halting the virtual machines were intuitive as well, and mouse integration and various graphics details were what i'd expect from a modern solution. So if Qemu/virt-manager/libvirt reached parity with the VirtualBox GUI, that would go a long, long way in satisfying non-expert virtualization users. I guess the first step would be to move away from the 'lets support lots of crappy virtualization solutions at once, poorly' model, and pick one good combo (i'd go for Qemu+KVM) and turn it into a heck of an all-around solution. Then all the other combos will catch up as well. (or will wither away) ( Sidenote: i also looked at the VirtualBox kernel driver. Oh my ... i really shouldnt have! They should migrate to the KVM kernel-side code ASAP ... ) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/02/10 14:37, Nikolai K. Bochev wrote: I don't see where this argument is leading to. So far there are arguments that qemu/kvm sucks as a desktop virtualization, now suddenly the gui tools are shitty and everything should be done cli , because there's no man pages for virt-manager. Explain. Lets face it: virt-manager has a big bunch of problems. For starters there is no (gui) way to create a virtual machine other than installing one from a iso image or via pxe. So if you downloaded a disk image and want to boot it -> no cookie for you. Likewise if you have a bunch of already installed guests and want to migrate from $othertool to virt-manager you can't do that easily. virt-manager builds on top of libvirt, so you always have the option to use other tools (virsh command line shell for example) to get something done which virt-manager doesn't provide a gui for. libvirt can handle everything Peter asked for without problems. It still sucks though. The whole point of a GUI is that you do *not* have to go to libvirt.org to figure how to tweak the virtual machine config xml using "virsh edit $vmname". cheers, Gerd -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
I don't see where this argument is leading to. So far there are arguments that qemu/kvm sucks as a desktop virtualization, now suddenly the gui tools are shitty and everything should be done cli , because there's no man pages for virt-manager. Explain. - Original Message - From: Peter Zijlstra To: Anthony Liguori Cc: Ingo Molnar , Avi Kivity , Yanmin Zhang , ming m lin , sheng yang , Jes Sorensen , KVM General , Zachary Amsden , Gleb Natapov , Arnaldo Carvalho de Melo , Fr??d??ric Weisbecker , Thomas Gleixner , H. Peter Anvin , Arjan van de Ven , Cole Robinson Sent: Tue, 02 Mar 2010 12:11:06 +0200 (EET) Subject: Re: KVM usability On Mon, 2010-03-01 at 09:14 -0600, Anthony Liguori wrote: > The real > question to ask is, why are you using qemu directly instead of using > virt-manager? Because I suspect Ingo, like me, is a command line user, launching a gui to start kvm when there is a kvm command around just sounds daft. Also, I just installed and tried it, virt-manager is a total piece of shit, I wouldn't even know how to begin telling it how to start my freshly baked kernel with serial console on stdio and some block image I just created from the gentoo stage3 tarball. That is, after 5 minutes clicking I have no idea how to even launch an ISO with the thing, I prefer reading the kvm manpage over using some mouse only gui crap like that. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
* Ingo Molnar wrote: > Here's our experience with tools/perf/. Hosting the project in the kernel > proper helped its quality immensely: > > - It's much easier to synchronize new features on the kernel side and on the >user-space side. The two go hand in hand - they are often implemented in >the same patch. Just look at an example from today, a perf+KVM feature patch posted by Yanmin Zhang: http://www.mail-archive.com/kvm@vger.kernel.org/msg29770.html That single patch implements the following "perf kvm" commands: perf kvm top perf kvm record perf kvm report perf kvm diff Both the kernel-space and the user-space changes are in that single patch. Anyone who'd like to try it out can apply it and get an updated kernel plus updated tooling and can start profiling KVM guests straight away. You just check out the kernel, apply the patch and that's it - you can go. It doesnt get any more convenient than that to do development. Such kind of a unified repository is a powerful concept, and we make use of those aspects of tools/perf/ every day. You could only pry it out of our cold, dead fingers ;-) Btw., this is one of the things that FreeBSD does right - and i believe it is one of the technical concepts behind Apple's success as well. Apple, with a tenth's of Linux's effective R&D budget can consistently out-develop Linux. I think that's in part due to there not being a strict chinese wall between the Apple kernel, libraries and applications - it's one coherent project where everyone is well-connected to each piece, with no artificial project-cultural boundaries and barriers. People can and do move between those areas of the larger "Apple" project to achieve their goals - regardless of how many components need touching for a given area of interest. IMHO we should learn from that - while we are good in many areas there's always aspects of Linux that can be improved. But i digress. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On Mon, 2010-03-01 at 09:14 -0600, Anthony Liguori wrote: > The real > question to ask is, why are you using qemu directly instead of using > virt-manager? Because I suspect Ingo, like me, is a command line user, launching a gui to start kvm when there is a kvm command around just sounds daft. Also, I just installed and tried it, virt-manager is a total piece of shit, I wouldn't even know how to begin telling it how to start my freshly baked kernel with serial console on stdio and some block image I just created from the gentoo stage3 tarball. That is, after 5 minutes clicking I have no idea how to even launch an ISO with the thing, I prefer reading the kvm manpage over using some mouse only gui crap like that. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
Ingo Molnar writes: > Yes, you are quite correct: udev has been argued to be a prime candidate for > tools/. (and some other kernel utilities as well) A small, static set of userspace like klibc (only 5M unpacked!) with enough tools for rolling up in a standard initramfs would be especially nice, and vastly less difficult to import than qemu. It's a pain in the neck to have to build two versions of lots of bits of userspace: one stripped down and statically linked for initramfs and one full-featured for the main system. However, trying to avoid initramfs altogether is an increasingly losing battle these days, and for quite understandable reasons. klibc + md* + mini lvm2 (enough to activate volumes) perhaps? Cheers, Chris. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
Dustin Kirkland writes: > On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote: > > > > Defaulting usb to on and defaulting to a usb tablet is a reasonable > > thing to do IMHO. > > \o/ Definitely a better user experience. I remember about a year ago, someone asserting on the list that -usbdevice tablet was very CPU intensive even when not in use, and should be avoided if mouse support wasn't needed, e.g. on non-graphical VMs. Was that actually a significant hit, and is it still true today? Cheers, Chris. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote: > On 03/01/2010 03:12 PM, Dustin Kirkland wrote: > > kvm -m 512 -cdrom > > /home/kirkland/.cache/testdrive/iso/lucid-desktop-amd64.iso -drive > > file=/home/kirkland/.cache/testdrive/img/testdrive-disk-0086OD.img,if=virtio,index=0,boot=on > > -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 > > > > Among these: > > * 512MB is a nice step up from the 128MB by default (this one scales > > based on your hosts memory) > > > > I'm not opposed to bumping from 128M to something else. I'd like to see > some indication though other than "seems reasonable" as to what the > value should be. For instance, if a Fedora 12 install doesn't work > without 256M, that's a solid argument to bump the allocation. Short > term, I'd like to see this globally configurable. That would be very nice! I think 256MB (or even 384MB) would be a reasonable default. Modern Ubuntu LiveCD's will work well with 256MB, but 128MB is essentially unusable. We should just make sure that the default is intelligently chosen based on the host's available memory resources. The crude logic in testdrive looks like this: if len(MEM) == 0: total = commands.getoutput("grep ^MemTotal /proc/meminfo | awk '{print $2}'") if total > 100: MEM = 512 elif total > 75: MEM = 384 else: MEM = 256 > > * virtio is used for disk and network for nice performance gains > > > > The problem with virtio is that very few OSes have the drivers right > now. For networking, we can do better, and I've just written a spec for > a new feature to attempt to address this[1]. For disk, I think we're > stuck with ide as the default for a long time. That's safe, reasonable position for upstream to make. And a sane one for distro's to tweak depending on their intended target guest OS's. > > * usb device tablet greatly improves the mouse experience > > > > Defaulting usb to on and defaulting to a usb tablet is a reasonable > thing to do IMHO. \o/ Definitely a better user experience. > > * sound card added > > > > This personally would annoy me but if there was wide consensus that this > was right, I'd be okay with it. I agree that sound-on by default might be annoying to some. Speaking for myself, if I don't want to hear guest noises, I usually don't want to hear host noises either. In which case I mute the sound on my host and solve both problems. But I don't feel strongly about this one. > > * qcow2 sparse disk image > > > > This is independent of qemu. Understood. This merely seemed like the best-practice, most-recommended, best-performing backing disk format for unwitting kvm users launching VMs when they don't actually care what the backing format is. > > * desktop is 1024 x 720 > > > > 1024x768 and this is what the default is today anyway. Ack. :-Dustin signature.asc Description: This is a digitally signed message part
Re: KVM usability
On 03/01/2010 08:34 PM, Alexander Graf wrote: On 01.03.2010, at 22:59, Anthony Liguori wrote: On 03/01/2010 03:12 PM, Dustin Kirkland wrote: kvm -m 512 -cdrom /home/kirkland/.cache/testdrive/iso/lucid-desktop-amd64.iso -drive file=/home/kirkland/.cache/testdrive/img/testdrive-disk-0086OD.img,if=virtio,index=0,boot=on -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 Among these: * 512MB is a nice step up from the 128MB by default (this one scales based on your hosts memory) I'm not opposed to bumping from 128M to something else. I'd like to see some indication though other than "seems reasonable" as to what the value should be. For instance, if a Fedora 12 install doesn't work without 256M, that's a solid argument to bump the allocation. Short term, I'd like to see this globally configurable. I keep a patch in the SUSE version for quite some time now that bumps the default to 384 for qemu-kvm. That was the first "round" number where an openSUSE installation worked. If someone works up a patch and tests at least a couple types of guests to confirm that they all install with that number, I'd be happy to apply it (although we need some trickery to support older pc versions). Regards, Anthony Liguori Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 01.03.2010, at 22:59, Anthony Liguori wrote: > On 03/01/2010 03:12 PM, Dustin Kirkland wrote: >> kvm -m 512 -cdrom >> /home/kirkland/.cache/testdrive/iso/lucid-desktop-amd64.iso -drive >> file=/home/kirkland/.cache/testdrive/img/testdrive-disk-0086OD.img,if=virtio,index=0,boot=on >> -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 >> >> Among these: >> * 512MB is a nice step up from the 128MB by default (this one scales >> based on your hosts memory) >> > > I'm not opposed to bumping from 128M to something else. I'd like to see some > indication though other than "seems reasonable" as to what the value should > be. For instance, if a Fedora 12 install doesn't work without 256M, that's a > solid argument to bump the allocation. Short term, I'd like to see this > globally configurable. I keep a patch in the SUSE version for quite some time now that bumps the default to 384 for qemu-kvm. That was the first "round" number where an openSUSE installation worked. Alex-- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/01/2010 06:30 PM, Ingo Molnar wrote: IMO that's a bug, not a feature. There should be a lot more interaction between kvm-qemu and KVM: for example Qemu should have a feature to install paravirt drivers in the guest, this would be helped by living in the kernel repo. Not in the slightest bit. To support automatically installing paravirt drivers in a guest, we need to distribute an ISO containing *binary* versions of drivers. For Windows, there's a licensing issue that I described earlier with respect to signing. Figuring out distribution is non-trivial and is being worked on. So far, Red Hat are the only ones actually capable of producing signed binaries (no mere mortal can do it). For Linux drivers, we need to be able to ship different versions of the kernel drivers for different distribution kernels if we don't want to rely on what they ship. The way we've tackled this in the past is by having an awk script that automatically converts the virtio drivers into something buildable across kernel versions. It's incredibly difficult to maintain and we stopped maintaining it about a year ago when virtio drivers became common in all distro kernels. See http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers-linux.git if you're interested. What would make this much easier for us is if we could add all of the #ifdef's for various kernel versions in the mainline source tree. I'm not holding my breath for that though :-) But once we had an ISO with binary drivers (and such a thing is available for Windows today), it's just a matter of adding an option to change the CDROM to the shipped ISO. This is purely within qemu and doesn't touch kvm.ko at all. Once the winpv driver's binary hosting is sorted out, virt-manager will have this feature. There are zero changes required to the kvm kernel code to support this. - It's released together with the kernel, which gives a periodic 3 months release frequency. Not too slow, not too fast. qemu release range in length from 3-6 months depending on distribution schedules. They are very regular. The Linux kernel is released every 3 months, +- one week. Our experience is that even 6 months would be (way) too painful for distros. I expect that we'll eventually even out to a consistent release schedule. For now, we're still trying to see what fits us best. The last 3 month release was very compressed so we're trying something a little longer this time. - Code quality requirements are that of the kernel's. No muck allowed and it's not hard to explain what kind of code is preferred. Code quality is subjective. We have a different coding style. That's somewhat of a problem when for example a KVM kernel-space developer crosses into Qemu code and back. Two separate styles, etc. I certainly remember a 'culture clash' when going from the kernel into Qemu and back. Different principles, different culture. It's better to standardize. Some would argue that having diversity of culture is a good thing that breeds creative thinking :-) It's annoying to switch coding styles but I don't think it's a major problem for anyone. - Tool breakage bisection is a breeze: there's never any mismatch between tools/perf and the kernel counterpart. With a separate package we'd have more complex test and bisection scenarios. KVM has a backwards compatible ABI so there's no such thing as mismatch between user and kernel space. perf too is ABI compatible (between releases) - still bisection is a lot easier because the evolution of a particular feature can be bisected back to. Btw., KVM certainly ha ABI breakages around 2.6.16(?) when it was added, even of released versions. That was a one-time thing in the very early days of KVM. Also, within a development version you sure sometimes iterate a new ABI component, right? It's not really happened. We introduce new ABIs very rarely. KVM has a very defined purpose; it provides CPU virtualization. We only extend the ABI to support new CPU features that we didn't previously support and since these things are defined by the Intel architecture, it's fairly easy to define the ABI properly up front. With a time-coherent repository both intentional and unintentional breakages and variations can be bisected back to as they happened. This is an unconditional advantage and i made use of it numerous times. We used to keep the kernel code in the same repository as the userspace code. We stopped doing that about a year ago and it's rare that we have a circumstance where joint bisecting is required. You should try it. I think you'll find that it's not as obvious thing to do as you think it is. A few years ago I looked into cleaning up Qemu, when i hacked KVM and Qemu. I also wanted to have a 'qemu light', which is both smaller and cleaner, and still fits to KVM. It didnt look particularly h
Re: KVM usability
On Mon, Mar 1, 2010 at 9:14 AM, Anthony Liguori wrote: > On 02/27/2010 04:56 AM, Ingo Molnar wrote: >> - But i'm a more advanced user so i dont need help screens, i knew that >> the >> "go full screen" hotkey is: >> >> LeftCtrl-LeftALT-F >> >> ... except that it is a one-way road: pressing it for a second time >> does >> not restore the window, trapping me in the guest altogether! Ctrl-ALT >> does >> not exit the trap either. I had to shut down the guest to get back my X >> desktop. >> > > That's a bug. The upstream QEMU bug for this is: * https://bugs.launchpad.net/qemu/+bug/483251 However, I just tried it on qemu-kvm_0.12.3 and I'm able to toggle in and out of fullscreen mode with ctrl-alt-F ad nauseum. :-Dustin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
* Zachary Amsden wrote: > On 03/01/2010 11:45 AM, Anthony Liguori wrote: > >On 03/01/2010 02:56 PM, Ingo Molnar wrote: > > > >> - Code distribution is easy: it comes with the kernel. This > >>spreads the code > >>far and wide. It's easy for kernel developers to jump in and > >>help out, the > >>latest devel code is always there, a single 'cd tools/perf/; > >>make -j install' > >>command away. > >> - Code reuse: we started sharing/librarizing code with the > >>kernel: bitmap.h, > >>hash.h, list.h, rbtree.h, bitops.h, prefetch.h. > > > >You could argue that any project should be in the kernel for these > >reasons. I see no reason why something as like KVM should be part > >of the kernel and udev shouldn't be. > > gcc and the kernel are quite closely coupled, btw. Note that GCC isnt very much coupled to the kernel. The _kernel_ is coupled to GCC pretty much. (although it's known to build with certain versions of LVVM and also perhaps ICC) The most obvious utilities to move into tools/ are the ones that are bidirectionally coupled: udev, perhaps util-linux, etc. Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
* Anthony Liguori wrote: > On 03/01/2010 02:56 PM, Ingo Molnar wrote: > >Here's our experience with tools/perf/. Hosting the project in the kernel > >proper helped its quality immensely: > > > > - It's much easier to synchronize new features on the kernel side and on > > the > >user-space side. The two go hand in hand - they are often implemented in > >the same patch. > > Kernel features and qemu features usually don't have a great amount of > intersect. All of the problems you've described are strictly in the qemu > space. IMO that's a bug, not a feature. There should be a lot more interaction between kvm-qemu and KVM: for example Qemu should have a feature to install paravirt drivers in the guest, this would be helped by living in the kernel repo. > > > - It's released together with the kernel, which gives a periodic 3 months > >release frequency. Not too slow, not too fast. > > qemu release range in length from 3-6 months depending on > distribution schedules. They are very regular. The Linux kernel is released every 3 months, +- one week. Our experience is that even 6 months would be (way) too painful for distros. > > - Lots of eyeballs and interest. In its mere 8 months of existence > >tools/perf/ has attracted more than 60 contributors already, and 35 KLOC > > of > >new code has been written. > > In our last release, we had around 100 contributors and about 100 KLOC of > code written. We've got a lot of eyeballs and a lot of interest. Congrats! > > - Code quality requirements are that of the kernel's. No muck allowed and > >it's not hard to explain what kind of code is preferred. > > Code quality is subjective. We have a different coding style. That's somewhat of a problem when for example a KVM kernel-space developer crosses into Qemu code and back. Two separate styles, etc. I certainly remember a 'culture clash' when going from the kernel into Qemu and back. Different principles, different culture. It's better to standardize. I.e. i think it would be useful to make it more of 'one' project, instead of this separation. > > - Tool breakage bisection is a breeze: there's never any mismatch between > >tools/perf and the kernel counterpart. With a separate package we'd > >have more complex test and bisection scenarios. > > KVM has a backwards compatible ABI so there's no such thing as mismatch > between user and kernel space. perf too is ABI compatible (between releases) - still bisection is a lot easier because the evolution of a particular feature can be bisected back to. Btw., KVM certainly ha ABI breakages around 2.6.16(?) when it was added, even of released versions. Also, within a development version you sure sometimes iterate a new ABI component, right? With a time-coherent repository both intentional and unintentional breakages and variations can be bisected back to as they happened. This is an unconditional advantage and i made use of it numerous times. > > - Code distribution is easy: it comes with the kernel. This spreads the > > code > >far and wide. It's easy for kernel developers to jump in and help out, > > the > >latest devel code is always there, a single 'cd tools/perf/; make -j > > install' > >command away. > > - Code reuse: we started sharing/librarizing code with the kernel: > > bitmap.h, > >hash.h, list.h, rbtree.h, bitops.h, prefetch.h. > > You could argue that any project should be in the kernel for these > reasons. I see no reason why something as like KVM should be part > of the kernel and udev shouldn't be. Yes, you are quite correct: udev has been argued to be a prime candidate for tools/. (and some other kernel utilities as well) >From a design POV all 'system/kernel utilities', which make little sense without the kernel and are license compatible can (and arguably should) move there. Obviously there's no pressure to do so - it's only an opportunity. > > etc. > > > > In the KVM context this was obviously only a suggestion though. If i were > > hacking on kvm-qemu i wouldnt hesitate for a moment to do it: the project > > has very close ties to kernel-KVM and repo level unification would create > > various synergies - but you are hacking on it, not me ;-) > > > > If i were doing it i'd probably start with a cleaned up and stripped down > > version of Qemu, to make it eligible for mainline kernel inclusion. > > You should try it. I think you'll find that it's not as obvious thing to do > as you think it is. A few years ago I looked into cleaning up Qemu, when i hacked KVM and Qemu. I also wanted to have a 'qemu light', which is both smaller and cleaner, and still fits to KVM. It didnt look particularly hard back then - but it's certainly not zero amount of work. Cleanups pay - they make a piece of code both more hackable, more debuggable and more appealing to new developers. (i suspect you have no argument with that notion) Also note that it wasnt me wh
Re: KVM usability
On 03/01/2010 11:45 AM, Anthony Liguori wrote: On 03/01/2010 02:56 PM, Ingo Molnar wrote: - Code distribution is easy: it comes with the kernel. This spreads the code far and wide. It's easy for kernel developers to jump in and help out, the latest devel code is always there, a single 'cd tools/perf/; make -j install' command away. - Code reuse: we started sharing/librarizing code with the kernel: bitmap.h, hash.h, list.h, rbtree.h, bitops.h, prefetch.h. You could argue that any project should be in the kernel for these reasons. I see no reason why something as like KVM should be part of the kernel and udev shouldn't be. gcc and the kernel are quite closely coupled, btw. etc. In the KVM context this was obviously only a suggestion though. If i were hacking on kvm-qemu i wouldnt hesitate for a moment to do it: the project has very close ties to kernel-KVM and repo level unification would create various synergies - but you are hacking on it, not me ;-) If i were doing it i'd probably start with a cleaned up and stripped down version of Qemu, to make it eligible for mainline kernel inclusion. You should try it. I think you'll find that it's not as obvious thing to do as you think it is. Yes. Yes. We've all looked at the hulking hairy behemoth of qemu and said, I think I can clean this beast up and make him look like a proper gentlemen. Then we tried to shave off the excess hair, only to find not only did it grow back as fast as we trimmed it, but his complexion underneath was mottled and inconsistent, so much so that the hair was actually helping. In the end, we just settled for dressing him up in a suit and tie. Zach -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/01/2010 03:12 PM, Dustin Kirkland wrote: kvm -m 512 -cdrom /home/kirkland/.cache/testdrive/iso/lucid-desktop-amd64.iso -drive file=/home/kirkland/.cache/testdrive/img/testdrive-disk-0086OD.img,if=virtio,index=0,boot=on -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 Among these: * 512MB is a nice step up from the 128MB by default (this one scales based on your hosts memory) I'm not opposed to bumping from 128M to something else. I'd like to see some indication though other than "seems reasonable" as to what the value should be. For instance, if a Fedora 12 install doesn't work without 256M, that's a solid argument to bump the allocation. Short term, I'd like to see this globally configurable. * virtio is used for disk and network for nice performance gains The problem with virtio is that very few OSes have the drivers right now. For networking, we can do better, and I've just written a spec for a new feature to attempt to address this[1]. For disk, I think we're stuck with ide as the default for a long time. * usb device tablet greatly improves the mouse experience Defaulting usb to on and defaulting to a usb tablet is a reasonable thing to do IMHO. * sound card added This personally would annoy me but if there was wide consensus that this was right, I'd be okay with it. * qcow2 sparse disk image This is independent of qemu. * desktop is 1024 x 720 1024x768 and this is what the default is today anyway. [1] http://wiki.qemu.org/Features/NetDeviceFailover Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/01/2010 02:56 PM, Ingo Molnar wrote: Here's our experience with tools/perf/. Hosting the project in the kernel proper helped its quality immensely: - It's much easier to synchronize new features on the kernel side and on the user-space side. The two go hand in hand - they are often implemented in the same patch. Kernel features and qemu features usually don't have a great amount of intersect. All of the problems you've described are strictly in the qemu space. - It's released together with the kernel, which gives a periodic 3 months release frequency. Not too slow, not too fast. qemu release range in length from 3-6 months depending on distribution schedules. They are very regular. - Lots of eyeballs and interest. In its mere 8 months of existence tools/perf/ has attracted more than 60 contributors already, and 35 KLOC of new code has been written. In our last release, we had around 100 contributors and about 100 KLOC of code written. We've got a lot of eyeballs and a lot of interest. - Code quality requirements are that of the kernel's. No muck allowed and it's not hard to explain what kind of code is preferred. Code quality is subjective. We have a different coding style. - Tool breakage bisection is a breeze: there's never any mismatch between tools/perf and the kernel counterpart. With a separate package we'd have more complex test and bisection scenarios. KVM has a backwards compatible ABI so there's no such thing as mismatch between user and kernel space. - Code distribution is easy: it comes with the kernel. This spreads the code far and wide. It's easy for kernel developers to jump in and help out, the latest devel code is always there, a single 'cd tools/perf/; make -j install' command away. - Code reuse: we started sharing/librarizing code with the kernel: bitmap.h, hash.h, list.h, rbtree.h, bitops.h, prefetch.h. You could argue that any project should be in the kernel for these reasons. I see no reason why something as like KVM should be part of the kernel and udev shouldn't be. etc. In the KVM context this was obviously only a suggestion though. If i were hacking on kvm-qemu i wouldnt hesitate for a moment to do it: the project has very close ties to kernel-KVM and repo level unification would create various synergies - but you are hacking on it, not me ;-) If i were doing it i'd probably start with a cleaned up and stripped down version of Qemu, to make it eligible for mainline kernel inclusion. You should try it. I think you'll find that it's not as obvious thing to do as you think it is. Regards, Anthony Liguori Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On Sat, Feb 27, 2010 at 4:56 AM, Ingo Molnar wrote: > Here's my experience with it: > > - qemu-kvm starts up with a miniature resolution by default. 640x480 - on my > 1680x1050 laptop screen. It's so small that initially i even overlooked > that i started it. It should multiplex pixels up to a reasonable screen > size by default. > > - The mouse is trapped straight away by default if you click into it. That's > very annoying if you actually try to integrate a guest OS into your desktop > - it's not just 'another, slightly weird app' but a sticky, opinionated GUI > component that you have to fight with all the time. > > - Once trapped it's not obvious how to untrap the mouse. The qemu window > title says: > > QEMU: Press Ctrl-ALT to exit grab > > Of course once you _know_ what a 'grab' is, you'll know where to look. > At minimum it should say: > > QEMU: Press Ctrl-ALT to exit mouse grab > > But to first-time users it's an annoying trap of the mouse and with no > obvious place to look for help. [besides, it doesnt tell which Ctrl and > which ALT to use - it's the left side. The right side Ctrl does not work.] > > - Graphics performance is awful even with the 640x480 miniature version. > During bootup I can see it drawing single characters. This is a Core2 > 2.8GHz. > > - Sound does not work by default. I have to go dig into command-line options > to see that i need to add: "-soundhw all". Why isnt sound enabled by > default? ..snip.. > ( I could go on and on about finer details of good integration, like the > difficulty of integrating host/guest files, networking, no way to quickly > attach ISOs via that window, no way to activate networking, sound and no way > to snapshot, no way to increase memory size except a command line option. ) ...snip... > I'm not trolling you at all: is it _really_ not obvious to you that the > KVM/qemu usability status quo honestly sucks, to an unbiased observer? Hi there- To a few of your comments shown above...I've noticed these two, and they've bothered me a bit. As Jan (and others) have mentioned, these are often "addressed" by frontends running on top of kvm (and libvirt). I look at kvm as a swissarmy knife, with lots of buttons and knobs and whistles, but you have to give it all of the "right" options to get it to do what you want. The graphical frontends make this easier. But running KVM from the command line, with the bare minimal options, is often a functional, but non-satisfactory impression of KVM. Maintaining the qemu-kvm package in Ubuntu, I've seen this over and over and over again, with Ubuntu users expecting a much smoother graphical experience. "Why can't I get my mouse back?" "Why doesn't sound work?" "How do I make networking work?" "Why is the resolution so low?" Etc. For these reasons (among others), we've created a little package and a python script in Ubuntu called Testdrive [1], which basically downloads an ISO (using rsync/zsync against cached images, if possible), and launches a VM with a "healthy" set of options. The package puts a pointy/clicky option in the Applications menu, and makes for a *very* easy way for Ubuntu users to launch a VM and try out the daily ISO builds (as well as install to the backing disk image). Once it's running, the kvm process looks something like this: kvm -m 512 -cdrom /home/kirkland/.cache/testdrive/iso/lucid-desktop-amd64.iso -drive file=/home/kirkland/.cache/testdrive/img/testdrive-disk-0086OD.img,if=virtio,index=0,boot=on -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370 Among these: * 512MB is a nice step up from the 128MB by default (this one scales based on your hosts memory) * virtio is used for disk and network for nice performance gains * usb device tablet greatly improves the mouse experience * sound card added * qcow2 sparse disk image * desktop is 1024 x 720 For what it's worth, you can just as easily run: testdrive -u http://download.fedoraproject.org/pub/fedora/linux/releases/12/Live/i686/Fedora-12-i686-Live.iso or any other http://, ftp://, rsync://, or file:/// accessible ISO. By no means is Testdrive supposed to be a production quality frontend for KVM (or replace any of the libvirt-based utilities like virt-manager). But I think it shows that KVM's default set of options is a little shy of what people expect for Desktop virtualization at least. For servers, lightweight defaults are perhaps more acceptable? But KVM has a number of new users by way of Ubuntu users just pointing and clicking "Testdrive" and launching a VM. [1] http://launchpad.net/testdrive Cheers, :-Dustin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
* Zachary Amsden wrote: > > I guess there is some misunderstanding here, the tools/ directory that > > lives in the kernel _sources_, has no kernel source, its all userspace > > stuff. > > Yeah, no morning coffee :=) > > So instead we are advocating forking qemu into the kernel. That makes even > less sense. It's not sustainable or eco-friendly to either community. Here's our experience with tools/perf/. Hosting the project in the kernel proper helped its quality immensely: - It's much easier to synchronize new features on the kernel side and on the user-space side. The two go hand in hand - they are often implemented in the same patch. - It's released together with the kernel, which gives a periodic 3 months release frequency. Not too slow, not too fast. - Lots of eyeballs and interest. In its mere 8 months of existence tools/perf/ has attracted more than 60 contributors already, and 35 KLOC of new code has been written. - Code quality requirements are that of the kernel's. No muck allowed and it's not hard to explain what kind of code is preferred. - Tool breakage bisection is a breeze: there's never any mismatch between tools/perf and the kernel counterpart. With a separate package we'd have more complex test and bisection scenarios. - Code distribution is easy: it comes with the kernel. This spreads the code far and wide. It's easy for kernel developers to jump in and help out, the latest devel code is always there, a single 'cd tools/perf/; make -j install' command away. - Code reuse: we started sharing/librarizing code with the kernel: bitmap.h, hash.h, list.h, rbtree.h, bitops.h, prefetch.h. etc. In the KVM context this was obviously only a suggestion though. If i were hacking on kvm-qemu i wouldnt hesitate for a moment to do it: the project has very close ties to kernel-KVM and repo level unification would create various synergies - but you are hacking on it, not me ;-) If i were doing it i'd probably start with a cleaned up and stripped down version of Qemu, to make it eligible for mainline kernel inclusion. Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/01/2010 07:41 AM, Arnaldo Carvalho de Melo wrote: Em Mon, Mar 01, 2010 at 06:48:07AM -1000, Zachary Amsden escreveu: On 02/27/2010 07:25 AM, Ingo Molnar wrote: I'm not talking about moving it into a kernel _module_ - albeit that alone is a worthwile thing to do for any performance sensitive hw component. I was talking about the option of a clean, stripped down Qemu base hosted in the kernel proper, in linux/tools/kvm/ or so. If i were running a virtualization effort it would be the first place i'd consider to put my tooling into. So ripping out a clean part interface like PCI bus infrastructure and using it in the kernel, for example, does nothing except put that infrastructure in two different places, because everything the kernel does, userspace will have to do again anyway. So now you have twice as much code involving the same idea and you have to keep the pieces in sync and from trampling each other. The only parts that warrant such complexity and high risk for bugs are performance critical things like the PIT and APIC. I guess there is some misunderstanding here, the tools/ directory that lives in the kernel _sources_, has no kernel source, its all userspace stuff. Yeah, no morning coffee :=) So instead we are advocating forking qemu into the kernel. That makes even less sense. It's not sustainable or eco-friendly to either community. Zach -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
Em Mon, Mar 01, 2010 at 06:48:07AM -1000, Zachary Amsden escreveu: > On 02/27/2010 07:25 AM, Ingo Molnar wrote: >> I'm not talking about moving it into a kernel _module_ - albeit that >> alone is a worthwile thing to do for any performance sensitive hw >> component. >> >> I was talking about the option of a clean, stripped down Qemu base >> hosted in the kernel proper, in linux/tools/kvm/ or so. If i were >> running a virtualization effort it would be the first place i'd >> consider to put my tooling into. > So ripping out a clean part interface like PCI bus infrastructure and > using it in the kernel, for example, does nothing except put that > infrastructure in two different places, because everything the kernel > does, userspace will have to do again anyway. So now you have twice as > much code involving the same idea and you have to keep the pieces in > sync and from trampling each other. > > The only parts that warrant such complexity and high risk for bugs are > performance critical things like the PIT and APIC. I guess there is some misunderstanding here, the tools/ directory that lives in the kernel _sources_, has no kernel source, its all userspace stuff. - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 02/27/2010 07:25 AM, Ingo Molnar wrote: * Zachary Amsden wrote: [...] Second, it's not over-modularized. The modules are the individual components of the architecture. How would you propose to put it differently. They really can't naturally combine. And with the code quality of qemu in general being problematic by Linux kernel standards, it's not natural to move the device emulation directly into the kernel module. So this is why we are where we are today. I'm not talking about moving it into a kernel _module_ - albeit that alone is a worthwile thing to do for any performance sensitive hw component. I was talking about the option of a clean, stripped down Qemu base hosted in the kernel proper, in linux/tools/kvm/ or so. If i were running a virtualization effort it would be the first place i'd consider to put my tooling into. The problem is there is no way to clean and strip down the Qemu code. It's got nicely abstracted bus and device interfaces, for example, but then these go poking under the covers at things which require interacting with the display rendering library or remoting interface, which is not something to reasonably do in the kernel. So ripping out a clean part interface like PCI bus infrastructure and using it in the kernel, for example, does nothing except put that infrastructure in two different places, because everything the kernel does, userspace will have to do again anyway. So now you have twice as much code involving the same idea and you have to keep the pieces in sync and from trampling each other. The only parts that warrant such complexity and high risk for bugs are performance critical things like the PIT and APIC. Zach -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On Mon, Mar 01, 2010 at 09:14:02AM -0600, Anthony Liguori wrote: > On 02/27/2010 04:56 AM, Ingo Molnar wrote: > > The other type of user we target is power virtualization/emulation > users. We certainly could do better for this type of user but it's > never going to fit what your expectation of desktop virtualization is. > Qemu is never going to be like running VMware Workstation or VirtualBox. > > There is very little split between qemu and kvm from a project > perspective. If anything, our lack of focus on desktop virtualization > comes from the split between qemu/kvm and libvirt. All of the end-user > usability is done in the context of libvirt and virt-manager whereas the > qemu/kvm developers tend to focus on performance, features, and robustness. > > I think we don't spend enough time in qemu/kvm thinking about how we > interact with libvirt with respect to end-to-end usability. It's > something I do believe we need to address and it's an area I have been > focusing on recently. On the other side of things, we (in libvirt community) have tended to be more focused on server virtualization use cases, than desktop ones. There is certainly alot more we could be doing for end user desktop usability in both libvirt & QEMU/KVM parts. As & when we move forward with spice integration, we'll get some significant improvements in usability through the improved graphics performance, flexible guest display resolution, and audio tunnelling to the clients. Daniel -- |: Red Hat, Engineering, London-o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org-o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 03/01/2010 03:25 AM, Ingo Molnar wrote: * Zachary Amsden wrote: Here's my experience with it: - qemu-kvm starts up with a miniature resolution by default. 640x480 - on my 1680x1050 laptop screen. It's so small that initially i even overlooked that i started it. It should multiplex pixels up to a reasonable screen size by default. No virtualization emulator today does this, it is not a reasonable thing to do. Unless you are running compiz and use hardware scaling. We should look into it. I tried VirtualBox and it does something sane here: while it does not give a larger guest screen area, it at least creates a large enough X window, with any border area whited out. That looks far more pleasing aesthetically than the Qemu method of resizing the full window wildly. The guest still resizes, but it stays within the same X window and the border is white. Also, with Windows guests, the Windows side resolution resizes dynamically if the window is grown/shrunk by the user. (I suspect that is done via a paravirt driver on the guest side, through 'Guest Additions'.) We have to core pieces to do this in qemu. The vmware vga driver supports this and it just takes a small userspace program to resize the VGA on demand. The problem is, you need a way to communicate from the host to the guest's userspace. We did not have a mechanism until very recently (virtio-serial) because we've encountered a ton of resistance within the kernel community for the things we've proposed. VirtualBox gets around this by just shipping their own Linux drivers. Regards, Anthony Liguori Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 02/27/2010 11:25 AM, Ingo Molnar wrote: * Zachary Amsden wrote: [...] Second, it's not over-modularized. The modules are the individual components of the architecture. How would you propose to put it differently. They really can't naturally combine. And with the code quality of qemu in general being problematic by Linux kernel standards, it's not natural to move the device emulation directly into the kernel module. So this is why we are where we are today. I'm not talking about moving it into a kernel _module_ - albeit that alone is a worthwile thing to do for any performance sensitive hw component. I was talking about the option of a clean, stripped down Qemu base hosted in the kernel proper, in linux/tools/kvm/ or so. If i were running a virtualization effort it would be the first place i'd consider to put my tooling into. Let's ignore the suggestion of hosting it in the kernel. There's no reason it couldn't be as successful hosted as a separate project. Let's consider what you would strip of out qemu. You would obviously pull out TCG and the device emulation that isn't useful for KVM. You can't compile out TCG today but you actually can compile out most device emulation so this doesn't actually buy you much. It certainly doesn't fix any of the problems you outlined. The GUI wouldn't change at all. You still have the same fundamental problem that whatever this userspace executable is, is not the place where you need to implement a user friendly GUI. That has to be a separate process. Maybe you could integrate that separate process into the same repository as the core process but we can still do this with qemu. It would be a no-brainer: most of the devs come from the KVM side, and KVM itself makes little sense without Qemu, and Qemu makes little sense without KVM these days. (and i know about the non-KVM and non-x86 roots of Qemu - still, it's not a significant piece of usage today) Do you have statistics to back this up? You would probably be surprised at how many people use TCG. To be honest, every KVM developer including myself has considered and even prototyped exactly what you described. We've all independently come to the same conclusion: it's easier to incrementally improve qemu than it is to split the code base and try to maintain the fork. And a lot of the other vendors who have decided to fork qemu in the past have learned the hard way that it's more difficult to maintain a fork and are now merging back to upstream qemu. We could certainly make the same argument about forking the kernel to make it optimized for virtualization. If we took Linux and added it to the qemu git tree, we would instantly have transparent large page support for users instead of having to wait years to get it properly integrated. We could also add gang scheduling and hard scheduler limits to the kernel. But we know better and even though the process is more painful and drawn out, we end up with a much better solution in the long run by including the input and feedback from people like you. Xen clearly made a different decision and is still suffering the consequences. They've done the same thing with qemu as you describe and have now realized it was a mistake and are working to merge their changes into upstream qemu. There are *plenty* of usability issues (like transparent large pages) that need to be addressed at the KVM/kernel level. Today, a user has to choose between a ~30% decrease in performance on Java workloads or the ability to overcommit memory. It's a pretty significant problem and there's been a lot of resistance within the kernel community to fix it. Likewise, I'm seeing a good number of people hit problems with lock holder pre-emption in the field. It's absolutely a usability problem when a user sees catastrophically bad performance running an 8-VCPU virtual machine on a 2 socket host. Whether it's gang scheduling or directed yields + pause loop detection, we definitely need some scheduler changes to fix this problem. Not having an option enabled by default is an annoyance that a user eventually overcomes with the help of documentation. Performance problems are deal breakers that lead users to switch to another virtualization technology. Just stripping down qemu and putting the result in the kernel source tree doesn't fix anything. We have plenty of hard problems to solve already. Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 02/27/2010 04:56 AM, Ingo Molnar wrote: * Avi Kivity wrote: On 02/26/2010 01:17 PM, Ingo Molnar wrote: Nobody is really 'in charge' of how KVM gets delivered to the user. You isolated the fun kernel part for you and pushed out the boring bits to user-space. So if mundane things like mouse integration sucks 'hey that's a user-space tooling problem', if file integration sucks then 'hey, that's an admin problem', if it cannot be used over the network 'hey, that's an Xorg problem', etc. etc. btw, mouse integration works with -usbdevice tablet and recent Fedoras, 'it was an X.org driver problem'. Really, I don't understand your problems. I run bleeding edge rawhide on my main desktop so i just tried latest& greatest KVM and Qemu bits and started up kvm-qemu with some Fedora and XP images i had around: 2.6.33-0.44.rc8.git0.fc13.x86_64 qemu-system-x86-0.12.2-6.fc13.x86_64 Here's my experience with it: - qemu-kvm starts up with a miniature resolution by default. 640x480 - on my Probably 720x480 if you're referring to CGA mode. 1680x1050 laptop screen. It's so small that initially i even overlooked that i started it. It should multiplex pixels up to a reasonable screen size by default. Resize the window to whatever size you want it to be. We'll automatically scale the screen. This works both with SDL and with VNC (provided you use a gtk-vnc based client). If you're suggesting we should scale by default, I disagree. I have the same size screen and the QEMU window is a little bit larger than a standard gnome-terminal. - The mouse is trapped straight away by default if you click into it. That's very annoying if you actually try to integrate a guest OS into your desktop - it's not just 'another, slightly weird app' but a sticky, opinionated GUI component that you have to fight with all the time. All virtualization software behaves this way. - Once trapped it's not obvious how to untrap the mouse. The qemu window title says: QEMU: Press Ctrl-ALT to exit grab Of course once you _know_ what a 'grab' is, you'll know where to look. At minimum it should say: QEMU: Press Ctrl-ALT to exit mouse grab Reasonable suggestion. I've changed it in my local branch. But to first-time users it's an annoying trap of the mouse and with no obvious place to look for help. [besides, it doesnt tell which Ctrl and which ALT to use - it's the left side. The right side Ctrl does not work.] - Graphics performance is awful even with the 640x480 miniature version. During bootup I can see it drawing single characters. This is a Core2 2.8GHz. That's a bug. Please report it. Graphics performance isn't great, but it should not be that bad. - Sound does not work by default. I have to go dig into command-line options to see that i need to add: "-soundhw all". Why isnt sound enabled by default? Because it's intrusive. If you're running 20 guests, you don't want them all trying to play the Windows start up noise. Even if you're running a single VM, you don't necessarily want your music interrupted to play the Ubuntu drums. It's particularly annoying if you're repeatedly starting up guests. - Qemu images are not integrated into the rest of the desktop. If i click on a Qemu image it says: Could not display "/home/mingo/qemu/hda.img". The file is of an unknown type. 10 years of Qemu and its base image format is still 'unknown' ? It's not been 10 years, but I presume you're using a raw image or your distro is fubar because: anth...@squirrel:~/images$ file linux.img linux.img: Qemu Image, Format: Qcow , Version: 2 We intentionally don't want images to be directly executable. An image doesn't include the necessary configuration information to launch a guest. Adding that info to an image is not an obvious thing to do either because a virtual machine may consist of multiple images. - Random bugs. I tried to boot some old Fedora image i had around, it says: spirit:~/qemu> qemu-kvm ./hda-fedora.img kvm: unhandled exit 8021 kvm_run returned -22 This error message is horrible and it warrants a bug report. See https://bugs.launchpad.net/qemu/+bug/530077 - When it boots up, the Qemu window flips around its size crazily, as the BIOS, the bootloader and the OS sets different screen resolutions. To the user that technical detail is immaterial, what matters is an amateurish-looking app that flips its window size as if it was an adware popup window trying to avoid being caught. All virtualization software does this and I think it's completely reasonable. Again, you can resize the window manually and it'll keep that resolution if you are so inclined. As KMS is better supported in Linux guests, we'll eventually get to the point where less screen flipping
Re: KVM usability
* Zachary Amsden wrote: > > Here's my experience with it: > > > > - qemu-kvm starts up with a miniature resolution by default. 640x480 - on > > my > >1680x1050 laptop screen. It's so small that initially i even overlooked > >that i started it. It should multiplex pixels up to a reasonable screen > >size by default. > > No virtualization emulator today does this, it is not a reasonable thing to > do. Unless you are running compiz and use hardware scaling. We should look > into it. I tried VirtualBox and it does something sane here: while it does not give a larger guest screen area, it at least creates a large enough X window, with any border area whited out. That looks far more pleasing aesthetically than the Qemu method of resizing the full window wildly. The guest still resizes, but it stays within the same X window and the border is white. Also, with Windows guests, the Windows side resolution resizes dynamically if the window is grown/shrunk by the user. (I suspect that is done via a paravirt driver on the guest side, through 'Guest Additions'.) Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
* Zachary Amsden wrote: [...] > > Second, it's not over-modularized. The modules are the individual > components of the architecture. How would you propose to put it > differently. They really can't naturally combine. And with the > code quality of qemu in general being problematic by Linux kernel > standards, it's not natural to move the device emulation directly > into the kernel module. So this is why we are where we are today. I'm not talking about moving it into a kernel _module_ - albeit that alone is a worthwile thing to do for any performance sensitive hw component. I was talking about the option of a clean, stripped down Qemu base hosted in the kernel proper, in linux/tools/kvm/ or so. If i were running a virtualization effort it would be the first place i'd consider to put my tooling into. It would be a no-brainer: most of the devs come from the KVM side, and KVM itself makes little sense without Qemu, and Qemu makes little sense without KVM these days. (and i know about the non-KVM and non-x86 roots of Qemu - still, it's not a significant piece of usage today) > Third, it's the maintainers upstream who are in charge of KVM > quality as a whole - when you are talking about upstream code > quality, and the package maintainers who are in charge of KVM > quality as a whole - when you are talking about a distro. This is > nothing new - it's just a statement of decentralization. It's certainly nothing new. Nor was the suckage of CVS newup until Git came along and changed the game on a fundamental basis. Suckage is there to be fought all the time. Ingo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
Ingo Molnar wrote: > I'm not trolling you at all: is it _really_ not obvious to you that the > KVM/qemu usability status quo honestly sucks, to an unbiased observer? I agree that for desktop-style (e.g. vmware workstation) style virtualisation, the plain QEMU+KVM package is terrible. However, in the case of Enterprise server virtualisation, a lot your comments relate to things that do not matter - sound, graphics, GUI, X integration. In the former use-case, it definitely needs significant work on the usability front. In the later use-case, libvirt, RHEV etc all provide a (some argue) decent interface, which removes the remaining niggles around obscure command line options. Which one is QEMU+KVM trying to be? IMO it is succeeding far, far better at server workloads than desktop usage. Ian -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM usability
On 02/27/2010 12:56 AM, Ingo Molnar wrote: * Avi Kivity wrote: On 02/26/2010 01:17 PM, Ingo Molnar wrote: Nobody is really 'in charge' of how KVM gets delivered to the user. You isolated the fun kernel part for you and pushed out the boring bits to user-space. So if mundane things like mouse integration sucks 'hey that's a user-space tooling problem', if file integration sucks then 'hey, that's an admin problem', if it cannot be used over the network 'hey, that's an Xorg problem', etc. etc. btw, mouse integration works with -usbdevice tablet and recent Fedoras, 'it was an X.org driver problem'. Really, I don't understand your problems. I run bleeding edge rawhide on my main desktop so i just tried latest& greatest KVM and Qemu bits and started up kvm-qemu with some Fedora and XP images i had around: 2.6.33-0.44.rc8.git0.fc13.x86_64 qemu-system-x86-0.12.2-6.fc13.x86_64 Here's my experience with it: - qemu-kvm starts up with a miniature resolution by default. 640x480 - on my 1680x1050 laptop screen. It's so small that initially i even overlooked that i started it. It should multiplex pixels up to a reasonable screen size by default. No virtualization emulator today does this, it is not a reasonable thing to do. Unless you are running compiz and use hardware scaling. We should look into it. - The mouse is trapped straight away by default if you click into it. That's very annoying if you actually try to integrate a guest OS into your desktop - it's not just 'another, slightly weird app' but a sticky, opinionated GUI component that you have to fight with all the time. - Once trapped it's not obvious how to untrap the mouse. The qemu window title says: QEMU: Press Ctrl-ALT to exit grab Of course once you _know_ what a 'grab' is, you'll know where to look. At minimum it should say: QEMU: Press Ctrl-ALT to exit mouse grab But to first-time users it's an annoying trap of the mouse and with no obvious place to look for help. [besides, it doesnt tell which Ctrl and which ALT to use - it's the left side. The right side Ctrl does not work.] As a long time user of other brand name virtualization software, this was immediately obvious to me and followed the paradigm I was used to - a two or three combination meta key press allows escape, while allowing you to send one or two combo meta keypresses to the VM. - Graphics performance is awful even with the 640x480 miniature version. During bootup I can see it drawing single characters. This is a Core2 2.8GHz. Yes it is. - Sound does not work by default. I have to go dig into command-line options to see that i need to add: "-soundhw all". Why isnt sound enabled by default? Probably because qemu as a platform supports 800 different kinds of hosts, all with their own sound solutions, sometimes integrated "for ease" as part of the display library, sometimes split into a myriad of confusing and incompatible options, like on Linux. - Qemu images are not integrated into the rest of the desktop. If i click on a Qemu image it says: Could not display "/home/mingo/qemu/hda.img". The file is of an unknown type. 10 years of Qemu and its base image format is still 'unknown' ? This is a desktop distro issue and easily fixed. Please file a bug. - Random bugs. I tried to boot some old Fedora image i had around, it says: spirit:~/qemu> qemu-kvm ./hda-fedora.img kvm: unhandled exit 8021 kvm_run returned -22 Bugs happen, but more important is what a user can do with it. To a user, what does this tell? Is it actionable? Does it give any URL to check? Any bug submit mechanism to follow? Does it even tell what the code itself thinks that happened? Nope - it just prints that error message (on the console, so to anyone starting it via a clicky interface wouldnt notice that there's something wrong) - and the guest session hanging indefinitely. Qemu code is very bad in general at error handling. It will take years to fix this. - When it boots up, the Qemu window flips around its size crazily, as the BIOS, the bootloader and the OS sets different screen resolutions. To the user that technical detail is immaterial, what matters is an amateurish-looking app that flips its window size as if it was an adware popup window trying to avoid being caught. This is true again of other major brand name virtualization solutions. The window resizes as the guest resizes the display. There really isn't a better solution. - There's no obvious way to activate paravirt drivers on the Windows side. There's no friendly "install guest drivers" button to click on with Qemu. _Of course_ you will end up emulating hardware in KVM (and passing it through to the guest once it's clear that emulation per
Re: KVM usability
[ adding qemu-devel to CC as most issues concern that project as well ] Ingo Molnar wrote: > * Avi Kivity wrote: > >> On 02/26/2010 01:17 PM, Ingo Molnar wrote: >>> Nobody is really 'in charge' of how KVM gets delivered to the user. You >>> isolated the fun kernel part for you and pushed out the boring bits to >>> user-space. So if mundane things like mouse integration sucks 'hey that's a >>> user-space tooling problem', if file integration sucks then 'hey, that's an >>> admin problem', if it cannot be used over the network 'hey, that's an Xorg >>> problem', etc. etc. >> btw, mouse integration works with -usbdevice tablet and recent >> Fedoras, 'it was an X.org driver problem'. >> >> Really, I don't understand your problems. > > I run bleeding edge rawhide on my main desktop so i just tried latest & > greatest KVM and Qemu bits and started up kvm-qemu with some Fedora and XP > images i had around: > > 2.6.33-0.44.rc8.git0.fc13.x86_64 > qemu-system-x86-0.12.2-6.fc13.x86_64 > > Here's my experience with it: > > - qemu-kvm starts up with a miniature resolution by default. 640x480 - on my >1680x1050 laptop screen. It's so small that initially i even overlooked >that i started it. It should multiplex pixels up to a reasonable screen >size by default. > > - The mouse is trapped straight away by default if you click into it. That's >very annoying if you actually try to integrate a guest OS into your > desktop >- it's not just 'another, slightly weird app' but a sticky, opinionated > GUI >component that you have to fight with all the time. > > - Once trapped it's not obvious how to untrap the mouse. The qemu window >title says: > > QEMU: Press Ctrl-ALT to exit grab > >Of course once you _know_ what a 'grab' is, you'll know where to look. >At minimum it should say: > > QEMU: Press Ctrl-ALT to exit mouse grab > >But to first-time users it's an annoying trap of the mouse and with no >obvious place to look for help. [besides, it doesnt tell which Ctrl and >which ALT to use - it's the left side. The right side Ctrl does not work.] > > - Graphics performance is awful even with the 640x480 miniature version. >During bootup I can see it drawing single characters. This is a Core2 >2.8GHz. > > - Sound does not work by default. I have to go dig into command-line options >to see that i need to add: "-soundhw all". Why isnt sound enabled by >default? > > - Qemu images are not integrated into the rest of the desktop. If i click on >a Qemu image it says: > > Could not display "/home/mingo/qemu/hda.img". > > The file is of an unknown type. > >10 years of Qemu and its base image format is still 'unknown' ? > > - Random bugs. I tried to boot some old Fedora image i had around, it says: > > spirit:~/qemu> qemu-kvm ./hda-fedora.img > kvm: unhandled exit 8021 > kvm_run returned -22 > >Bugs happen, but more important is what a user can do with it. To a user, >what does this tell? Is it actionable? Does it give any URL to check? Any > bug >submit mechanism to follow? Does it even tell what the code itself thinks >that happened? Nope - it just prints that error message (on the console, > so >to anyone starting it via a clicky interface wouldnt notice that there's >something wrong) - and the guest session hanging indefinitely. > > - When it boots up, the Qemu window flips around its size crazily, as the > BIOS, >the bootloader and the OS sets different screen resolutions. To the user > that >technical detail is immaterial, what matters is an amateurish-looking app >that flips its window size as if it was an adware popup window trying to >avoid being caught. > > - There's no obvious way to activate paravirt drivers on the Windows side. >There's no friendly "install guest drivers" button to click on with Qemu. > >_Of course_ you will end up emulating hardware in KVM (and passing it > through >to the guest once it's clear that emulation performance sucks) and sooner >or later you will end up requesting unreasonable things of the host kernel >to achieve that ... > > - Another small detail: there is zero on-screen help (beyond the Ctrl-ALT >line) for a newbie to quickly find his way around it. No wiki address, no >help, no nothing. There's not even any hint about what this window does. >Which guest is it? In what state is that guest? > > - But i'm a more advanced user so i dont need help screens, i knew that the >"go full screen" hotkey is: > >LeftCtrl-LeftALT-F > >... except that it is a one-way road: pressing it for a second time does >not restore the window, trapping me in the guest altogether! Ctrl-ALT does >not exit the trap either. I had to shut down the guest to get back my X >desktop. > > etc., etc. > > ( I could go on and on about finer