subject:"KVM usability"


On 03/09/2010 07:32 AM, Avi Kivity wrote:

On 03/02/2010 04:36 AM, Anthony Liguori wrote:
I keep a patch in the SUSE version for quite some time now that 
bumps the default to 384 for qemu-kvm. That was the first round 
number where an openSUSE installation worked.


If someone works up a patch and tests at least a couple types of 
guests to confirm that they all install with that number, I'd be 
happy to apply it (although we need some trickery to support older pc 
versions).


We should avoid changing defaults.


I disagree.  IMHO, the defaults should represent our best suggestion for 
any given release.  The compatibility machines make it very easier for a 
user to fix on a particular version of a machine type.


Regards,

Anthony Liguori

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 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.patchpackage=kvmproject=Virtualization

It merely changes DEFAULT_RAM_SIZE in vl.c from 128 to 384 for the kvm 
package.
   


We should attempt to do three things with default ram size:

1) bump it up to a more reasonable number
2) make it specified in the global default config
3) make sure we can provide compatibility support for older machine types


Alex
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
   


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/09/2010 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.patchpackage=kvmproject=Virtualization 



It merely changes DEFAULT_RAM_SIZE in vl.c from 128 to 384 for the 
kvm package.


We should attempt to do three things with default ram size:

1) bump it up to a more reasonable number
2) make it specified in the global default config
3) make sure we can provide compatibility support for older machine types


It's really sad, the amount of code needed to change a number.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-09 Thread Alexander Graf


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.patchpackage=kvmproject=Virtualization

It merely changes DEFAULT_RAM_SIZE in vl.c from 128 to 384 for the kvm 
package.


Alex
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/09/2010 04:49 PM, Anthony Liguori wrote:

On 03/09/2010 07:32 AM, Avi Kivity wrote:

On 03/02/2010 04:36 AM, Anthony Liguori wrote:
I keep a patch in the SUSE version for quite some time now that 
bumps the default to 384 for qemu-kvm. That was the first round 
number where an openSUSE installation worked.


If someone works up a patch and tests at least a couple types of 
guests to confirm that they all install with that number, I'd be 
happy to apply it (although we need some trickery to support older 
pc versions).


We should avoid changing defaults.


I disagree.  IMHO, the defaults should represent our best suggestion 
for any given release.  The compatibility machines make it very easier 
for a user to fix on a particular version of a machine type.




Agreed, should have said, avoid changing defaults without taking care of 
backwards compatibility.


--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/09/2010 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.patchpackage=kvmproject=Virtualization 



It merely changes DEFAULT_RAM_SIZE in vl.c from 128 to 384 for the 
kvm package.


We should attempt to do three things with default ram size:

1) bump it up to a more reasonable number
2) make it specified in the global default config
3) make sure we can provide compatibility support for older machine 
types


It's really sad, the amount of code needed to change a number.


We don't do enough via a config.  If we did, we could just have a 0.12 
config version that got frozen over time.


So really, if we can make the mem readable by global config, and we can 
have machine specific configs, it would simplify the problem in the 
future so that we just had to bump a number.


Regards,

Anthony Liguori

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/02/2010 04:36 AM, Anthony Liguori wrote:
I keep a patch in the SUSE version for quite some time now that bumps 
the default to 384 for qemu-kvm. That was the first round number 
where an openSUSE installation worked.


If someone works up a patch and tests at least a couple types of 
guests to confirm that they all install with that number, I'd be happy 
to apply it (although we need some trickery to support older pc 
versions).


We should avoid changing defaults.  I don't think in this case it 
matters, since everyone specifies -m anyway, but as a general rule 
changing defaults = breakage for the unwary.  At least make the default 
part of the machine type to preserve compatibility.


--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/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.patchpackage=kvmproject=Virtualization 



It merely changes DEFAULT_RAM_SIZE in vl.c from 128 to 384 for the 
kvm package.


We should attempt to do three things with default ram size:

1) bump it up to a more reasonable number
2) make it specified in the global default config
3) make sure we can provide compatibility support for older machine 
types


It's really sad, the amount of code needed to change a number.


We don't do enough via a config.  If we did, we could just have a 0.12 
config version that got frozen over time.


So really, if we can make the mem readable by global config, and we 
can have machine specific configs, it would simplify the problem in 
the future so that we just had to bump a number.


Perhaps a json representation of things.  We already have the parser.

--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/09/2010 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.patchpackage=kvmproject=Virtualization 



It merely changes DEFAULT_RAM_SIZE in vl.c from 128 to 384 for the 
kvm package.


We should attempt to do three things with default ram size:

1) bump it up to a more reasonable number
2) make it specified in the global default config
3) make sure we can provide compatibility support for older machine 
types


It's really sad, the amount of code needed to change a number.


We don't do enough via a config.  If we did, we could just have a 
0.12 config version that got frozen over time.


So really, if we can make the mem readable by global config, and we 
can have machine specific configs, it would simplify the problem in 
the future so that we just had to bump a number.


Perhaps a json representation of things.  We already have the parser.


Please no :-)

We have a config format, QemuOpts ties nicely into it as does qdev.  We 
just need to represent machine information via QemuOpts and tie -m to 
manipulating the memory assigned to a machine.  IOW, instead of:


(machine_init)(ram_addr_t ram_size,
const char *boot_device,
const char *kernel_filename,
const char *kernel_cmdline,
const char *initrd_filename,
const char *cpu_model)

It should be:

(machine_init)(QemuOpts *opts);

Then we can have a [machine] section in the config where we describe all 
of these things.


Regards,

Anthony Liguori


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/09/2010 07:27 PM, Anthony Liguori wrote:

Perhaps a json representation of things.  We already have the parser.



Please no :-)

We have a config format, QemuOpts ties nicely into it as does qdev.  
We just need to represent machine information via QemuOpts and tie -m 
to manipulating the memory assigned to a machine.  IOW, instead of:


(machine_init)(ram_addr_t ram_size,
const char *boot_device,
const char *kernel_filename,
const char *kernel_cmdline,
const char *initrd_filename,
const char *cpu_model)

It should be:

(machine_init)(QemuOpts *opts);

Then we can have a [machine] section in the config where we describe 
all of these things.


Looks good.

One day we'll read VHDL descriptions of the device model from the 
machine config file and tcg them to host native code, and qemu will be 
pure infrastructure with zero details.


--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/02/2010 04:29 PM, Ingo Molnar wrote:


I guess the first step would be to move away from the 'lets support lots of
crappy virtualization solutions at once, poorly' model, and pick one good
combo (i'd go for Qemu+KVM) and turn it into a heck of an all-around solution.
Then all the other combos will catch up as well. (or will wither away)
   


Should desktop integration be GNOME or KDE based?

IMO this should be addressed via a plugin system so that we can have a 
well integrated single process VM, without choosing one or the other.  
Also, the qemu community doesn't really have serious graphics design 
expertise; best to leave that to people who won't make it a total disaster.



( Sidenote: i also looked at the VirtualBox kernel driver. Oh my ... i really
   shouldnt have! They should migrate to the KVM kernel-side code ASAP ... )
   


They can't, if they want to continue to support hardware without 
virtualization extensions.


--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/02/2010 12:30 PM, Ingo Molnar wrote:

* Ingo Molnarmi...@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 RD budget can consistently out-develop Linux. I
think that's in part due to there not being a strict chinese wall between the
Apple kernel, libraries and applications - it's one coherent project where
everyone is well-connected to each piece, with no artificial project-cultural
boundaries and barriers. People can and do move between those areas of the
larger Apple project to achieve their goals - regardless of how many
components need touching for a given area of interest.

IMHO we should learn from that - while we are good in many areas there's
always aspects of Linux that can be improved. But i digress.
   


Folding everything into the kernel tree is one way to approach it; IMO 
it is completely unreasonable.  The kernel is a very small part of a 
complete system.


--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-07 Thread Pekka Enberg

Hi Avi,

(slightly off-topic)

On Sun, Mar 7, 2010 at 11:35 AM, Avi Kivity a...@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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/07/2010 11:56 AM, Pekka Enberg wrote:

Hi Avi,

(slightly off-topic)

On Sun, Mar 7, 2010 at 11:35 AM, Avi Kivitya...@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

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/01/2010 05:14 PM, Anthony Liguori wrote:
  - Graphics performance is awful even with the 640x480 miniature 
version.
During bootup I can see it drawing single characters. This is a 
Core2

2.8GHz.



That's a bug.  Please report it.  Graphics performance isn't great, 
but it should not be that bad.


(This is in grub, right?)

That's not fixable in kvm.  In 4-bit vga mode you cannot allow the guest 
to access emulated VRAM directly (since each access has side effects).  
A Core 2 will only do about 250K emulations per second, so screen 
redraws take about 3 seconds.


--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/02/2010 11:34 AM, Jernej Simončič wrote:

On Tuesday, March 2, 2010, 9:21:18, Chris Webb wrote:

   

I remember about a year ago, someone asserting on the list that -usbdevice
tablet was very CPU intensive even when not in use, and should be avoided if
mouse support wasn't needed, e.g. on non-graphical VMs. Was that actually a
significant hit, and is it still true today?
 

It would appear that this is still the case, at least on slower hosts
- on Atom Z530 (1,6GHz), the XP VM uses ~30% CPU when idle with
-usbdevice tablet, but only ~4% without it. However, on a faster host
(Core2 Quad 2,66GHz), there's practically no difference (Vista x64 VM
uses ~1% CPU when idle regardless of -usbdevice tablet).
   


Looks like the tablet is set to 100 Hz polling rate.  We may be able to 
get away with 30 Hz or even less (ep_bInterval, in ms, in hw/usb-wacom.c).


--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/03/2010 05:42 PM, Ross Boylan wrote:

Of course this is itself still far from optimal
as a user experiance. We really want it to be fully configured to any
resolution as easily as the user would do with a real graphics card
monitor.
 

Is there some obstacle to getting the virtual monitor to provide
configuration info when it's queried?  That seems like the most direct
solution.
   


That was my conclusion as well.  All that's missing is something to code 
it up.


--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-07 Thread Luca Barbieri

 perf really is wonderful, but to be really competitive, and usable to more
 developers, it needs to be in a graphical environment.  I want 'perf report'
 output to start out collapsed and drill down by clicking on a tree widget.
  Clicking on a function name opens its definition.  'perf annotate' should
 display annotations on my editor window, not in a pager.  I should be able
 to check events on a list, not using 'perf list'.

 Is something like that suitable for tools/perf/?  I think you'll find the
 intersection of kernel developers and GUI developers to be fairly small.

The latest versions of Gnome Sysprof use perf and provide a GTK+ tree
interface for the profiling output.

However, they are not configurable at all and don't support anything
but call graph profiling, unless they added more features very
recently.
It would be nice to extend sysprof into a more capable tool, and one
that can read perf output files and do so when launched from the
command line.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-07 Thread Arnaldo Carvalho de Melo

Em Sun, Mar 07, 2010 at 11:35:31AM +0200, Avi Kivity escreveu:
 perf really is wonderful, but to be really competitive, and usable to  
 more developers, it needs to be in a graphical environment.  I want  
 'perf report' output to start out collapsed and drill down by clicking  
 on a tree widget.  Clicking on a function name opens its definition.   
 'perf annotate' should display annotations on my editor window, not in a  
 pager.  I should be able to check events on a list, not using 'perf 
 list'.

Do you really think that more kernel developers would use perf more
frequently if it had some GUI?

I plan to work on a ncurses tool combining aspects of the existing perf
tools, integrating them more, like you suggest above, but even having
worked on a pygtk tool that is close to the kernel [1], I'm unsure if
doing it using gtk or QT would be something that would entice more
developers to use it.

- Arnaldo

[1] http://www.osadl.org/Single-View.111+M52212cb1379.0.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/07/2010 08:01 PM, Arnaldo Carvalho de Melo wrote:

Em Sun, Mar 07, 2010 at 11:35:31AM +0200, Avi Kivity escreveu:
   

perf really is wonderful, but to be really competitive, and usable to
more developers, it needs to be in a graphical environment.  I want
'perf report' output to start out collapsed and drill down by clicking
on a tree widget.  Clicking on a function name opens its definition.
'perf annotate' should display annotations on my editor window, not in a
pager.  I should be able to check events on a list, not using 'perf
list'.
 

Do you really think that more kernel developers would use perf more
frequently if it had some GUI?
   


Not much.  Is perf's target kernel developers exclusively?  Who are we 
writing this kernel for?


No wonder everything is benchmarked using kbuild.


I plan to work on a ncurses tool combining aspects of the existing perf
tools, integrating them more, like you suggest above, but even having
worked on a pygtk tool that is close to the kernel [1], I'm unsure if
doing it using gtk or QT would be something that would entice more
developers to use it.
   


Even for kernel developers there are advantages in a GUI, namely that 
features are easily discovered, the amount of information is easily 
controlled, and in that you can interact (not redo everything from 
scratch every time you want to change something).  The difference 
between a curses based tool and a true GUI are minimal for this audience.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/07/2010 05:14 PM, Luca Barbieri wrote:

perf really is wonderful, but to be really competitive, and usable to more
developers, it needs to be in a graphical environment.  I want 'perf report'
output to start out collapsed and drill down by clicking on a tree widget.
  Clicking on a function name opens its definition.  'perf annotate' should
display annotations on my editor window, not in a pager.  I should be able
to check events on a list, not using 'perf list'.

Is something like that suitable for tools/perf/?  I think you'll find the
intersection of kernel developers and GUI developers to be fairly small.
 

The latest versions of Gnome Sysprof use perf and provide a GTK+ tree
interface for the profiling output.

However, they are not configurable at all and don't support anything
but call graph profiling, unless they added more features very
recently.
It would be nice to extend sysprof into a more capable tool, and one
that can read perf output files and do so when launched from the
command line.
   


Looks like a step in the right direction.  I don't think this belong in 
tools/, though.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 02/27/2010 07:25 PM, Ingo Molnar wrote:

* Zachary Amsdenzams...@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.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/02/2010 02:30 AM, Ingo Molnar wrote:

* Anthony Liguorianth...@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

Re: KVM usability


On 03/07/2010 08:53 PM, Arnaldo Carvalho de Melo wrote:

Do you really think that more kernel developers would use perf more
frequently if it had some GUI?
   

Not much.  Is perf's target kernel developers exclusively?  Who are
we writing this kernel for?
 

No, we aren't writing this tool only for kernel developers exclusively,
but that wasn't my question, it was badly formulated, sorry, I shouldn't
have included kernel in it :-\
   


In this case, I will reformulate my answer.  Very much.


Even for kernel developers there are advantages in a GUI, namely
that features are easily discovered, the amount of information is
easily controlled, and in that you can interact (not redo everything
from scratch every time you want to change something).  The
difference between a curses based tool and a true GUI are minimal
for this audience.
 

Ok, I agree with you about easier discoverability of features, path
shortened from report to annotate to starting the editor right at the
line where some event of interest happened,


Another path is browse some function, start profiling, see perf data 
fill up in the margin.  Or, jump to callers.  etc.  You need an 
integrated browser for that (or an emacs perf mode).



will try to keep the
routines not much coupled with ncurses, but definetely ncurses will be
the first step.
   


Great.  ncurses is certainly much easier to experiment with and will 
likely provide useful experience.


--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-04 Thread Lucas Meneghel Rodrigues

On Tue, 2010-03-02 at 11:11 +0100, Peter Zijlstra wrote:
 On Mon, 2010-03-01 at 09:14 -0600, Anthony Liguori wrote:
  The real 
  question to ask is, why are you using qemu directly instead of using 
  virt-manager? 
 
 Because I suspect Ingo, like me, is a command line user, launching a gui
 to start kvm when there is a kvm command around just sounds daft.
 
 Also, I just installed and tried it, virt-manager is a total piece of
 shit, 

That statement is far from being fair. I use virt-manager quite a lot,
since I want to keep track of what's going on on KVM virtualization for
end users in Fedora. What's shipped with Fedora 12 is pretty decent in
many regards, but as in any other software there's plenty of room for
improvements.

 I wouldn't even know how to begin telling it how to start my
 freshly baked kernel with serial console on stdio and some block image I
 just created from the gentoo stage3 tarball.

Fair enough, it is convoluted to do what you want using virt-manager
(although possible), but mainly because this wasn't a use case for it.
You can't expect the application designers to support every single type
of work flow under the sun.

 That is, after 5 minutes clicking I have no idea how to even launch an
 ISO with the thing, I prefer reading the kvm manpage over using some
 mouse only gui crap like that.

For the 1st thing you wanted to do, I agree that it was cumbersome. But
to create a VM and make it boot an ISO available on your hard drive it
*is* trivial. There's a wizard to do it, because it's the main use case
of the thing.

If you want to point out problems on virt-manager that is fine, and the
developers will do what is possible to address problems, insults are not
necessary.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-04 Thread Zachary Amsden


On 03/04/2010 10:00 AM, Lucas Meneghel Rodrigues wrote:

On Tue, 2010-03-02 at 11:11 +0100, Peter Zijlstra wrote:
   

On Mon, 2010-03-01 at 09:14 -0600, Anthony Liguori wrote:
 

The real
question to ask is, why are you using qemu directly instead of using
virt-manager?
   

Because I suspect Ingo, like me, is a command line user, launching a gui
to start kvm when there is a kvm command around just sounds daft.

Also, I just installed and tried it, virt-manager is a total piece of
shit,
 

That statement is far from being fair. I use virt-manager quite a lot,
since I want to keep track of what's going on on KVM virtualization for
end users in Fedora. What's shipped with Fedora 12 is pretty decent in
many regards, but as in any other software there's plenty of room for
improvements.
   


The biggest problem with virt-manager isn't virt-manager, it's that it 
is trying to do a nearly intractable task.  Because a qemu virtual 
machine is not a machine at all, just a disk image without the proper 
metadata to track the important properties of the machine, like what 
revision of PCI chipset, how many disk controllers the thing is using, 
what kind of graphics card, etc.


These are all basic things that are left completely undefined by qemu's 
lack of a top-level configuration file, and it's an inexcusable disgrace.


So virt-manager or any other management tool has the burden of creating 
and maintaining a bunch of metadata around this workhorse tool called 
qemu and invoking libvirt to figure out which set of 100,000 blasted 
command line options to pass on.


That's why it falls short of expectations at times, not because 
virt-manager is crap, but because there is no well defined, well 
designed infrastructure for it to manage and the ad-hoc solution here is 
total crap.


Zach
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-04 Thread Anthony Liguori


On 03/04/2010 02:13 PM, Zachary Amsden wrote:


The biggest problem with virt-manager isn't virt-manager, it's that it 
is trying to do a nearly intractable task.  Because a qemu virtual 
machine is not a machine at all, just a disk image without the proper 
metadata to track the important properties of the machine, like what 
revision of PCI chipset, how many disk controllers the thing is using, 
what kind of graphics card, etc.


These are all basic things that are left completely undefined by 
qemu's lack of a top-level configuration file, and it's an inexcusable 
disgrace.


So virt-manager or any other management tool has the burden of 
creating and maintaining a bunch of metadata around this workhorse 
tool called qemu and invoking libvirt to figure out which set of 
100,000 blasted command line options to pass on.


That's why it falls short of expectations at times, not because 
virt-manager is crap, but because there is no well defined, well 
designed infrastructure for it to manage and the ad-hoc solution here 
is total crap.


And this is why we're doing QMP and qdev.  It's long overdue 
infrastructure.  It's not just the problem that you describe though.  
virt-manager is limited by what libvirt provides and today libvirt does 
not expose nearly enough qemu features for virt-manager to even attempt 
to solve the problem on it's own.


Regards,

Anthony Liguori


Zach


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-04 Thread H. Peter Anvin

On 03/04/2010 12:13 PM, Zachary Amsden wrote:
 
 These are all basic things that are left completely undefined by qemu's 
 lack of a top-level configuration file, and it's an inexcusable disgrace.
 

There is a top-level configuration file for Qemu, at least in the
development tree.  It's optional, still, but it's there now.

-hpa
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-04 Thread Markus Armbruster

H. Peter Anvin h...@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.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-03 Thread Daniel P. Berrange

On Tue, Mar 02, 2010 at 06:57:54PM -0800, Ross Boylan wrote:
 On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote:
  
 * desktop is 1024 x 720
  
  
  1024x768 and this is what the default is today anyway.
 That was not my experience, as reported in my post a few days ago
 (800x600 max resolution), nor is it the experience reported in the
 message that kicked off this thread.
 
 I have been able to get a higher resolution, but it was far from
 automatic.

It depends on the guest OS version. QEMU exposes a cirrus logic card by
defualt, and given the lack of vsync/hsync info, the Xorg driver will
pick 800x600 as the default resolution in absence of any Xorg.conf About
6 months or so back, we got Xorg guys to add a code to the Xorg cirrus
driver that looked for the QEMU PCI subsystem ID and if found, defaults
to 1024x768 instead. Of course this is itself still far from optimal
as a user experiance. We really want it to be fully configured to any
resolution as easily as the user would do with a real graphics card 
monitor.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-03 Thread Ross Boylan

On Wed, 2010-03-03 at 08:55 +, Daniel P. Berrange wrote:
 On Tue, Mar 02, 2010 at 06:57:54PM -0800, Ross Boylan wrote:
  On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote:
   
  * desktop is 1024 x 720
   
   
   1024x768 and this is what the default is today anyway.
  That was not my experience, as reported in my post a few days ago
  (800x600 max resolution), nor is it the experience reported in the
  message that kicked off this thread.
  
  I have been able to get a higher resolution, but it was far from
  automatic.
 
 It depends on the guest OS version. QEMU exposes a cirrus logic card by
 defualt, 
QEMU docs recommend -std vga for higher resolutions; I used that.
 and given the lack of vsync/hsync info, the Xorg driver will
 pick 800x600 as the default resolution in absence of any Xorg.conf About
 6 months or so back, we got Xorg guys to add a code to the Xorg cirrus
 driver that looked for the QEMU PCI subsystem ID and if found, defaults
 to 1024x768 instead. 
So presumably that logic wouldn't have kicked in.  I had xorg 7.5 on
Debian squeeze as the guest.
 Of course this is itself still far from optimal
 as a user experiance. We really want it to be fully configured to any
 resolution as easily as the user would do with a real graphics card 
 monitor.
Is there some obstacle to getting the virtual monitor to provide
configuration info when it's queried?  That seems like the most direct
solution.

Ross


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-02 Thread Chris Webb

Dustin Kirkland kirkl...@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.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-02 Thread Chris Webb

Ingo Molnar mi...@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.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-02 Thread Peter Zijlstra

On Mon, 2010-03-01 at 09:14 -0600, Anthony Liguori wrote:
 The real 
 question to ask is, why are you using qemu directly instead of using 
 virt-manager? 

Because I suspect Ingo, like me, is a command line user, launching a gui
to start kvm when there is a kvm command around just sounds daft.

Also, I just installed and tried it, virt-manager is a total piece of
shit, I wouldn't even know how to begin telling it how to start my
freshly baked kernel with serial console on stdio and some block image I
just created from the gentoo stage3 tarball.

That is, after 5 minutes clicking I have no idea how to even launch an
ISO with the thing, I prefer reading the kvm manpage over using some
mouse only gui crap like that.

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-02 Thread Ingo Molnar


* Ingo Molnar mi...@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 RD budget can consistently out-develop Linux. I 
think that's in part due to there not being a strict chinese wall between the 
Apple kernel, libraries and applications - it's one coherent project where 
everyone is well-connected to each piece, with no artificial project-cultural 
boundaries and barriers. People can and do move between those areas of the 
larger Apple project to achieve their goals - regardless of how many 
components need touching for a given area of interest.

IMHO we should learn from that - while we are good in many areas there's 
always aspects of Linux that can be improved. But i digress.

Thanks,

Ingo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-02 Thread Nikolai K. Bochev

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 pet...@infradead.org
To: Anthony Liguori anth...@codemonkey.ws
Cc: Ingo Molnar mi...@elte.hu, Avi Kivity a...@redhat.com, Yanmin Zhang 
yanmin_zh...@linux.intel.com, ming m lin ming.m@intel.com, sheng yang 
sheng.y...@intel.com, Jes Sorensen jes.soren...@redhat.com, KVM General 
kvm@vger.kernel.org, Zachary Amsden zams...@redhat.com, Gleb Natapov 
g...@redhat.com, Arnaldo Carvalho de Melo a...@redhat.com, Fr??d??ric 
Weisbecker fweis...@gmail.com, Thomas Gleixner t...@linutronix.de, H. Peter 
Anvin h...@zytor.com, Arjan van de Ven ar...@infradead.org, Cole Robinson 
crobi...@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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-02 Thread Gerd Hoffmann


On 03/02/10 14:37, Nikolai K. Bochev wrote:

I don't see where this argument is leading to. So far there are
arguments that qemu/kvm sucks as a desktop virtualization, now
suddenly the gui tools are shitty and everything should be done cli ,
because there's no man pages for virt-manager. Explain.


Lets face it:  virt-manager has a big bunch of problems.  For starters 
there is no (gui) way to create a virtual machine other than installing 
one from a iso image or via pxe.  So if you downloaded a disk image and 
want to boot it - no cookie for you.  Likewise if you have a bunch of 
already installed guests and want to migrate from $othertool to 
virt-manager you can't do that easily.


virt-manager builds on top of libvirt, so you always have the option to 
use other tools (virsh command line shell for example) to get something 
done which virt-manager doesn't provide a gui for.  libvirt can handle 
everything Peter asked for without problems.  It still sucks though. 
The whole point of a GUI is that you do *not* have to go to libvirt.org 
to figure how to tweak the virtual machine config xml using virsh edit 
$vmname.


cheers,
  Gerd

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-02 Thread Daniel P. Berrange

On Tue, Mar 02, 2010 at 03:22:07PM +0100, Gerd Hoffmann wrote:
 On 03/02/10 14:37, Nikolai K. Bochev wrote:
 I don't see where this argument is leading to. So far there are
 arguments that qemu/kvm sucks as a desktop virtualization, now
 suddenly the gui tools are shitty and everything should be done cli ,
 because there's no man pages for virt-manager. Explain.
 
 Lets face it:  virt-manager has a big bunch of problems.  For starters 
 there is no (gui) way to create a virtual machine other than installing 
 one from a iso image or via pxe.  So if you downloaded a disk image and 
 want to boot it - no cookie for you.  Likewise if you have a bunch of 
 already installed guests and want to migrate from $othertool to 
 virt-manager you can't do that easily.

The ability to import existing KVM disk images is available in the 
latest release of virt-manager, targetted for Fedora 13. Migrating
from another tool like VMWare is a much harder than just importing
the disk image, since you have to update the drivers inside the guest,
likely reconfigure several config files, etc, etc. There is work on
a full v2v tool to automate this task, for both Linux  Windows guests.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-02 Thread Ingo Molnar


* Gerd Hoffmann kra...@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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-02 Thread Gerd Hoffmann


On 03/02/10 15:37, Daniel P. Berrange wrote:

On Tue, Mar 02, 2010 at 03:22:07PM +0100, Gerd Hoffmann wrote:

On 03/02/10 14:37, Nikolai K. Bochev wrote:

I don't see where this argument is leading to. So far there are
arguments that qemu/kvm sucks as a desktop virtualization, now
suddenly the gui tools are shitty and everything should be done cli ,
because there's no man pages for virt-manager. Explain.


Lets face it:  virt-manager has a big bunch of problems.  For starters
there is no (gui) way to create a virtual machine other than installing
one from a iso image or via pxe.  So if you downloaded a disk image and
want to boot it -  no cookie for you.  Likewise if you have a bunch of
already installed guests and want to migrate from $othertool to
virt-manager you can't do that easily.


The ability to import existing KVM disk images is available in the
latest release of virt-manager, targetted for Fedora 13.


Glad to hear that.  Are these bits in F12 virt-preview already?


Migrating
from another tool like VMWare  is a much harder than just importing
the disk image, since you have to update the drivers inside the guest,
likely reconfigure several config files, etc, etc. There is work on
a full v2v tool to automate this task, for both Linux  Windows guests.


I meant migrating from another qemu management tool, be it some other 
gui tool or self-baked shell scripts or something else.


Migrating from other virtualization products is harder of course.

cheers,
  Gerd
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-02 Thread Dustin Kirkland

On Tue, Mar 2, 2010 at 2:21 AM, Chris Webb ch...@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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-02 Thread Daniel P. Berrange

On Tue, Mar 02, 2010 at 03:52:52PM +0100, Gerd Hoffmann wrote:
 On 03/02/10 15:37, Daniel P. Berrange wrote:
 On Tue, Mar 02, 2010 at 03:22:07PM +0100, Gerd Hoffmann wrote:
 On 03/02/10 14:37, Nikolai K. Bochev wrote:
 I don't see where this argument is leading to. So far there are
 arguments that qemu/kvm sucks as a desktop virtualization, now
 suddenly the gui tools are shitty and everything should be done cli ,
 because there's no man pages for virt-manager. Explain.
 
 Lets face it:  virt-manager has a big bunch of problems.  For starters
 there is no (gui) way to create a virtual machine other than installing
 one from a iso image or via pxe.  So if you downloaded a disk image and
 want to boot it -  no cookie for you.  Likewise if you have a bunch of
 already installed guests and want to migrate from $othertool to
 virt-manager you can't do that easily.
 
 The ability to import existing KVM disk images is available in the
 latest release of virt-manager, targetted for Fedora 13.
 
 Glad to hear that.  Are these bits in F12 virt-preview already?

I believe so.

 Migrating
 from another tool like VMWare  is a much harder than just importing
 the disk image, since you have to update the drivers inside the guest,
 likely reconfigure several config files, etc, etc. There is work on
 a full v2v tool to automate this task, for both Linux  Windows guests.
 
 I meant migrating from another qemu management tool, be it some other 
 gui tool or self-baked shell scripts or something else.

That's pretty much what the 'disk import' could deal with, unless we wanted
to provide a way to read the config files from those other  qemu mgmt tools
directly on a case-by-case basis

Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-02 Thread Gerd Hoffmann


On 03/02/10 15:56, Daniel P. Berrange wrote:

Glad to hear that.  Are these bits in F12 virt-preview already?


I believe so.


/me goes fetch updates to check it out.


Migrating

from another tool like VMWare  is a much harder than just importing

the disk image, since you have to update the drivers inside the guest,
likely reconfigure several config files, etc, etc. There is work on
a full v2v tool to automate this task, for both Linux   Windows guests.


I meant migrating from another qemu management tool, be it some other
gui tool or self-baked shell scripts or something else.


That's pretty much what the 'disk import' could deal with,  unless we wanted
to provide a way to read the config files from those other  qemu mgmt tools
directly on a case-by-case basis


What I'll expect:

At minimum a way to create a virtual machine without the auto-started 
installation, with no or minimal hardware plugged in, so I can configure 
it the way I want via add hardware, then boot it.


Better would be some dialog to shortcut the add hardware clicking for 
the most common stuff, i.e. a single dialog box asking for disk image, 
nic type, mac address, sound card, serial console.  I guess this is 
roughly what the disk import feature will do for me.


Analyzing the guest image, trying to figure what nic, disk and mac 
address it expects and pre-filling the dialog box with the results would 
be really great.  I suspect that is alot of work for little gains, but 
hey, maybe the v2v tool has most of the bits needed for that anyway, so 
we can get that nevertheless.


cheers,
  Gerd
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-02 Thread Ross Boylan

On Mon, 2010-03-01 at 15:59 -0600, Anthony Liguori wrote:
 
* desktop is 1024 x 720
 
 
 1024x768 and this is what the default is today anyway.
That was not my experience, as reported in my post a few days ago
(800x600 max resolution), nor is it the experience reported in the
message that kicked off this thread.

I have been able to get a higher resolution, but it was far from
automatic.

I believe the root cause is the failure of the virtual monitor to
respond to or provide EDID (?) to tell the kernel available screen
resolutions, sync values, and similar information.  I recall seeing an
open bug on this, not sure if it was kvm or qemu.  I also recall it had
been open for a fairly long time.

Ross

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


* Zachary Amsden zams...@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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 02/27/2010 04:56 AM, Ingo Molnar wrote:

* Avi Kivitya...@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:


anth...@squirrel:~/images$ file linux.img
linux.img: Qemu Image, Format: Qcow , Version: 2

We intentionally don't want images to be directly executable.  An image 
doesn't include the necessary configuration information to launch a 
guest.  Adding that info to an image is not an obvious thing to do 
either because a virtual machine may consist of multiple images.



  - Random bugs. I tried to boot some old Fedora image i had around, it says:

  spirit:~/qemu  qemu-kvm ./hda-fedora.img
  kvm: unhandled exit 8021
  kvm_run returned -22
   


This error message is horrible and it warrants a bug report.   See 
https://bugs.launchpad.net/qemu/+bug/530077



  - When it boots up, the Qemu window flips around its size crazily, as the 
BIOS,
the bootloader and the OS sets different screen resolutions. To the user 
that
technical detail is immaterial, what matters is an amateurish-looking app
that flips its window size as if it was an adware popup window trying to
avoid being caught.
   


All virtualization software does this and I think it's completely 
reasonable.  Again, you can resize the window manually and it'll keep 
that resolution if you are so inclined.  As KMS is better supported in 
Linux guests, we'll eventually get to the point where less screen

Re: KVM usability


On 02/27/2010 11:25 AM, Ingo Molnar wrote:

* Zachary Amsdenzams...@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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/01/2010 03:25 AM, Ingo Molnar wrote:

* Zachary Amsdenzams...@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
   


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-01 Thread Daniel P. Berrange

On Mon, Mar 01, 2010 at 09:14:02AM -0600, Anthony Liguori wrote:
 On 02/27/2010 04:56 AM, Ingo Molnar wrote:
 
 The other type of user we target is power virtualization/emulation 
 users.  We certainly could do better for this type of user but it's 
 never going to fit what your expectation of desktop virtualization is.  
 Qemu is never going to be like running VMware Workstation or VirtualBox.
 
 There is very little split between qemu and kvm from a project 
 perspective.  If anything, our lack of focus on desktop virtualization 
 comes from the split between qemu/kvm and libvirt.  All of the end-user 
 usability is done in the context of libvirt and virt-manager whereas the 
 qemu/kvm developers tend to focus on performance, features, and robustness.
 
 I think we don't spend enough time in qemu/kvm thinking about how we 
 interact with libvirt with respect to end-to-end usability.  It's 
 something I do believe we need to address and it's an area I have been 
 focusing on recently.

On the other side of things, we (in libvirt community) have tended to be
more focused on server virtualization use cases, than desktop ones. There
is certainly alot more we could be doing for end user desktop usability
in both libvirt  QEMU/KVM parts. As  when we move forward with spice
integration, we'll get some significant improvements in usability through
the improved graphics performance, flexible guest display resolution, and
audio tunnelling to the clients.

Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-01 Thread Zachary Amsden


On 02/27/2010 07:25 AM, Ingo Molnar wrote:

* Zachary Amsdenzams...@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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-01 Thread Arnaldo Carvalho de Melo

Em Mon, Mar 01, 2010 at 06:48:07AM -1000, Zachary Amsden escreveu:
 On 02/27/2010 07:25 AM, Ingo Molnar wrote:
 I'm not talking about moving it into a kernel _module_ - albeit that
 alone is a worthwile thing to do for any performance sensitive hw
 component.

 I was talking about the option of a clean, stripped down Qemu base
 hosted in the kernel proper, in linux/tools/kvm/ or so. If i were
 running a virtualization effort it would be the first place i'd
 consider to put my tooling into.

 So ripping out a clean part interface like PCI bus infrastructure and  
 using it in the kernel, for example, does nothing except put that  
 infrastructure in two different places, because everything the kernel  
 does, userspace will have to do again anyway.  So now you have twice as  
 much code involving the same idea and you have to keep the pieces in  
 sync and from trampling each other.

 The only parts that warrant such complexity and high risk for bugs are  
 performance critical things like the PIT and APIC.

I guess there is some misunderstanding here, the tools/ directory that
lives in the kernel _sources_, has no kernel source, its all userspace
stuff.

- Arnaldo
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-01 Thread Zachary Amsden


On 03/01/2010 07:41 AM, Arnaldo Carvalho de Melo wrote:

Em Mon, Mar 01, 2010 at 06:48:07AM -1000, Zachary Amsden escreveu:
   

On 02/27/2010 07:25 AM, Ingo Molnar wrote:
 

I'm not talking about moving it into a kernel _module_ - albeit that
alone is a worthwile thing to do for any performance sensitive hw
component.

I was talking about the option of a clean, stripped down Qemu base
hosted in the kernel proper, in linux/tools/kvm/ or so. If i were
running a virtualization effort it would be the first place i'd
consider to put my tooling into.
   
   

So ripping out a clean part interface like PCI bus infrastructure and
using it in the kernel, for example, does nothing except put that
infrastructure in two different places, because everything the kernel
does, userspace will have to do again anyway.  So now you have twice as
much code involving the same idea and you have to keep the pieces in
sync and from trampling each other.

The only parts that warrant such complexity and high risk for bugs are
performance critical things like the PIT and APIC.
 

I guess there is some misunderstanding here, the tools/ directory that
lives in the kernel _sources_, has no kernel source, its all userspace
stuff.


Yeah, no morning coffee :=)

So instead we are advocating forking qemu into the kernel.  That makes 
even less sense.  It's not sustainable or eco-friendly to either community.


Zach
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


* Zachary Amsden zams...@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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-01 Thread Dustin Kirkland

On Sat, Feb 27, 2010 at 4:56 AM, Ingo Molnar mi...@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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/01/2010 02:56 PM, Ingo Molnar wrote:

Here's our experience with tools/perf/. Hosting the project in the kernel
proper helped its quality immensely:

  - It's much easier to synchronize new features on the kernel side and on the
user-space side. The two go hand in hand - they are often implemented in
the same patch.
   


Kernel features and qemu features usually don't have a great amount of 
intersect.  All of the problems you've described are strictly in the 
qemu space.



  - It's released together with the kernel, which gives a periodic 3 months
release frequency. Not too slow, not too fast.
   


qemu release range in length from 3-6 months depending on distribution 
schedules.  They are very regular.



  - Lots of eyeballs and interest. In its mere 8 months of existence
tools/perf/ has attracted more than 60 contributors already, and 35 KLOC of
new code has been written.
   


In our last release, we had around 100 contributors and about 100 KLOC 
of code written.  We've got a lot of eyeballs and a lot of interest.



  - Code quality requirements are that of the kernel's. No muck allowed and
it's not hard to explain what kind of code is preferred.
   


Code quality is subjective.  We have a different coding style.


  - Tool breakage bisection is a breeze: there's never any mismatch between
tools/perf and the kernel counterpart. With a separate package we'd
have more complex test and bisection scenarios.
   


KVM has a backwards compatible ABI so there's no such thing as mismatch 
between user and kernel space.



  - Code distribution is easy: it comes with the kernel. This spreads the code
far and wide. It's easy for kernel developers to jump in and help out, the
latest devel code is always there, a single 'cd tools/perf/; make -j 
install'
command away.
  - Code reuse: we started sharing/librarizing code with the kernel: bitmap.h,
hash.h, list.h, rbtree.h, bitops.h, prefetch.h.
   


You could argue that any project should be in the kernel for these 
reasons.  I see no reason why something as like KVM should be part of 
the kernel and udev shouldn't be.



etc.

In the KVM context this was obviously only a suggestion though. If i were
hacking on kvm-qemu i wouldnt hesitate for a moment to do it: the project has
very close ties to kernel-KVM and repo level unification would create various
synergies - but you are hacking on it, not me ;-)

If i were doing it i'd probably start with a cleaned up and stripped down
version of Qemu, to make it eligible for mainline kernel inclusion.
   


You should try it.  I think you'll find that it's not as obvious thing 
to do as you think it is.


Regards,

Anthony Liguori


Ingo
   


--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

On 03/01/2010 03:12 PM, Dustin Kirkland wrote:

Among these:
* 512MB is a nice step up from the 128MB by default (this one scales
based on your hosts memory)

I'm not opposed to bumping from 128M to something else. I'd like to see
some indication though other than seems reasonable as to what the
value should be. For instance, if a Fedora 12 install doesn't work
without 256M, that's a solid argument to bump the allocation. Short
term, I'd like to see this globally configurable.

* virtio is used for disk and network for nice performance gains

The problem with virtio is that very few OSes have the drivers right
now. For networking, we can do better, and I've just written a spec for
a new feature to attempt to address this[1]. For disk, I think we're
stuck with ide as the default for a long time.

* usb device tablet greatly improves the mouse experience

Defaulting usb to on and defaulting to a usb tablet is a reasonable
thing to do IMHO.

* sound card added

This personally would annoy me but if there was wide consensus that this
was right, I'd be okay with it.

* qcow2 sparse disk image

This is independent of qemu.

* desktop is 1024 x 720

1024x768 and this is what the default is today anyway.

[1] http://wiki.qemu.org/Features/NetDeviceFailover

Regards,

Anthony Liguori

--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-01 Thread Zachary Amsden


On 03/01/2010 11:45 AM, Anthony Liguori wrote:

On 03/01/2010 02:56 PM, Ingo Molnar wrote:

  - Code distribution is easy: it comes with the kernel. This spreads 
the code
far and wide. It's easy for kernel developers to jump in and help 
out, the
latest devel code is always there, a single 'cd tools/perf/; make 
-j install'

command away.
  - Code reuse: we started sharing/librarizing code with the kernel: 
bitmap.h,

hash.h, list.h, rbtree.h, bitops.h, prefetch.h.


You could argue that any project should be in the kernel for these 
reasons.  I see no reason why something as like KVM should be part of 
the kernel and udev shouldn't be.


gcc and the kernel are quite closely coupled, btw.




etc.

In the KVM context this was obviously only a suggestion though. If i 
were
hacking on kvm-qemu i wouldnt hesitate for a moment to do it: the 
project has
very close ties to kernel-KVM and repo level unification would create 
various

synergies - but you are hacking on it, not me ;-)

If i were doing it i'd probably start with a cleaned up and stripped 
down

version of Qemu, to make it eligible for mainline kernel inclusion.


You should try it.  I think you'll find that it's not as obvious thing 
to do as you think it is.


Yes.  Yes.

We've all looked at the hulking hairy behemoth of qemu and said, I think 
I can clean this beast up and make him look like a proper gentlemen.  
Then we tried to shave off the excess hair, only to find not only did it 
grow back as fast as we trimmed it, but his complexion underneath was 
mottled and inconsistent, so much so that the hair was actually helping.


In the end, we just settled for dressing him up in a suit and tie.

Zach
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


* Anthony Liguori anth...@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

Re: KVM usability


* Zachary Amsden zams...@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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability

2010-03-01 Thread Dustin Kirkland

On Mon, Mar 1, 2010 at 9:14 AM, Anthony Liguori anth...@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
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability


On 03/01/2010 06:30 PM, Ingo Molnar wrote:

IMO that's a bug, not a feature. There should be a lot more interaction
between kvm-qemu and KVM: for example Qemu should have a feature to install
paravirt drivers in the guest, this would be helped by living in the kernel
repo.
   


Not in the slightest bit.

To support automatically installing paravirt drivers in a guest, we need 
to distribute an ISO containing *binary* versions of drivers.  For 
Windows, there's a licensing issue that I described earlier with respect 
to signing.  Figuring out distribution is non-trivial and is being 
worked on.  So far, Red Hat are the only ones actually capable of 
producing signed binaries (no mere mortal can do it).  For Linux 
drivers, we need to be able to ship different versions of the kernel 
drivers for different distribution kernels if we don't want to rely on 
what they ship.


The way we've tackled this in the past is by having an awk script that 
automatically converts the virtio drivers into something buildable 
across kernel versions.  It's incredibly difficult to maintain and we 
stopped maintaining it about a year ago when virtio drivers became 
common in all distro kernels.  See 
http://git.kernel.org/?p=virt/kvm/kvm-guest-drivers-linux.git if you're 
interested.


What would make this much easier for us is if we could add all of the 
#ifdef's for various kernel versions in the mainline source tree.  I'm 
not holding my breath for that though :-)


But once we had an ISO with binary drivers (and such a thing is 
available for Windows today), it's just a matter of adding an option to 
change the CDROM to the shipped ISO.  This is purely within qemu and 
doesn't touch kvm.ko at all.


Once the winpv driver's binary hosting is sorted out, virt-manager will 
have this feature.  There are zero changes required to the kvm kernel 
code to support this.


 

  - It's released together with the kernel, which gives a periodic 3 months
release frequency. Not too slow, not too fast.
   

qemu release range in length from 3-6 months depending on
distribution schedules.  They are very regular.
 

The Linux kernel is released every 3 months, +- one week. Our experience is
that even 6 months would be (way) too painful for distros.
   


I expect that we'll eventually even out to a consistent release 
schedule. For now, we're still trying to see what fits us best.  The 
last 3 month release was very compressed so we're trying something a 
little longer this time.



  - Code quality requirements are that of the kernel's. No muck allowed and
it's not hard to explain what kind of code is preferred.
   

Code quality is subjective.  We have a different coding style.
 

That's somewhat of a problem when for example a KVM kernel-space developer
crosses into Qemu code and back. Two separate styles, etc. I certainly
remember a 'culture clash' when going from the kernel into Qemu and back.
Different principles, different culture. It's better to standardize.
   


Some would argue that having diversity of culture is a good thing that 
breeds creative thinking :-)


It's annoying to switch coding styles but I don't think it's a major 
problem for anyone.



  - Tool breakage bisection is a breeze: there's never any mismatch between
tools/perf and the kernel counterpart. With a separate package we'd
have more complex test and bisection scenarios.
   

KVM has a backwards compatible ABI so there's no such thing as mismatch
between user and kernel space.
 

perf too is ABI compatible (between releases) - still bisection is a lot
easier because the evolution of a particular feature can be bisected back to.

Btw., KVM certainly ha ABI breakages around 2.6.16(?) when it was added, even
of released versions.


That was a one-time thing in the very early days of KVM.


  Also, within a development version you sure sometimes
iterate a new ABI component, right?


It's not really happened.  We introduce new ABIs very rarely.  KVM has a 
very defined purpose; it provides CPU virtualization.  We only extend 
the ABI to support new CPU features that we didn't previously support 
and since these things are defined by the Intel architecture, it's 
fairly easy to define the ABI properly up front.



  With a time-coherent repository both
intentional and unintentional breakages and variations can be bisected back to
as they happened.

This is an unconditional advantage and i made use of it numerous times.
   


We used to keep the kernel code in the same repository as the userspace 
code.  We stopped doing that about a year ago and it's rare that we have 
a circumstance where joint bisecting is required.



You should try it.  I think you'll find that it's not as obvious thing to do
as you think it is.
 

A few years ago I looked into cleaning up Qemu, when i hacked KVM and Qemu. I
also wanted to have a 'qemu light', which is both smaller and cleaner, and
still fits to KVM. It didnt look particularly

Re: KVM usability

2010-03-01 Thread Alexander Graf


On 01.03.2010, at 22:59, Anthony Liguori wrote:

 On 03/01/2010 03:12 PM, Dustin Kirkland wrote:
 kvm -m 512 -cdrom
 /home/kirkland/.cache/testdrive/iso/lucid-desktop-amd64.iso -drive
 file=/home/kirkland/.cache/testdrive/img/testdrive-disk-0086OD.img,if=virtio,index=0,boot=on
 -usb -usbdevice tablet -net nic,model=virtio -net user -soundhw es1370
 
 Among these:
  * 512MB is a nice step up from the 128MB by default (this one scales
 based on your hosts memory)
   
 
 I'm not opposed to bumping from 128M to something else.  I'd like to see some 
 indication though other than seems reasonable as to what the value should 
 be.  For instance, if a Fedora 12 install doesn't work without 256M, that's a 
 solid argument to bump the allocation.  Short term, I'd like to see this 
 globally configurable.

I keep a patch in the SUSE version for quite some time now that bumps the 
default to 384 for qemu-kvm. That was the first round number where an 
openSUSE installation worked.

Alex--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: KVM usability