Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On Thu, Mar 22, 2012 at 03:01:17PM -0500, Anthony Liguori wrote: On 03/22/2012 12:14 PM, Eduardo Habkost wrote: On Thu, Mar 22, 2012 at 11:37:39AM -0500, Anthony Liguori wrote: On 03/22/2012 04:32 AM, Gleb Natapov wrote: On Tue, Mar 13, 2012 at 11:53:19AM -0300, Eduardo Habkost wrote: So, this problem is solved if the defaults are easily found on /usr/share. What problem is solved and why are we mixing machine configuration files and cpu configuration files? They are different and should be treated differently. -nodefconfig exists only because there is not machine configuration files currently. With machine configuration files libvirt does not need -nodefconfig because it can create its own machine file and make QEMU use it. So specifying machine file on QEMU's command line implies -nodefconfig. The option itself loses its meaning and can be dropped. No, -nodefconfig means no default config. As with many projects, we can have *some* configuration required. The default configure should have a: [system] readconfig=@SYSCONFDIR@/cpu-models-x86_64.cfg Not @SYSCONFDIR@, but @DATADIR@. CPU models belong to /usr/share because they aren't meant to be changed by the user (I think I already explained why: because we have to be able to deploy fixes to them). Stanza by default. If libvirt wants to reuse this, they can use -readconfig if they use -nodefconfig. You are just repeating how you believe it should work based on the premise that cpudefs are configuration. We're discussing/questioning this exact premise, here, and I would really appreciate to hear why the model Gleb is proposing is not valid. More precisely, this part: cpu-models-x86.conf is not a configuration file. It is hardware description file. QEMU should not lose capability just because you run it with -nodefconfig. -nodefconfig means that QEMU does not create machine for you, but all parts needed to create a machine that would have been created without -nodefconfig are still present. Not been able to create Nehalem CPU after specifying -nodefconfig is the same as not been able to create virtio-net i.e the bug. And the related points Gleb mentioned further in this thread. Because the next patch series that would follow would be a -cpu-defs-path that would be a one-off hack with a global variable and a -no-cpu-defs. And it will be rejected since cpu models are not part of configuration, but QEMU internals stored in outside file. We have -L switch to tell qemu where such things should be loaded from and that's it. So let's avoid that and start by having a positive configuration mechanism that the user can use to change the path and exclude it. My suggestion eliminate the need for two future command line options. If cpu models are not part of configuration they should not be affected by configuration mechanism. You are just avoiding addressing the real question that if asked above. -- Gleb. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On Thu, Mar 22, 2012 at 12:50:18PM -0300, Eduardo Habkost wrote: On Thu, Mar 22, 2012 at 04:30:55PM +0200, Gleb Natapov wrote: On Thu, Mar 22, 2012 at 10:31:21AM -0300, Eduardo Habkost wrote: On Thu, Mar 22, 2012 at 11:32:44AM +0200, Gleb Natapov wrote: What does this mean? Will -nodefconfig disable loading of bios.bin, option roms, keymaps? Correcting myself: loading of _config_ files on /usr/share. ROM images are opaque data to be presented to the guest somehow, just like a disk image or kernel binary. But maybe keymaps will become configuration someday, I really don't know. Where do you draw the line between opaque data and configuration. CPU models are also something that is present to a guest somehow. Just the fact that it's in a structured key=value format that Qemu itself will interpret before exposing something to the guest. Yes, it's a bit arbitrary. If we could make everything configuration data, we would (or that's what I think Anthony is pushing for--I hope he will reply and clarify that). It is not a bit arbitrary it is completely arbitrary. Are you consider ROMs to be opaque data because they are binary and CPU models to be config just because it is ascii file? Not just ascii file, but structured (and relatively small) [section]key=value data. If BIOSes were not opaque binary code and could be converted to a small set of config sections and key=values just like cpudefs, one could argue that BIOSes could become configuration data, too. There is no argument I can make about it since there is no logic to refute to begin with :) Well may be except that when cpu model file will support configuring all couid leafs for each cpu model it will not be so small :) What if we pre-process CPU models into binary for QEMU to read will it magically stop being configuration? Doing the reverse (transforming simple [section]key=value data to a binary format) would just be silly and wouldn't gain us anything. The point here is that we (Qemu) seem to be moving towards a design where most things are structured configuration data that fits on a [section]key=value model, and Qemu just interprets that structured data to build a virtual machine. Nothing silly about it. You can move data parsing outside of QEMU and just mmap cpu definitions in QEMU. (That's why I said that perhaps keymaps could become configuration someday. Because maybe they can be converted to a key=value model relatively easily) Such whole sale approach is harmful since it starts to affect design decisions. So now if it seams logical to move something outside the code one can decide against it just because it will become configuration due to that design. Doing this would make it impossible to deploy fixes to users if we evern find out that the default configuration file had a serious bug. What if a bug in our default configuration file has a serious security implication? The answer to this is: if the broken templates/defaults are on /usr/share, it would be easy to deploy the fix. So, the compromise solution is: - We can move some configuration data (especially defaults/templates) to /usr/share (machine-types and CPU models could go there). This way we can easily deploy fixes to the defaults, if necessary. - To reuse Qemu models, or machine-types, and not define everything from scratch, libvirt will have to use something like: -nodefconfig -readconfig /usr/share/qemu/cpu-models-x86.conf cpu-models-x86.conf is not a configuration file. It is hardware description file. QEMU should not lose capability just because you run it with -nodefconfig. -nodefconfig means that QEMU does not create machine for you, but all parts needed to create a machine that would have been created without -nodefconfig are still present. Not been able to create Nehalem CPU after specifying -nodefconfig is the same as not been able to create virtio-net i.e the bug. The current design direction Qemu seems to be following is different from that: hardware description is also considered configuration just like actual machine configuration. Anthony, please correct me if I am wrong. That's a bug. Why trying to rationalize it now instead of fixing it. It's just a bug for you because you disagree with the current design. You can call it rationalization, yes; I am just accepting Anthony's proposal because it's equally good (to me) as what you are proposing. It was fixed in RHEL by the same person who introduced it in upstream in the first place. He just forgot to send the fix upstream. Does bug that is present for a long time is promoted to a feature? John didn't forget it, he knew that upstream could go in a different direction. The RHEL6 patch description has this: Note this is intended as an
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 04:49 AM, Gleb Natapov wrote: On Thu, Mar 22, 2012 at 03:01:17PM -0500, Anthony Liguori wrote: So let's avoid that and start by having a positive configuration mechanism that the user can use to change the path and exclude it. My suggestion eliminate the need for two future command line options. If cpu models are not part of configuration they should not be affected by configuration mechanism. You are just avoiding addressing the real question that if asked above. I think you're just refusing to listen. The stated direction of QEMU, for literally years now, is that we want to arrive at the following: QEMU is composed of a series of objects who's relationships can be fully described by an external configuration file. Much of the current baked in concepts (like machines) would then become configuration files. qemu -M pc Would effectively be short hand for -readconfig /usr/share/qemu/machines/pc.cfg There are some valid points that were raised in this thread, namely that the user needs to have a file that acts as strictly config (stored in /etc). I'm totally happy moving the CPU configuration to /usr/share in order to address this. I think the thread has reduced to: should /usr/share configuration files be read by default or just treated as additional configuration files. It seems pretty obvious to me that they should be treated as normal configuration files. This gives you the user the ability to have fine grain control over which files are used including the ability to change the location for each file. Maybe RHEL only wants to expose supported CPUs and supported machines, wouldn't it be better to not have to patch QEMU to do that? Wouldn't it be even better if you could drop in a separate CPU configuration file with the supported CPU types and then change the default /etc config to use that instead? Regards, Anthony Liguori -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 02:55 PM, Anthony Liguori wrote: If cpu models are not part of configuration they should not be affected by configuration mechanism. You are just avoiding addressing the real question that if asked above. I think you're just refusing to listen. The stated direction of QEMU, for literally years now, is that we want to arrive at the following: QEMU is composed of a series of objects who's relationships can be fully described by an external configuration file. Much of the current baked in concepts (like machines) would then become configuration files. qemu -M pc Would effectively be short hand for -readconfig /usr/share/qemu/machines/pc.cfg In that case qemu -cpu westmere is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg. I think the thread has reduced to: should /usr/share configuration files be read by default or just treated as additional configuration files. If they're read as soon as they're referenced, what's the difference? -- error compiling committee.c: too many arguments to function -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 08:08 AM, Avi Kivity wrote: On 03/25/2012 02:55 PM, Anthony Liguori wrote: If cpu models are not part of configuration they should not be affected by configuration mechanism. You are just avoiding addressing the real question that if asked above. I think you're just refusing to listen. The stated direction of QEMU, for literally years now, is that we want to arrive at the following: QEMU is composed of a series of objects who's relationships can be fully described by an external configuration file. Much of the current baked in concepts (like machines) would then become configuration files. qemu -M pc Would effectively be short hand for -readconfig /usr/share/qemu/machines/pc.cfg In that case qemu -cpu westmere is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg. This is not a bad suggestion, although it would make -cpu ? a bit awkward. Do you see an advantage to this over having /usr/share/qemu/target-x86_64-cpus.cfg that's read early on? I think the thread has reduced to: should /usr/share configuration files be read by default or just treated as additional configuration files. If they're read as soon as they're referenced, what's the difference? I suspect libvirt would not be happy with reading configuration files on demand.. Regards, Anthony Liguori -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 03:12 PM, Anthony Liguori wrote: qemu -M pc Would effectively be short hand for -readconfig /usr/share/qemu/machines/pc.cfg In that case qemu -cpu westmere is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg. This is not a bad suggestion, although it would make -cpu ? a bit awkward. Do you see an advantage to this over having /usr/share/qemu/target-x86_64-cpus.cfg that's read early on? Nope. As long as qemu -nodefconfig -cpu westmere works, I'm happy. The reasoning is, loading target-x86_64-cpus.cfg does not alter the current instance's configuration, so reading it doesn't violate -nodefconfig. files be read by default or just treated as additional configuration files. If they're read as soon as they're referenced, what's the difference? I think the thread has reduced to: should /usr/share configuration I suspect libvirt would not be happy with reading configuration files on demand.. Why not? -- error compiling committee.c: too many arguments to function -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/11/2012 04:12 PM, Anthony Liguori wrote: Let me elaborate about the later. Suppose host CPU has kill_guest feature and at the time a guest was installed it was not implemented by kvm. Since it was not implemented by kvm it was not present in vcpu during installation and the guest didn't install workaround kill_guest module. Now unsuspecting user upgrades the kernel and tries to restart the guest and fails. He writes angry letter to qemu-devel and is asked to reinstall his guest and move along. -cpu best wouldn't solve this. You need a read/write configuration file where QEMU probes the available CPU and records it to be used for the lifetime of the VM. This doesn't work with live migration, and makes templating harder. The only persistent storage we can count on are disk images. The current approach is simple. The management tool determines the configuration, qemu applies it. Unidirectional information flow. This also lends itself to the management tool scanning a cluster and determining a GCD. This discussion isn't about whether QEMU should have a Westmere processor definition. In fact, I think I already applied that patch. It's a discussion about how we handle this up and down the stack. The question is who should define and manage CPU compatibility. Right now QEMU does to a certain degree, libvirt discards this and does it's own thing, and VDSM/ovirt-engine assume that we're providing something and has built a UI around it. What I'm proposing we consider: have VDSM manage CPU definitions in order to provide a specific user experience in ovirt-engine. We would continue to have Westmere/etc in QEMU exposed as part of the user configuration. But I don't think it makes a lot of sense to have to modify QEMU any time a new CPU comes out. We have to. New features often come with new MSRs which need to be live migrated, and of course the cpu flags as well. We may push all these to qemu data files, but this is still qemu. We can't let a management tool decide that cpu feature X is safe to use on qemu version Y. -- error compiling committee.c: too many arguments to function -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 08:14 AM, Avi Kivity wrote: On 03/25/2012 03:12 PM, Anthony Liguori wrote: qemu -M pc Would effectively be short hand for -readconfig /usr/share/qemu/machines/pc.cfg In that case qemu -cpu westmere is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg. This is not a bad suggestion, although it would make -cpu ? a bit awkward. Do you see an advantage to this over having /usr/share/qemu/target-x86_64-cpus.cfg that's read early on? Nope. As long as qemu -nodefconfig -cpu westmere works, I'm happy. Why? What's wrong with: qemu -nodefconfig -readconfig /usr/share/qemu/cpus/target-x86_64-cpus.cfg \ -cpu westmere And if that's not okay, would: qemu -nodefconfig -nocpudefconfig -cpu Westmere Not working be a problem? The reasoning is, loading target-x86_64-cpus.cfg does not alter the current instance's configuration, so reading it doesn't violate -nodefconfig. I think we have a different view of what -nodefconfig does. We have a couple options today: -nodefconfig Don't read the default configuration files. By default, we read /etc/qemu/qemu.cfg and /etc/qemu/target-$(ARCH).cfg -nodefaults Don't create default devices. -vga none Don't create the default VGA device (not covered by -nodefaults). With these two options, the semantics you get an absolutely minimalistic instance of QEMU. Tools like libguestfs really want to create the simplest guest and do the least amount of processing so the guest runs as fast as possible. It does suck a lot that this isn't a single option. I would much prefer -nodefaults to be implied by -nodefconfig. Likewise, I would prefer that -nodefaults implied -vga none. files be read by default or just treated as additional configuration files. If they're read as soon as they're referenced, what's the difference? I think the thread has reduced to: should /usr/share configuration I suspect libvirt would not be happy with reading configuration files on demand.. Why not? It implies a bunch of SELinux labeling to make sVirt work. libvirt tries very hard to avoid having QEMU read *any* files at all when it starts up. Regards, Anthony Liguori -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 08:21 AM, Avi Kivity wrote: On 03/11/2012 04:12 PM, Anthony Liguori wrote: This discussion isn't about whether QEMU should have a Westmere processor definition. In fact, I think I already applied that patch. It's a discussion about how we handle this up and down the stack. The question is who should define and manage CPU compatibility. Right now QEMU does to a certain degree, libvirt discards this and does it's own thing, and VDSM/ovirt-engine assume that we're providing something and has built a UI around it. What I'm proposing we consider: have VDSM manage CPU definitions in order to provide a specific user experience in ovirt-engine. We would continue to have Westmere/etc in QEMU exposed as part of the user configuration. But I don't think it makes a lot of sense to have to modify QEMU any time a new CPU comes out. We have to. New features often come with new MSRs which need to be live migrated, and of course the cpu flags as well. We may push all these to qemu data files, but this is still qemu. We can't let a management tool decide that cpu feature X is safe to use on qemu version Y. I think QEMU should own CPU definitions. I think a management tool should have the choice of whether they are used though because they are a policy IMHO. It's okay for QEMU to implement some degree of policy as long as a management tool can override it with a different policy. Regards, Anthony Liguori -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 03:22 PM, Anthony Liguori wrote:
In that case
qemu -cpu westmere
is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg.
This is not a bad suggestion, although it would make -cpu ? a bit
awkward. Do you see an advantage to this over having
/usr/share/qemu/target-x86_64-cpus.cfg that's read early on?
Nope. As long as qemu -nodefconfig -cpu westmere works, I'm happy.
Why? What's wrong with:
qemu -nodefconfig -readconfig
/usr/share/qemu/cpus/target-x86_64-cpus.cfg \
-cpu westmere
And if that's not okay, would:
qemu -nodefconfig -nocpudefconfig -cpu Westmere
Not working be a problem?
Apart from the command line length, it confuses configuration with
definition.
target-x86_64-cpus.cfg does not configure qemu for anything, it's merely
the equivalent of
#define westmere (x86_def_t) { ... }
#define nehalem (x86_def_t) { ... }
#define bulldozer (x86_def_t) { ... } // for PC
so it should be read at each invocation. On the other hand, pc.cfg and
westmere.cfg (as used previously) are shorthand for
machine = (QEMUMachine) { ... };
cpu = (x86_def_t) { ... };
so they should only be read if requested explicitly (or indirectly).
The reasoning is, loading target-x86_64-cpus.cfg does not alter the
current instance's configuration, so reading it doesn't violate
-nodefconfig.
I think we have a different view of what -nodefconfig does.
We have a couple options today:
-nodefconfig
Don't read the default configuration files. By default, we read
/etc/qemu/qemu.cfg and /etc/qemu/target-$(ARCH).cfg
The latter seems meaningless to avoid reading. It's just a set of
#defines, what do you get by not reading it?
-nodefaults
Don't create default devices.
-vga none
Don't create the default VGA device (not covered by -nodefaults).
With these two options, the semantics you get an absolutely
minimalistic instance of QEMU. Tools like libguestfs really want to
create the simplest guest and do the least amount of processing so the
guest runs as fast as possible.
It does suck a lot that this isn't a single option. I would much
prefer -nodefaults to be implied by -nodefconfig. Likewise, I would
prefer that -nodefaults implied -vga none.
I don't have a qemu.cfg so can't comment on it, but in what way does
reading target-x86_64.cfg affect the current instance (that is, why is
-nodefconfig needed over -nodefaults -vga look-at-the-previous-option?)
files be read by default or just treated as additional configuration
files.
If they're read as soon as they're referenced, what's the difference?
I think the thread has reduced to: should /usr/share configuration
I suspect libvirt would not be happy with reading configuration files
on demand..
Why not?
It implies a bunch of SELinux labeling to make sVirt work. libvirt
tries very hard to avoid having QEMU read *any* files at all when it
starts up.
The /usr/share/qemu files should be statically labelled to allow qemu to
read them, so we can push more code into data files.
--
error compiling committee.c: too many arguments to function
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Add qemu support for ppc64 on FC16 or above for rpm packaging
On 03/23/2012 12:29 PM, Li Zhang wrote:
On Fedora16 or above, qemu is supported now. So it is added
in rpm packaging.
Signed-off-by: Li Zhangzhlci...@linux.vnet.ibm.com
---
libvirt.spec.in |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 072fd8e..568a84f 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -139,8 +139,8 @@
%define with_xen 0
%endif
-# Fedora doesn't have any QEMU on ppc64 - only ppc
-%if 0%{?fedora}
+# Fedora doesn't have any QEMU on ppc64 until FC16 - only ppc
+%if 0%{?fedora} 16
%ifarch ppc64
%define with_qemu 0
%endif
Any comment is appreciated. :)
Thanks :)
Li
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Add qemu support for ppc64 on FC16 or above for rpm packaging
On 03/25/2012 10:10 AM, Li Zhang wrote:
On 03/23/2012 12:29 PM, Li Zhang wrote:
On Fedora16 or above, qemu is supported now. So it is added
in rpm packaging.
Signed-off-by: Li Zhangzhlci...@linux.vnet.ibm.com
---
libvirt.spec.in |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 072fd8e..568a84f 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -139,8 +139,8 @@
%define with_xen 0
%endif
-# Fedora doesn't have any QEMU on ppc64 - only ppc
-%if 0%{?fedora}
+# Fedora doesn't have any QEMU on ppc64 until FC16 - only ppc
+%if 0%{?fedora} 16
%ifarch ppc64
%define with_qemu 0
%endif
Any comment is appreciated. :)
I made a small change and pushed your patch on Friday. I guess you must
have missed the email:
https://www.redhat.com/archives/libvir-list/2012-March/msg01034.html
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 08:34 AM, Avi Kivity wrote:
On 03/25/2012 03:22 PM, Anthony Liguori wrote:
In that case
qemu -cpu westmere
is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg.
This is not a bad suggestion, although it would make -cpu ? a bit
awkward. Do you see an advantage to this over having
/usr/share/qemu/target-x86_64-cpus.cfg that's read early on?
Nope. As long as qemu -nodefconfig -cpu westmere works, I'm happy.
Why? What's wrong with:
qemu -nodefconfig -readconfig
/usr/share/qemu/cpus/target-x86_64-cpus.cfg \
-cpu westmere
And if that's not okay, would:
qemu -nodefconfig -nocpudefconfig -cpu Westmere
Not working be a problem?
Apart from the command line length, it confuses configuration with
definition.
There is no distinction with what we have today. Our configuration file
basically corresponds to command line options and as there is no distinction in
command line options, there's no distinction in the configuration format.
target-x86_64-cpus.cfg does not configure qemu for anything, it's merely
the equivalent of
#define westmere (x86_def_t) { ... }
#define nehalem (x86_def_t) { ... }
#define bulldozer (x86_def_t) { ... } // for PC
so it should be read at each invocation. On the other hand, pc.cfg and
westmere.cfg (as used previously) are shorthand for
machine = (QEMUMachine) { ... };
cpu = (x86_def_t) { ... };
so they should only be read if requested explicitly (or indirectly).
This doesn't make a lot of sense to me. Here's what I'm proposing:
1) QEMU would have a target-x86_64-cpu.cfg.in that is installed by default in
/etc/qemu. It would contain:
[system]
# Load default CPU definitions
readconfig = @DATADIR@/target-x86_64-cpus.cfg
2) target-x86_64-cpus.cfg would be installed to @DATADIR@ and would contain:
[cpudef]
name = Westmere
...
This has the following properties:
A) QEMU has no builtin notion of CPU definitions. It just has a cpu factory.
-cpudef will create a new class called Westmere that can then be enumerated
through qom-type-list and created via qom-create.
B) A management tool has complete control over cpu definitions without modifying
the underlying filesystem. -nodefconfig will prevent it from loading and the
management tool can explicitly load the QEMU definition (via -readconfig,
potentially using a /dev/fd/N path) or it can define it's own cpu definitions.
C) This model maps to any other type of class factory. Machines will eventually
be expressed as a class factory. When we implement this, we would change the
default target-x86_64-cpu.cfg to:
[system]
# Load default CPU definitions
readconfig = @DATADIR@/target-x86_64-cpus.cfg
# Load default machines
readconfig = @DATADIR@/target-x86_64-machines.cfg
A machine definition would look like:
[machinedef]
name = pc-0.15
virtio-blk.class_code = 32
...
Loading a file based on -cpu doesn't generalize well unless we try to load a
definition for any possible QOM type to find the class factory for it. I don't
think this is a good idea.
The reasoning is, loading target-x86_64-cpus.cfg does not alter the
current instance's configuration, so reading it doesn't violate
-nodefconfig.
I think we have a different view of what -nodefconfig does.
We have a couple options today:
-nodefconfig
Don't read the default configuration files. By default, we read
/etc/qemu/qemu.cfg and /etc/qemu/target-$(ARCH).cfg
The latter seems meaningless to avoid reading. It's just a set of
#defines, what do you get by not reading it?
In my target-$(ARCH).cfg, I have:
[machine]
enable-kvm = on
Which means I don't have to use -enable-kvm anymore. But if you look at a tool
like libguestfs, start up time is the most important thing so avoiding
unnecessary I/O and processing is critical.
-nodefaults
Don't create default devices.
-vga none
Don't create the default VGA device (not covered by -nodefaults).
With these two options, the semantics you get an absolutely
minimalistic instance of QEMU. Tools like libguestfs really want to
create the simplest guest and do the least amount of processing so the
guest runs as fast as possible.
It does suck a lot that this isn't a single option. I would much
prefer -nodefaults to be implied by -nodefconfig. Likewise, I would
prefer that -nodefaults implied -vga none.
I don't have a qemu.cfg so can't comment on it, but in what way does
reading target-x86_64.cfg affect the current instance (that is, why is
-nodefconfig needed over -nodefaults -vga look-at-the-previous-option?)
It depends on what the user configures it to do.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Add qemu support for ppc64 on FC16 or above for rpm packaging
On 03/25/2012 10:24 PM, Laine Stump wrote:
On 03/25/2012 10:10 AM, Li Zhang wrote:
On 03/23/2012 12:29 PM, Li Zhang wrote:
On Fedora16 or above, qemu is supported now. So it is added
in rpm packaging.
Signed-off-by: Li Zhangzhlci...@linux.vnet.ibm.com
---
libvirt.spec.in |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 072fd8e..568a84f 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -139,8 +139,8 @@
%define with_xen 0
%endif
-# Fedora doesn't have any QEMU on ppc64 - only ppc
-%if 0%{?fedora}
+# Fedora doesn't have any QEMU on ppc64 until FC16 - only ppc
+%if 0%{?fedora} 16
%ifarch ppc64
%define with_qemu 0
%endif
Any comment is appreciated. :)
I made a small change and pushed your patch on Friday. I guess you must
have missed the email:
https://www.redhat.com/archives/libvir-list/2012-March/msg01034.html
Got it. Thanks very much.
I really missed the email. :)
Thanks
Li
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 04:36 PM, Anthony Liguori wrote:
Apart from the command line length, it confuses configuration with
definition.
There is no distinction with what we have today. Our configuration
file basically corresponds to command line options and as there is no
distinction in command line options, there's no distinction in the
configuration format.
We don't have command line options for defining, only configuring.
Again, defining = #define
Configuring = modifying current instance
target-x86_64-cpus.cfg does not configure qemu for anything, it's merely
the equivalent of
#define westmere (x86_def_t) { ... }
#define nehalem (x86_def_t) { ... }
#define bulldozer (x86_def_t) { ... } // for PC
so it should be read at each invocation. On the other hand, pc.cfg and
westmere.cfg (as used previously) are shorthand for
machine = (QEMUMachine) { ... };
cpu = (x86_def_t) { ... };
so they should only be read if requested explicitly (or indirectly).
This doesn't make a lot of sense to me. Here's what I'm proposing:
1) QEMU would have a target-x86_64-cpu.cfg.in that is installed by
default in /etc/qemu. It would contain:
[system]
# Load default CPU definitions
readconfig = @DATADIR@/target-x86_64-cpus.cfg
2) target-x86_64-cpus.cfg would be installed to @DATADIR@ and would
contain:
[cpudef]
name = Westmere
...
This has the following properties:
A) QEMU has no builtin notion of CPU definitions. It just has a cpu
factory. -cpudef will create a new class called Westmere that can
then be enumerated through qom-type-list and created via qom-create.
B) A management tool has complete control over cpu definitions without
modifying the underlying filesystem. -nodefconfig will prevent it
from loading and the management tool can explicitly load the QEMU
definition (via -readconfig, potentially using a /dev/fd/N path) or it
can define it's own cpu definitions.
Why does -nodefconfig affect anything?
The file defines westmere as an alias for a grab bag of options.
Whether it's loaded or not is immaterial, unless someone uses one of the
names within.
C) This model maps to any other type of class factory. Machines will
eventually be expressed as a class factory. When we implement this,
we would change the default target-x86_64-cpu.cfg to:
[system]
# Load default CPU definitions
readconfig = @DATADIR@/target-x86_64-cpus.cfg
# Load default machines
readconfig = @DATADIR@/target-x86_64-machines.cfg
A machine definition would look like:
[machinedef]
name = pc-0.15
virtio-blk.class_code = 32
...
Loading a file based on -cpu doesn't generalize well unless we try to
load a definition for any possible QOM type to find the class factory
for it. I don't think this is a good idea.
Why not load all class factories? Just don't instantiate any objects.
Otherwise, the meaning of -nodefconfig changes as more stuff is moved
out of .c and into .cfg.
The reasoning is, loading target-x86_64-cpus.cfg does not alter the
current instance's configuration, so reading it doesn't violate
-nodefconfig.
I think we have a different view of what -nodefconfig does.
We have a couple options today:
-nodefconfig
Don't read the default configuration files. By default, we read
/etc/qemu/qemu.cfg and /etc/qemu/target-$(ARCH).cfg
The latter seems meaningless to avoid reading. It's just a set of
#defines, what do you get by not reading it?
In my target-$(ARCH).cfg, I have:
[machine]
enable-kvm = on
Which means I don't have to use -enable-kvm anymore. But if you look
at a tool like libguestfs, start up time is the most important thing
so avoiding unnecessary I/O and processing is critical.
So this is definitely configuration (applies to the current instance) as
opposed to target-x86_64.cfg, which doesn't.
-nodefaults
Don't create default devices.
-vga none
Don't create the default VGA device (not covered by -nodefaults).
With these two options, the semantics you get an absolutely
minimalistic instance of QEMU. Tools like libguestfs really want to
create the simplest guest and do the least amount of processing so the
guest runs as fast as possible.
It does suck a lot that this isn't a single option. I would much
prefer -nodefaults to be implied by -nodefconfig. Likewise, I would
prefer that -nodefaults implied -vga none.
I don't have a qemu.cfg so can't comment on it, but in what way does
reading target-x86_64.cfg affect the current instance (that is, why is
-nodefconfig needed over -nodefaults -vga look-at-the-previous-option?)
It depends on what the user configures it to do.
How?
As far as I can tell, the only difference is that -nodefconfig -cpu
westmere will error out instead of working. But if you don't supply
-cpu westmere, the configuration is identical.
--
error compiling committee.c: too many arguments to function
--
libvir-list mailing list
libvir-list@redhat.com
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On Sun, Mar 25, 2012 at 03:14:56PM +0200, Avi Kivity wrote: On 03/25/2012 03:12 PM, Anthony Liguori wrote: qemu -M pc Would effectively be short hand for -readconfig /usr/share/qemu/machines/pc.cfg In that case qemu -cpu westmere is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg. This is not a bad suggestion, although it would make -cpu ? a bit awkward. Do you see an advantage to this over having /usr/share/qemu/target-x86_64-cpus.cfg that's read early on? Nope. As long as qemu -nodefconfig -cpu westmere works, I'm happy. As log as qemu -nodefconfig -cpu westmere -M pc1.1 can use different westmere definition than -M pc1.0 (by amending it according to qom properties in pc1.1 machine description or by reading /usr/share/qemu/cpus/westmere-pc1.1.cfg instead) I'm happy too. The reasoning is, loading target-x86_64-cpus.cfg does not alter the current instance's configuration, so reading it doesn't violate -nodefconfig. files be read by default or just treated as additional configuration files. If they're read as soon as they're referenced, what's the difference? I think the thread has reduced to: should /usr/share configuration I suspect libvirt would not be happy with reading configuration files on demand.. Why not? -- error compiling committee.c: too many arguments to function -- Gleb. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 09:46 AM, Avi Kivity wrote:
On 03/25/2012 04:36 PM, Anthony Liguori wrote:
Apart from the command line length, it confuses configuration with
definition.
There is no distinction with what we have today. Our configuration
file basically corresponds to command line options and as there is no
distinction in command line options, there's no distinction in the
configuration format.
We don't have command line options for defining, only configuring.
That's an oversight. There should be a -cpudef option. It's a QemuOptsList.
Again, defining = #define
I think -global fits your definition of #define...
Configuring = modifying current instance
target-x86_64-cpus.cfg does not configure qemu for anything, it's merely
the equivalent of
#define westmere (x86_def_t) { ... }
#define nehalem (x86_def_t) { ... }
#define bulldozer (x86_def_t) { ... } // for PC
so it should be read at each invocation. On the other hand, pc.cfg and
westmere.cfg (as used previously) are shorthand for
machine = (QEMUMachine) { ... };
cpu = (x86_def_t) { ... };
so they should only be read if requested explicitly (or indirectly).
This doesn't make a lot of sense to me. Here's what I'm proposing:
1) QEMU would have a target-x86_64-cpu.cfg.in that is installed by
default in /etc/qemu. It would contain:
[system]
# Load default CPU definitions
readconfig = @DATADIR@/target-x86_64-cpus.cfg
2) target-x86_64-cpus.cfg would be installed to @DATADIR@ and would
contain:
[cpudef]
name = Westmere
...
This has the following properties:
A) QEMU has no builtin notion of CPU definitions. It just has a cpu
factory. -cpudef will create a new class called Westmere that can
then be enumerated through qom-type-list and created via qom-create.
B) A management tool has complete control over cpu definitions without
modifying the underlying filesystem. -nodefconfig will prevent it
from loading and the management tool can explicitly load the QEMU
definition (via -readconfig, potentially using a /dev/fd/N path) or it
can define it's own cpu definitions.
Why does -nodefconfig affect anything?
Because -nodefconfig means don't load *any* default configuration files.
The file defines westmere as an alias for a grab bag of options.
Whether it's loaded or not is immaterial, unless someone uses one of the
names within.
But you would agree, a management tool should be able to control whether class
factories get loaded, right? So what's the mechanism to do this?
C) This model maps to any other type of class factory. Machines will
eventually be expressed as a class factory. When we implement this,
we would change the default target-x86_64-cpu.cfg to:
[system]
# Load default CPU definitions
readconfig = @DATADIR@/target-x86_64-cpus.cfg
# Load default machines
readconfig = @DATADIR@/target-x86_64-machines.cfg
A machine definition would look like:
[machinedef]
name = pc-0.15
virtio-blk.class_code = 32
...
Loading a file based on -cpu doesn't generalize well unless we try to
load a definition for any possible QOM type to find the class factory
for it. I don't think this is a good idea.
Why not load all class factories? Just don't instantiate any objects.
Unless we have two different config syntaxes, I think it will lead to a lot of
confusion. Having some parts of a config file be parsed and others not is
fairly strange.
Otherwise, the meaning of -nodefconfig changes as more stuff is moved
out of .c and into .cfg.
What's the problem with this?
The reasoning is, loading target-x86_64-cpus.cfg does not alter the
current instance's configuration, so reading it doesn't violate
-nodefconfig.
I think we have a different view of what -nodefconfig does.
We have a couple options today:
-nodefconfig
Don't read the default configuration files. By default, we read
/etc/qemu/qemu.cfg and /etc/qemu/target-$(ARCH).cfg
The latter seems meaningless to avoid reading. It's just a set of
#defines, what do you get by not reading it?
In my target-$(ARCH).cfg, I have:
[machine]
enable-kvm = on
Which means I don't have to use -enable-kvm anymore. But if you look
at a tool like libguestfs, start up time is the most important thing
so avoiding unnecessary I/O and processing is critical.
So this is definitely configuration (applies to the current instance) as
opposed to target-x86_64.cfg, which doesn't.
I'm not sure which part you're responding to..
-nodefaults
Don't create default devices.
-vga none
Don't create the default VGA device (not covered by -nodefaults).
With these two options, the semantics you get an absolutely
minimalistic instance of QEMU. Tools like libguestfs really want to
create the simplest guest and do the least amount of processing so the
guest runs as fast as possible.
It does suck a lot that this isn't a single option. I would much
prefer -nodefaults to be implied by -nodefconfig. Likewise, I would
prefer that -nodefaults implied -vga
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 09:58 AM, Gleb Natapov wrote: On Sun, Mar 25, 2012 at 03:14:56PM +0200, Avi Kivity wrote: On 03/25/2012 03:12 PM, Anthony Liguori wrote: qemu -M pc Would effectively be short hand for -readconfig /usr/share/qemu/machines/pc.cfg In that case qemu -cpu westmere is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg. This is not a bad suggestion, although it would make -cpu ? a bit awkward. Do you see an advantage to this over having /usr/share/qemu/target-x86_64-cpus.cfg that's read early on? Nope. As long as qemu -nodefconfig -cpu westmere works, I'm happy. As log as qemu -nodefconfig -cpu westmere -M pc1.1 -nodefconfig is going to eventually mean that -cpu westmere and -M pc-1.1 will not work. This is where QEMU is going. There is no reason that a normal user should ever use -nodefconfig. Regards, Anthony Liguori -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 04:59 PM, Anthony Liguori wrote: On 03/25/2012 09:46 AM, Avi Kivity wrote: On 03/25/2012 04:36 PM, Anthony Liguori wrote: Apart from the command line length, it confuses configuration with definition. There is no distinction with what we have today. Our configuration file basically corresponds to command line options and as there is no distinction in command line options, there's no distinction in the configuration format. We don't have command line options for defining, only configuring. That's an oversight. There should be a -cpudef option. It's a QemuOptsList. Again, defining = #define I think -global fits your definition of #define... Yes (apart from the corner case of modifying a default-instantiated device). B) A management tool has complete control over cpu definitions without modifying the underlying filesystem. -nodefconfig will prevent it from loading and the management tool can explicitly load the QEMU definition (via -readconfig, potentially using a /dev/fd/N path) or it can define it's own cpu definitions. Why does -nodefconfig affect anything? Because -nodefconfig means don't load *any* default configuration files. Put the emphasis around *configuration*. #define westmere blah is not configuration, otherwise the meaning of configuration will drift over time. -cpu blah is, of course. The file defines westmere as an alias for a grab bag of options. Whether it's loaded or not is immaterial, unless someone uses one of the names within. But you would agree, a management tool should be able to control whether class factories get loaded, right? No, why? But perhaps I don't entirely get what you mean by class factories. Aren't they just implementations of virtual Device *new_instance(...) = 0? if so, why not load them? So what's the mechanism to do this? C) This model maps to any other type of class factory. Machines will eventually be expressed as a class factory. When we implement this, we would change the default target-x86_64-cpu.cfg to: [system] # Load default CPU definitions readconfig = @DATADIR@/target-x86_64-cpus.cfg # Load default machines readconfig = @DATADIR@/target-x86_64-machines.cfg A machine definition would look like: [machinedef] name = pc-0.15 virtio-blk.class_code = 32 ... Loading a file based on -cpu doesn't generalize well unless we try to load a definition for any possible QOM type to find the class factory for it. I don't think this is a good idea. Why not load all class factories? Just don't instantiate any objects. Unless we have two different config syntaxes, I think it will lead to a lot of confusion. Having some parts of a config file be parsed and others not is fairly strange. Parse all of them (and make sure all are class factories). The only real configuration item is that without -nodefconfig, we create a -M pc-1.1 system. Everything else derives from that. Otherwise, the meaning of -nodefconfig changes as more stuff is moved out of .c and into .cfg. What's the problem with this? The command line becomes unstable if you use -nodefconfig. In my target-$(ARCH).cfg, I have: [machine] enable-kvm = on Which means I don't have to use -enable-kvm anymore. But if you look at a tool like libguestfs, start up time is the most important thing so avoiding unnecessary I/O and processing is critical. So this is definitely configuration (applies to the current instance) as opposed to target-x86_64.cfg, which doesn't. I'm not sure which part you're responding to.. I was saying that target-x86_64.cfg appears to be definitions, not configuration, and was asking about qemu.cfg (which is configuration). As far as I can tell, the only difference is that -nodefconfig -cpu westmere will error out instead of working. But if you don't supply -cpu westmere, the configuration is identical. What configuration? Let me ask, what do you think the semantics of -nodefconfig should be? I'm not sure I understand what you're advocating for. -nodefconfig = create an empty machine, don't assume anything (=don't read qemu.cfg) let me build it out of all those lego bricks. Those can be defined in code or in definition files in /usr/share, I don't care. Maybe that's -nodevices -vga none. But in this case I don't see the point in -nodefconfig. Not loading target_x86-64.cfg doesn't buy the user anything, since it wouldn't affect the guest in any way. -- error compiling committee.c: too many arguments to function -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 05:07 PM, Anthony Liguori wrote: As log as qemu -nodefconfig -cpu westmere -M pc1.1 -nodefconfig is going to eventually mean that -cpu westmere and -M pc-1.1 will not work. This is where QEMU is going. There is no reason that a normal user should ever use -nodefconfig. I don't think anyone or anything can use it, since it's meaning is not well defined. not read any configuration files where parts of qemu are continually moved out to configuration files means its a moving target. Suppose we define the southbridge via a configuration file. Does that mean we don't load it any more? -- error compiling committee.c: too many arguments to function -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 10:16 AM, Avi Kivity wrote: On 03/25/2012 04:59 PM, Anthony Liguori wrote: On 03/25/2012 09:46 AM, Avi Kivity wrote: On 03/25/2012 04:36 PM, Anthony Liguori wrote: Apart from the command line length, it confuses configuration with definition. There is no distinction with what we have today. Our configuration file basically corresponds to command line options and as there is no distinction in command line options, there's no distinction in the configuration format. We don't have command line options for defining, only configuring. That's an oversight. There should be a -cpudef option. It's a QemuOptsList. Again, defining = #define I think -global fits your definition of #define... Yes (apart from the corner case of modifying a default-instantiated device). B) A management tool has complete control over cpu definitions without modifying the underlying filesystem. -nodefconfig will prevent it from loading and the management tool can explicitly load the QEMU definition (via -readconfig, potentially using a /dev/fd/N path) or it can define it's own cpu definitions. Why does -nodefconfig affect anything? Because -nodefconfig means don't load *any* default configuration files. Put the emphasis around *configuration*. So how about: 1) Load ['@SYSCONFDIR@/qemu/qemu.cfg', '@SYSCONFDIR@/qemu/target-@ARCH@.cfg', '@DATADIR@/system.cfg', '@DATADIR@/system-@ARCH@.cfg'] 2) system-@ARCH@.cfg will contain: [system] readconfig=@DATADIR@/target-@a...@-cpus.cfg readconfig=@DATADIR@/target-@a...@-machine.cfg 3) -nodefconfig will not load any configuration files from DATADIR or SYSCONFDIR. -no-user-config will not load any configuration files from SYSCONFDIR. #define westmere blah is not configuration, otherwise the meaning of configuration will drift over time. -cpu blah is, of course. It's the same mechanism, but the above would create two classes of default configuration files and then it becomes a question of how they're used. The file defines westmere as an alias for a grab bag of options. Whether it's loaded or not is immaterial, unless someone uses one of the names within. But you would agree, a management tool should be able to control whether class factories get loaded, right? No, why? But perhaps I don't entirely get what you mean by class factories. Aren't they just implementations of virtual Device *new_instance(...) = 0? if so, why not load them? No, a class factory creates a new type of class. -cpudef will ultimately call type_register() to create a new QOM visible type. From a management tools perspective, the type is no different than a built-in type. Otherwise, the meaning of -nodefconfig changes as more stuff is moved out of .c and into .cfg. What's the problem with this? The command line becomes unstable if you use -nodefconfig. -no-user-config solves this but I fully expect libvirt would continue to use -nodefconfig. In my target-$(ARCH).cfg, I have: [machine] enable-kvm = on Which means I don't have to use -enable-kvm anymore. But if you look at a tool like libguestfs, start up time is the most important thing so avoiding unnecessary I/O and processing is critical. So this is definitely configuration (applies to the current instance) as opposed to target-x86_64.cfg, which doesn't. I'm not sure which part you're responding to.. I was saying that target-x86_64.cfg appears to be definitions, not configuration, and was asking about qemu.cfg (which is configuration). As far as I can tell, the only difference is that -nodefconfig -cpu westmere will error out instead of working. But if you don't supply -cpu westmere, the configuration is identical. What configuration? Let me ask, what do you think the semantics of -nodefconfig should be? I'm not sure I understand what you're advocating for. -nodefconfig = create an empty machine, don't assume anything (=don't read qemu.cfg) let me build it out of all those lego bricks. Those can be defined in code or in definition files in /usr/share, I don't care. Maybe that's -nodevices -vga none. But in this case I don't see the point in -nodefconfig. Not loading target_x86-64.cfg doesn't buy the user anything, since it wouldn't affect the guest in any way. -nodefconfig doesn't mean what you think it means. -nodefconfig doesn't say anything about the user visible machine. -nodefconfig tells QEMU not to read any configuration files at start up. This has an undefined affect on the user visible machine that depends on the specific version of QEMU. Regards, Anthony Liguori -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 10:18 AM, Avi Kivity wrote: On 03/25/2012 05:07 PM, Anthony Liguori wrote: As log as qemu -nodefconfig -cpu westmere -M pc1.1 -nodefconfig is going to eventually mean that -cpu westmere and -M pc-1.1 will not work. This is where QEMU is going. There is no reason that a normal user should ever use -nodefconfig. I don't think anyone or anything can use it, since it's meaning is not well defined. not read any configuration files where parts of qemu are continually moved out to configuration files means its a moving target. I think you assume that all QEMU users care about forward and backwards compatibility on the command line about all else. That's really not true. The libvirt folks have stated repeatedly that command line backwards compatibility is not critical to them. They are happy to require that a new version of QEMU requires a new version of libvirt. I'm not saying that backwards compat isn't important--it is. But there are users who are happy to live on the bleeding edge. Suppose we define the southbridge via a configuration file. Does that mean we don't load it any more? Yes. If I want the leanest and meanest version of QEMU that will start in the smallest number of milliseconds, then being able to tell QEMU not to load configuration files and create a very specific machine is a Good Thing. Why exclude users from being able to do this? Regards, Anthony Liguori -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 05:26 PM, Anthony Liguori wrote: Put the emphasis around *configuration*. So how about: 1) Load ['@SYSCONFDIR@/qemu/qemu.cfg', '@SYSCONFDIR@/qemu/target-@ARCH@.cfg', '@DATADIR@/system.cfg', '@DATADIR@/system-@ARCH@.cfg'] 2) system-@ARCH@.cfg will contain: [system] readconfig=@DATADIR@/target-@a...@-cpus.cfg readconfig=@DATADIR@/target-@a...@-machine.cfg 3) -nodefconfig will not load any configuration files from DATADIR or SYSCONFDIR. -no-user-config will not load any configuration files from SYSCONFDIR. What, more options? I don't think -nodefconfig (as defined) is usable, since there is no way for the user to tell what it means short of reading those files. -no-user-config is usable, I think it needs also to mean that qemu without -M/-cpu/-m options will error out? since the default machine/cpu types are default configuration. #define westmere blah is not configuration, otherwise the meaning of configuration will drift over time. -cpu blah is, of course. It's the same mechanism, but the above would create two classes of default configuration files and then it becomes a question of how they're used. Confused. The file defines westmere as an alias for a grab bag of options. Whether it's loaded or not is immaterial, unless someone uses one of the names within. But you would agree, a management tool should be able to control whether class factories get loaded, right? No, why? But perhaps I don't entirely get what you mean by class factories. Aren't they just implementations of virtual Device *new_instance(...) = 0? if so, why not load them? No, a class factory creates a new type of class. -cpudef will ultimately call type_register() to create a new QOM visible type. From a management tools perspective, the type is no different than a built-in type. Exactly. The types are no different, so there's no reason to discriminate against types that happen to live in qemu-provided data files vs. qemu code. They aren't instantiated, so we lose nothing by creating the factories (just so long as the factories aren't mass-producing objects). Otherwise, the meaning of -nodefconfig changes as more stuff is moved out of .c and into .cfg. What's the problem with this? The command line becomes unstable if you use -nodefconfig. -no-user-config solves this but I fully expect libvirt would continue to use -nodefconfig. I don't see how libvirt can use -nodefconfig with the fluid meaning you attach to it, or what it gains from it. -nodefconfig = create an empty machine, don't assume anything (=don't read qemu.cfg) let me build it out of all those lego bricks. Those can be defined in code or in definition files in /usr/share, I don't care. Maybe that's -nodevices -vga none. But in this case I don't see the point in -nodefconfig. Not loading target_x86-64.cfg doesn't buy the user anything, since it wouldn't affect the guest in any way. -nodefconfig doesn't mean what you think it means. -nodefconfig doesn't say anything about the user visible machine. -nodefconfig tells QEMU not to read any configuration files at start up. This has an undefined affect on the user visible machine that depends on the specific version of QEMU. Then it's broken. How can anyone use something that has an undefined effect? If I see something like -nodefconfig, I assume it will create a bare bones guest that will not depend on any qemu defaults and will be stable across releases. I don't think anyone will understand -nodefconfig to be something version dependent without reading the qemu management tool author's guide. -- error compiling committee.c: too many arguments to function -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 05:30 PM, Anthony Liguori wrote: On 03/25/2012 10:18 AM, Avi Kivity wrote: On 03/25/2012 05:07 PM, Anthony Liguori wrote: As log as qemu -nodefconfig -cpu westmere -M pc1.1 -nodefconfig is going to eventually mean that -cpu westmere and -M pc-1.1 will not work. This is where QEMU is going. There is no reason that a normal user should ever use -nodefconfig. I don't think anyone or anything can use it, since it's meaning is not well defined. not read any configuration files where parts of qemu are continually moved out to configuration files means its a moving target. I think you assume that all QEMU users care about forward and backwards compatibility on the command line about all else. That's really not true. The libvirt folks have stated repeatedly that command line backwards compatibility is not critical to them. They are happy to require that a new version of QEMU requires a new version of libvirt. I don't think this came out of happiness, but despair. Seriously, keeping compatibility is one of the things we work hardest to achieve, and we can't manage it for our command line? I'm not saying that backwards compat isn't important--it is. But there are users who are happy to live on the bleeding edge. That's fine, but I don't see how -nodefconfig helps them. All it does is take away the building blocks (definitions) that they can use when setting up their configuration. Suppose we define the southbridge via a configuration file. Does that mean we don't load it any more? Yes. If I want the leanest and meanest version of QEMU that will start in the smallest number of milliseconds, then being able to tell QEMU not to load configuration files and create a very specific machine is a Good Thing. Why exclude users from being able to do this? So is this the point? Reducing startup time? I can't say I see the reason to invest so much effort in shaving a millisecond or less from this, but if we did want to, the way would be lazy loading of the configuration where items are parsed as they are referenced. -- error compiling committee.c: too many arguments to function -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 03:26 PM, Anthony Liguori wrote: We would continue to have Westmere/etc in QEMU exposed as part of the user configuration. But I don't think it makes a lot of sense to have to modify QEMU any time a new CPU comes out. We have to. New features often come with new MSRs which need to be live migrated, and of course the cpu flags as well. We may push all these to qemu data files, but this is still qemu. We can't let a management tool decide that cpu feature X is safe to use on qemu version Y. I think QEMU should own CPU definitions. Agree. I think a management tool should have the choice of whether they are used though because they are a policy IMHO. It's okay for QEMU to implement some degree of policy as long as a management tool can override it with a different policy. Sure. We can have something like # default machine's westmere qemu -cpu westmere # pc-1.0's westmere qemu -M pc-1.0 -cpu westmere # pc-1.0's westmere, without nx-less qemu -M pc-1.0 -cpu westmere,-nx # specify everything in painful detail qemu -cpu vendor=Foo,family=17,model=19,stepping=3,maxleaf=12,+fpu,+vme,leaf10eax=0x1234567,+etc -- error compiling committee.c: too many arguments to function -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 10:45 AM, Avi Kivity wrote: On 03/25/2012 05:30 PM, Anthony Liguori wrote: On 03/25/2012 10:18 AM, Avi Kivity wrote: On 03/25/2012 05:07 PM, Anthony Liguori wrote: As log as qemu -nodefconfig -cpu westmere -M pc1.1 -nodefconfig is going to eventually mean that -cpu westmere and -M pc-1.1 will not work. This is where QEMU is going. There is no reason that a normal user should ever use -nodefconfig. I don't think anyone or anything can use it, since it's meaning is not well defined. not read any configuration files where parts of qemu are continually moved out to configuration files means its a moving target. I think you assume that all QEMU users care about forward and backwards compatibility on the command line about all else. That's really not true. The libvirt folks have stated repeatedly that command line backwards compatibility is not critical to them. They are happy to require that a new version of QEMU requires a new version of libvirt. I don't think this came out of happiness, but despair. Seriously, keeping compatibility is one of the things we work hardest to achieve, and we can't manage it for our command line? I hate to burst your bubble, but we struggle and rarely maintain the level of compatibility you're seeking to have. I agree with you that we need to do a better job maintaining compatibility which is why I'm trying to clearly separate the things that we will never break from the things that will change over time. -nodefconfig is a moving target. If you want stability, don't use it. If you just want to prevent the user's /etc/qemu stuff from being loaded, use -no-user-config. I'm not saying that backwards compat isn't important--it is. But there are users who are happy to live on the bleeding edge. That's fine, but I don't see how -nodefconfig helps them. All it does is take away the building blocks (definitions) that they can use when setting up their configuration. Yes, this is a feature. Suppose we define the southbridge via a configuration file. Does that mean we don't load it any more? Yes. If I want the leanest and meanest version of QEMU that will start in the smallest number of milliseconds, then being able to tell QEMU not to load configuration files and create a very specific machine is a Good Thing. Why exclude users from being able to do this? So is this the point? Reducing startup time? Yes, that's one reason. But maybe a user wants to have a whole different set of machine types and doesn't care to have the ones we provide. Why prevent a user from doing this? Maybe they have a management tool that attempts to totally hide QEMU from the end user and exposes a different set of machine types. It's certainly more convenient for something like the Android emulator to only have to deal with QEMU knowing about the 4 types of machines that it specifically supports. Regards, Anthony Liguori -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 10:40 AM, Avi Kivity wrote: On 03/25/2012 05:26 PM, Anthony Liguori wrote: Put the emphasis around *configuration*. So how about: 1) Load ['@SYSCONFDIR@/qemu/qemu.cfg', '@SYSCONFDIR@/qemu/target-@ARCH@.cfg', '@DATADIR@/system.cfg', '@DATADIR@/system-@ARCH@.cfg'] 2) system-@ARCH@.cfg will contain: [system] readconfig=@DATADIR@/target-@a...@-cpus.cfg readconfig=@DATADIR@/target-@a...@-machine.cfg 3) -nodefconfig will not load any configuration files from DATADIR or SYSCONFDIR. -no-user-config will not load any configuration files from SYSCONFDIR. What, more options? Okay, we can just drop -no-user-config and then if a management tool wants to do the equivalent, they can do -nodefconfig + '-readconfig @DATADIR@/system-@ARCH@.cfg'. I'm equally happy with that :-) I don't think -nodefconfig (as defined) is usable, since there is no way for the user to tell what it means short of reading those files. *if the user doesn't know specifics about this QEMU version. You make the assumption that all users are going to throw arbitrary options at arbitrary QEMU versions. That's certainly an important use-case but it's not the only one. -no-user-config is usable, I think it needs also to mean that qemu without -M/-cpu/-m options will error out? You're confusing -nodefaults (or something stronger than -nodefaults) with -no-user-config. Yes, the distinctions are confusing. It's not all fixable tomorrow. If we take my config refactoring series, we can get 90% of the way there soon but Paolo has a more thorough refactoring.. #define westmere blah is not configuration, otherwise the meaning of configuration will drift over time. -cpu blah is, of course. It's the same mechanism, but the above would create two classes of default configuration files and then it becomes a question of how they're used. Confused. We don't have a formal concept of -read-definition-config and -read-configuration-config There's no easy or obvious way to create such a concept either nor do I think the distinction is meaningful to users. The file defines westmere as an alias for a grab bag of options. Whether it's loaded or not is immaterial, unless someone uses one of the names within. But you would agree, a management tool should be able to control whether class factories get loaded, right? No, why? But perhaps I don't entirely get what you mean by class factories. Aren't they just implementations of virtual Device *new_instance(...) = 0? if so, why not load them? No, a class factory creates a new type of class. -cpudef will ultimately call type_register() to create a new QOM visible type. From a management tools perspective, the type is no different than a built-in type. Exactly. The types are no different, so there's no reason to discriminate against types that happen to live in qemu-provided data files vs. qemu code. They aren't instantiated, so we lose nothing by creating the factories (just so long as the factories aren't mass-producing objects). At some point, I'd like to have type modules that are shared objects. I'd like QEMU to start with almost no builtin types and allow the user to configure which modules get loaded. In the long term, I'd like QEMU to be a small, robust core with the vast majority of code relegated to modules with the user ultimately in control of module loading. Yes, I'd want some module autoloading system but there should always be a way to launch QEMU without loading any modules and then load a very specific set of modules (as defined by the user). You can imagine this being useful for something like Common Criteria certifications. Otherwise, the meaning of -nodefconfig changes as more stuff is moved out of .c and into .cfg. What's the problem with this? The command line becomes unstable if you use -nodefconfig. -no-user-config solves this but I fully expect libvirt would continue to use -nodefconfig. I don't see how libvirt can use -nodefconfig with the fluid meaning you attach to it, or what it gains from it. -nodefconfig = create an empty machine, don't assume anything (=don't read qemu.cfg) let me build it out of all those lego bricks. Those can be defined in code or in definition files in /usr/share, I don't care. Maybe that's -nodevices -vga none. But in this case I don't see the point in -nodefconfig. Not loading target_x86-64.cfg doesn't buy the user anything, since it wouldn't affect the guest in any way. -nodefconfig doesn't mean what you think it means. -nodefconfig doesn't say anything about the user visible machine. -nodefconfig tells QEMU not to read any configuration files at start up. This has an undefined affect on the user visible machine that depends on the specific version of QEMU. Then it's broken. How can anyone use something that has an undefined effect? It's obviously defined for a given release, just not defined long term. If I see something like
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
On 03/25/2012 08:01 PM, Anthony Liguori wrote: I don't think this came out of happiness, but despair. Seriously, keeping compatibility is one of the things we work hardest to achieve, and we can't manage it for our command line? I hate to burst your bubble, but we struggle and rarely maintain the level of compatibility you're seeking to have. I agree with you that we need to do a better job maintaining compatibility which is why I'm trying to clearly separate the things that we will never break from the things that will change over time. -nodefconfig is a moving target. If you want stability, don't use it. If you just want to prevent the user's /etc/qemu stuff from being loaded, use -no-user-config. Fine, but let's clearly document it as such. Note just saying it doesn't load any configuration files isn't sufficient. We have to say that it kills Westmere and some of its friends, but preserves others like qemu64. Otherwise it's impossible to use it except by trial and error. I'm not saying that backwards compat isn't important--it is. But there are users who are happy to live on the bleeding edge. That's fine, but I don't see how -nodefconfig helps them. All it does is take away the building blocks (definitions) that they can use when setting up their configuration. Yes, this is a feature. I don't see how, but okay. Suppose we define the southbridge via a configuration file. Does that mean we don't load it any more? Yes. If I want the leanest and meanest version of QEMU that will start in the smallest number of milliseconds, then being able to tell QEMU not to load configuration files and create a very specific machine is a Good Thing. Why exclude users from being able to do this? So is this the point? Reducing startup time? Yes, that's one reason. But maybe a user wants to have a whole different set of machine types and doesn't care to have the ones we provide. Why prevent a user from doing this? How are we preventing a user from doing it? In what way is -nodefconfig helping it? Maybe they have a management tool that attempts to totally hide QEMU from the end user and exposes a different set of machine types. It's certainly more convenient for something like the Android emulator to only have to deal with QEMU knowing about the 4 types of machines that it specifically supports. If it supports four types, it should always pass one of them to qemu. The only thing -nodefconfig adds is breakage when qemu moves something that one of those four machines relies on to a config file. -- error compiling committee.c: too many arguments to function -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Start of freeze for libvirt-0.9.11 and availability of rc1
As scheduled, we are entering the freeze for 0.9.11. I think most API additions are now commited to git upstream (please raise your voice quickly if you see something missing !) I have made a release candidate 1 tarball (and associated rpms) at ftp://libvirt.org/libvirt/libvirt-0.9.11-rc1.tar.gz and the git tree is tagged. I think I will make an release candidate 2 tarball on Wednesday, and I'm hoping for a final release on Friday, or maybe Monday if there are issues found. Please give it a try ! Stability and portability feedback are really welcome as we didn't had a release in Feb and the risk of having something messed up is slightly higher than usual ! thanks in advance, Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2 2/2] Added syntax-check rule for return with parentheses
On 2012年03月23日 15:34, Martin Kletzander wrote: After cleanup introduced with previous commit, there is a need for syntax-check rule taking care of return(). Regexp used in 'prohibit' parameter is taken from the cleanup commit and modified so it fits 'grep -E' format. Semicolon at the end is needed, otherwise the regexp could match return with cast. Exception is created for python source files because we don't have any documentation restricting the use of return that matches this case. --- cfg.mk |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/cfg.mk b/cfg.mk index 24e6a69..eae629b 100644 --- a/cfg.mk +++ b/cfg.mk @@ -469,6 +469,12 @@ sc_prohibit_xmlURI: halt='use virURI(Parse|Format), not xml(ParseURI|SaveUri)' \ $(_sc_search_regexp) +# we don't want old old-style return with parentheses around argument +sc_prohibit_return_as_function: + @prohibit='\return *\(([^()]*(\([^()]*\)[^()]*)*)\) *;'\ + halt='avoid extra () with return statements'\ + $(_sc_search_regexp) + # ATTRIBUTE_UNUSED should only be applied in implementations, not # header declarations sc_avoid_attribute_unused_in_header: @@ -791,6 +797,8 @@ exclude_file_name_regexp--sc_prohibit_xmlGetProp = ^src/util/xml\.c$$ exclude_file_name_regexp--sc_prohibit_xmlURI = ^src/util/viruri\.c$$ +exclude_file_name_regexp--sc_prohibit_return_as_function = ^\.py$$ + exclude_file_name_regexp--sc_require_config_h = ^examples/ exclude_file_name_regexp--sc_require_config_h_first = ^examples/ -- 1.7.3.4 Looks good from my point of view, ACK. But we might need to push these later after 0.9.11. Regards, Osier -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Createion of external snapshot qcow2
Hi all, I have a query regarding the external snapshot in qcow2 also known as backing file. In qemu I created a external snapshot and then create its xml in order to boot it from VIRSH. But that is complex process. I want to know whether there is any command in LIBVIRT which can create external snapshot(Backing file) and also we can boot from it? DISCLAIMER: --- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NECHCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NECHCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. . - libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
