* Re: Enhance perf to support KVM
[not found] ` <1267089644.12790.74.camel@laptop>
@ 2010-02-26 2:49 ` Zhang, Yanmin
2010-02-26 9:01 ` Ingo Molnar
0 siblings, 1 reply; 109+ messages in thread
From: Zhang, Yanmin @ 2010-02-26 2:49 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, ming.m.lin, sheng.yang, Jes Sorensen, KVM General,
Avi Kivity, Zachary Amsden, Gleb Natapov
On Thu, 2010-02-25 at 10:20 +0100, Peter Zijlstra wrote:
> On Thu, 2010-02-25 at 11:27 +0800, Zhang, Yanmin wrote:
> > Ingo,
> >
> > I did some testing with KVM virtualization. perf shows vmx_vcpu_run
> > consumes more than 50% cpu time. Actually, the info is incorrect because
> > when perf counter overflows and NMI is triggered, vm exit to function
> > vmx_vcpu_run, then vmx_vcpu_run triggers a software NMI so perf event is
> > notified. perf just checks regs which just saves the address of vmx_vcpu_run.
> >
> > I want to enhance perf to collect real guest os address.
> >
> > Below is the design.
> > KVM uses multi-thread model. Every guest os is a process of multi-thread.
> >
> > 1) Kernel:
> > Add a per_cpu var and some functions, so KVM records interrupted
> > guest os address before triggering the software NMI. perf event would check
> > the per_cpu var to use it if it's not zero, or just goes though the old path.
> >
> > 2) User space: Add a new parameter to perf-top and perf-report, such like
> > -g pid:guest_os_vmlinux_path. Command perf parses the guest os kernel image
> > to collect symbols. Change perf to summarize results based on pid.
> > Another direction is to use the new parameter -g only when old parameter
> > -p is defined. Perf just needs separate native kernel and guest os kernel.
>
I really appreciate your kind comments, and will contact you again in
the future for help.
> -g is already taken :-)
We could use other flag or just -G.
>
> One thing I worry about is making sense of the guest data, it might be
> possible to sorta make sense of the main kernel image, but after that
> its going to be 'interesting' in deed.
>
> You're going to have to extend PERF_RECORD_MISC_* though, perhaps you
> can reuse CPUMODE_UNKNOWN for GUEST.
>
> The callchain stuff already has GUEST context identifiers, however
> determining KERNEL/USER context might be hard and interpreting it is
> going to be harder still since we don't have map information for the
> guest.
Right. As for side #1 pointed in Ingo' email, we assume guest os is
linux. We couldn't support all capabilities of perf on KVM from host side.
1) We couldn't get module and process mapping info in guest os in an easy way,
so we can't support to collect guest kernel module and user space hot functions.
A work around is user could get guest os /proc/kallsym and pass it to tool perf
at host side so we could analyze module host functions.
2) We couldn't get guest os kernel/user stack data in an easy way, so we might not
support callchain feature of tool perf. A work around is KVM copies kernel stack
data out, so we could at least support guest os kernel callchain.
So the host side perf support on guest os:
perf kvm list
perf kvm record # records the first running guest
perf kvm stat # stats the first running KVM guest
perf kvm top # shows the profile of the first running
guest
perf kvm trace # active the KVM specific tracepoints
As for record, doesn't support to record guest os user space stack
callchain and guest os user space hot functions.
Yanmin
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 2:49 ` Enhance perf to support KVM Zhang, Yanmin
@ 2010-02-26 9:01 ` Ingo Molnar
2010-02-26 9:53 ` Avi Kivity
0 siblings, 1 reply; 109+ messages in thread
From: Ingo Molnar @ 2010-02-26 9:01 UTC (permalink / raw)
To: Zhang, Yanmin
Cc: Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Avi Kivity, Zachary Amsden, Gleb Natapov,
Arnaldo Carvalho de Melo,
=?unknown-8bit?B?RnLDqWTDqXJpYw==?= Weisbecker, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra, Arjan van de Ven
* Zhang, Yanmin <yanmin_zhang@linux.intel.com> wrote:
> 2) We couldn't get guest os kernel/user stack data in an easy way, so we
> might not support callchain feature of tool perf. A work around is KVM
> copies kernel stack data out, so we could at least support guest os kernel
> callchain.
If the guest is Linux, KVM can get all the info we need.
While the PMU event itself might trigger in an NMI (where we cannot access
most of KVM's data structures safely), for this specific case of KVM
instrumentation we can delay the processing to a more appropriate time - in
fact we can do it in the KVM thread itself.
We can do that because we just triggered a VM exit, so the VM state is for all
purposes frozen (as far as this virtual CPU goes).
Which egives us plenty of time and opportunity to piggy back to the KVM
thread, look up the guest stack, process/fill the MMU cache as we walk the
guest page tables, etc. etc.
It would need some minimal callback facility towards KVM, triggered by a perf
event PMI.
One additional step needed is to get symbol information from the guest, and to
integrate it into the symbol cache on the host side in ~/.debug. We already
support cross-arch symbols and 'perf archive', so the basic facilities are
there for that. So you can profile on 32-bit PA-RISC and type 'perf report' on
64-bit x86 and get all the right info.
For this to work across a guest, a gateway is needed towards the guest.
There's several ways to achieve this. The most practical would be two steps:
- a user-space facility to access guest images/libraries. (say via ssh, or
just a plain TCP port) This would be useful for general 'remote profiling'
sessions as well, so it's not KVM specific - it would be useful for remote
debugging.
- The guest /proc/kallsyms (and vmlinux) could be accessed via that channel
as well.
(Note that this is purely for guest symbol space access - all the profiling
data itself comes via the host kernel.)
In theory we could build some sort of 'symbol server' facility into the
kernel, which could be enabled in guest kernels too - but i suspect existing,
user-space transports go most of the way already. (the only disadvantage of
existing transports is that they all have to be configured, enabled and made
user-accessible, which is one of the few weak points of KVM in general.)
Thanks,
Ingo
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 9:01 ` Ingo Molnar
@ 2010-02-26 9:53 ` Avi Kivity
2010-02-26 10:35 ` Ingo Molnar
0 siblings, 1 reply; 109+ messages in thread
From: Avi Kivity @ 2010-02-26 9:53 UTC (permalink / raw)
To: Ingo Molnar
Cc: Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra,
Arjan van de Ven
On 02/26/2010 11:01 AM, Ingo Molnar wrote:
> * Zhang, Yanmin<yanmin_zhang@linux.intel.com> wrote:
>
>
>> 2) We couldn't get guest os kernel/user stack data in an easy way, so we
>> might not support callchain feature of tool perf. A work around is KVM
>> copies kernel stack data out, so we could at least support guest os kernel
>> callchain.
>>
> If the guest is Linux, KVM can get all the info we need.
>
> While the PMU event itself might trigger in an NMI (where we cannot access
> most of KVM's data structures safely), for this specific case of KVM
> instrumentation we can delay the processing to a more appropriate time - in
> fact we can do it in the KVM thread itself.
>
The nmi will be a synchronous event: it happens in guest context, and we
program the hardware to intercept nmis, so we just get an exit telling
us that an nmi has happened.
(would also be interesting to allow the guest to process the nmi
directly in some scenarios, though that would require that there be no
nmi sources on the host).
> We can do that because we just triggered a VM exit, so the VM state is for all
> purposes frozen (as far as this virtual CPU goes).
>
Yes.
> Which egives us plenty of time and opportunity to piggy back to the KVM
> thread, look up the guest stack, process/fill the MMU cache as we walk the
> guest page tables, etc. etc.
>
> It would need some minimal callback facility towards KVM, triggered by a perf
> event PMI.
>
Since the event is synchronous and kvm is aware of it we don't need a
callback; kvm can call directly into perf with all the information.
> One additional step needed is to get symbol information from the guest, and to
> integrate it into the symbol cache on the host side in ~/.debug. We already
> support cross-arch symbols and 'perf archive', so the basic facilities are
> there for that. So you can profile on 32-bit PA-RISC and type 'perf report' on
> 64-bit x86 and get all the right info.
>
> For this to work across a guest, a gateway is needed towards the guest.
> There's several ways to achieve this. The most practical would be two steps:
>
> - a user-space facility to access guest images/libraries. (say via ssh, or
> just a plain TCP port) This would be useful for general 'remote profiling'
> sessions as well, so it's not KVM specific - it would be useful for remote
> debugging.
>
> - The guest /proc/kallsyms (and vmlinux) could be accessed via that channel
> as well.
>
> (Note that this is purely for guest symbol space access - all the profiling
> data itself comes via the host kernel.)
>
> In theory we could build some sort of 'symbol server' facility into the
> kernel, which could be enabled in guest kernels too - but i suspect existing,
> user-space transports go most of the way already.
There is also vmchannel aka virtio-serial, a guest-to-host communication
channel.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 9:53 ` Avi Kivity
@ 2010-02-26 10:35 ` Ingo Molnar
2010-02-26 10:47 ` Avi Kivity
2010-02-26 20:17 ` Anthony Liguori
0 siblings, 2 replies; 109+ messages in thread
From: Ingo Molnar @ 2010-02-26 10:35 UTC (permalink / raw)
To: Avi Kivity
Cc: Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
* Avi Kivity <avi@redhat.com> wrote:
> On 02/26/2010 11:01 AM, Ingo Molnar wrote:
> >* Zhang, Yanmin<yanmin_zhang@linux.intel.com> wrote:
> >
> >>2) We couldn't get guest os kernel/user stack data in an easy way, so we
> >>might not support callchain feature of tool perf. A work around is KVM
> >>copies kernel stack data out, so we could at least support guest os kernel
> >>callchain.
> >If the guest is Linux, KVM can get all the info we need.
> >
> >While the PMU event itself might trigger in an NMI (where we cannot access
> >most of KVM's data structures safely), for this specific case of KVM
> >instrumentation we can delay the processing to a more appropriate time - in
> >fact we can do it in the KVM thread itself.
>
> The nmi will be a synchronous event: it happens in guest context,
> and we program the hardware to intercept nmis, so we just get an
> exit telling us that an nmi has happened.
>
> (would also be interesting to allow the guest to process the nmi
> directly in some scenarios, though that would require that there be
> no nmi sources on the host).
>
> >We can do that because we just triggered a VM exit, so the VM state is for all
> >purposes frozen (as far as this virtual CPU goes).
>
> Yes.
>
> >Which egives us plenty of time and opportunity to piggy back to the KVM
> >thread, look up the guest stack, process/fill the MMU cache as we walk the
> >guest page tables, etc. etc.
> >
> >It would need some minimal callback facility towards KVM, triggered by a perf
> >event PMI.
>
> Since the event is synchronous and kvm is aware of it we don't need
> a callback; kvm can call directly into perf with all the
> information.
Yes - it's still a "callback" in the abstract sense. Much of it already all
existing.
> >One additional step needed is to get symbol information from the guest, and to
> >integrate it into the symbol cache on the host side in ~/.debug. We already
> >support cross-arch symbols and 'perf archive', so the basic facilities are
> >there for that. So you can profile on 32-bit PA-RISC and type 'perf report' on
> >64-bit x86 and get all the right info.
> >
> >For this to work across a guest, a gateway is needed towards the guest.
> >There's several ways to achieve this. The most practical would be two steps:
> >
> > - a user-space facility to access guest images/libraries. (say via ssh, or
> > just a plain TCP port) This would be useful for general 'remote profiling'
> > sessions as well, so it's not KVM specific - it would be useful for remote
> > debugging.
> >
> > - The guest /proc/kallsyms (and vmlinux) could be accessed via that channel
> > as well.
> >
> >(Note that this is purely for guest symbol space access - all the profiling
> >data itself comes via the host kernel.)
> >
> >In theory we could build some sort of 'symbol server' facility into the
> >kernel, which could be enabled in guest kernels too - but i suspect existing,
> >user-space transports go most of the way already.
>
> There is also vmchannel aka virtio-serial, a guest-to-host communication
> channel.
Basically what is needed is plain filesystem access - properly privileged. So
doing this via a vmchannel would be nice, but for the symbol extraction it
would be a glorified NFS server in essence.
Do you have (or plan) any turn-key 'access to all files of the guest' kind of
guest-transparent facility that could be used for such purposes? That would
have various advantages over a traditional explicit file server approach:
- it would not contaminate the guest port space
- no guest side configuration needed (the various oprofile remote daemons
always sucked as they needed extra setup)
- it might even be used with a guest that does no networking
- if done fully in the kernel it could be done with a fully 'unaware' guest, etc.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 10:35 ` Ingo Molnar
@ 2010-02-26 10:47 ` Avi Kivity
2010-02-26 11:17 ` Ingo Molnar
2010-02-26 11:48 ` Enhance perf to support KVM Peter Zijlstra
2010-02-26 20:17 ` Anthony Liguori
1 sibling, 2 replies; 109+ messages in thread
From: Avi Kivity @ 2010-02-26 10:47 UTC (permalink / raw)
To: Ingo Molnar
Cc: Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
On 02/26/2010 12:35 PM, Ingo Molnar wrote:
>
>>> One additional step needed is to get symbol information from the guest, and to
>>> integrate it into the symbol cache on the host side in ~/.debug. We already
>>> support cross-arch symbols and 'perf archive', so the basic facilities are
>>> there for that. So you can profile on 32-bit PA-RISC and type 'perf report' on
>>> 64-bit x86 and get all the right info.
>>>
>>> For this to work across a guest, a gateway is needed towards the guest.
>>> There's several ways to achieve this. The most practical would be two steps:
>>>
>>> - a user-space facility to access guest images/libraries. (say via ssh, or
>>> just a plain TCP port) This would be useful for general 'remote profiling'
>>> sessions as well, so it's not KVM specific - it would be useful for remote
>>> debugging.
>>>
>>> - The guest /proc/kallsyms (and vmlinux) could be accessed via that channel
>>> as well.
>>>
>>> (Note that this is purely for guest symbol space access - all the profiling
>>> data itself comes via the host kernel.)
>>>
>>> In theory we could build some sort of 'symbol server' facility into the
>>> kernel, which could be enabled in guest kernels too - but i suspect existing,
>>> user-space transports go most of the way already.
>>>
>> There is also vmchannel aka virtio-serial, a guest-to-host communication
>> channel.
>>
> Basically what is needed is plain filesystem access - properly privileged. So
> doing this via a vmchannel would be nice, but for the symbol extraction it
> would be a glorified NFS server in essence.
>
Well, we could run an nfs server over vmchannel, or over a private
network interface.
> Do you have (or plan) any turn-key 'access to all files of the guest' kind of
> guest-transparent facility that could be used for such purposes?
Not really. The guest and host admins are usually different people, who
may, being admins, even actively hate each other. The guest admin would
probably regard it as a security hole. It's probably useful for the
single-host scenario, and of course for developers.
I guess sshfs can fill this role, with one command it gives you secure
access to all guest files, provided you have the proper credentials.
> That would
> have various advantages over a traditional explicit file server approach:
>
> - it would not contaminate the guest port space
>
> - no guest side configuration needed (the various oprofile remote daemons
> always sucked as they needed extra setup)
>
> - it might even be used with a guest that does no networking
>
> - if done fully in the kernel it could be done with a fully 'unaware' guest, etc.
>
Seems sshfs fulfils the first two. For the latter, we could do a
vmchannelfs, but it seems quite a bit of work, and would require fairly
new guest kernels, whereas sshfs would work out of the box on 10 year
old guests and can be easily made to work on Windows.
Somewhat related, see libguestfs/guestfish, though that provides offline
access only.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 10:47 ` Avi Kivity
@ 2010-02-26 11:17 ` Ingo Molnar
2010-02-26 11:44 ` Avi Kivity
2010-02-26 18:33 ` Avi Kivity
2010-02-26 11:48 ` Enhance perf to support KVM Peter Zijlstra
1 sibling, 2 replies; 109+ messages in thread
From: Ingo Molnar @ 2010-02-26 11:17 UTC (permalink / raw)
To: Avi Kivity
Cc: Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
* Avi Kivity <avi@redhat.com> wrote:
> > Do you have (or plan) any turn-key 'access to all files of the guest' kind
> > of guest-transparent facility that could be used for such purposes?
>
> Not really. The guest and host admins are usually different people, who
> may, being admins, even actively hate each other. The guest admin would
> probably regard it as a security hole. It's probably useful for the
> single-host scenario, and of course for developers.
Sounds like an exceedingly silly argument to me - the host admin is the king
in any case.
Your argument boils down to: 'dont offer transparent, turn-key solutions
because some might object to the functionality they offer for all the wrong
reasons'. Which does not withstand elementary scrutiny.
This is a basic usability issue, and affects many parts of the KVM universe.
Really, it's by far the most fubar-ed notion of KVM. You are pushing _way_ too
much to user-space into different modules and maintenance domains, and
user-space forks those bits, fragments, diverts, delays and messes up basic
features in the usual fashion.
The result is a basic out-of-box virtualization experience that sucks even
these days.
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.
You basically have given up control over the quality of KVM by pushing so many
aspects of it to user-space and letting it rot there.
Sure the design looks somewhat cleaner on paper, but if the end result is not
helped by it then over-modularization sure can hurt ...
( Note that i dont mind user-space tooling per se, as long as it sits together
with the kernel bits and gets developed, packaged and given to the user in
the same domain. )
And that's a key conceptual area were tools/perf/ differs: it's an integrated,
turn-key solution that you can really rely on. We take responsibility for the
full thing, no ifs and when. And if you cannot rely on your instrumentation
tooling as a single unit you cannot use it, simple as that. (that is a key
mistake Oprofile made a decade ago too btw.)
So i can see some upcoming culture friction with standing KVM principles there
;-)
Ingo
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 11:17 ` Ingo Molnar
@ 2010-02-26 11:44 ` Avi Kivity
2010-02-26 12:46 ` Ingo Molnar
2010-02-26 18:33 ` Avi Kivity
1 sibling, 1 reply; 109+ messages in thread
From: Avi Kivity @ 2010-02-26 11:44 UTC (permalink / raw)
To: Ingo Molnar
Cc: Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
On 02/26/2010 01:17 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com> wrote:
>
>
>>> Do you have (or plan) any turn-key 'access to all files of the guest' kind
>>> of guest-transparent facility that could be used for such purposes?
>>>
>> Not really. The guest and host admins are usually different people, who
>> may, being admins, even actively hate each other. The guest admin would
>> probably regard it as a security hole. It's probably useful for the
>> single-host scenario, and of course for developers.
>>
> Sounds like an exceedingly silly argument to me - the host admin is the king
> in any case.
>
> Your argument boils down to: 'dont offer transparent, turn-key solutions
> because some might object to the functionality they offer for all the wrong
> reasons'. Which does not withstand elementary scrutiny.
>
Again, the host admin and the guest admin are different people. What
would the host admin do with guest files? Why would the guest admin
want to run any code that exposes their files?
> This is a basic usability issue, and affects many parts of the KVM universe.
>
> Really, it's by far the most fubar-ed notion of KVM. You are pushing _way_ too
> much to user-space into different modules and maintenance domains, and
> user-space forks those bits, fragments, diverts, delays and messes up basic
> features in the usual fashion.
>
> The result is a basic out-of-box virtualization experience that sucks even
> these days.
>
> 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.
>
What would you have me do? Push 200K lines of device emulation code
into the kernel? Write an X client, toolkit, and display in the kernel
so that mouse integration works out of the box when you install Linux
2.6.653?
As to "nobody is in charge", that's really insulting to the people who
are in charge of the userspace components. Perhaps the problems that we
see are not the same problems that you see. It might be that direct
access to guest files from the host is only a pressing problem for you,
but nobody else. If there are features that you miss, post patches, if
you will deign to code for lowly user space.
> You basically have given up control over the quality of KVM by pushing so many
> aspects of it to user-space and letting it rot there.
>
That's wrong on so many levels. First, nothing is rotting in userspace,
qemu is evolving faster than kvm is. If I pushed it into the kernel
then development pace would be much slower (since kernel development is
harder), quality would be lower (less infrastructure, any bug is a host
crash or security issue), and I personally would be totally swamped.
> Sure the design looks somewhat cleaner on paper, but if the end result is not
> helped by it then over-modularization sure can hurt ...
>
Run 'rpm -qa' one of these days. Modern software is modular, that's the
only way to manage it.
> ( Note that i dont mind user-space tooling per se, as long as it sits together
> with the kernel bits and gets developed, packaged and given to the user in
> the same domain. )
>
Call me when glibc, the X servers and clients, and everything else qemu
now uses is developed, packaged, and given to the user in the same domain.
> And that's a key conceptual area were tools/perf/ differs: it's an integrated,
> turn-key solution that you can really rely on. We take responsibility for the
> full thing, no ifs and when. And if you cannot rely on your instrumentation
> tooling as a single unit you cannot use it, simple as that. (that is a key
> mistake Oprofile made a decade ago too btw.)
>
perf is a tool written by developers for developers. kvm is written for
users (most of them hidden behind management interfaces). There's no
point at all in shipping it as part of the kernel, users don't install
and use kernels, they install and use distributions.
> So i can see some upcoming culture friction with standing KVM principles there
> ;-)
>
No friction at all - I don't think any kvm developer agrees with you
(but if anyone does please speak up).
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 10:47 ` Avi Kivity
2010-02-26 11:17 ` Ingo Molnar
@ 2010-02-26 11:48 ` Peter Zijlstra
2010-02-26 11:53 ` Avi Kivity
1 sibling, 1 reply; 109+ messages in thread
From: Peter Zijlstra @ 2010-02-26 11:48 UTC (permalink / raw)
To: Avi Kivity
Cc: Ingo Molnar, Zhang, Yanmin, 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
On Fri, 2010-02-26 at 12:47 +0200, Avi Kivity wrote:
> Not really. The guest and host admins are usually different people, who
> may, being admins, even actively hate each other. The guest admin would
> probably regard it as a security hole. It's probably useful for the
> single-host scenario, and of course for developers.
LOL, let me be the malicious host admin, then you can be the guest,
there is no way you can protect yourself. If you don't trust the host,
don't use it.
All your IO flows through the host, all your sekrit keys are in memory,
there is no security.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 11:48 ` Enhance perf to support KVM Peter Zijlstra
@ 2010-02-26 11:53 ` Avi Kivity
0 siblings, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-02-26 11:53 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Ingo Molnar, Zhang, Yanmin, 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
On 02/26/2010 01:48 PM, Peter Zijlstra wrote:
> On Fri, 2010-02-26 at 12:47 +0200, Avi Kivity wrote:
>
>> Not really. The guest and host admins are usually different people, who
>> may, being admins, even actively hate each other. The guest admin would
>> probably regard it as a security hole. It's probably useful for the
>> single-host scenario, and of course for developers.
>>
> LOL, let me be the malicious host admin, then you can be the guest,
> there is no way you can protect yourself. If you don't trust the host,
> don't use it.
>
> All your IO flows through the host, all your sekrit keys are in memory,
> there is no security.
>
That's true. But guest admins are going to be unhappy about a file
server serving their data to the host all the same.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 11:44 ` Avi Kivity
@ 2010-02-26 12:46 ` Ingo Molnar
2010-02-26 12:54 ` Avi Kivity
0 siblings, 1 reply; 109+ messages in thread
From: Ingo Molnar @ 2010-02-26 12:46 UTC (permalink / raw)
To: Avi Kivity
Cc: Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
* Avi Kivity <avi@redhat.com> wrote:
> > You basically have given up control over the quality of KVM by pushing so
> > many aspects of it to user-space and letting it rot there.
>
> That's wrong on so many levels. First, nothing is rotting in userspace,
> qemu is evolving faster than kvm is. If I pushed it into the kernel then
> development pace would be much slower (since kernel development is harder),
> quality would be lower (less infrastructure, any bug is a host crash or
> security issue), and I personally would be totally swamped.
That was not what i suggested tho. tools/kvm/ would work plenty fine.
As i said:
> > [...] You are pushing _way_ too much to user-space into different modules
> > and maintenance domains, [...]
> >
> > ( Note that i dont mind user-space tooling per se, as long as it sits together
> > with the kernel bits and gets developed, packaged and given to the user
> > in the same domain. ) [...]
> > Sure the design looks somewhat cleaner on paper, but if the end result is
> > not helped by it then over-modularization sure can hurt ...
>
> Run 'rpm -qa' one of these days. Modern software is modular, that's the
> only way to manage it.
Of course rpm -qa shows cases where modularization works. But my point was
over-modularization, which due to the KVM/qemu split we all suffer from.
Modularizing along the wrong interface is worse than not modularizing
something that could be. So when designing software you generally want to err
on the side of _under_-modularizing. It's always very easy to split stuff up,
when there's a really strong technical argument for it. It's very hard to pull
the broken pieces back together though once they are in difference domains of
maintanence - as then it's usually social integration that has to happen,
which is always harder than a technical split-up.
Ingo
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 12:46 ` Ingo Molnar
@ 2010-02-26 12:54 ` Avi Kivity
2010-02-26 13:16 ` Ingo Molnar
0 siblings, 1 reply; 109+ messages in thread
From: Avi Kivity @ 2010-02-26 12:54 UTC (permalink / raw)
To: Ingo Molnar
Cc: Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
On 02/26/2010 02:46 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com> wrote:
>
>
>>> You basically have given up control over the quality of KVM by pushing so
>>> many aspects of it to user-space and letting it rot there.
>>>
>> That's wrong on so many levels. First, nothing is rotting in userspace,
>> qemu is evolving faster than kvm is. If I pushed it into the kernel then
>> development pace would be much slower (since kernel development is harder),
>> quality would be lower (less infrastructure, any bug is a host crash or
>> security issue), and I personally would be totally swamped.
>>
> That was not what i suggested tho. tools/kvm/ would work plenty fine.
>
I'll wait until we have tools/libc and tools/X. After all, they affect
a lot more people and are concerned with a lot more kernel/user
interfaces than kvm.
> As i said:
>
>
>>> [...] You are pushing _way_ too much to user-space into different modules
>>> and maintenance domains, [...]
>>>
>>> ( Note that i dont mind user-space tooling per se, as long as it sits together
>>> with the kernel bits and gets developed, packaged and given to the user
>>> in the same domain. ) [...]
>>>
>
>
>>> Sure the design looks somewhat cleaner on paper, but if the end result is
>>> not helped by it then over-modularization sure can hurt ...
>>>
>> Run 'rpm -qa' one of these days. Modern software is modular, that's the
>> only way to manage it.
>>
> Of course rpm -qa shows cases where modularization works. But my point was
> over-modularization, which due to the KVM/qemu split we all suffer from.
>
You're the only one who suffers from it. Everyone else is happy with
adding features in the modules that implements them, be it kvm, qemu,
libvirt, or virt-manager (to name one tool stack out of several).
> Modularizing along the wrong interface is worse than not modularizing
> something that could be. So when designing software you generally want to err
> on the side of _under_-modularizing. It's always very easy to split stuff up,
> when there's a really strong technical argument for it. It's very hard to pull
> the broken pieces back together though once they are in difference domains of
> maintanence - as then it's usually social integration that has to happen,
> which is always harder than a technical split-up.
>
As it happens, the kvm and qemu development community has a large
overlap. Many developers read both lists, contribute to both projects,
and participate on the same weekly call. While we had difficulties
pushing patches to qemu in the past, that's behind us, and qemu is now
accepting patches at a much higher rate than kvm.
Technically, it is obvious that the userspace and kernel components are
separate projects. All that remains is the social divide. Since
everyone (except you) is mostly happy, I see no reason to change.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 12:54 ` Avi Kivity
@ 2010-02-26 13:16 ` Ingo Molnar
2010-02-26 13:57 ` Jes Sorensen
2010-02-26 14:04 ` Avi Kivity
0 siblings, 2 replies; 109+ messages in thread
From: Ingo Molnar @ 2010-02-26 13:16 UTC (permalink / raw)
To: Avi Kivity
Cc: Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
* Avi Kivity <avi@redhat.com> wrote:
> > That was not what i suggested tho. tools/kvm/ would work plenty fine.
>
> I'll wait until we have tools/libc and tools/X. After all, they affect a
> lot more people and are concerned with a lot more kernel/user interfaces
> than kvm.
So your answer can be summed up as: 'we wont do what makes sense technically
because others suck even more' ?
And it's not just the kernel<->user interface (which btw., for the case of X
is far narrower than what KVM currently has to Qemu).
The issue is a basic question of software design: does kvm-qemu really make as
much sense without the kernel component as with it? The answer is: it will
borderline-work with CPU emulation (and i'm sure there are people making use
of it that way), but 90%+ of the userbase uses it with KVM and vice versa. It
is really a single logical component as far as maintenance goes, and
tools/kvm/ would make quite a bit of sense.
But i digress.
Ingo
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 13:16 ` Ingo Molnar
@ 2010-02-26 13:57 ` Jes Sorensen
2010-02-26 14:04 ` Avi Kivity
1 sibling, 0 replies; 109+ messages in thread
From: Jes Sorensen @ 2010-02-26 13:57 UTC (permalink / raw)
To: Ingo Molnar
Cc: Avi Kivity, Zhang, Yanmin, Peter Zijlstra, ming.m.lin,
sheng.yang, KVM General, Zachary Amsden, Gleb Natapov,
Arnaldo Carvalho de Melo, Fr??d??ric Weisbecker, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra, Arjan van de Ven
On 02/26/10 14:16, Ingo Molnar wrote:
>
> * Avi Kivity<avi@redhat.com> wrote:
>
>>> That was not what i suggested tho. tools/kvm/ would work plenty fine.
>>
>> I'll wait until we have tools/libc and tools/X. After all, they affect a
>> lot more people and are concerned with a lot more kernel/user interfaces
>> than kvm.
>
> So your answer can be summed up as: 'we wont do what makes sense technically
> because others suck even more' ?
Well in this discussion what makes sense technically differs depending
on who you ask.
I will argue that emulating the MSR access doesn't make sense
technically because there is no fixed specification we can rely on,
since the spec seems to change randomly with every cpu family release
from Inte. In addition the overhead is making the resulting numbers
less if at all interesting.
Jes
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 13:16 ` Ingo Molnar
2010-02-26 13:57 ` Jes Sorensen
@ 2010-02-26 14:04 ` Avi Kivity
2010-02-26 14:23 ` Ingo Molnar
1 sibling, 1 reply; 109+ messages in thread
From: Avi Kivity @ 2010-02-26 14:04 UTC (permalink / raw)
To: Ingo Molnar
Cc: Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
On 02/26/2010 03:16 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com> wrote:
>
>
>>> That was not what i suggested tho. tools/kvm/ would work plenty fine.
>>>
>> I'll wait until we have tools/libc and tools/X. After all, they affect a
>> lot more people and are concerned with a lot more kernel/user interfaces
>> than kvm.
>>
> So your answer can be summed up as: 'we wont do what makes sense technically
> because others suck even more' ?
>
I can sum up your this remark as 'whenever you disagree with me, I will
rephrase your words to make you look like an idiot'.
If you believe I'm an idiot, there's no need to have this (or any)
conversation. If not, please refrain from this type of verbal gymnastics.
> And it's not just the kernel<->user interface (which btw., for the case of X
> is far narrower than what KVM currently has to Qemu).
>
> The issue is a basic question of software design: does kvm-qemu really make as
> much sense without the kernel component as with it? The answer is: it will
> borderline-work with CPU emulation (and i'm sure there are people making use
> of it that way), but 90%+ of the userbase uses it with KVM and vice versa. It
> is really a single logical component as far as maintenance goes, and
> tools/kvm/ would make quite a bit of sense.
>
There are two separate questions. Is there room for a kvm-only
userspace component? I believe so, but throwing away the momentum
behind qemu would be foolish.
Does it make sense for such a component to live in linux.git? IMO, no,
and certainly a lot less than libc and X.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 14:04 ` Avi Kivity
@ 2010-02-26 14:23 ` Ingo Molnar
2010-02-26 15:06 ` Avi Kivity
2010-03-02 16:46 ` Paolo Bonzini
0 siblings, 2 replies; 109+ messages in thread
From: Ingo Molnar @ 2010-02-26 14:23 UTC (permalink / raw)
To: Avi Kivity
Cc: Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
* Avi Kivity <avi@redhat.com> wrote:
> On 02/26/2010 03:16 PM, Ingo Molnar wrote:
> >* Avi Kivity<avi@redhat.com> wrote:
> >
> >>> That was not what i suggested tho. tools/kvm/ would work plenty fine.
> >>>
> >> I'll wait until we have tools/libc and tools/X. After all, they affect a
> >> lot more people and are concerned with a lot more kernel/user interfaces
> >> than kvm.
> >
> > So your answer can be summed up as: 'we wont do what makes sense
> > technically because others suck even more' ?
>
> I can sum up your this remark as 'whenever you disagree with me, I will
> rephrase your words to make you look like an idiot'.
Two points:
1)
You can try to ridicule me if you want, but do you actually claim that my
summary is inaccurate?
I do claim it's a substantially accurate summary: you said you will (quote:)
"wait with tools/kvm/ until we have tools/libc and tools/X".
I do think tools/X and tools/libc would make quite a bit of sense - this is
one of the better design aspects of FreeBSD et al. It's a mistake that it's
not being done.
2)
I used a question mark (the sentence was not a statement of fact), and you
have no obligation to agree with the summary i provided.
Ingo
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 14:23 ` Ingo Molnar
@ 2010-02-26 15:06 ` Avi Kivity
2010-03-02 16:46 ` Paolo Bonzini
1 sibling, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-02-26 15:06 UTC (permalink / raw)
To: Ingo Molnar
Cc: Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
On 02/26/2010 04:23 PM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com> wrote:
>
>
>> On 02/26/2010 03:16 PM, Ingo Molnar wrote:
>>
>>> * Avi Kivity<avi@redhat.com> wrote:
>>>
>>>
>>>>> That was not what i suggested tho. tools/kvm/ would work plenty fine.
>>>>>
>>>>>
>>>> I'll wait until we have tools/libc and tools/X. After all, they affect a
>>>> lot more people and are concerned with a lot more kernel/user interfaces
>>>> than kvm.
>>>>
>>> So your answer can be summed up as: 'we wont do what makes sense
>>> technically because others suck even more' ?
>>>
>> I can sum up your this remark as 'whenever you disagree with me, I will
>> rephrase your words to make you look like an idiot'.
>>
> Two points:
>
> 1)
>
> You can try to ridicule me if you want,
I'd much prefer it if if no ridiculing was employed on either side.
> but do you actually claim that my
> summary is inaccurate?
>
> I do claim it's a substantially accurate summary: you said you will (quote:)
> "wait with tools/kvm/ until we have tools/libc and tools/X".
>
> I do think tools/X and tools/libc would make quite a bit of sense - this is
> one of the better design aspects of FreeBSD et al. It's a mistake that it's
> not being done.
>
There are arguments for libc to be developed in linux-2.6.git, and
arguments against. The fact is that they are not, so presumably the
arguments against plus inertia outweigh the arguments for.
The same logic holds for kvm, except that there are less arguments for
development in linux-2.6.git. Only a small part of qemu is actually
concerned with kvm; most of it is mucking around with X, emulating old
devices, emulating instruction sets (irrelevant for tools/kvm) and doing
boring managementy stuff.
Do we really want to add several hundered thousand lines to Linux, only
a few thousand or of which talk to the kernel?
> 2)
>
> I used a question mark (the sentence was not a statement of fact), and you
> have no obligation to agree with the summary i provided.
>
>
Thanks. I hope you don't agree with it either.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 11:17 ` Ingo Molnar
2010-02-26 11:44 ` Avi Kivity
@ 2010-02-26 18:33 ` Avi Kivity
2010-02-27 10:56 ` KVM usability Ingo Molnar
1 sibling, 1 reply; 109+ messages in thread
From: Avi Kivity @ 2010-02-26 18:33 UTC (permalink / raw)
To: Ingo Molnar
Cc: Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
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.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 10:35 ` Ingo Molnar
2010-02-26 10:47 ` Avi Kivity
@ 2010-02-26 20:17 ` Anthony Liguori
1 sibling, 0 replies; 109+ messages in thread
From: Anthony Liguori @ 2010-02-26 20:17 UTC (permalink / raw)
To: Ingo Molnar
Cc: Avi Kivity, Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra,
Arjan van de Ven
On 02/26/2010 04:35 AM, Ingo Molnar wrote:
> Basically what is needed is plain filesystem access - properly privileged. So
> doing this via a vmchannel would be nice, but for the symbol extraction it
> would be a glorified NFS server in essence.
>
> Do you have (or plan) any turn-key 'access to all files of the guest' kind of
> guest-transparent facility that could be used for such purposes? That would
> have various advantages over a traditional explicit file server approach:
>
> - it would not contaminate the guest port space
>
> - no guest side configuration needed (the various oprofile remote daemons
> always sucked as they needed extra setup)
>
> - it might even be used with a guest that does no networking
>
If you look at VMware, they provide a guest daemon that runs in
userspace and communicates with the host to allow the host to do
operations like execute a binary or read a file.
We've been trying to build this for years and virtio-console is what
we've finally settled on. The userspace bits are super easy to build.
The problem is that we need guest kernel support. We've not had a lot
of success there as we've had a number of things Nacked. The approach
we originally started with was to introduce a new socket family for
virtualization. This is what s390 does and this is what VMware does.
But Dave Miller nacked that. VMware happily carries their own module so
they don't have to deal with problems like this. I guess s390 was able
to get away with it because noone pays attention to what they do.
Rusty had a proposal very similar to vhost-net that he posted two years
ago but Andrew Morton nacked that because it wasn't generic enough
(serves us right for trying to do anything generic in the first place).
Honestly, what's hardest for us to build a turn key solution is that
unlike our competition, we've got to deal with getting people who don't
necessarily care about virtualization to agree with what we're doing as
opposed to just maintaining our own set of kernel modules.
Things limited to userspace have not slowed us down compared to getting
things into the kernel. Look at how difficult it was to get MMU
notifiers merged as another example.
If you're volunteering to commit the things that we need to build a turn
key solution, then that would certainly be a big help to us.
Regards,
Anthony Liguori
^ permalink raw reply [flat|nested] 109+ messages in thread
* KVM usability
2010-02-26 18:33 ` Avi Kivity
@ 2010-02-27 10:56 ` Ingo Molnar
2010-02-27 13:30 ` [Qemu-devel] " Jan Kiszka
` (4 more replies)
0 siblings, 5 replies; 109+ messages in thread
From: Ingo Molnar @ 2010-02-27 10:56 UTC (permalink / raw)
To: Avi Kivity, Anthony Liguori
Cc: Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
* Avi Kivity <avi@redhat.com> 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 80000021
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 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. )
etc - but that's not the point really: i only spent 10 minutes on this and i
didnt try hard at all - _11_ bugs/annoyances from all across the functionality
spectrum.
And the thing is _me_ reporting bugs does not matter at all in this picture,
so please dont come with "why didnt you report this?".
_Anyone_ with half a brain who takes a critical look at this virtualization
solution would notice the same. Still, it's essentially unchanged from 5 years
ago.
Why is that so? I have outlined my opinion that this is due to the artificial
package separation / over-modularization and no-one really being in charge of
"KVM quality as a whole" - and i'm wondering what your theory is how such a
state of affairs became possible.
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?
And AFAICS KVM developers keep concentrating on all the wrong things due to
that bad split/packaging: writing newer and newer low level kernel patches and
optimizations which are nice but in large part irrelevant because the
_fundamental basics_ of usability suck so much ... But to you it's probably
just another external package so not really something you can do much about,
right?
Really, the KVM design is so nice in many regards and Qemu has come forward
leaps and bounds in the past few years as well, how can you miss such basic
areas of weakness? 'First impression' is the thing that gives you new
developers - it's any OSS project's bread and butter.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-02-27 10:56 ` KVM usability Ingo Molnar
@ 2010-02-27 13:30 ` Jan Kiszka
2010-02-27 14:48 ` Ian Kirk
` (3 subsequent siblings)
4 siblings, 0 replies; 109+ messages in thread
From: Jan Kiszka @ 2010-02-27 13:30 UTC (permalink / raw)
To: Ingo Molnar
Cc: Avi Kivity, Anthony Liguori, Zhang, Yanmin, Peter Zijlstra,
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,
Peter Zijlstra, Arjan van de Ven, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 8577 bytes --]
[ adding qemu-devel to CC as most issues concern that project as well ]
Ingo Molnar wrote:
> * Avi Kivity <avi@redhat.com> 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 80000021
> 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 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. )
>
> etc - but that's not the point really: i only spent 10 minutes on this and i
> didnt try hard at all - _11_ bugs/annoyances from all across the functionality
> spectrum.
>
> And the thing is _me_ reporting bugs does not matter at all in this picture,
> so please dont come with "why didnt you report this?".
>
> _Anyone_ with half a brain who takes a critical look at this virtualization
> solution would notice the same. Still, it's essentially unchanged from 5 years
> ago.
>
> Why is that so? I have outlined my opinion that this is due to the artificial
> package separation / over-modularization and no-one really being in charge of
> "KVM quality as a whole" - and i'm wondering what your theory is how such a
> state of affairs became possible.
>
> 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?
>
> And AFAICS KVM developers keep concentrating on all the wrong things due to
> that bad split/packaging: writing newer and newer low level kernel patches and
> optimizations which are nice but in large part irrelevant because the
> _fundamental basics_ of usability suck so much ... But to you it's probably
> just another external package so not really something you can do much about,
> right?
Yes, there are quite a few frontends around, also for desktop
virtualization. AQEMU [1], e.g., should address at least some of your
valuable usability criticisms. If GUIs are not yet optimally integrated
with QEMU and if there is something that can be done inside QEMU or even
KVM, let's discuss that together with the related communities. However,
that is definitely not a valid reason for KVM developers to stop
improving the virtualization core for demanding use cases and start
writing GUIs.
Likely it is unfortunate that there is not The One And Only graphical
frontend for the desktop scenario we can focus on (But is it unfortunate
for desktop Linux that there is still Gnome vs. KDE? I bet there are
zillion opinions on that.). But maybe this discussion here will have the
positive effect that the QEMU/KVM community starts giving more feedback
to some of those projects, and vice versa.
>
> Really, the KVM design is so nice in many regards and Qemu has come forward
> leaps and bounds in the past few years as well, how can you miss such basic
> areas of weakness? 'First impression' is the thing that gives you new
> developers - it's any OSS project's bread and butter.
'First impression' mostly gives us more users - a worthwhile goal as well!
But developers are rather attracted by rich features, a flexible,
extensible design, a working community and - of course - a proper
licensing model. Look at Virtualbox, they probably meet your usability
requirements out of the box. Do they have a developer community? Not at
all because they miss some of that key requirements. Also for those
reasons, Vbox dropped from the list of candidates for many
virtualization projects @work, and we decided to invest in the true
Linux stack.
Jan
[1] http://sourceforge.net/projects/aqemu/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
^ permalink raw reply [flat|nested] 109+ messages in thread
* [Qemu-devel] Re: KVM usability
@ 2010-02-27 13:30 ` Jan Kiszka
0 siblings, 0 replies; 109+ messages in thread
From: Jan Kiszka @ 2010-02-27 13:30 UTC (permalink / raw)
To: Ingo Molnar
Cc: Zhang, Yanmin, H. Peter Anvin, KVM General, ming.m.lin,
Peter Zijlstra, sheng.yang, Zachary Amsden, qemu-devel,
Gleb Natapov, Arnaldo Carvalho de Melo, Avi Kivity, Jes Sorensen,
Thomas Gleixner, Arjan van de Ven, Fr??d??ric Weisbecker,
Peter Zijlstra
[-- Attachment #1: Type: text/plain, Size: 8577 bytes --]
[ adding qemu-devel to CC as most issues concern that project as well ]
Ingo Molnar wrote:
> * Avi Kivity <avi@redhat.com> 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 80000021
> 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 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. )
>
> etc - but that's not the point really: i only spent 10 minutes on this and i
> didnt try hard at all - _11_ bugs/annoyances from all across the functionality
> spectrum.
>
> And the thing is _me_ reporting bugs does not matter at all in this picture,
> so please dont come with "why didnt you report this?".
>
> _Anyone_ with half a brain who takes a critical look at this virtualization
> solution would notice the same. Still, it's essentially unchanged from 5 years
> ago.
>
> Why is that so? I have outlined my opinion that this is due to the artificial
> package separation / over-modularization and no-one really being in charge of
> "KVM quality as a whole" - and i'm wondering what your theory is how such a
> state of affairs became possible.
>
> 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?
>
> And AFAICS KVM developers keep concentrating on all the wrong things due to
> that bad split/packaging: writing newer and newer low level kernel patches and
> optimizations which are nice but in large part irrelevant because the
> _fundamental basics_ of usability suck so much ... But to you it's probably
> just another external package so not really something you can do much about,
> right?
Yes, there are quite a few frontends around, also for desktop
virtualization. AQEMU [1], e.g., should address at least some of your
valuable usability criticisms. If GUIs are not yet optimally integrated
with QEMU and if there is something that can be done inside QEMU or even
KVM, let's discuss that together with the related communities. However,
that is definitely not a valid reason for KVM developers to stop
improving the virtualization core for demanding use cases and start
writing GUIs.
Likely it is unfortunate that there is not The One And Only graphical
frontend for the desktop scenario we can focus on (But is it unfortunate
for desktop Linux that there is still Gnome vs. KDE? I bet there are
zillion opinions on that.). But maybe this discussion here will have the
positive effect that the QEMU/KVM community starts giving more feedback
to some of those projects, and vice versa.
>
> Really, the KVM design is so nice in many regards and Qemu has come forward
> leaps and bounds in the past few years as well, how can you miss such basic
> areas of weakness? 'First impression' is the thing that gives you new
> developers - it's any OSS project's bread and butter.
'First impression' mostly gives us more users - a worthwhile goal as well!
But developers are rather attracted by rich features, a flexible,
extensible design, a working community and - of course - a proper
licensing model. Look at Virtualbox, they probably meet your usability
requirements out of the box. Do they have a developer community? Not at
all because they miss some of that key requirements. Also for those
reasons, Vbox dropped from the list of candidates for many
virtualization projects @work, and we decided to invest in the true
Linux stack.
Jan
[1] http://sourceforge.net/projects/aqemu/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-02-27 10:56 ` KVM usability Ingo Molnar
2010-02-27 13:30 ` [Qemu-devel] " Jan Kiszka
@ 2010-02-27 14:48 ` Ian Kirk
2010-02-27 15:32 ` Zachary Amsden
` (2 subsequent siblings)
4 siblings, 0 replies; 109+ messages in thread
From: Ian Kirk @ 2010-02-27 14:48 UTC (permalink / raw)
To: Ingo Molnar
Cc: Avi Kivity, Anthony Liguori, Zhang, Yanmin, Peter Zijlstra,
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,
Peter Zijlstra, Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-02-27 10:56 ` KVM usability Ingo Molnar
2010-02-27 13:30 ` [Qemu-devel] " Jan Kiszka
2010-02-27 14:48 ` Ian Kirk
@ 2010-02-27 15:32 ` Zachary Amsden
2010-02-27 17:25 ` Ingo Molnar
2010-03-01 9:25 ` Ingo Molnar
2010-03-01 15:14 ` Anthony Liguori
2010-03-01 21:12 ` Dustin Kirkland
4 siblings, 2 replies; 109+ messages in thread
From: Zachary Amsden @ 2010-02-27 15:32 UTC (permalink / raw)
To: Ingo Molnar
Cc: Avi Kivity, Anthony Liguori, Zhang, Yanmin, Peter Zijlstra,
ming.m.lin, sheng.yang, Jes Sorensen, KVM General, Gleb Natapov,
Arnaldo Carvalho de Melo, Fr??d??ric Weisbecker, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra, Arjan van de Ven
On 02/27/2010 12:56 AM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com> 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 80000021
> 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 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?
>
These are productized refinements we should look at implementing.
> - 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 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. )
>
> etc - but that's not the point really: i only spent 10 minutes on this and i
> didnt try hard at all - _11_ bugs/annoyances from all across the functionality
> spectrum.
>
> And the thing is _me_ reporting bugs does not matter at all in this picture,
> so please dont come with "why didnt you report this?".
>
> _Anyone_ with half a brain who takes a critical look at this virtualization
> solution would notice the same. Still, it's essentially unchanged from 5 years
> ago.
>
> Why is that so? I have outlined my opinion that this is due to the artificial
> package separation / over-modularization and no-one really being in charge of
> "KVM quality as a whole" - and i'm wondering what your theory is how such a
> state of affairs became possible.
>
This is really packed with a bunch of loaded statements.
First of all, the package separation is not artificial, it is a natural
consequence of the architecture. There is a CPU, it manipulates and is
tightly integrated with memory, and there are devices which are part of
the chipset, and so on.
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.
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.
Zach
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-02-27 15:32 ` Zachary Amsden
@ 2010-02-27 17:25 ` Ingo Molnar
2010-03-01 15:33 ` Anthony Liguori
` (2 more replies)
2010-03-01 9:25 ` Ingo Molnar
1 sibling, 3 replies; 109+ messages in thread
From: Ingo Molnar @ 2010-02-27 17:25 UTC (permalink / raw)
To: Zachary Amsden
Cc: Avi Kivity, Anthony Liguori, Zhang, Yanmin, Peter Zijlstra,
ming.m.lin, sheng.yang, Jes Sorensen, KVM General, Gleb Natapov,
Arnaldo Carvalho de Melo, Fr??d??ric Weisbecker, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra, Arjan van de Ven
* Zachary Amsden <zamsden@redhat.com> 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-02-27 15:32 ` Zachary Amsden
2010-02-27 17:25 ` Ingo Molnar
@ 2010-03-01 9:25 ` Ingo Molnar
2010-03-01 15:36 ` Anthony Liguori
1 sibling, 1 reply; 109+ messages in thread
From: Ingo Molnar @ 2010-03-01 9:25 UTC (permalink / raw)
To: Zachary Amsden
Cc: Avi Kivity, Anthony Liguori, Zhang, Yanmin, Peter Zijlstra,
ming.m.lin, sheng.yang, Jes Sorensen, KVM General, Gleb Natapov,
Arnaldo Carvalho de Melo, Fr??d??ric Weisbecker, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra, Arjan van de Ven
* Zachary Amsden <zamsden@redhat.com> 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-02-27 10:56 ` KVM usability Ingo Molnar
` (2 preceding siblings ...)
2010-02-27 15:32 ` Zachary Amsden
@ 2010-03-01 15:14 ` Anthony Liguori
2010-03-01 15:42 ` Daniel P. Berrange
` (3 more replies)
2010-03-01 21:12 ` Dustin Kirkland
4 siblings, 4 replies; 109+ messages in thread
From: Anthony Liguori @ 2010-03-01 15:14 UTC (permalink / raw)
To: Ingo Molnar
Cc: Avi Kivity, Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra,
Arjan van de Ven, Cole Robinson
On 02/27/2010 04:56 AM, Ingo Molnar wrote:
> * Avi Kivity<avi@redhat.com> 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:
anthony@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 80000021
> 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 is done. This is as much a usability issue on bare metal as it
is in a VM.
> - 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 ...
>
This is a licensing issue. You cannot just build Windows drivers
anymore. They need to be signed by Microsoft in order to be loadable in
the most recent versions of Windows. If you look at the recent Fedora
Advisory Board minutes, you'll see that this issue has been discussed
specifically around how a distribution like Fedora can provide Windows
drivers to end users in a friendly way.
I believe the current proposal is to host a signed binary on a site like
Fedora Hosted, and then have virt-manager automatically download the ISO
on demand. Shipping the binary ISO as part of a distribution package
though is not possible since it cannot be rebuilt like any other package.
> - 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?
>
This is a valid criticism but is tied to the fact that we use SDL.
> - 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.
> etc., etc.
>
> ( 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. )
>
> etc - but that's not the point really: i only spent 10 minutes on this and i
> didnt try hard at all - _11_ bugs/annoyances from all across the functionality
> spectrum.
>
> And the thing is _me_ reporting bugs does not matter at all in this picture,
> so please dont come with "why didnt you report this?".
>
> _Anyone_ with half a brain who takes a critical look at this virtualization
> solution would notice the same. Still, it's essentially unchanged from 5 years
> ago.
>
> Why is that so? I have outlined my opinion that this is due to the artificial
> package separation / over-modularization and no-one really being in charge of
> "KVM quality as a whole" - and i'm wondering what your theory is how such a
> state of affairs became possible.
>
> 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?
>
> And AFAICS KVM developers keep concentrating on all the wrong things due to
> that bad split/packaging: writing newer and newer low level kernel patches and
> optimizations which are nice but in large part irrelevant because the
> _fundamental basics_ of usability suck so much ... But to you it's probably
> just another external package so not really something you can do much about,
> right?
>
> Really, the KVM design is so nice in many regards and Qemu has come forward
> leaps and bounds in the past few years as well, how can you miss such basic
> areas of weakness? 'First impression' is the thing that gives you new
> developers - it's any OSS project's bread and butter.
>
Ultimately, the problem you're facing is choice. It's the same problem
that faces a lot of other open source projects.
Your expectation of QEMU/KVM is that the graphics experience is
optimized for a casual desktop virtualization user. That is not the
goal of QEMU/KVM though. That is the goal of virt-manager. The real
question to ask is, why are you using qemu directly instead of using
virt-manager?
Qemu targets two types of users. The first is third party management
interfaces. Qemu can be used for a lot of purposes beyond desktop
virtualization. Most cell phone SDKs use qemu arm emulation. The
interface for a cell phone SDK is obviously very different from the
interface for desktop virtualization. Taking the gui out of qemu lets
us support both.
It makes very little sense to integrate a powerful gui directly into
qemu because in many circumstances, the qemu instance that you are
interacting with is on a completely different box. This is where
something like virt-manager comes into play because you can just as
easily manage a remote instance of qemu as a local one.
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.
Regards,
Anthony Liguori
> Thanks,
>
> Ingo
>
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-02-27 17:25 ` Ingo Molnar
@ 2010-03-01 15:33 ` Anthony Liguori
2010-03-01 16:48 ` Zachary Amsden
2010-03-07 18:25 ` Avi Kivity
2 siblings, 0 replies; 109+ messages in thread
From: Anthony Liguori @ 2010-03-01 15:33 UTC (permalink / raw)
To: Ingo Molnar
Cc: Zachary Amsden, Avi Kivity, Zhang, Yanmin, Peter Zijlstra,
ming.m.lin, sheng.yang, Jes Sorensen, KVM General, Gleb Natapov,
Arnaldo Carvalho de Melo, Fr??d??ric Weisbecker, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra, Arjan van de Ven
On 02/27/2010 11:25 AM, Ingo Molnar wrote:
> * Zachary Amsden<zamsden@redhat.com> 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 9:25 ` Ingo Molnar
@ 2010-03-01 15:36 ` Anthony Liguori
0 siblings, 0 replies; 109+ messages in thread
From: Anthony Liguori @ 2010-03-01 15:36 UTC (permalink / raw)
To: Ingo Molnar
Cc: Zachary Amsden, Avi Kivity, Zhang, Yanmin, Peter Zijlstra,
ming.m.lin, sheng.yang, Jes Sorensen, KVM General, Gleb Natapov,
Arnaldo Carvalho de Melo, Fr??d??ric Weisbecker, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra, Arjan van de Ven
On 03/01/2010 03:25 AM, Ingo Molnar wrote:
> * Zachary Amsden<zamsden@redhat.com> 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
>
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 15:14 ` Anthony Liguori
@ 2010-03-01 15:42 ` Daniel P. Berrange
2010-03-02 1:12 ` Dustin Kirkland
` (2 subsequent siblings)
3 siblings, 0 replies; 109+ messages in thread
From: Daniel P. Berrange @ 2010-03-01 15:42 UTC (permalink / raw)
To: Anthony Liguori
Cc: Ingo Molnar, Avi Kivity, Zhang, Yanmin, Peter Zijlstra,
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,
Peter Zijlstra, Arjan van de Ven, Cole Robinson
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 :|
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-02-27 17:25 ` Ingo Molnar
2010-03-01 15:33 ` Anthony Liguori
@ 2010-03-01 16:48 ` Zachary Amsden
2010-03-01 17:41 ` Arnaldo Carvalho de Melo
2010-03-07 18:25 ` Avi Kivity
2 siblings, 1 reply; 109+ messages in thread
From: Zachary Amsden @ 2010-03-01 16:48 UTC (permalink / raw)
To: Ingo Molnar
Cc: Avi Kivity, Anthony Liguori, Zhang, Yanmin, Peter Zijlstra,
ming.m.lin, sheng.yang, Jes Sorensen, KVM General, Gleb Natapov,
Arnaldo Carvalho de Melo, Fr??d??ric Weisbecker, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra, Arjan van de Ven
On 02/27/2010 07:25 AM, Ingo Molnar wrote:
> * Zachary Amsden<zamsden@redhat.com> 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 16:48 ` Zachary Amsden
@ 2010-03-01 17:41 ` Arnaldo Carvalho de Melo
2010-03-01 18:29 ` Zachary Amsden
0 siblings, 1 reply; 109+ messages in thread
From: Arnaldo Carvalho de Melo @ 2010-03-01 17:41 UTC (permalink / raw)
To: Zachary Amsden
Cc: Ingo Molnar, Avi Kivity, Anthony Liguori, Zhang, Yanmin,
Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 17:41 ` Arnaldo Carvalho de Melo
@ 2010-03-01 18:29 ` Zachary Amsden
2010-03-01 20:56 ` Ingo Molnar
0 siblings, 1 reply; 109+ messages in thread
From: Zachary Amsden @ 2010-03-01 18:29 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Ingo Molnar, Avi Kivity, Anthony Liguori, Zhang, Yanmin,
Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 18:29 ` Zachary Amsden
@ 2010-03-01 20:56 ` Ingo Molnar
2010-03-01 21:45 ` Anthony Liguori
2010-03-02 10:30 ` Ingo Molnar
0 siblings, 2 replies; 109+ messages in thread
From: Ingo Molnar @ 2010-03-01 20:56 UTC (permalink / raw)
To: Zachary Amsden
Cc: Arnaldo Carvalho de Melo, Avi Kivity, Anthony Liguori, Zhang,
Yanmin, Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven
* Zachary Amsden <zamsden@redhat.com> 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-02-27 10:56 ` KVM usability Ingo Molnar
` (3 preceding siblings ...)
2010-03-01 15:14 ` Anthony Liguori
@ 2010-03-01 21:12 ` Dustin Kirkland
2010-03-01 21:59 ` Anthony Liguori
4 siblings, 1 reply; 109+ messages in thread
From: Dustin Kirkland @ 2010-03-01 21:12 UTC (permalink / raw)
To: Ingo Molnar
Cc: Avi Kivity, Anthony Liguori, Zhang, Yanmin, Peter Zijlstra,
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,
Peter Zijlstra, Arjan van de Ven
On Sat, Feb 27, 2010 at 4:56 AM, Ingo Molnar <mingo@elte.hu> 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 20:56 ` Ingo Molnar
@ 2010-03-01 21:45 ` Anthony Liguori
2010-03-01 22:06 ` Zachary Amsden
2010-03-02 0:30 ` Ingo Molnar
2010-03-02 10:30 ` Ingo Molnar
1 sibling, 2 replies; 109+ messages in thread
From: Anthony Liguori @ 2010-03-01 21:45 UTC (permalink / raw)
To: Ingo Molnar
Cc: Zachary Amsden, Arnaldo Carvalho de Melo, Avi Kivity, Zhang,
Yanmin, Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven
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
>
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 21:12 ` Dustin Kirkland
@ 2010-03-01 21:59 ` Anthony Liguori
2010-03-02 2:34 ` Alexander Graf
` (2 more replies)
0 siblings, 3 replies; 109+ messages in thread
From: Anthony Liguori @ 2010-03-01 21:59 UTC (permalink / raw)
To: Dustin Kirkland
Cc: Ingo Molnar, Avi Kivity, Zhang, Yanmin, Peter Zijlstra,
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,
Peter Zijlstra, Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 21:45 ` Anthony Liguori
@ 2010-03-01 22:06 ` Zachary Amsden
2010-03-02 0:33 ` Ingo Molnar
2010-03-02 0:30 ` Ingo Molnar
1 sibling, 1 reply; 109+ messages in thread
From: Zachary Amsden @ 2010-03-01 22:06 UTC (permalink / raw)
To: Anthony Liguori
Cc: Ingo Molnar, Arnaldo Carvalho de Melo, Avi Kivity, Zhang, Yanmin,
Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 21:45 ` Anthony Liguori
2010-03-01 22:06 ` Zachary Amsden
@ 2010-03-02 0:30 ` Ingo Molnar
2010-03-02 2:34 ` Anthony Liguori
` (2 more replies)
1 sibling, 3 replies; 109+ messages in thread
From: Ingo Molnar @ 2010-03-02 0:30 UTC (permalink / raw)
To: Anthony Liguori
Cc: Zachary Amsden, Arnaldo Carvalho de Melo, Avi Kivity, Zhang,
Yanmin, Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven
* Anthony Liguori <anthony@codemonkey.ws> 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 who suggested that Qemu wouldnt fit
the kernel standards as-is - it was raised by others in this discussion.
Ingo
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 22:06 ` Zachary Amsden
@ 2010-03-02 0:33 ` Ingo Molnar
0 siblings, 0 replies; 109+ messages in thread
From: Ingo Molnar @ 2010-03-02 0:33 UTC (permalink / raw)
To: Zachary Amsden
Cc: Anthony Liguori, Arnaldo Carvalho de Melo, Avi Kivity, Zhang,
Yanmin, Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven
* Zachary Amsden <zamsden@redhat.com> 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 15:14 ` Anthony Liguori
2010-03-01 15:42 ` Daniel P. Berrange
@ 2010-03-02 1:12 ` Dustin Kirkland
2010-03-02 10:11 ` Peter Zijlstra
2010-03-07 11:25 ` Avi Kivity
3 siblings, 0 replies; 109+ messages in thread
From: Dustin Kirkland @ 2010-03-02 1:12 UTC (permalink / raw)
To: Anthony Liguori
Cc: Ingo Molnar, Avi Kivity, Zhang, Yanmin, Peter Zijlstra,
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,
Peter Zijlstra, Arjan van de Ven, Cole Robinson
On Mon, Mar 1, 2010 at 9:14 AM, Anthony Liguori <anthony@codemonkey.ws> 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 0:30 ` Ingo Molnar
@ 2010-03-02 2:34 ` Anthony Liguori
2010-03-02 8:39 ` Chris Webb
2010-03-07 18:42 ` Avi Kivity
2 siblings, 0 replies; 109+ messages in thread
From: Anthony Liguori @ 2010-03-02 2:34 UTC (permalink / raw)
To: Ingo Molnar
Cc: Zachary Amsden, Arnaldo Carvalho de Melo, Avi Kivity, Zhang,
Yanmin, Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven
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 hard back then - but it's
> certainly not zero amount of work.
>
First impressions are deceptive. My long term goal for qemu is to get
to a point where the device models live independently of the rest of
qemu. I think it's reasonable to split these devices into a modular
library that can then be used by other applications.
That would make it possible to create a kvm-specific virtualization tool
that only supported tap and linux-aio and the bare minimum numbers of
devices. It would be easy to look at and for kernel hackers to play with.
But to be honest, it would never replace qemu. Once you add a VNC/Spice
server (you need remote connectivity), support for sparse file formats
(because we can't wait forever for btrfs to solve all of our problems),
live migration and snapshotting (required ticky marks for
virtualization), a management layer, and all of the other bells and
whistles, you'll find that you did an awful lot of work to recreate what
qemu does.
Most people that have gone down this road believe that it's more
efficient to just improve qemu's quality than it is to try and replicate
it. So far, we've been pretty successful IMHO.
Regards,
Anthony Liguori
> 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 who suggested that Qemu wouldnt fit
> the kernel standards as-is - it was raised by others in this discussion.
>
> Ingo
>
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 21:59 ` Anthony Liguori
@ 2010-03-02 2:34 ` Alexander Graf
2010-03-02 2:36 ` Anthony Liguori
2010-03-02 3:02 ` Dustin Kirkland
2010-03-03 2:57 ` KVM usability Ross Boylan
2 siblings, 1 reply; 109+ messages in thread
From: Alexander Graf @ 2010-03-02 2:34 UTC (permalink / raw)
To: Anthony Liguori
Cc: Dustin Kirkland, Ingo Molnar, Avi Kivity, Zhang, Yanmin,
Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 2:34 ` Alexander Graf
@ 2010-03-02 2:36 ` Anthony Liguori
2010-03-09 13:32 ` Avi Kivity
0 siblings, 1 reply; 109+ messages in thread
From: Anthony Liguori @ 2010-03-02 2:36 UTC (permalink / raw)
To: Alexander Graf
Cc: Dustin Kirkland, Ingo Molnar, Avi Kivity, Zhang, Yanmin,
Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 21:59 ` Anthony Liguori
2010-03-02 2:34 ` Alexander Graf
@ 2010-03-02 3:02 ` Dustin Kirkland
2010-03-02 8:21 ` Chris Webb
2010-03-03 2:57 ` KVM usability Ross Boylan
2 siblings, 1 reply; 109+ messages in thread
From: Dustin Kirkland @ 2010-03-02 3:02 UTC (permalink / raw)
To: Anthony Liguori
Cc: Ingo Molnar, Avi Kivity, Zhang, Yanmin, Peter Zijlstra,
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,
Peter Zijlstra, Arjan van de Ven
[-- Attachment #1: Type: text/plain, Size: 3055 bytes --]
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 > 1000000:
MEM = 512
elif total > 750000:
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 3:02 ` Dustin Kirkland
@ 2010-03-02 8:21 ` Chris Webb
2010-03-02 14:54 ` Dustin Kirkland
[not found] ` <428008581.20100302103400@eternallybored.org>
0 siblings, 2 replies; 109+ messages in thread
From: Chris Webb @ 2010-03-02 8:21 UTC (permalink / raw)
To: Dustin Kirkland
Cc: Anthony Liguori, Ingo Molnar, Avi Kivity, Zhang, Yanmin,
Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
Dustin Kirkland <kirkland@canonical.com> 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.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 0:30 ` Ingo Molnar
2010-03-02 2:34 ` Anthony Liguori
@ 2010-03-02 8:39 ` Chris Webb
2010-03-07 18:42 ` Avi Kivity
2 siblings, 0 replies; 109+ messages in thread
From: Chris Webb @ 2010-03-02 8:39 UTC (permalink / raw)
To: Ingo Molnar
Cc: Anthony Liguori, Zachary Amsden, Arnaldo Carvalho de Melo,
Avi Kivity, Zhang, Yanmin, Peter Zijlstra, ming.m.lin,
sheng.yang, Jes Sorensen, KVM General, Gleb Natapov,
Fr??d??ric Weisbecker, Thomas Gleixner, H. Peter Anvin,
Peter Zijlstra, Arjan van de Ven
Ingo Molnar <mingo@elte.hu> 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.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 15:14 ` Anthony Liguori
2010-03-01 15:42 ` Daniel P. Berrange
2010-03-02 1:12 ` Dustin Kirkland
@ 2010-03-02 10:11 ` Peter Zijlstra
2010-03-02 13:37 ` Nikolai K. Bochev
2010-03-04 20:00 ` Lucas Meneghel Rodrigues
2010-03-07 11:25 ` Avi Kivity
3 siblings, 2 replies; 109+ messages in thread
From: Peter Zijlstra @ 2010-03-02 10:11 UTC (permalink / raw)
To: Anthony Liguori
Cc: Ingo Molnar, Avi Kivity, Zhang, Yanmin, 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
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.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 20:56 ` Ingo Molnar
2010-03-01 21:45 ` Anthony Liguori
@ 2010-03-02 10:30 ` Ingo Molnar
2010-03-07 9:35 ` Avi Kivity
1 sibling, 1 reply; 109+ messages in thread
From: Ingo Molnar @ 2010-03-02 10:30 UTC (permalink / raw)
To: Zachary Amsden
Cc: Arnaldo Carvalho de Melo, Avi Kivity, Anthony Liguori, Zhang,
Yanmin, Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven, linux-kernel
* Ingo Molnar <mingo@elte.hu> 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 10:11 ` Peter Zijlstra
@ 2010-03-02 13:37 ` Nikolai K. Bochev
2010-03-02 14:22 ` Gerd Hoffmann
2010-03-04 20:00 ` Lucas Meneghel Rodrigues
1 sibling, 1 reply; 109+ messages in thread
From: Nikolai K. Bochev @ 2010-03-02 13:37 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Anthony Liguori, 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
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 <peterz@infradead.org>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Ingo Molnar <mingo@elte.hu>, Avi Kivity <avi@redhat.com>, Yanmin Zhang <yanmin_zhang@linux.intel.com>, ming m lin <ming.m.lin@intel.com>, sheng yang <sheng.yang@intel.com>, Jes Sorensen <Jes.Sorensen@redhat.com>, KVM General <kvm@vger.kernel.org>, Zachary Amsden <zamsden@redhat.com>, Gleb Natapov <gleb@redhat.com>, Arnaldo Carvalho de Melo <acme@redhat.com>, Fr??d??ric Weisbecker <fweisbec@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, H. Peter Anvin <hpa@zytor.com>, Arjan van de Ven <arjan@infradead.org>, Cole Robinson <crobinso@redhat.com>
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 13:37 ` Nikolai K. Bochev
@ 2010-03-02 14:22 ` Gerd Hoffmann
2010-03-02 14:29 ` Ingo Molnar
2010-03-02 14:37 ` Daniel P. Berrange
0 siblings, 2 replies; 109+ messages in thread
From: Gerd Hoffmann @ 2010-03-02 14:22 UTC (permalink / raw)
To: Nikolai K. Bochev
Cc: Peter Zijlstra, Anthony Liguori, 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
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 14:22 ` Gerd Hoffmann
@ 2010-03-02 14:29 ` Ingo Molnar
2010-03-07 9:22 ` Avi Kivity
2010-03-02 14:37 ` Daniel P. Berrange
1 sibling, 1 reply; 109+ messages in thread
From: Ingo Molnar @ 2010-03-02 14:29 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Nikolai K. Bochev, Peter Zijlstra, Anthony Liguori, 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
* Gerd Hoffmann <kraxel@redhat.com> 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 14:22 ` Gerd Hoffmann
2010-03-02 14:29 ` Ingo Molnar
@ 2010-03-02 14:37 ` Daniel P. Berrange
2010-03-02 14:52 ` Gerd Hoffmann
1 sibling, 1 reply; 109+ messages in thread
From: Daniel P. Berrange @ 2010-03-02 14:37 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Nikolai K. Bochev, Peter Zijlstra, Anthony Liguori, 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
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 :|
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 14:37 ` Daniel P. Berrange
@ 2010-03-02 14:52 ` Gerd Hoffmann
2010-03-02 14:56 ` Daniel P. Berrange
0 siblings, 1 reply; 109+ messages in thread
From: Gerd Hoffmann @ 2010-03-02 14:52 UTC (permalink / raw)
To: Daniel P. Berrange
Cc: Nikolai K. Bochev, Peter Zijlstra, Anthony Liguori, 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
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 8:21 ` Chris Webb
@ 2010-03-02 14:54 ` Dustin Kirkland
[not found] ` <428008581.20100302103400@eternallybored.org>
1 sibling, 0 replies; 109+ messages in thread
From: Dustin Kirkland @ 2010-03-02 14:54 UTC (permalink / raw)
To: Chris Webb
Cc: Anthony Liguori, Ingo Molnar, Avi Kivity, Zhang, Yanmin,
Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
On Tue, Mar 2, 2010 at 2:21 AM, Chris Webb <chris@arachsys.com> 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 14:52 ` Gerd Hoffmann
@ 2010-03-02 14:56 ` Daniel P. Berrange
2010-03-02 15:13 ` Gerd Hoffmann
0 siblings, 1 reply; 109+ messages in thread
From: Daniel P. Berrange @ 2010-03-02 14:56 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Nikolai K. Bochev, Peter Zijlstra, Anthony Liguori, 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
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 :|
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 14:56 ` Daniel P. Berrange
@ 2010-03-02 15:13 ` Gerd Hoffmann
0 siblings, 0 replies; 109+ messages in thread
From: Gerd Hoffmann @ 2010-03-02 15:13 UTC (permalink / raw)
To: Daniel P. Berrange
Cc: Nikolai K. Bochev, Peter Zijlstra, Anthony Liguori, 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
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-02-26 14:23 ` Ingo Molnar
2010-02-26 15:06 ` Avi Kivity
@ 2010-03-02 16:46 ` Paolo Bonzini
2010-03-02 17:12 ` Arnaldo Carvalho de Melo
2010-03-02 17:17 ` Ingo Molnar
1 sibling, 2 replies; 109+ messages in thread
From: Paolo Bonzini @ 2010-03-02 16:46 UTC (permalink / raw)
To: Ingo Molnar
Cc: Avi Kivity, Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra,
Arjan van de Ven
On 02/26/2010 03:23 PM, Ingo Molnar wrote:
> I do think tools/X and tools/libc would make quite a bit of sense - this is
> one of the better design aspects of FreeBSD et al. It's a mistake that it's
> not being done.
I don't see what it would buy to have tools/libc. You cannot force
users to update kernel-space and user-space in lockstep (Apple forced
you to do that sometimes when I used Macs at work, and it was very very
inconvenient), so it's not like libc would be able to always assume the
latest system calls. There is (relatively) a lot of
backwards-compatibility code in libc; it's ugly code, but you have to
live with it.
Any case in which you need lockstep upgrades of kernel and libc for
bisectability is a bug in libc, and I haven't seen it happen enough to
be a problem.
Paolo
ps: does it make sense to keep such a long list of recipients???
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-03-02 16:46 ` Paolo Bonzini
@ 2010-03-02 17:12 ` Arnaldo Carvalho de Melo
2010-03-02 17:20 ` Paolo Bonzini
2010-03-02 17:17 ` Ingo Molnar
1 sibling, 1 reply; 109+ messages in thread
From: Arnaldo Carvalho de Melo @ 2010-03-02 17:12 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Ingo Molnar, Avi Kivity, Zhang, Yanmin, Peter Zijlstra,
ming.m.lin, sheng.yang, Jes Sorensen, KVM General,
Zachary Amsden, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven
Em Tue, Mar 02, 2010 at 05:46:03PM +0100, Paolo Bonzini escreveu:
> On 02/26/2010 03:23 PM, Ingo Molnar wrote:
>> I do think tools/X and tools/libc would make quite a bit of sense - this is
>> one of the better design aspects of FreeBSD et al. It's a mistake that it's
>> not being done.
>
> I don't see what it would buy to have tools/libc. You cannot force
> users to update kernel-space and user-space in lockstep (Apple forced
> you to do that sometimes when I used Macs at work, and it was very very
> inconvenient), so it's not like libc would be able to always assume the
> latest system calls. There is (relatively) a lot of
> backwards-compatibility code in libc; it's ugly code, but you have to
> live with it.
>
> Any case in which you need lockstep upgrades of kernel and libc for
> bisectability is a bug in libc, and I haven't seen it happen enough to
> be a problem.
You imply lockstep updates because both are on the same source tree? I
don't see why that would be required, there is an ABI contract to be
respected no matter where the sources for the signatories live.
perf lives in the kernel sources and while developing it I use all sorts
of combinations of userland and kernel perf bits so as not to be
rebooting the many machines of different arches where I test the
userspace bits all the time with a new kernel, even if it indeed has new
in-kernel perf bits.
As an instance where I could have worked on tools/libc recently was the
recvmmsg syscall I introduced.
Till it got into glibc (IIRC it was, but I wasn't involved in it, google
alert told me) interested parties had to use 'man syscall' and pick the
syscall number for their specific architecture, etc.
I could've done both the kernel and userspace bits in the same patch.
- Arnaldo
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-03-02 16:46 ` Paolo Bonzini
2010-03-02 17:12 ` Arnaldo Carvalho de Melo
@ 2010-03-02 17:17 ` Ingo Molnar
2010-03-07 14:17 ` Avi Kivity
1 sibling, 1 reply; 109+ messages in thread
From: Ingo Molnar @ 2010-03-02 17:17 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Avi Kivity, Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra,
Arjan van de Ven
* Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 02/26/2010 03:23 PM, Ingo Molnar wrote:
> >I do think tools/X and tools/libc would make quite a bit of sense - this is
> >one of the better design aspects of FreeBSD et al. It's a mistake that it's
> >not being done.
>
> I don't see what it would buy to have tools/libc. You cannot force users to
> update kernel-space and user-space in lockstep (Apple forced you to do that
> sometimes when I used Macs at work, and it was very very inconvenient), so
> it's not like libc would be able to always assume the latest system calls.
> There is (relatively) a lot of backwards-compatibility code in libc; it's
> ugly code, but you have to live with it.
If glibc was part of the kernel repo with a klibc alike approach we wouldnt
have such problems: the kernel would provide the system library and that's it.
You'd not want to upgrade them separately, just like you generally wouldnt
want to upgrade your memory management code separately from the scheduler
either.
The same argument could be made in a reverse fashion with just about any part
of the kernel: 'it would be better to upgrade the ext3 driver separately' -
etc. It's similar to all the classic microkernel versus monolithic kernel
arguments.
There are costs with increasing size and increasing integration - but fact is
that we can manage a 13+ MLOC kernel just fine and the benefits of an
integrated approach far outweigh the costs.
In my experience it's far better to have one project for 'infrastructure'
bits: developed, tested and offered as one coherent entity in essence. A bit
like how Xorg does it.
These many splintered kernel facilities are historical legacies in essence
(from the times when there was no single usable free OS available), and
over-modularization has many costs and few advantages.
Thanks,
Ingo
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-03-02 17:12 ` Arnaldo Carvalho de Melo
@ 2010-03-02 17:20 ` Paolo Bonzini
2010-03-02 17:24 ` Ingo Molnar
0 siblings, 1 reply; 109+ messages in thread
From: Paolo Bonzini @ 2010-03-02 17:20 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Ingo Molnar, Avi Kivity, Zhang, Yanmin, Peter Zijlstra,
ming.m.lin, sheng.yang, Jes Sorensen, KVM General,
Zachary Amsden, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven
On 03/02/2010 06:12 PM, Arnaldo Carvalho de Melo wrote:
> You imply lockstep updates because both are on the same source tree? I
> don't see why that would be required, there is an ABI contract to be
> respected no matter where the sources for the signatories live.
It's not about ABIs, it's about not being able to rely exclusively on
new syscalls or flags (one for all: SOCK_NONBLOCK) because people can
run new glibc on old kernels.
If libc had this luxury, it would possibly make a lot more sense to have
it in the kernel tree. But it doesn't.
Also, setting up a testing environment for glibc is not trivial, and the
intersection of people that care about developing the kernel _and_ glibc
is probably too small and opinionated to make this easier.
>I could've done both the kernel and userspace bits in the same patch.
You could add a glibc submodule to your git tree, and ask on the git
list for help adding some kind of multi-destination support to
git-{format-patch,send-email}.
Paolo
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-03-02 17:20 ` Paolo Bonzini
@ 2010-03-02 17:24 ` Ingo Molnar
0 siblings, 0 replies; 109+ messages in thread
From: Ingo Molnar @ 2010-03-02 17:24 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Arnaldo Carvalho de Melo, Avi Kivity, Zhang, Yanmin,
Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Zachary Amsden, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven
* Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 03/02/2010 06:12 PM, Arnaldo Carvalho de Melo wrote:
> >You imply lockstep updates because both are on the same source tree? I
> >don't see why that would be required, there is an ABI contract to be
> >respected no matter where the sources for the signatories live.
>
> It's not about ABIs, it's about not being able to rely exclusively on new
> syscalls or flags (one for all: SOCK_NONBLOCK) because people can run new
> glibc on old kernels.
That is not what i was suggesting though.
I am suggesting a klibc-alike approach, where glibc is not on the filesystem
but mapped by the kernel, basically as an extension of the standard vDSO.
We always have most of glibc paged in all the time, so there's no real RAM
usage difference. (and ultra-embedded would sure make use of this to trim RAM
usage in fact.)
That way the C library comes with the kernel. New kernel, new/updated system
library.
Ingo
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 21:59 ` Anthony Liguori
2010-03-02 2:34 ` Alexander Graf
2010-03-02 3:02 ` Dustin Kirkland
@ 2010-03-03 2:57 ` Ross Boylan
2010-03-03 8:55 ` Daniel P. Berrange
2 siblings, 1 reply; 109+ messages in thread
From: Ross Boylan @ 2010-03-03 2:57 UTC (permalink / raw)
To: Anthony Liguori; +Cc: ross, KVM General
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-03 2:57 ` KVM usability Ross Boylan
@ 2010-03-03 8:55 ` Daniel P. Berrange
2010-03-03 15:42 ` Ross Boylan
0 siblings, 1 reply; 109+ messages in thread
From: Daniel P. Berrange @ 2010-03-03 8:55 UTC (permalink / raw)
To: Ross Boylan; +Cc: Anthony Liguori, KVM General
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 :|
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-03 8:55 ` Daniel P. Berrange
@ 2010-03-03 15:42 ` Ross Boylan
2010-03-07 14:29 ` Avi Kivity
0 siblings, 1 reply; 109+ messages in thread
From: Ross Boylan @ 2010-03-03 15:42 UTC (permalink / raw)
To: Daniel P. Berrange; +Cc: ross, Anthony Liguori, KVM General
On Wed, 2010-03-03 at 08:55 +0000, 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 10:11 ` Peter Zijlstra
2010-03-02 13:37 ` Nikolai K. Bochev
@ 2010-03-04 20:00 ` Lucas Meneghel Rodrigues
2010-03-04 20:13 ` Zachary Amsden
1 sibling, 1 reply; 109+ messages in thread
From: Lucas Meneghel Rodrigues @ 2010-03-04 20:00 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Anthony Liguori, Ingo Molnar, Avi Kivity, Zhang, Yanmin,
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
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.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-04 20:00 ` Lucas Meneghel Rodrigues
@ 2010-03-04 20:13 ` Zachary Amsden
2010-03-04 20:34 ` Anthony Liguori
2010-03-04 22:23 ` H. Peter Anvin
0 siblings, 2 replies; 109+ messages in thread
From: Zachary Amsden @ 2010-03-04 20:13 UTC (permalink / raw)
To: Lucas Meneghel Rodrigues
Cc: Peter Zijlstra, Anthony Liguori, Ingo Molnar, Avi Kivity, Zhang,
Yanmin, ming.m.lin, sheng.yang, Jes Sorensen, KVM General,
Gleb Natapov, Arnaldo Carvalho de Melo, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Arjan van de Ven, Cole Robinson
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-04 20:13 ` Zachary Amsden
@ 2010-03-04 20:34 ` Anthony Liguori
2010-03-04 22:23 ` H. Peter Anvin
1 sibling, 0 replies; 109+ messages in thread
From: Anthony Liguori @ 2010-03-04 20:34 UTC (permalink / raw)
To: Zachary Amsden
Cc: Lucas Meneghel Rodrigues, Peter Zijlstra, Ingo Molnar,
Avi Kivity, Zhang, Yanmin, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Arnaldo Carvalho de Melo,
Fr??d??ric Weisbecker, Thomas Gleixner, H. Peter Anvin,
Arjan van de Ven, Cole Robinson
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-04 20:13 ` Zachary Amsden
2010-03-04 20:34 ` Anthony Liguori
@ 2010-03-04 22:23 ` H. Peter Anvin
2010-03-05 7:44 ` Markus Armbruster
1 sibling, 1 reply; 109+ messages in thread
From: H. Peter Anvin @ 2010-03-04 22:23 UTC (permalink / raw)
To: Zachary Amsden
Cc: Lucas Meneghel Rodrigues, Peter Zijlstra, Anthony Liguori,
Ingo Molnar, Avi Kivity, Zhang, Yanmin, ming.m.lin, sheng.yang,
Jes Sorensen, KVM General, Gleb Natapov,
Arnaldo Carvalho de Melo, Fr??d??ric Weisbecker, Thomas Gleixner,
Arjan van de Ven, Cole Robinson
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-04 22:23 ` H. Peter Anvin
@ 2010-03-05 7:44 ` Markus Armbruster
0 siblings, 0 replies; 109+ messages in thread
From: Markus Armbruster @ 2010-03-05 7:44 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Zachary Amsden, Lucas Meneghel Rodrigues, Peter Zijlstra,
Anthony Liguori, Ingo Molnar, Avi Kivity, Zhang, Yanmin,
ming.m.lin, sheng.yang, Jes Sorensen, KVM General, Gleb Natapov,
Arnaldo Carvalho de Melo, Fr??d??ric Weisbecker, Thomas Gleixner,
Arjan van de Ven, Cole Robinson
"H. Peter Anvin" <hpa@zytor.com> 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.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 14:29 ` Ingo Molnar
@ 2010-03-07 9:22 ` Avi Kivity
0 siblings, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-03-07 9:22 UTC (permalink / raw)
To: Ingo Molnar
Cc: Gerd Hoffmann, Nikolai K. Bochev, Peter Zijlstra,
Anthony Liguori, 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
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 10:30 ` Ingo Molnar
@ 2010-03-07 9:35 ` Avi Kivity
2010-03-07 9:56 ` Pekka Enberg
` (2 more replies)
0 siblings, 3 replies; 109+ messages in thread
From: Avi Kivity @ 2010-03-07 9:35 UTC (permalink / raw)
To: Ingo Molnar
Cc: Zachary Amsden, Arnaldo Carvalho de Melo, Anthony Liguori, Zhang,
Yanmin, Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven, linux-kernel
On 03/02/2010 12:30 PM, Ingo Molnar wrote:
> * Ingo Molnar<mingo@elte.hu> 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-07 9:35 ` Avi Kivity
@ 2010-03-07 9:56 ` Pekka Enberg
2010-03-07 10:11 ` Avi Kivity
2010-03-07 18:42 ` Ingo Molnar
2010-03-07 15:14 ` Luca Barbieri
2010-03-07 18:01 ` Arnaldo Carvalho de Melo
2 siblings, 2 replies; 109+ messages in thread
From: Pekka Enberg @ 2010-03-07 9:56 UTC (permalink / raw)
To: Avi Kivity
Cc: Ingo Molnar, Zachary Amsden, Arnaldo Carvalho de Melo,
Anthony Liguori, Zhang, Yanmin, Peter Zijlstra, ming.m.lin,
sheng.yang, Jes Sorensen, KVM General, Gleb Natapov,
Fr??d??ric Weisbecker, Thomas Gleixner, H. Peter Anvin,
Peter Zijlstra, Arjan van de Ven, linux-kernel
Hi Avi,
(slightly off-topic)
On Sun, Mar 7, 2010 at 11:35 AM, Avi Kivity <avi@redhat.com> 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-07 9:56 ` Pekka Enberg
@ 2010-03-07 10:11 ` Avi Kivity
2010-03-07 18:42 ` Ingo Molnar
1 sibling, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-03-07 10:11 UTC (permalink / raw)
To: Pekka Enberg
Cc: Ingo Molnar, Zachary Amsden, Arnaldo Carvalho de Melo,
Anthony Liguori, Zhang, Yanmin, Peter Zijlstra, ming.m.lin,
sheng.yang, Jes Sorensen, KVM General, Gleb Natapov,
Fr??d??ric Weisbecker, Thomas Gleixner, H. Peter Anvin,
Peter Zijlstra, Arjan van de Ven, linux-kernel
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<avi@redhat.com> 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-01 15:14 ` Anthony Liguori
` (2 preceding siblings ...)
2010-03-02 10:11 ` Peter Zijlstra
@ 2010-03-07 11:25 ` Avi Kivity
3 siblings, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-03-07 11:25 UTC (permalink / raw)
To: Anthony Liguori
Cc: Ingo Molnar, Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra,
Arjan van de Ven, Cole Robinson
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
[not found] ` <428008581.20100302103400@eternallybored.org>
@ 2010-03-07 11:35 ` Avi Kivity
2010-04-04 12:31 ` [Qemu-devel] " Chris Webb
0 siblings, 1 reply; 109+ messages in thread
From: Avi Kivity @ 2010-03-07 11:35 UTC (permalink / raw)
To: Jernej Simončič
Cc: Chris Webb on [KVM],
Dustin Kirkland, Anthony Liguori, Ingo Molnar, Zhang, Yanmin,
Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
Zachary Amsden, Gleb Natapov, Arnaldo Carvalho de Melo,
Fr??d??ric Weisbecker, Thomas Gleixner, H. Peter Anvin,
Peter Zijlstra, Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: Enhance perf to support KVM
2010-03-02 17:17 ` Ingo Molnar
@ 2010-03-07 14:17 ` Avi Kivity
0 siblings, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-03-07 14:17 UTC (permalink / raw)
To: Ingo Molnar
Cc: Paolo Bonzini, Zhang, Yanmin, Peter Zijlstra, 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, Peter Zijlstra,
Arjan van de Ven
On 03/02/2010 07:17 PM, Ingo Molnar wrote:
> * Paolo Bonzini<pbonzini@redhat.com> wrote:
>
>
>> On 02/26/2010 03:23 PM, Ingo Molnar wrote:
>>
>>> I do think tools/X and tools/libc would make quite a bit of sense - this is
>>> one of the better design aspects of FreeBSD et al. It's a mistake that it's
>>> not being done.
>>>
>> I don't see what it would buy to have tools/libc. You cannot force users to
>> update kernel-space and user-space in lockstep (Apple forced you to do that
>> sometimes when I used Macs at work, and it was very very inconvenient), so
>> it's not like libc would be able to always assume the latest system calls.
>> There is (relatively) a lot of backwards-compatibility code in libc; it's
>> ugly code, but you have to live with it.
>>
> If glibc was part of the kernel repo with a klibc alike approach we wouldnt
> have such problems: the kernel would provide the system library and that's it.
> You'd not want to upgrade them separately, just like you generally wouldnt
> want to upgrade your memory management code separately from the scheduler
> either.
>
> The same argument could be made in a reverse fashion with just about any part
> of the kernel: 'it would be better to upgrade the ext3 driver separately' -
> etc. It's similar to all the classic microkernel versus monolithic kernel
> arguments.
>
No, that's Documentation/stable_api_nonsense.txt. It's perfectly
possible to have a filesystem driver that is decoupled from the kernel,
yet both are in the same address space.
> There are costs with increasing size and increasing integration - but fact is
> that we can manage a 13+ MLOC kernel just fine and the benefits of an
> integrated approach far outweigh the costs.
>
> In my experience it's far better to have one project for 'infrastructure'
> bits: developed, tested and offered as one coherent entity in essence. A bit
> like how Xorg does it.
>
> These many splintered kernel facilities are historical legacies in essence
> (from the times when there was no single usable free OS available), and
> over-modularization has many costs and few advantages.
>
You're probably right for core libraries, but I don't think a GUI for
kvm qualifies. A server oriented application, maybe.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-03 15:42 ` Ross Boylan
@ 2010-03-07 14:29 ` Avi Kivity
0 siblings, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-03-07 14:29 UTC (permalink / raw)
To: Ross Boylan; +Cc: Daniel P. Berrange, Anthony Liguori, KVM General
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-07 9:35 ` Avi Kivity
2010-03-07 9:56 ` Pekka Enberg
@ 2010-03-07 15:14 ` Luca Barbieri
2010-03-07 18:16 ` Avi Kivity
2010-03-07 18:01 ` Arnaldo Carvalho de Melo
2 siblings, 1 reply; 109+ messages in thread
From: Luca Barbieri @ 2010-03-07 15:14 UTC (permalink / raw)
To: Avi Kivity
Cc: Ingo Molnar, Zachary Amsden, Arnaldo Carvalho de Melo,
Anthony Liguori, Zhang, Yanmin, Peter Zijlstra, ming.m.lin,
sheng.yang, Jes Sorensen, KVM General, Gleb Natapov,
Fr??d??ric Weisbecker, Thomas Gleixner, H. Peter Anvin,
Peter Zijlstra, Arjan van de Ven, linux-kernel
> 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.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-07 9:35 ` Avi Kivity
2010-03-07 9:56 ` Pekka Enberg
2010-03-07 15:14 ` Luca Barbieri
@ 2010-03-07 18:01 ` Arnaldo Carvalho de Melo
2010-03-07 18:15 ` Avi Kivity
2 siblings, 1 reply; 109+ messages in thread
From: Arnaldo Carvalho de Melo @ 2010-03-07 18:01 UTC (permalink / raw)
To: Avi Kivity
Cc: Ingo Molnar, Zachary Amsden, Anthony Liguori, Zhang, Yanmin,
Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven, linux-kernel
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-07 18:01 ` Arnaldo Carvalho de Melo
@ 2010-03-07 18:15 ` Avi Kivity
2010-03-07 18:53 ` Arnaldo Carvalho de Melo
0 siblings, 1 reply; 109+ messages in thread
From: Avi Kivity @ 2010-03-07 18:15 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Ingo Molnar, Zachary Amsden, Anthony Liguori, Zhang, Yanmin,
Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven, linux-kernel
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.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-07 15:14 ` Luca Barbieri
@ 2010-03-07 18:16 ` Avi Kivity
0 siblings, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-03-07 18:16 UTC (permalink / raw)
To: Luca Barbieri
Cc: Ingo Molnar, Zachary Amsden, Arnaldo Carvalho de Melo,
Anthony Liguori, Zhang, Yanmin, Peter Zijlstra, ming.m.lin,
sheng.yang, Jes Sorensen, KVM General, Gleb Natapov,
Fr??d??ric Weisbecker, Thomas Gleixner, H. Peter Anvin,
Peter Zijlstra, Arjan van de Ven, linux-kernel
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.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-02-27 17:25 ` Ingo Molnar
2010-03-01 15:33 ` Anthony Liguori
2010-03-01 16:48 ` Zachary Amsden
@ 2010-03-07 18:25 ` Avi Kivity
2 siblings, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-03-07 18:25 UTC (permalink / raw)
To: Ingo Molnar
Cc: Zachary Amsden, Anthony Liguori, Zhang, Yanmin, Peter Zijlstra,
ming.m.lin, sheng.yang, Jes Sorensen, KVM General, Gleb Natapov,
Arnaldo Carvalho de Melo, Fr??d??ric Weisbecker, Thomas Gleixner,
H. Peter Anvin, Peter Zijlstra, Arjan van de Ven
On 02/27/2010 07:25 PM, Ingo Molnar wrote:
> * Zachary Amsden<zamsden@redhat.com> 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.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 0:30 ` Ingo Molnar
2010-03-02 2:34 ` Anthony Liguori
2010-03-02 8:39 ` Chris Webb
@ 2010-03-07 18:42 ` Avi Kivity
2 siblings, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-03-07 18:42 UTC (permalink / raw)
To: Ingo Molnar
Cc: Anthony Liguori, Zachary Amsden, Arnaldo Carvalho de Melo, Zhang,
Yanmin, Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven
On 03/02/2010 02:30 AM, Ingo Molnar wrote:
> * Anthony Liguori<anthony@codemonkey.ws> 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 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 who suggested that Qemu wouldnt fit
> the kernel standards as-is - it was raised by others in this discussion.
>
I'm sure patches to clean up qemu will be more than welcome on qemu-devel.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-07 9:56 ` Pekka Enberg
2010-03-07 10:11 ` Avi Kivity
@ 2010-03-07 18:42 ` Ingo Molnar
1 sibling, 0 replies; 109+ messages in thread
From: Ingo Molnar @ 2010-03-07 18:42 UTC (permalink / raw)
To: Pekka Enberg
Cc: Avi Kivity, Zachary Amsden, Arnaldo Carvalho de Melo,
Anthony Liguori, Zhang, Yanmin, Peter Zijlstra, ming.m.lin,
sheng.yang, Jes Sorensen, KVM General, Gleb Natapov,
Fr??d??ric Weisbecker, Thomas Gleixner, H. Peter Anvin,
Peter Zijlstra, Arjan van de Ven, linux-kernel
* Pekka Enberg <penberg@cs.helsinki.fi> 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-07 18:15 ` Avi Kivity
@ 2010-03-07 18:53 ` Arnaldo Carvalho de Melo
2010-03-07 19:05 ` Avi Kivity
0 siblings, 1 reply; 109+ messages in thread
From: Arnaldo Carvalho de Melo @ 2010-03-07 18:53 UTC (permalink / raw)
To: Avi Kivity
Cc: Ingo Molnar, Zachary Amsden, Anthony Liguori, Zhang, Yanmin,
Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven, linux-kernel
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-07 18:53 ` Arnaldo Carvalho de Melo
@ 2010-03-07 19:05 ` Avi Kivity
0 siblings, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-03-07 19:05 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Ingo Molnar, Zachary Amsden, Anthony Liguori, Zhang, Yanmin,
Peter Zijlstra, ming.m.lin, sheng.yang, Jes Sorensen,
KVM General, Gleb Natapov, Fr??d??ric Weisbecker,
Thomas Gleixner, H. Peter Anvin, Peter Zijlstra,
Arjan van de Ven, linux-kernel
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.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-02 2:36 ` Anthony Liguori
@ 2010-03-09 13:32 ` Avi Kivity
2010-03-09 14:32 ` Dustin Kirkland
2010-03-09 14:49 ` Anthony Liguori
0 siblings, 2 replies; 109+ messages in thread
From: Avi Kivity @ 2010-03-09 13:32 UTC (permalink / raw)
To: Anthony Liguori
Cc: Alexander Graf, Dustin Kirkland, Ingo Molnar, Zhang, Yanmin,
Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-09 13:32 ` Avi Kivity
@ 2010-03-09 14:32 ` Dustin Kirkland
2010-03-09 14:38 ` Alexander Graf
2010-03-09 14:49 ` Anthony Liguori
1 sibling, 1 reply; 109+ messages in thread
From: Dustin Kirkland @ 2010-03-09 14:32 UTC (permalink / raw)
To: Avi Kivity
Cc: Anthony Liguori, Alexander Graf, Ingo Molnar, Zhang, Yanmin,
Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
[-- Attachment #1: Type: text/plain, Size: 936 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-09 14:32 ` Dustin Kirkland
@ 2010-03-09 14:38 ` Alexander Graf
2010-03-09 14:50 ` Anthony Liguori
0 siblings, 1 reply; 109+ messages in thread
From: Alexander Graf @ 2010-03-09 14:38 UTC (permalink / raw)
To: kirkland
Cc: Avi Kivity, Anthony Liguori, Ingo Molnar, Zhang, Yanmin,
Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-09 13:32 ` Avi Kivity
2010-03-09 14:32 ` Dustin Kirkland
@ 2010-03-09 14:49 ` Anthony Liguori
2010-03-09 14:54 ` Avi Kivity
1 sibling, 1 reply; 109+ messages in thread
From: Anthony Liguori @ 2010-03-09 14:49 UTC (permalink / raw)
To: Avi Kivity
Cc: Alexander Graf, Dustin Kirkland, Ingo Molnar, Zhang, Yanmin,
Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-09 14:38 ` Alexander Graf
@ 2010-03-09 14:50 ` Anthony Liguori
2010-03-09 14:52 ` Avi Kivity
0 siblings, 1 reply; 109+ messages in thread
From: Anthony Liguori @ 2010-03-09 14:50 UTC (permalink / raw)
To: Alexander Graf
Cc: kirkland, Avi Kivity, Ingo Molnar, Zhang, Yanmin, Peter Zijlstra,
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,
Peter Zijlstra, Arjan van de Ven
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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-09 14:50 ` Anthony Liguori
@ 2010-03-09 14:52 ` Avi Kivity
2010-03-09 14:57 ` Anthony Liguori
0 siblings, 1 reply; 109+ messages in thread
From: Avi Kivity @ 2010-03-09 14:52 UTC (permalink / raw)
To: Anthony Liguori
Cc: Alexander Graf, kirkland, Ingo Molnar, Zhang, Yanmin,
Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-09 14:49 ` Anthony Liguori
@ 2010-03-09 14:54 ` Avi Kivity
0 siblings, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-03-09 14:54 UTC (permalink / raw)
To: Anthony Liguori
Cc: Alexander Graf, Dustin Kirkland, Ingo Molnar, Zhang, Yanmin,
Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-09 14:52 ` Avi Kivity
@ 2010-03-09 14:57 ` Anthony Liguori
2010-03-09 17:11 ` Avi Kivity
0 siblings, 1 reply; 109+ messages in thread
From: Anthony Liguori @ 2010-03-09 14:57 UTC (permalink / raw)
To: Avi Kivity
Cc: Alexander Graf, kirkland, Ingo Molnar, Zhang, Yanmin,
Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-09 14:57 ` Anthony Liguori
@ 2010-03-09 17:11 ` Avi Kivity
2010-03-09 17:27 ` Anthony Liguori
0 siblings, 1 reply; 109+ messages in thread
From: Avi Kivity @ 2010-03-09 17:11 UTC (permalink / raw)
To: Anthony Liguori
Cc: Alexander Graf, kirkland, Ingo Molnar, Zhang, Yanmin,
Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-09 17:11 ` Avi Kivity
@ 2010-03-09 17:27 ` Anthony Liguori
2010-03-09 17:30 ` Avi Kivity
0 siblings, 1 reply; 109+ messages in thread
From: Anthony Liguori @ 2010-03-09 17:27 UTC (permalink / raw)
To: Avi Kivity
Cc: Alexander Graf, kirkland, Ingo Molnar, Zhang, Yanmin,
Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: KVM usability
2010-03-09 17:27 ` Anthony Liguori
@ 2010-03-09 17:30 ` Avi Kivity
0 siblings, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-03-09 17:30 UTC (permalink / raw)
To: Anthony Liguori
Cc: Alexander Graf, kirkland, Ingo Molnar, Zhang, Yanmin,
Peter Zijlstra, 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, Peter Zijlstra, Arjan van de Ven
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
^ permalink raw reply [flat|nested] 109+ messages in thread
* High CPU use of -usbdevice tablet (was Re: KVM usability)
2010-03-07 11:35 ` Avi Kivity
@ 2010-04-04 12:31 ` Chris Webb
0 siblings, 0 replies; 109+ messages in thread
From: Chris Webb @ 2010-04-04 12:31 UTC (permalink / raw)
To: Avi Kivity; +Cc: Jernej Simončič, kvm, qemu-devel
Avi Kivity <avi@redhat.com> 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.
^ permalink raw reply [flat|nested] 109+ messages in thread
* [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
@ 2010-04-04 12:31 ` Chris Webb
0 siblings, 0 replies; 109+ messages in thread
From: Chris Webb @ 2010-04-04 12:31 UTC (permalink / raw)
To: Avi Kivity; +Cc: kvm, Jernej Simončič, qemu-devel
Avi Kivity <avi@redhat.com> 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.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
2010-04-04 12:31 ` [Qemu-devel] " Chris Webb
@ 2010-04-04 14:25 ` Paul Brook
-1 siblings, 0 replies; 109+ messages in thread
From: Paul Brook @ 2010-04-04 14:25 UTC (permalink / raw)
To: qemu-devel; +Cc: Chris Webb, Avi Kivity, kvm, Jernej Simončič
> > 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
@ 2010-04-04 14:25 ` Paul Brook
0 siblings, 0 replies; 109+ messages in thread
From: Paul Brook @ 2010-04-04 14:25 UTC (permalink / raw)
To: qemu-devel; +Cc: Chris Webb, Jernej, Avi Kivity, kvm, Simončič
> > 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
2010-04-04 14:25 ` Paul Brook
@ 2010-04-04 16:58 ` Avi Kivity
-1 siblings, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-04-04 16:58 UTC (permalink / raw)
To: Paul Brook; +Cc: qemu-devel, Chris Webb, kvm, Jernej Simončič
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.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
@ 2010-04-04 16:58 ` Avi Kivity
0 siblings, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-04-04 16:58 UTC (permalink / raw)
To: Paul Brook; +Cc: Chris Webb, qemu-devel, kvm, Jernej Simončič
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.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
2010-04-04 16:58 ` Avi Kivity
@ 2010-04-04 21:03 ` Paul Brook
-1 siblings, 0 replies; 109+ messages in thread
From: Paul Brook @ 2010-04-04 21:03 UTC (permalink / raw)
To: qemu-devel; +Cc: Avi Kivity, Chris Webb, kvm, Jernej Simončič
> > 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
@ 2010-04-04 21:03 ` Paul Brook
0 siblings, 0 replies; 109+ messages in thread
From: Paul Brook @ 2010-04-04 21:03 UTC (permalink / raw)
To: qemu-devel; +Cc: Chris Webb, Jernej, Avi Kivity, kvm, Simončič
> > 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
2010-04-04 16:58 ` Avi Kivity
@ 2010-04-04 21:53 ` Paul Brook
-1 siblings, 0 replies; 109+ messages in thread
From: Paul Brook @ 2010-04-04 21:53 UTC (permalink / raw)
To: qemu-devel; +Cc: Avi Kivity, Chris Webb, kvm, Jernej Simončič
> > 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
@ 2010-04-04 21:53 ` Paul Brook
0 siblings, 0 replies; 109+ messages in thread
From: Paul Brook @ 2010-04-04 21:53 UTC (permalink / raw)
To: qemu-devel; +Cc: Chris Webb, Jernej, Avi Kivity, kvm, Simončič
> > 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
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
2010-04-04 21:53 ` Paul Brook
@ 2010-04-05 8:22 ` Avi Kivity
-1 siblings, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-04-05 8:22 UTC (permalink / raw)
To: Paul Brook; +Cc: qemu-devel, Chris Webb, kvm, Jernej Simončič
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.
^ permalink raw reply [flat|nested] 109+ messages in thread
* Re: [Qemu-devel] High CPU use of -usbdevice tablet (was Re: KVM usability)
@ 2010-04-05 8:22 ` Avi Kivity
0 siblings, 0 replies; 109+ messages in thread
From: Avi Kivity @ 2010-04-05 8:22 UTC (permalink / raw)
To: Paul Brook; +Cc: Chris Webb, qemu-devel, kvm, Jernej Simončič
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.
^ permalink raw reply [flat|nested] 109+ messages in thread
end of thread, other threads:[~2010-04-05 8:23 UTC | newest]
Thread overview: 109+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1267068445.1726.25.camel@localhost>
[not found] ` <1267089644.12790.74.camel@laptop>
2010-02-26 2:49 ` Enhance perf to support KVM Zhang, Yanmin
2010-02-26 9:01 ` Ingo Molnar
2010-02-26 9:53 ` Avi Kivity
2010-02-26 10:35 ` Ingo Molnar
2010-02-26 10:47 ` Avi Kivity
2010-02-26 11:17 ` Ingo Molnar
2010-02-26 11:44 ` Avi Kivity
2010-02-26 12:46 ` Ingo Molnar
2010-02-26 12:54 ` Avi Kivity
2010-02-26 13:16 ` Ingo Molnar
2010-02-26 13:57 ` Jes Sorensen
2010-02-26 14:04 ` Avi Kivity
2010-02-26 14:23 ` Ingo Molnar
2010-02-26 15:06 ` Avi Kivity
2010-03-02 16:46 ` Paolo Bonzini
2010-03-02 17:12 ` Arnaldo Carvalho de Melo
2010-03-02 17:20 ` Paolo Bonzini
2010-03-02 17:24 ` Ingo Molnar
2010-03-02 17:17 ` Ingo Molnar
2010-03-07 14:17 ` Avi Kivity
2010-02-26 18:33 ` Avi Kivity
2010-02-27 10:56 ` KVM usability Ingo Molnar
2010-02-27 13:30 ` Jan Kiszka
2010-02-27 13:30 ` [Qemu-devel] " Jan Kiszka
2010-02-27 14:48 ` Ian Kirk
2010-02-27 15:32 ` Zachary Amsden
2010-02-27 17:25 ` Ingo Molnar
2010-03-01 15:33 ` Anthony Liguori
2010-03-01 16:48 ` Zachary Amsden
2010-03-01 17:41 ` Arnaldo Carvalho de Melo
2010-03-01 18:29 ` Zachary Amsden
2010-03-01 20:56 ` Ingo Molnar
2010-03-01 21:45 ` Anthony Liguori
2010-03-01 22:06 ` Zachary Amsden
2010-03-02 0:33 ` Ingo Molnar
2010-03-02 0:30 ` Ingo Molnar
2010-03-02 2:34 ` Anthony Liguori
2010-03-02 8:39 ` Chris Webb
2010-03-07 18:42 ` Avi Kivity
2010-03-02 10:30 ` Ingo Molnar
2010-03-07 9:35 ` Avi Kivity
2010-03-07 9:56 ` Pekka Enberg
2010-03-07 10:11 ` Avi Kivity
2010-03-07 18:42 ` Ingo Molnar
2010-03-07 15:14 ` Luca Barbieri
2010-03-07 18:16 ` Avi Kivity
2010-03-07 18:01 ` Arnaldo Carvalho de Melo
2010-03-07 18:15 ` Avi Kivity
2010-03-07 18:53 ` Arnaldo Carvalho de Melo
2010-03-07 19:05 ` Avi Kivity
2010-03-07 18:25 ` Avi Kivity
2010-03-01 9:25 ` Ingo Molnar
2010-03-01 15:36 ` Anthony Liguori
2010-03-01 15:14 ` Anthony Liguori
2010-03-01 15:42 ` Daniel P. Berrange
2010-03-02 1:12 ` Dustin Kirkland
2010-03-02 10:11 ` Peter Zijlstra
2010-03-02 13:37 ` Nikolai K. Bochev
2010-03-02 14:22 ` Gerd Hoffmann
2010-03-02 14:29 ` Ingo Molnar
2010-03-07 9:22 ` Avi Kivity
2010-03-02 14:37 ` Daniel P. Berrange
2010-03-02 14:52 ` Gerd Hoffmann
2010-03-02 14:56 ` Daniel P. Berrange
2010-03-02 15:13 ` Gerd Hoffmann
2010-03-04 20:00 ` Lucas Meneghel Rodrigues
2010-03-04 20:13 ` Zachary Amsden
2010-03-04 20:34 ` Anthony Liguori
2010-03-04 22:23 ` H. Peter Anvin
2010-03-05 7:44 ` Markus Armbruster
2010-03-07 11:25 ` Avi Kivity
2010-03-01 21:12 ` Dustin Kirkland
2010-03-01 21:59 ` Anthony Liguori
2010-03-02 2:34 ` Alexander Graf
2010-03-02 2:36 ` Anthony Liguori
2010-03-09 13:32 ` Avi Kivity
2010-03-09 14:32 ` Dustin Kirkland
2010-03-09 14:38 ` Alexander Graf
2010-03-09 14:50 ` Anthony Liguori
2010-03-09 14:52 ` Avi Kivity
2010-03-09 14:57 ` Anthony Liguori
2010-03-09 17:11 ` Avi Kivity
2010-03-09 17:27 ` Anthony Liguori
2010-03-09 17:30 ` Avi Kivity
2010-03-09 14:49 ` Anthony Liguori
2010-03-09 14:54 ` Avi Kivity
2010-03-02 3:02 ` Dustin Kirkland
2010-03-02 8:21 ` Chris Webb
2010-03-02 14:54 ` Dustin Kirkland
[not found] ` <428008581.20100302103400@eternallybored.org>
2010-03-07 11:35 ` Avi Kivity
2010-04-04 12:31 ` High CPU use of -usbdevice tablet (was Re: KVM usability) Chris Webb
2010-04-04 12:31 ` [Qemu-devel] " Chris Webb
2010-04-04 14:25 ` Paul Brook
2010-04-04 14:25 ` Paul Brook
2010-04-04 16:58 ` Avi Kivity
2010-04-04 16:58 ` Avi Kivity
2010-04-04 21:03 ` Paul Brook
2010-04-04 21:03 ` Paul Brook
2010-04-04 21:53 ` Paul Brook
2010-04-04 21:53 ` Paul Brook
2010-04-05 8:22 ` Avi Kivity
2010-04-05 8:22 ` Avi Kivity
2010-03-03 2:57 ` KVM usability Ross Boylan
2010-03-03 8:55 ` Daniel P. Berrange
2010-03-03 15:42 ` Ross Boylan
2010-03-07 14:29 ` Avi Kivity
2010-02-26 11:48 ` Enhance perf to support KVM Peter Zijlstra
2010-02-26 11:53 ` Avi Kivity
2010-02-26 20:17 ` Anthony Liguori
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.