June 2010 - Devel - libvirt List Archives

Re: [libvirt] Documentation for synchronous hooks
by Jintao Yang 02 Jul '10

02 Jul '10

hi DV, I saw the changelog of 0.7.8, which told the hooks scripts are supported. but is it took away in 0.8.0-4? [root@dhcp-66-70 libvirt]# rpm -ql libvirt | grep etc /etc/libvirt /etc/libvirt/libvirtd.conf /etc/libvirt/lxc.conf /etc/libvirt/nwfilter /etc/libvirt/nwfilter/allow-arp.xml /etc/libvirt/nwfilter/allow-dhcp-server.xml /etc/libvirt/nwfilter/allow-dhcp.xml /etc/libvirt/nwfilter/allow-incoming-ipv4.xml /etc/libvirt/nwfilter/allow-ipv4.xml /etc/libvirt/nwfilter/clean-traffic.xml /etc/libvirt/nwfilter/no-arp-spoofing.xml /etc/libvirt/nwfilter/no-ip-multicast.xml /etc/libvirt/nwfilter/no-ip-spoofing.xml /etc/libvirt/nwfilter/no-mac-broadcast.xml /etc/libvirt/nwfilter/no-mac-spoofing.xml /etc/libvirt/nwfilter/no-other-l2-traffic.xml /etc/libvirt/qemu /etc/libvirt/qemu.conf /etc/libvirt/qemu/networks /etc/libvirt/qemu/networks/autostart /etc/logrotate.d/libvirtd.lxc /etc/logrotate.d/libvirtd.qemu /etc/rc.d/init.d/libvirtd /etc/sysconfig/libvirtd [root@dhcp-66-70 libvirt]# rpm -q libvirt libvirt-0.8.0-4.el6.x86_64 Regards osier ----- Original Message ----- From: "Daniel Veillard" <veillard(a)redhat.com> To: libvir-list(a)redhat.com Sent: Monday, April 12, 2010 11:16:27 PM GMT +08:00 Beijing / Chongqing / Hong Kong / Urumqi Subject: [libvirt] Documentation for synchronous hooks Was still missing from main commits and would be needed for 0.8.0 Add documentation for synchronous hooks * docs/sitemap.html.in: add in navigation under Documentation/Deployment/Hooks * docs/hooks.html.in: new doc describing current support for 0.8.0 diff --git a/docs/hooks.html.in b/docs/hooks.html.in new file mode 100644 index 0000000..4ebeec3 --- /dev/null +++ b/docs/hooks.html.in @@ -0,0 +1,71 @@ +<?xml version="1.0"?> +<html> + <body> + <h1>Hooks for specific system management</h1> + Libvirt includes synchronous hooks starting from version 0.8.0, + this is a way to tie specific tailored system actions at specific + time. This is based on scripts being called on the Host where the + hypervisor is running, if the script is present when the libvirtd + daemon is doing some significant actions. + The scripts are expected to execute quickly, return a zero exit + status if all conditions are set for the daemon to continue the + action (non zero will be considered a failure which may + be ignored but in general will stops the ongoing operation). + The script also should not call back into libvirt as the daemon + is waiting for the script exit and deadlock is likely to occur + otherwise. + The scripts are stored in the directory <code>/etc/libvirt/hooks/</code> + when using a standard installation path + (<code>$SYSCONF_DIR/libvirt/hook/</code> in general). + The scripts gets arguments as parameter on their command line: + <ul> + <li> the first argument is the name of the object involved in the + operation or '-' if there is none. + <li> the second argument is the name of the operation. + <li> the third argument is a suboperation indication like 'start' + 'end' or '-' if there is none. + <li> the last argument is an extra argument string or '-' if there + is none. + </ul> + There is currently scripts for 3 domains of operation: + <ul> + <li><code>/etc/libvirt/hooks/daemon</code> script if + present is called at 3 points in time: + at daemon startup, typically started with the following + arguments: + <pre>/etc/libvirt/hooks/daemon - start - start</pre> + at daemon shutdown when it is about to exit, with the following + arguments: + <pre>/etc/libvirt/hooks/daemon - shutdown - shutdown</pre> + When the daemon is asked to reload its driver state when + receiving the SIGHUP signal, arguments are: + <pre>/etc/libvirt/hooks/daemon - reload begin SIGHUP</pre> + </li> + <li><code>/etc/libvirt/hooks/qemu</code> script and + <code>/etc/libvirt/hooks/lxc</code> to associate hooks for domain + operation on the respective QEmu/KVM and LXC drivers. + The domain related hooks also receive the full XML description + for the concerned domain on their stdin, which allows to get + all the informations from the domain, including UUID or storage + if that is needed for the script operation. + Currently only domain startup and domain end operations + involve the hook, the first one just before the domain gets + created. + For example if starting a QEmu domain named <code>test</code> + the following script will get called: + <pre>/etc/libvirt/hooks/qemu test start begin -</pre> + note that a non-zero return value from the script will abort the + domain startup operation, and if an error string is passed on + stderr by the hook script, it will be provided back to the user + at the libvirt API level. + For domain shutdown, the script will be called just after the + domain has finished execution, and the script will get: + <pre>/etc/libvirt/hooks/qemu test stopped end -</pre> + It is expected that other operation will be associated to hooks + but at the time of 0.8.0 only those 2 are associated to domains + lifecycle + </li> + </ul> + + </body> +</html> diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in index 0c3f0c3..0117c8d 100644 --- a/docs/sitemap.html.in +++ b/docs/sitemap.html.in @@ -50,6 +50,10 @@ <a href="logging.html">Logging</a> The library and the daemon logging support </li> + <li> + <a href="hooks.html">Hooks</a> + Hooks for system specific management + </li> </ul> </li> <li> -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list(a)redhat.com https://www.redhat.com/mailman/listinfo/libvir-list

5 6

[libvirt] [PATCH] ruby-libvirt: virNodeGetFreeMemory and virGetLibVersion
by Jaromír Červenka 01 Jul '10

01 Jul '10

Author is Michal Hrušecký <mhrusecky(a)suse.cz>. He was unsure about second patch, maybe adds duplicate functionality, please check it. Greetings, Jaromir.

3 2

[libvirt] make check fails on CentOS 5
by Daniel Berteaud 01 Jul '10

01 Jul '10

Hi. I'm using libvirt on a CentOS 5.4 x86_64 host without issue, until libvirt 0.8.1. I usually just rebuild the available src rpm with the following args: --without xen --without xen-proxy \ --without lxc --without vbox --without esx \ --without phyp --without one --without avahi \ --without openvz --without uml (I only use KVM) But, with libvirt 0.8.1, the buiild process now include make check, and one of the check fails: interfaceschematest Attached is the full build log, you can see the failure line 1841. I really don't know how to debug this. For now, I've just added interfaceschematest to the list of check to skip in the spec file (for i in nodeinfotest daemon-conf seclabeltest interfaceschematest). With this modification, everything works, and I'm actually using it this way. Anybody knows why this test fails ? Regards, Daniel -- Daniel Berteaud FIREWALL-SERVICES SARL. Société de Services en Logiciels Libres Technopôle Montesquieu 33650 MARTILLAC Tel : 05 56 64 15 32 Fax : 05 56 64 15 32 Mail: daniel(a)firewall-services.com Web : http://www.firewall-services.com

3 3

[libvirt] Ask for help about libvirt error: can't get physical interface data for kvm.
by Feng Dan Liu 01 Jul '10

01 Jul '10

Hi I find this mail address from the internet and hope I can get the reply from anyone of you, that will be very appreciated. I'm using virsh to manage the KVM(qemu-kvm 0.12.4, libvirt 0.8.1), but I encounter an error as below: I saw both libvirt api and virsh commands support to get the physical interfaces data, but it always fail when I using them for KVM hypervisor. I was thought that it was due to the old version of libvirt/KVM hypervisor, but the error still exist when using the latest libvirt and kvm hypervisor. So I wonder if the following functions of libvirt haven't been implemented for KVM, could you pls help me get the answer about this? Thanks in advance! virConnectListInterfaces virConnectNumOfDefinedInterfaces virConnectNumOfInterfaces virConnectListDefinedInterfaces virInterfaceLookupByName Best Regards, Fengdan Liu Tivoli ITCAM Solution, IBM China Software Development Lab, Tel: 13811762746 Email: liufengd(a)cn.ibm.com 3/F, Haohai Bldg., No.7, 5th Street, Shangdi, Haidian District, Beijing 100085, P.R.China

2 2

[libvirt] Maintenance of ruby bindings
by Neil Wilson 30 Jun '10

30 Jun '10

Hi, Is there anybody looking after the Ruby bindings? Are you still taking patches? It seems quite out of date wrt. the current interface. Rgs Neil Wilson

4 6

[libvirt] Update on PHP libvirt
by Radek Hladik 30 Jun '10

30 Jun '10

I would like to post some update about PHP bindings for libvirt I started last year. As usual I do not have enough time to work on it however the last version 0.3 seems to be quite stable. I did get some reports from people using it and it seems that the code is working without problems. I will probably change the status from alpha to beta. The code (available at http://phplibvirt.cybersales.cz/ ) implements basic Libvirt functions for readonly access and machine live-cycle management. I should be able to add any other libvirt function but i do not know all the libvirt functions so well. So if you miss some function and you are willing to test it I can implement it. I would appreciate any feedback and suggestions on this code. Radek

5 10

[libvirt] [PATCH] cgroup: Fix compilation broken on MinGW due to dirent->d_type
by Ryota Ozaki 30 Jun '10

30 Jun '10

As pointed out by Eric Blake, using dirent->d_type breaks compilation on MinGW. This patch addresses this by using '#if defined' as same as doing for virCgroupForDriver. --- src/util/cgroup.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/src/util/cgroup.c b/src/util/cgroup.c index 9fa64dc..024036a 100644 --- a/src/util/cgroup.c +++ b/src/util/cgroup.c @@ -608,6 +608,7 @@ cleanup: } #endif +#if defined _DIRENT_HAVE_D_TYPE static int virCgroupRemoveRecursively(char *grppath) { DIR *grpdir; @@ -656,6 +657,13 @@ static int virCgroupRemoveRecursively(char *grppath) return rc; } +#else +static int virCgroupRemoveRecursively(char *grppath ATTRIBUTE_UNUSED) +{ + /* Claim no support */ + return -ENXIO; +} +#endif /** * virCgroupRemove: -- 1.6.5.2

2 3

[libvirt] [PATCH] virsh: tweak help output for VSH_OT_DATA
by Eric Blake 30 Jun '10

30 Jun '10

https://bugzilla.redhat.com/show_bug.cgi?id=609044 complained that 'virsh help pool-create-as' didn't document the shortcut that you can do 'virsh pool-create-as $name $type --target $target' rather than having to supply the four optional source- arguments in order to fill out the necessary positional arguments. This one-liner changes the help output to hopefully make this more obvious: NAME pool-create-as - create a pool from a set of args SYNOPSIS pool-create-as <name> [--print-xml] <type> [<source-host>] [<source-path>] [<source-dev>] [<source-name>] [<target>] [--source-format <string>] DESCRIPTION Create a pool. OPTIONS [--name] <string> name of the pool --print-xml print XML document, but don't define/create [--type] <string> type of the pool [--source-host] <string> source-host for underlying storage [--source-path] <string> source path for underlying storage [--source-dev] <string> source device for underlying storage [--source-name] <string> source name for underlying storage [--target] <string> target for underlying storage --source-format <string> format for underlying storage * tools/virsh.c (vshCmddefHelp): Make it more obvious that data arguments may, but not must, be specified by option leaders. --- Wow - the commit message is 30 times bigger than the commit itself! If additionally wanted, I could make the help output wrap if the left column is long, so that the right column lines up, looking more like: OPTIONS [--name] <string> name of the pool --print-xml print XML document, but don't define/create [--type] <string> type of the pool [--source-host] <string> source-host for underlying storage [--source-path] <string> source path for underlying storage [--source-dev] <string> source device for underlying storage [--source-name] <string> source name for underlying storage [--target] <string> target for underlying storage --source-format <string> format for underlying storage tools/virsh.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/tools/virsh.c b/tools/virsh.c index f1bb295..cdac9c0 100644 --- a/tools/virsh.c +++ b/tools/virsh.c @@ -9558,7 +9558,7 @@ vshCmddefHelp(vshControl *ctl, const char *cmdname) else if (opt->type == VSH_OT_STRING) snprintf(buf, sizeof(buf), _("--%s <string>"), opt->name); else if (opt->type == VSH_OT_DATA) - snprintf(buf, sizeof(buf), "<%s>", opt->name); + snprintf(buf, sizeof(buf), "[--%s] <string>", opt->name); fprintf(stdout, " %-15s %s\n", buf, _(opt->help)); } -- 1.7.0.1

2 4

[libvirt] [PATCH] Avoid invoking the qemu monitor destroy callback if the constructor fails
by Daniel P. Berrange 30 Jun '10

30 Jun '10

Some, but not all, codepaths in the qemuMonitorOpen() method would trigger the destroy callback. The caller does not expect this to be invoked if construction fails, only during normal release of the monitor. This resulted in a possible double-unref of the virDomainObjPtr, because the caller explicitly unrefs the virDomainObjPtr if qemuMonitorOpen() fails * src/qemu/qemu_monitor.c: Don't invoke destroy callback from qemuMonitorOpen() failure paths --- src/qemu/qemu_monitor.c | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/src/qemu/qemu_monitor.c b/src/qemu/qemu_monitor.c index f428665..ff613a0 100644 --- a/src/qemu/qemu_monitor.c +++ b/src/qemu/qemu_monitor.c @@ -671,6 +671,12 @@ qemuMonitorOpen(virDomainObjPtr vm, return mon; cleanup: + /* We don't want the 'destroy' callback invoked during + * cleanup from construction failure, because that can + * give a double-unref on virDomainObjPtr in the caller, + * so kill the callbacks now. + */ + mon->cb = NULL; qemuMonitorUnlock(mon); qemuMonitorClose(mon); return NULL; -- 1.6.6.1

3 3

[libvirt] [PATCH] cgroup: Add missing errno == ENOENT check in virCgroupRemoveRecursively
by Ryota Ozaki 30 Jun '10

30 Jun '10

ENOENT happens normally when a subsystem is enabled with any other subsystems and the directory of the target group has already removed in a prior loop. In that case, the function should just return without leaving an error message. NB this is the same behavior as before introducing virCgroupRemoveRecursively. --- src/util/cgroup.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/src/util/cgroup.c b/src/util/cgroup.c index 62b1446..9fa64dc 100644 --- a/src/util/cgroup.c +++ b/src/util/cgroup.c @@ -616,6 +616,8 @@ static int virCgroupRemoveRecursively(char *grppath) grpdir = opendir(grppath); if (grpdir == NULL) { + if (errno == ENOENT) + return 0; VIR_ERROR(_("Unable to open %s (%d)"), grppath, errno); rc = -errno; return rc; -- 1.6.5.2

2 4