- Devel - libvirt List Archives

[libvirt] [PATCH] drop the -logrotate.conf from /etc/logrotate.d/ovirt-logrotate.conf
by Dan Kenigsberg 01 Nov '09

01 Nov '09

No Fedora package uses .conf in that directory; furthermore, rpmlint protests about it: the file name should match the name of the containing rpm. Let us conform. --- logrotate/ovirt-logrotate | 2 +- ovirt-node.spec.in | 4 ++-- scripts/ovirt-config-logging | 2 +- scripts/ovirt-functions | 2 +- 4 files changed, 5 insertions(+), 5 deletions(-) diff --git a/logrotate/ovirt-logrotate b/logrotate/ovirt-logrotate index a61af6f..ad32951 100644 --- a/logrotate/ovirt-logrotate +++ b/logrotate/ovirt-logrotate @@ -1,3 +1,3 @@ # Run each log rotation every 10 minutes -*/10 * * * * root /usr/sbin/logrotate /etc/logrotate.d/ovirt-logrotate.conf +*/10 * * * * root /usr/sbin/logrotate /etc/logrotate.d/ovirt-node-stateless */10 * * * * root /usr/sbin/logrotate /etc/logrotate.d/syslog diff --git a/ovirt-node.spec.in b/ovirt-node.spec.in index 3a8266e..20fea25 100644 --- a/ovirt-node.spec.in +++ b/ovirt-node.spec.in @@ -180,7 +180,7 @@ cd - %{__install} -p -m0755 kinit/ovirt-kinit %{buildroot}%{_sysconfdir}/cron.hourly %{__install} -p -m0644 logrotate/ovirt-logrotate %{buildroot}%{_sysconfdir}/cron.d -%{__install} -p -m0644 logrotate/ovirt-logrotate.conf %{buildroot}%{_sysconfdir}/logrotate.d +%{__install} -p -m0644 logrotate/ovirt-logrotate.conf %{buildroot}%{_sysconfdir}/logrotate.d/ovirt-node-stateless echo "oVirt Node release %{version}-%{release}" > %{buildroot}%{_sysconfdir}/ovirt-release mkdir -p %{buildroot}/%{_sysconfdir}/default @@ -310,7 +310,7 @@ fi %{_initrddir}/ovirt %{_initrddir}/ovirt-post %config %{_sysconfdir}/cron.hourly/ovirt-kinit -%config %{_sysconfdir}/logrotate.d/ovirt-logrotate.conf +%config %{_sysconfdir}/logrotate.d/ovirt-node-stateless %config %{_sysconfdir}/cron.d/ovirt-logrotate %{_sysconfdir}/ovirt-config-boot.d %{_sysconfdir}/ovirt-config-setup.d diff --git a/scripts/ovirt-config-logging b/scripts/ovirt-config-logging index 464dfcb..de238b7 100755 --- a/scripts/ovirt-config-logging +++ b/scripts/ovirt-config-logging @@ -158,7 +158,7 @@ function prompt_user { $syslog_server_protocol fi sed -c -i -e "s/^size=.*/size=${max_log_size}k/" \ - /etc/logrotate.d/ovirt-logrotate.conf + /etc/logrotate.d/ovirt-node-stateless return ;; 1) diff --git a/scripts/ovirt-functions b/scripts/ovirt-functions index 98e88e7..7e84415 100644 --- a/scripts/ovirt-functions +++ b/scripts/ovirt-functions @@ -28,7 +28,7 @@ OVIRT_CONFIG_FILES="\ /etc/default/ovirt \ /etc/sysconfig/network \ /etc/collectd.conf \ - /etc/logrotate.d/ovirt-logrotate.conf + /etc/logrotate.d/ovirt-node-stateless " # Save stdout to fd 6 and stderr to fd 7. Redirect normal stdout/stderr -- 1.6.2.5

2 2

Re: [libvirt] [PATCH 10/21] Don't let parent of daemon exit until basic initialization is done
by Laurent Léonard 01 Nov '09

01 Nov '09

Hi, I'm not a C expert, but I see there is a use of an unitialized variable: default: { int got, exitstatus = 0; int ret; char status; close(statuspipe[1]); /* We wait to make sure the first child forked successfully */ if ((got = waitpid(pid, &exitstatus, 0)) < 0 || got != pid || status != 0) { <<< here return -1; } That explains the issue described by Guido, because he uses an i386 system. It was impossible for me to reproduce the issue because I use an amd64 system. char test; if (test == 0) puts("ok"); else puts("ko"); produces: - "ok" on amd64 system - "ko" on i386 system If I use the exitstatus variable in the test it seems to work great on both architectures. -- Laurent Léonard

2 1

[libvirt] [PATCH] network utilities
by Daniel Veillard 30 Oct '09

30 Oct '09

Revamping my previous patches to parse IPv4/6 numeric addresses, adding range computation and netmask checking entries too. As suggested I used an union for the socket address type: typedef union { struct sockaddr_storage stor; struct sockaddr_in inet4; struct sockaddr_in6 inet6; } virSocketAddr; typedef virSocketAddr *virSocketAddrPtr; But I wonder if it's not better to make it a struct and add the lenght of the address as this is usually needed when passing one of the struct sockaddr_* and that lenght is returned as part of parsing, keeping both together is probably more useful. A macro to get the type AF_INET/AF_INET6 out of a virSocketAddr might be useful instead of having the users manually guess that ->stor.ss_family is teh filed to look at. Also I wonder how useful the Ipv6 code for netmask and ranges really is, it seems that IPv6 mostly go with prefix and never use netmasks, maybe that's just dead code, maybe that's just wrong, anyway here it is. I named the header and file network.[ch] as I think other network related utilities like validation or generation of MAC addresses could well be moved in that file too. 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/

3 8

[libvirt] [PATCH] Fix up a bogus TLS message.
by Chris Lalancette 30 Oct '09

30 Oct '09

When working with the TLS transport, I noticed that every single time a remote stream was closed, I would get a message like: 09:09:40.793: error : remoteIOReadBuffer:7328 : failed to read from TLS socket A TLS packet with unexpected length was received. libvir: QEMU error : failed to read from TLS socket A TLS packet with unexpected length was received. in the logs. This happens because of a race in libvirtd; one thread handles the doRemoteClose(), which calls gnutls_bye() followed by close() while another thread is poll()'ing on the same fd. Once the close() happens, the poll returns with revents set to POLLIN, and we would poll one more time for data from the now-closed fd. Fix this situation by setting poll->session to NULL when we clean up, and check for that in remoteIOHandleInput(). Signed-off-by: Chris Lalancette <clalance(a)redhat.com> --- src/remote/remote_driver.c | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/src/remote/remote_driver.c b/src/remote/remote_driver.c index bf001eb..335f44b 100644 --- a/src/remote/remote_driver.c +++ b/src/remote/remote_driver.c @@ -1389,6 +1389,7 @@ doRemoteClose (virConnectPtr conn, struct private_data *priv) if (priv->uses_tls && priv->session) { gnutls_bye (priv->session, GNUTLS_SHUT_RDWR); gnutls_deinit (priv->session); + priv->session = NULL; } #if HAVE_SASL if (priv->saslconn) @@ -7223,6 +7224,12 @@ remoteIOReadBuffer(virConnectPtr conn, int ret; if (priv->uses_tls) { + if (!priv->session) { + /* we may have reached here one more time after gnutls_bye() + * was called, so just return here + */ + return 0; + } tls_resend: ret = gnutls_record_recv (priv->session, bytes, len); if (ret == GNUTLS_E_INTERRUPTED) -- 1.6.0.6

3 3

[libvirt] Restore after restart libvirtd
by Diego Woitasen 30 Oct '09

30 Oct '09

Hi, I 'm playing with save/restore domains. It's working, but if I restart libvirtd after 'save domain file' and then try to restore it I get: error: Failed to restore domain from /tmp/domain.out error: operation failed: domain 'domainname' is already defined with uuid 17c77406-b6e3-621a-1fae-420affce8f48 If I move domainname.xml out of libvirt config. directory it works, but I think this should not be necessary. Regards, Diego -- Diego Woitasen

2 3

[libvirt] 0.7.1 compile fails on opensuse 11.1
by Dominik Klein 30 Oct '09

30 Oct '09

Hi it seems openSuSE 11.1 does not come with a pkgconfig for the device-mapper-devel package. I created a bug [1] for opensuse but was also told to mention it here so configure.in could be patched once the bug was fixed. Regards Dominik 1 https://bugzilla.novell.com/show_bug.cgi?id=54094

4 9

[libvirt] [PATCH] Priority of vzctl create should be lower
by Yuji NISHIDA 30 Oct '09

30 Oct '09

Hi all About OpenVZ, it uses vzctl command that produces tar/gzip commands. I think we should lower these commands for running other procedures prior to them. This is the patch to achieve it with nice/ionice commands. From ff3cf022995ef541136bd40579af2eeb20aeafdb Mon Sep 17 00:00:00 2001 From: root <root(a)node13.nvlab.org> Date: Mon, 26 Oct 2009 02:44:43 +0000 Subject: [PATCH] lower priority for running tar and gzip during vzctl create --- src/openvz/openvz_driver.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/src/openvz/openvz_driver.c b/src/openvz/openvz_driver.c index f64ad1e..59d38ae 100644 --- a/src/openvz/openvz_driver.c +++ b/src/openvz/openvz_driver.c @@ -130,6 +130,14 @@ openvzDomainDefineCmd(virConnectPtr conn, } while (0) narg = 0; + + /* lower priority for running tar and gzip */ + ADD_ARG_LIT("nice"); + ADD_ARG_LIT("-n"); + ADD_ARG_LIT("19"); + ADD_ARG_LIT("ionice"); + ADD_ARG_LIT("-c3"); + ADD_ARG_LIT(VZCTL); ADD_ARG_LIT("--quiet"); ADD_ARG_LIT("create"); -- 1.5.3.4 ----- Yuji Nishida nishidy(a)nict.go.jp

3 3

[libvirt] QEMU driver thread safety rules
by Daniel P. Berrange 30 Oct '09

30 Oct '09

The current QEMU driver makes use of 2 locks - The driver lock - The virDomainObjPtr lock The idea is the driver lock is not held for long periods of time. Unfortunately we don't always deal with this very well - some code needs todo quite alot with the driver - particularly starting and stopping of guests. The bigger problem is that the virDomainObjPtr lock is often held for long periods, specifically whenever we invoke a monitor command. Some of these commands can take a very long time (even infinite if someone has send SIGSTOP to QEMU). This very quickly blocks the whole driver. I've realized that even with the series of monitor patches I sent out, changing the driver mutex to a RWLock, and adding a separate lock on the qemuMonitorPtr object iself, there's still a major concurrency problem: the virDomainObjPtr lock is held for too long. I propose to drop the RWLock patch, and do something totally different instead.... We fundamentally need to drop the virDomainObjPtr lock whenever we invoke a monitor command. Unfortunately, merely dropping the virDomainObjPtr and acquiring the qemuMonitorPtr is not safe. An API call which changes the VM state typically has 3 phases 1. Check what state/config the VM is in 2. Invoke the monitor command 3. Update the state/config of the VM If we release the virDomainObjPtr, and acquire qemuMonitorPtr at step 2, then other APIs calls will be able to complete their own step 1 checks, and get blocked at step 2. This is not safe, because when the original call moves onto step 3 and changes the state, this will have invalidated the checks the other sleeping API calls made in step 1. We need to prevent any API call starting step 1, for as long as there is a monitor command being run, even if the lock on virDomainObjPtr is not held. The only way I see todo this, is to introduce a condition variable indicating that a state change is to be made. Any API call which intends to make a state change must acquire this condition prior to step 1. They can thus safely do their checks, and move onto step 2, releasing the virDomainObj lock whle the monitor command is running, and reacquiring it after. All other API calls making changes get safely queued up at step 1, but API calls which simply wish to query information can run without being blocked at all. This fixes the major concurrency problem with running monitor commands. The use of a condition variable at the start of step 1, also allows us to time out API calls, if some other thread get stuck in the monitor for too long. I think this also makes the use of a RWLock on the QEMU driver unneccessary, since no code will ever be holding a mutex in any place that sleeps/wait. Only the condition variable will be held during sleeps/waits. Since we'll now effectively have 3 locks, and 1 condition variable this is getting kind of complex. So the rest of this mail is a file I propose to put in src/qemu/THREADS.txt describing what is going on, and showing the recommended design patterns to use. Daniel QEMU Driver Threading: The Rules ================================= This document describes how thread safety is ensured throughout the QEMU driver. The criteria for this model are: - Objects must never be exclusively locked for any pro-longed time - Code which sleeps must be able to time out after suitable period - Must be safe against dispatch asynchronous events from monitor Basic locking primitives ------------------------ There are a number of locks on various objects * struct qemud_driver: RWLock This is the top level lock on the entire driver. Every API call in the QEMU driver is blocked while this is held, though some internal callbacks may still run asynchronously. This lock must never be held for anything which sleeps/waits (ie monitor commands) When obtaining the driver lock, under *NO* circumstances must any lock be held on a virDomainObjPtr. This *WILL* result in deadlock. * virDomainObjPtr: Mutex Will be locked after calling any of the virDomainFindBy{ID,Name,UUID} methods. Lock must be held when changing/reading any variable in the virDomainObjPtr Once the lock is held, you must *NOT* try to lock the driver. You must release all virDomainObjPtr locks before locking the driver, or deadlock *WILL* occurr. If the lock needs to be dropped & then re-acquired for a short period of time, the reference count must be incremented first using virDomainObjRef(). If the reference count is incremented in this way, it is not neccessary to have the driver locked when re-acquiring the dropped locked, since the reference count prevents it being freed by another thread. This lock must not be held for anything which sleeps/waits (ie monitor commands). * qemuMonitorPrivatePtr: Job condition Since virDomainObjPtr lock must not be held during sleeps, the job condition provides additional protection for code making updates. Immediately after acquiring the virDomainObjPtr lock, any method which intends to update state, must acquire the job condition. The virDomainObjPtr lock is released while blocking on this condition variable. Once the job condition is acquired a method can safely release the virDomainObjPtr lock whenever it hits a piece of code which may sleep/wait, and re-acquire it after the sleep/ wait. * qemuMonitorPtr: Mutex Lock to be used when invoking any monitor command to ensure safety wrt any asynchronous events that may be dispatched from the monitor. It should be acquired before running a command. The job condition *MUST* be held before acquiring the monitor lock The virDomainObjPtr lock *MUST* be held before acquiring the monitor lock. The virDomainObjPtr lock *MUST* then be released when invoking the monitor command. The driver lock *MUST* be released when invoking the monitor commands. This ensures that the virDomainObjPtr & driver are both unlocked while sleeping/waiting for the monitor response. Helper methods -------------- To lock the driver qemuDriverLock() - Acquires the driver lock qemuDriverUnlock() - Releases the driver lock To lock the virDomainObjPtr virDomainObjLock() - Acquires the virDomainObjPtr lock virDomainObjUnlock() - Releases the virDomainObjPtr lock To acquire the job condition variable (int jobActive) qemuDomainObjBeginJob() (if driver is unlocked) - Increments ref count on virDomainObjPtr - Wait qemuDomainObjPrivate condition 'jobActive != 0' using virDomainObjPtr mutex - Sets jobActive to 1 qemuDomainObjBeginJobWithDriver() (if driver needs to be locked) - Unlocks driver - Increments ref count on virDomainObjPtr - Wait qemuDomainObjPrivate condition 'jobActive != 0' using virDomainObjPtr mutex - Sets jobActive to 1 - Unlocks virDomainObjPtr - Locks driver - Locks virDomainObjPtr NB: this variant is required in order to comply with lock ordering rules for virDomainObjPtr vs driver qemuDomainObjEndJob() - Set jobActive to 0 - Signal on qemuDomainObjPrivate condition - Decrements ref count on virDomainObjPtr To acquire the QEMU monitor lock qemuDomainObjEnterMonitor() - Acquires the qemuMonitorObjPtr lock - Releases the virDomainObjPtr lock qemuDomainObjExitMonitor() - Acquires the virDomainObjPtr lock - Releases the qemuMonitorObjPtr lock NB: caller must take care to drop the driver lock if neccessary Design patterns --------------- All driver methods must follow one of these design patterns to ensure thread safety and lock correctness. * Accessing or updating something with just the driver qemuDriverLock(driver); ...do work... qemuDriverUnlock(driver); * Accessing something directly todo with a virDomainObjPtr virDomainObjPtr obj; qemuDriverLock(driver); obj = virDomainFindByUUID(driver->domains, dom->uuid); qemuDriverUnlock(driver); ...do work... virDomainObjUnlock(obj); * Accessing something directly todo with a virDomainObjPtr and driver virDomainObjPtr obj; qemuDriverLock(driver); obj = virDomainFindByUUID(driver->domains, dom->uuid); ...do work... virDomainObjUnlock(obj); qemuDriverUnlock(driver); * Updating something directly todo with a virDomainObjPtr virDomainObjPtr obj; qemuDriverLock(driver); obj = virDomainFindByUUID(driver->domains, dom->uuid); qemuDriverUnlock(driver); qemuDomainObjBeginJob(obj); ...do work... qemuDomainObjEndJob(obj); virDomainObjUnlock(obj); * Invoking a monitor command on a virDomainObjPtr virDomainObjPtr obj; qemuDomainObjPrivatePtr priv; qemuDriverLockRO(driver); obj = virDomainFindByUUID(driver->domains, dom->uuid); qemuDriverUnlock(driver); qemuDomainObjBeginJob(obj); ...do prep work... qemuDomainObjEnterMonitor(obj); qemuMonitorXXXX(priv->mon); qemuDomainObjExitMonitor(obj); ...do final work... qemuDomainObjEndJob(obj); virDomainObjUnlock(obj); * Invoking a monitor command on a virDomainObjPtr with driver locked too virDomainObjPtr obj; qemuDomainObjPrivatePtr priv; qemuDriverLock(driver); obj = virDomainFindByUUID(driver->domains, dom->uuid); qemuDomainObjBeginJobWithDriver(obj); ...do prep work... qemuDomainObjEnterMonitor(obj); qemuDriverUnlock(driver); qemuMonitorXXXX(priv->mon); qemuDriverLock(driver); qemuDomainObjExitMonitor(obj); ...do final work... qemuDomainObjEndJob(obj); virDomainObjUnlock(obj); qemuDriverUnlock(driver); Summary ------- * Respect lock ordering rules: never lock driver if anything else is already locked * Don't hold locks in code which sleeps: unlock driver & virDomainObjPtr when using monitor -- |: 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 :|

2 4

[libvirt] remote clients are non-interruptible
by John Levon 30 Oct '09

30 Oct '09

remoteIOEventLoop() has this: 6974 repoll: 6975 ret = poll(fds, ARRAY_CARDINALITY(fds), -1); 6976 if (ret < 0 && errno == EINTR) 6977 goto repoll; with the result that all clients using the remote driver cannot be control-C'd. Dan, you added this code it seems, why? regards john

4 3

[libvirt] Re: [virt-tools-list] Remote management over SSH fails to connect
by Cole Robinson 30 Oct '09

30 Oct '09

On 10/25/2009 10:25 AM, Jon Nordby wrote: > I get the following errors (skipping "system" yields the same): > [root@jon-laptop ~]# virsh -c qemu+ssh://10.0.0.2/system list > error: server closed connection > error: failed to connect to the hypervisor > > However, SSH and libvirtd both work on their own: > [root@jon-laptop ~]# ssh 10.0.0.2 > Last login: Sun Oct 25 14:06:07 2009 from 10.0.0.143 > [root@server0 ~]# virsh list > Id Name State > ---------------------------------- > 21 family-server running > > The connection is allowed in hosts.allow > libvirt 0.7.2 in both ends, kvm backend, Arch Linux > > What could be the source of this problem? And how can I find it? > ccing libvirt-list This could be an issue of 'nc' incompatibility. Does the 'nc' command on the remote system support the -U option? If you run the virsh command with LIBVIRT_DEBUG=1 virsh ... you should see the ssh command being run. See if running the command by hand produces an error. - Cole

3 2