Re: [libvirt] [PATCH v3 1/8] Add namespace callback hooks to domain_conf.
On Fri, Jul 02, 2010 at 11:18:18AM -0400, Chris Lalancette wrote: This patch adds namespace XML parsers to be hooked into the main domain parser. This allows for individual hypervisor drivers to add per-namespace XML into the main domain XML. Changes since v1: - Use a statically declared table for caps-ns, removing the need to allocate/free it. Changes since v2: - None Signed-off-by: Chris Lalancette clala...@redhat.com --- src/conf/capabilities.h | 17 + src/conf/domain_conf.c | 38 +++--- src/conf/domain_conf.h |3 +++ 3 files changed, 51 insertions(+), 7 deletions(-) ACK 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt][qemu] Ho to get a 'boot=on' parameter to appear on kvm command line
On Wed, Jun 10, 2009 at 01:07:34PM +0400, Anton Protopopov wrote: Hi, all. Can someone tell me how to get boot=on parameter to appear on my kvm cmdline? What version of KVM have you got ? There was one recent release which broke the 'boot=on' parameter. I define domain with the following xml domain type=kvm namekvm-1/name memory524288/memory vcpu1/vcpu os type arch=x86_64 machine=pchvm/type boot dev=hd/ /os devices emulator/usr/bin/kvm/emulator graphics type=vnc port=-1/ disk device=disk type=file source file=test.img/ target dev=sda/ /disk interface type=bridge source bridge=breth0/ /interface /devices /domain and get /usr/bin/kvm -S -M pc -m 512 -smp 1 -name kvm-1 -uuid b462e575-4044-146c-193a-9a70523b4258 -monitor pty -no-acpi -boot c -drive file=test.img,if=scsi,index=0 -net nic,macaddr=52:54:00:09:9b:19,vlan=0 -net tap,fd=15,vlan=0 -serial none -parallel none -usb But I want to get -drive file=test.img,if=scsi,index=0,boot=on instead. Your XML looks fine - the boot dev='hd'/ tag should have resulted in the boot=on parameter being used on the first disk. Thus I suspect you have the broken KVM release. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] QEMU/KVM auto-detection bug
On Tue, May 12, 2009 at 11:36:50AM +0200, Chris Lalancette wrote:
All,
Even with Guido/Pritesh's recent changes to the vbox open routine, the
auto-detection in libvirt is currently broken. What happens is that in
src/libvirt.c:do_open(), at the start of the loop to auto-detect drivers,
ret-uri is NULL. As each driver declines, it remains NULL. However, the
very
first thing the vboxOpen() routine does is:
if (conn-uri == NULL) {
conn-uri = xmlParseURI(uid ? vbox:///session : vbox:///system);
if (conn-uri == NULL) {
return VIR_DRV_OPEN_ERROR;
}
So, any driver that is trying to auto-probe after vboxOpen sees a conn-uri
with
a scheme of vbox and a path of system/session, and they all fail (including
Qemu, which is what I'm mostly concerned with at the moment).
Please re-test with the patch I posted yesterday
http://www.redhat.com/archives/libvir-list/2009-May/msg00198.html
In point of fact, this whole auto-detection thing is fragile. We got away
with
it before because the qemuOpen() routine bombs out before doing the whole
conn-uri == NULL check, but in general, it's very easy for one buggy driver
to
mess up auto-detection for all drivers.
The general rule is that a driver should not set conn-uri to non-NULL
until *after* it has determined that it can handle it.
The problem here was that virtualbox driver was setting the uri to non-NULL,
and only then seeing if virtalbox was available. My patch fixes that logic
ordering bug
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] adding tests....
On Mon, Jan 12, 2009 at 01:28:41PM +0100, Jim Meyering wrote:
Daniel P. Berrange berra...@redhat.com wrote:
+if (remote_config_file == NULL) {
+ static const char *default_config_file
+= SYSCONF_DIR /libvirt/libvirtd.conf;
+ remote_config_file =
+(access(default_config_file, X_OK) == 0
+ ? default_config_file
+ : /dev/null);
+}
That should be R_OK, not X_OK - the config files aren't
marked executable, so this will never load the config.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
Libvir-list mailing list
Libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] mark a few diagnostics for translation
On Mon, Jan 05, 2009 at 08:31:59AM +0100, Jim Meyering wrote: Here are two warning-avoidance changes I'm about to commit: From 588ecf78ffd6f284aa7872c13d946b9b5a146ef0 Mon Sep 17 00:00:00 2001 From: Jim Meyering meyer...@redhat.com Date: Tue, 23 Dec 2008 16:49:26 +0100 Subject: [PATCH 1/2] mark a few diagnostics for translation ACK Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] make install doesn't install to /usr/lib64
On Thu, Nov 20, 2008 at 07:32:56PM +0200, Kenneth Nagin wrote: I am working on a x86_64 machine. I expected 'make install' to install to libvirt.so to /usr/lib64. But it installs to /usr/lib. Is this a bug or is it the expected behavior? That is a distro specific policy, whcih varies from autoconf policy. So to make it follow the distro policy yuou must supply an explicit arg to configure, --libdir=/usr/lib64 As an example, RPM does this automatically if you use the %configure macro, but if you're doing builds by hand you must add whatever args are needed Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Pass a callback for freeing opaque data when registering handle/timer events
On Wed, Nov 19, 2008 at 02:21:40PM +0100, Daniel Veillard wrote: On Mon, Nov 17, 2008 at 05:02:40PM +, Daniel P. Berrange wrote: When registering for a file descriptor event, or timer events, the event callback has an associated 'void *opaque' data blob. When removing a registered event, the removal may be done asynchronously to allow safe removal from within a callback. This means that it is not safe for the application to assume they can free the 'void *opaque' data immediately after calling virEventRemoveHandle/Timer. So, we extend the AddHandle/Timer method to allow a 2nd callback to be provided. This callback is used to free the 'void *opaque' data at the appropriate (safe) point in time. okay, it makes more sense to provide the API framework on how to free the data I've committed this change, but using the generic virFreeCallback typedef, instead of my custom one. Also I put the virFreeCallback as the last arg, to match the style of David Lively's equivalent patch to the virDomainEventRegister call. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Suggestion on commit rules when fixing breakages
On Thu, Oct 16, 2008 at 03:15:08PM +0200, Daniel Veillard wrote: As the number of compilation options and platform grows, it gets more difficult for a commiter to always ensure one chunk of code won't give a problem in a different situation. To try to lower the cost of maintaining the protability I would suggest the following rule for commit: - if a recently commited patch breaks compilation on a platform or for a given driver then it's fine to commit a minimal fix directly without getting the review feedback first - similary if make check or make syntax-chek breaks, if there is an obvious fix, it's fine to commit immediately Note that this would remove the need to send the patch to the list anyway (or tell what the fix was if trivial). This doesn't either remove the rule that 'make check syntax-check' should pass before commiting anything, and obviously the existing review process is still needed t for anything which is not a trivial fix breaking make or checks. I guess it makes sense to minimize disruption for those working on head and lower the time needed to get those fix in for those who catch and fix them ;-) Opinions ? Yes, this is reasonable idea - its crazy to wait for ACKs on the list to fix 1-2 line typos in the code which break compilation. I'll also remind all those with commit access that you should run be running autogen.sh or configure with --enable-compile-warnings=error which adds -Werror to compile flags, so no warnings get missed. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] introducing source name (for logical storage pools)
On Fri, Aug 08, 2008 at 03:17:52PM -0400, David Lively wrote: Daniel B proposed having storage pool discovery return a bunch of XML storage source elements, rather than full pool elements (which contain target-dependent details like the local pool name and device or mount path -- things which don't need to be decided unless/until the pool is defined). I like his suggestion a lot, and I think it addresses the final API-definition problem keeping storage pool discovery out of libvirt. But ... it doesn't quite work for logical storage pools because those are created from the pool name element (which is the same as the volume group name). Yep, I half-expected that format decision to come back haunt me :-( ???This patch introduces a new source element name, which is distinct from the pool name. name is used only by the logical storage backend, and represents the volume group name. For convenience and back-compatibility, source name defaults to the pool name if not specified when the pool is defined, and pool name defaults to the source name if not specified. There is no requirement that pool and source name be the same, though. While admittedly it seems a little weird, it does allow more flexibility (pool name not tied to vol group name), and allows source to fully specify a logical pool source, as it does for the other pool types[*]. Defaulting the source name from the pool name means all existing pool XML definitions continue to work. Defaulting the pool name from the source name is simply a matter of convenience (but perhaps a step too far?) If this is accepted, logical pool discovery can then return a bunch of sources like: sourcenameVolGroup00/name/source sourcenameVolGroup01/name/source Please note I'll be on vacation next week (Aug 11-15), so I may not be responding until the following week. Thanks, Dave [*] Well ... almost. Note that directory pools have a similar issue -- the source of the pool is given by the target path -- there's no source. I suppose implementing directory pool discovery (for the sake of completeness) means addressing this as well, maybe via some similar mechanism ... We already have a sourcedirectory/directory/source element we use for NFS exports. I didn't bother with it for directory pools because it'd be duplicating info from the target path, but in retrospect we should use it for directory pools. Perhaps we could even use it for the LVM pools instead of adding a new name element - eg, sourcedirectory/dev/VolGroup00/directory/source sourcedirectory/dev/VolGroup01/directory/source I don't feel too strongly about this though - either name or directory in the source would do the job for LVM pools nicely. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] PATCH: Generic internal API for domain XML parser/formatter
On Wed, Jun 25, 2008 at 11:58:10AM +0200, Gerd Hoffmann wrote: Daniel P. Berrange wrote: IMHO it is a fundamental design flaw that dumpxml gives different results depending on whenever the domain is running or not. Hard to fix by now though :-( Actually there is another way to access the info - pass the flag VIR_DOMAIN_XML_INACTIVE to the DumpXML method to explicitly request the inactive XML. Oh, good. Has virsh a switch for that? Not yet - it also doesn't actually work fully with current libvirt - this is something I'm fixed with the re-factoring of the XML parsing patches so that all drivers honour this flag fully. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
