[libvirt] [PATCH 2/5] daemonize qemu processes
by Guido Günther
Make sure vms don't get killed when the libvirtd quits unexpectedly.
Needs the previous patch since it looks at the pid file.
---
src/qemu_driver.c | 36 ++++++++++++++++++++++++------------
1 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/src/qemu_driver.c b/src/qemu_driver.c
index a2e573e..7804094 100644
--- a/src/qemu_driver.c
+++ b/src/qemu_driver.c
@@ -858,6 +858,7 @@ static int qemudStartVMDaemon(virConnectPtr conn,
const char *emulator;
uid_t uid = geteuid();
mode_t logmode;
+ pid_t child;
FD_ZERO(&keepfd);
@@ -988,12 +989,26 @@ static int qemudStartVMDaemon(virConnectPtr conn,
for (i = 0 ; i < ntapfds ; i++)
FD_SET(tapfds[i], &keepfd);
- ret = virExec(conn, argv, progenv, &keepfd, &vm->pid,
+ ret = virExec(conn, argv, progenv, &keepfd, &child,
vm->stdin_fd, &vm->stdout_fd, &vm->stderr_fd,
- VIR_EXEC_NONBLOCK);
- if (ret == 0)
+ VIR_EXEC_NONBLOCK | VIR_EXEC_DAEMON);
+
+ /* wait for qemu process to to show up */
+ if (ret == 0) {
+ int retries = 100;
+ while (retries) {
+ if ((ret = virFileReadPid(driver->stateDir, vm->def->name, &vm->pid)) == 0)
+ break;
+ usleep(10*1000);
+ retries--;
+ }
+ if (ret)
+ qemudLog(QEMUD_WARN, _("Domain %s didn't show up\n"), vm->def->name);
+ }
+
+ if (ret == 0) {
vm->state = migrateFrom ? VIR_DOMAIN_PAUSED : VIR_DOMAIN_RUNNING;
- else
+ } else
vm->def->id = -1;
for (i = 0 ; argv[i] ; i++)
@@ -1069,7 +1084,9 @@ static void qemudShutdownVMDaemon(virConnectPtr conn ATTRIBUTE_UNUSED,
qemudLog(QEMUD_INFO, _("Shutting down VM '%s'\n"), vm->def->name);
- kill(vm->pid, SIGTERM);
+ if (kill(vm->pid, SIGTERM) < 0)
+ qemudLog(QEMUD_ERROR, _("Failed to send SIGTERM to %s (%d): %s\n"),
+ vm->def->name, vm->pid, strerror(errno));
qemudVMData(driver, vm, vm->stdout_fd);
qemudVMData(driver, vm, vm->stderr_fd);
@@ -1089,13 +1106,8 @@ static void qemudShutdownVMDaemon(virConnectPtr conn ATTRIBUTE_UNUSED,
vm->stderr_fd = -1;
vm->monitor = -1;
- if (waitpid(vm->pid, NULL, WNOHANG) != vm->pid) {
- kill(vm->pid, SIGKILL);
- if (waitpid(vm->pid, NULL, 0) != vm->pid) {
- qemudLog(QEMUD_WARN,
- "%s", _("Got unexpected pid, damn\n"));
- }
- }
+ /* shut it off for sure */
+ kill(vm->pid, SIGKILL);
vm->pid = -1;
vm->def->id = -1;
--
1.6.0.2
15 years, 11 months
[libvirt] [PATCH] Fix !SASL qemud compile
by john.levon＠sun.com
# HG changeset patch
# User john.levon(a)sun.com
# Date 1229980020 28800
# Node ID 4fbf7139ca42757d771f03578e91038bf28a5e0e
# Parent fd97ec8e5799120ebf5ea9ed73d681c6d1386970
Fix !SASL qemud compile
Replace qemudLog() with ERROR0()
Signed-off-by: John Levon <john.levon(a)sun.com>
diff --git a/qemud/remote.c b/qemud/remote.c
--- a/qemud/remote.c
+++ b/qemud/remote.c
@@ -2968,7 +2968,7 @@ remoteDispatchAuthSaslInit (struct qemud
void *args ATTRIBUTE_UNUSED,
remote_auth_sasl_init_ret *ret ATTRIBUTE_UNUSED)
{
- qemudLog(QEMUD_ERR, "%s", _("client tried unsupported SASL init request"));
+ ERROR0(_("client tried unsupported SASL init request"));
remoteDispatchAuthError(rerr);
return -1;
}
@@ -2981,7 +2981,7 @@ remoteDispatchAuthSaslStart (struct qemu
remote_auth_sasl_start_args *args ATTRIBUTE_UNUSED,
remote_auth_sasl_start_ret *ret ATTRIBUTE_UNUSED)
{
- qemudLog(QEMUD_ERR, "%s", _("client tried unsupported SASL start request"));
+ ERROR0(_("client tried unsupported SASL start request"));
remoteDispatchAuthError(rerr);
return -1;
}
@@ -2994,7 +2994,7 @@ remoteDispatchAuthSaslStep (struct qemud
remote_auth_sasl_step_args *args ATTRIBUTE_UNUSED,
remote_auth_sasl_step_ret *ret ATTRIBUTE_UNUSED)
{
- qemudLog(QEMUD_ERR, "%s", _("client tried unsupported SASL step request"));
+ ERROR0(_("client tried unsupported SASL step request"));
remoteDispatchAuthError(rerr);
return -1;
}
15 years, 11 months
[libvirt] [PATCH] Make mntent.h specific to the FS storage backend
by john.levon＠sun.com
# HG changeset patch
# User john.levon(a)sun.com
# Date 1229789393 28800
# Node ID c433c57ef39b2c343653910df84130c8849a7c11
# Parent 100de621beed6e146b239df3691bd426090955b4
Make mntent.h specific to the FS storage backend
It's Linux specific, so for now, put it behind a WITH_STORAGE_FS guard.
Signed-off-by: John Levon <john.levon(a)sun.com>
diff --git a/src/storage_backend_fs.c b/src/storage_backend_fs.c
--- a/src/storage_backend_fs.c
+++ b/src/storage_backend_fs.c
@@ -31,7 +31,6 @@
#include <errno.h>
#include <fcntl.h>
#include <unistd.h>
-#include <mntent.h>
#include <string.h>
#include <libxml/parser.h>
@@ -242,6 +241,9 @@ static int virStorageBackendProbeFile(vi
}
#if WITH_STORAGE_FS
+
+#include <mntent.h>
+
struct _virNetfsDiscoverState {
const char *host;
virStoragePoolSourceList list;
15 years, 11 months
[libvirt] [PATCH] virAsprintf cleanup
by Guido Günther
Hi,
please find a possible asprintf vs. virAsprintf cleanup attached. There
were several occations where the result of a failed asprintf was used.
Cheers,
-- Guido
15 years, 11 months
Re: [libvirt] KVM/qemu: problems with autostart of vms with non-bridged nets
by Gerd v. Egidy
> > I came up with the attached patch to fix this for me, but
> > a) I'm not sure if it is a clean use of the api to call virConnectOpen()
> > from within a state-initializer function
> > b) This is just for qemu/kvm, I haven't looked at any other drivers
> >
> > It would be nice if an experienced libvirt-developer could take a look at
> > this. Thank you very much.
>
> Thanks for the bug report & patch.
>
> Did this patch actually make it work for you ? AFAICT, there's a problem
> even earlier, which is that we are doing autostart of the virtual machines,
> before autostart of the networks and storage pools, so I'm not sure that
> this patch is sufficient.
This patch alone not, but this patch + the one in my first mail
(see https://www.redhat.com/archives/libvir-list/2008-November/msg00457.html)
together make it work for me. The first patch fixes the autostart order, the
second one adds the necessary conn structure.
Kind regards,
Gerd
--
Address (better: trap) for people I really don't want to get mail from:
james(a)cactusamerica.com
15 years, 11 months
[libvirt] libvirtd crashing with network bridge configuration
by Emre Erenoglu
Dear Developers, Users,
I'm trying to package libvirt for our distribution, however, having some
problems past the libvirt 0.4.3 series. Everything compiles and installs
fine.
With versions above and including 0.5.1, I'm getting the following errors in
the dmesg output:
virbr0: Dropping NETIF_F_UFO since no NETIF_F_HW_CSUM
feature.
virbr0: starting userspace STP failed, starting kernel
STP
sysfs: duplicate filename '0' can not be
created
------------[ cut here
]------------
WARNING: at fs/sysfs/dir.c:424
sysfs_add_one+0x34/0xa6()
Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4
xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables
microcode firmware_class acpi_cpufreq cpufreq_powersave cpufreq_userspace
ipv6 bridge fuse loop tun kvm_intel kvm coretemp w83627ehf hwmon_vid hwmon
snd_hda_intel nvidia(P) snd_seq_dummy snd_seq_oss snd_seq_midi_event joydev
snd_seq rtc_cmos rtc_core rtc_lib snd_seq_device i2c_i801 iTCO_wdt usbhid
serio_raw snd_pcm_oss snd_mixer_oss hid iTCO_vendor_support snd_pcm
ff_memless snd_timer snd_page_alloc thermal atl1 snd_hwdep processor
intel_agp snd button mii agpgart i2c_core soundcore sg ext3 jbd mbcache
raid456 async_xor async_memcpy async_tx xor raid10 raid1 raid0 dm_mod sd_mod
sr_mod cdrom usb_storage pata_jmicron ehci_hcd uhci_hcd usbcore ohci1394
ieee1394 pata_acpi ahci ata_generic libata scsi_mod
dock
Pid: 3605, comm: libvirtd Tainted: P 2.6.25.20-113
#1
[<c02d60e6>] ?
printk+0xf/0x11
[<c0122e01>]
warn_on_slowpath+0x41/0x67
[<c01dbae8>] ?
vsnprintf+0x287/0x40f
[<c012352e>] ?
release_console_sem+0x194/0x19c
[<c01d7e32>] ?
ida_get_new_above+0xd0/0x171
[<c0185afb>] ?
find_inode+0x1f/0x5b
[<c01afde8>] ?
sysfs_ilookup_test+0x0/0x11
[<c0185bfb>] ?
ifind+0x32/0x76
[<c01b00ca>]
sysfs_add_one+0x34/0xa6
[<c01b05b2>]
create_dir+0x43/0x72
[<c01b060e>]
sysfs_create_dir+0x2d/0x41
[<c01d85de>] ?
kobject_get+0x12/0x17
[<c01d86dc>]
kobject_add_internal+0xa9/0x14a
[<c01d8811>]
kobject_add_varg+0x35/0x41
[<c01d883d>]
kobject_init_and_add+0x20/0x22
[<c012ae70>]
uids_user_create+0x36/0x5b
[<c012b028>] alloc_uid+0xf3/0x1b6
[<c01486c6>] copy_user_ns+0x59/0xaf
[<c0136833>] create_new_namespaces+0xe9/0x196
[<c013697e>] copy_namespaces+0x45/0x73
[<c0122152>] copy_process+0xba9/0x11e5
[<c012283d>] do_fork+0xaf/0x1e4
[<c0103428>] sys_clone+0x1f/0x21
[<c0104a2e>] syscall_call+0x7/0xb
[<c02d0000>] ? pci_fixup_msi_k8t_onboard_sound+0x68/0x98
=======================
---[ end trace e8211acaf4c7288d ]---
kobject_add_internal failed for 0 with -EEXIST, don't try to register things
with the same name in the same directory.
Pid: 3605, comm: libvirtd Tainted: P 2.6.25.20-113 #1
[<c01d876b>] kobject_add_internal+0x138/0x14a
[<c01d8811>] kobject_add_varg+0x35/0x41
[<c01d883d>] kobject_init_and_add+0x20/0x22
[<c012ae70>] uids_user_create+0x36/0x5b
[<c012b028>] alloc_uid+0xf3/0x1b6
[<c01486c6>] copy_user_ns+0x59/0xaf
[<c0136833>] create_new_namespaces+0xe9/0x196
[<c013697e>] copy_namespaces+0x45/0x73
[<c0122152>] copy_process+0xba9/0x11e5
[<c012283d>] do_fork+0xaf/0x1e4
[<c0103428>] sys_clone+0x1f/0x21
[<c0104a2e>] syscall_call+0x7/0xb
[<c02d0000>] ? pci_fixup_msi_k8t_onboard_sound+0x68/0x98
=======================
virbr0: no IPv6 routers present
ps ax shows the following output right after the service is started:
3605 ? S 0:00 /usr/sbin/libvirtd --daemon
3624 ? Z 0:00 [libvirtd] <defunct>
If I don't enable any network at /etc/libvirt/qemu/networks/autostart, then
there's no error.
Any clues are appreciated, I'm unable to proceed with it.
Best Regards.
Emre
15 years, 11 months
[libvirt] [PATCH] 0/8 logging infrastructure for libvirt[d]
by Daniel Veillard
the following set of patches implement the logging infrastructure
based on the discussion about it last month. It is based on the
following interfaces, and in a large part reflects the log4j principles.
4 level of logging priorities:
typedef enum {
VIR_LOG_DEBUG = 1,
VIR_LOG_INFO,
VIR_LOG_WARN,
VIR_LOG_ERROR,
} virLogPriority;
An output is a channel to output logging informations and a filter is a
rule to allow or not log information to flow through.
At any given time a set of output and filters can be defined though
a public API (but I didn't put them yet in libvirt.h
that's still confined in logging.h ATM)
/**
* virLogOutputFunc:
* @data: extra output logging data
* @category: the category for the message
* @priority: the priority for the message
* @msg: the message to log, preformatted and zero terminated
* @len: the lenght of the message in bytes without the terminating zero
*
* Callback function used to output messages
*
* Returns the number of bytes written or -1 in case of error
*/
typedef int (*virLogOutputFunc) (void *data, const char *category,
int priority, const char *str, int len);
/**
* virLogCloseFunc:
* @data: extra output logging data
*
* Callback function used to close a log output
*/
typedef void (*virLogCloseFunc) (void *data);
extern int virLogSetDefaultPriority(int priority);
extern int virLogDefineFilter(const char *match, int priority, int
flags);
extern int virLogDefineOutput(virLogOutputFunc f, virLogCloseFunc c,
void *data, int priority, int flags);
The default priority allows to set a default level of logging,
individual logs matching filters will follow the rules defined for the
filters, i.e. if the logged data is of a lower level than what the
first filter matching it then it is dropped.
The internal APIs defines a function to log a message:
extern void virLogMessage(const char *category, int priority, int flags,
const char *fmt, ...);
the category is in general the file name as defined by __FILE__
The matching is done against the category based on a substring,
for example "xen" would match all logs emitted by
xend_internal.c xen_inotify.c xen_internal.c xen_unified.c
Something more complex could be defined for example matching based on
regexp or based on the full message content and not just the category
but this gets heavier and could be done later using specific flags
in virLogDefineFilter.
The preferred user interface for setting the output and filters
is through environment variables for application linking to libvirt
LIBVIRT_DEBUG defines the default logging level from 1 to 4
LIBVIRT_LOG_FILTERS defines the set filters
LIBVIRT_LOG_OUTPUTS defines the set outputs
and though the configuration file libvirtd.conf for the daemon with
the corresponding values:
log_level
log_filters
log_outputs
The convenience internal functions virLogParseFilters and
virLogParseOutputs parse the format of the values for filters and
outputs, so they share the same format explained in libvirtd.conf:
------------------------------------------------------------------
# Logging filters:
# A filter allows to select a different logging level for a given
category
# of logs
# The format for a filter is:
# x:name
# where name is a match string e.g. remote or qemu
# the x prefix is the minimal level where matching messages should be
logged
# 1: DEBUG
# 2: INFO
# 3: WARNING
# 4: ERROR
#
# Multiple filter can be defined in a single @filters, they just need
to be
# separated by spaces.
#
# e.g:
# log_filters="3:remote 4:event"
# to only get warning or errors from the remote layer and only errors
from
# the event layer.
# Logging outputs:
# An output is one of the places to save logging informations
# The format for an output can be:
# x:stderr
# output goes to stderr
# x:syslog:name
# use syslog for the output and use the given name as the ident
# x:file:file_path
# output to a file, with the given filepath
# In all case the x prefix is the minimal level, acting as a filter
# 0: everything
# 1: DEBUG
# 2: INFO
# 3: WARNING
# 4: ERROR
#
# Multiple output can be defined , they just need to be separated by
spaces.
# e.g.:
# log_outputs="3:syslog:libvirtd"
# to log all warnings and errors to syslog under the libvirtd ident
-----------------------------------------------------------------------
In practice
export LIBVIRT_DEBUG=1
export LIBVIRT_LOG_OUTPUTS="0:file:virsh.log"
and then running virsh will accumulate all logging to the virsh.log
file in the current directory.
One thing which I feel is somewhat incomplete is that it's impossible
to remotely get debugging output from the libvirt daemon serving the
requests. Currently all logs are also accumulated in a cyclic logging
buffer, I would associate a dump function later to be hooked for example
to a signal handler in the daemon. But I'm unsure we should allow
dumping logging information to the remote end, probably not the whole
set.
So there is still room for a bit more development, but I think it's
usable as-is and already cleans quite a bit of the various logging
interface scattered in the various modules.
Daniel
--
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/
15 years, 11 months