Jim Meyering j...@meyering.net wrote:
Jim Meyering j...@meyering.net wrote:
Daniel P. Berrange berra...@redhat.com wrote:
...
The QEMU driver runs as non-root too. This is what the qemu:///session
URI is used for. Likewise with the UML driver. The existing tests that
invoke libvirtd fail
On Mon, Feb 09, 2009 at 11:25:24AM +0100, Jim Meyering wrote:
I've rebased this and made some minor improvements,
like calling virReportOOMError and having a single exit point.
From 907671319b056495eef1d146dc9260a1a2fcb64c Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Daniel P. Berrange berra...@redhat.com wrote:
[snip]
+if (snprintf(server-logDir, PATH_MAX, %s/.libvirt/log,
+ dir_prefix) = PATH_MAX)
+goto snprintf_error;
If I'm reading correctly, this will cause system logs to get put in
the directory /var/.libvirt/log
On Sun, Feb 08, 2009 at 10:34:06PM +0100, Remko Nolten wrote:
Hi!
For a shared virtual hosting project with some friends we need a pretty
specialized network configuration. Because we have virtually no time for
experimenting (no pun intended), and the hosting organization has no
Below is what /proc/cpuinfo looks like on an Ultrasparc T1 running
Linux.
I haven't looked into it in detail yet, but the report from Dennis
Gilmore is that this breaks every libvirt command. Presumably we are
parsing /proc/cpuinfo at libvirt startup ...
(Initially reported by Dennis Gilmore)
On Mon, Feb 09, 2009 at 01:37:14PM +, Richard W.M. Jones wrote:
Below is what /proc/cpuinfo looks like on an Ultrasparc T1 running
Linux.
I haven't looked into it in detail yet, but the report from Dennis
Gilmore is that this breaks every libvirt command. Presumably we are
parsing
Jim Meyering j...@meyering.net wrote:
Daniel P. Berrange berra...@redhat.com wrote:
[snip]
+if (snprintf(server-logDir, PATH_MAX, %s/.libvirt/log,
+ dir_prefix) = PATH_MAX)
+goto snprintf_error;
If I'm reading correctly, this will cause system logs to get put
On Mon, Feb 09, 2009 at 01:48:58PM +, Daniel P. Berrange wrote:
On Mon, Feb 09, 2009 at 01:37:14PM +, Richard W.M. Jones wrote:
Below is what /proc/cpuinfo looks like on an Ultrasparc T1 running
Linux.
I haven't looked into it in detail yet, but the report from Dennis
Gilmore
OK so the report is that NOT all commands fail. 'virsh nodeinfo'
fails with:
libvir: error : no cpus found
Other commands work, eg. 'virsh list --all' is fine.
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny
On Mon, Feb 09, 2009 at 02:01:19PM +0100, Jim Meyering wrote:
However, first things first:
Here's a patch that adds two blocks, neither pretty,
but with less duplication than the 3rd alternative,
which duplicates both the snprintf and the result comparison.
(of course, I'll use only one of
Daniel P. Berrange berra...@redhat.com wrote:
On Mon, Feb 09, 2009 at 02:01:19PM +0100, Jim Meyering wrote:
However, first things first:
Here's a patch that adds two blocks, neither pretty,
but with less duplication than the 3rd alternative,
which duplicates both the snprintf and the result
On Mon, Feb 09, 2009 at 03:39:15PM +0100, Jim Meyering wrote:
Daniel P. Berrange berra...@redhat.com wrote:
On Mon, Feb 09, 2009 at 02:01:19PM +0100, Jim Meyering wrote:
However, first things first:
Here's a patch that adds two blocks, neither pretty,
but with less duplication than
Daniel P. Berrange berra...@redhat.com wrote:
On Mon, Feb 09, 2009 at 03:39:15PM +0100, Jim Meyering wrote:
Daniel P. Berrange berra...@redhat.com wrote:
On Mon, Feb 09, 2009 at 02:01:19PM +0100, Jim Meyering wrote:
However, first things first:
Here's a patch that adds two blocks,
Here's another error, starting the default network:
dgilmore libvir: error : internal error '/usr/sbin/brctl setfd virbr0 0'
exited with non-zero status 1 and signal 0: set forward delay failed: Operation
not supported
dgilmore Failed to autostart network 'default': internal error
I'm applying these fixes to avoid make check failures:
From f41517a4250db0961482e097813eb39da5bea963 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Mon, 9 Feb 2009 16:25:36 +0100
Subject: [PATCH] avoid two test failures induced by today's error-reporting
changes
*
I wanted to bring this topic out of a patch review thread.
Dan recently stated that only patches that use upstream facilities are
acceptable, meaning the xend delivered by XenSource. I'd like to make a
few points on this note:
1. I'd like to hear from the other core maintainers if they agree
On Mon, Feb 09, 2009 at 04:29:56PM +0100, Jim Meyering wrote:
I'm applying these fixes to avoid make check failures:
I normally do a full install, syntax-check, and check. I must have
missed the latter this time round - sorry.
thanks
john
--
Libvir-list mailing list
Libvir-list@redhat.com
On Mon, Feb 09, 2009 at 04:54:51PM +, Daniel P. Berrange wrote:
2. I'd like to hear a rationale for this rule.
The number one rule is not to fork codebases in incompatible ways.
Agreed. Thankfully, we haven't done that.
Adding new features to a particular version of Xen and not making
I'm working on an existing system that creates, manages, and destroys
Xen guests on a pool of host systems, and I use LVM copy-on-write
snapshots to keep creation rapid.
http://libvirt.org/storage.html describes logical volume pools, for
which you simply supply the name of a volume group and it
19 matches
Mail list logo
