Daniel P. Berrange wrote:
I noticed that when using the SSH tunnel for the remote driver I ended up
with alot of zombie SSH processes. We simply forgot to waitpid() on the
child when a connection attempt failed, or when shutting down an open remote
connection. Attached is a possible patch
This
On Tue, Sep 11, 2007 at 12:59:59AM +0100, Daniel P. Berrange wrote:
I noticed that when using the SSH tunnel for the remote driver I ended up
with alot of zombie SSH processes. We simply forgot to waitpid() on the
child when a connection attempt failed, or when shutting down an open remote
On Fri, Sep 07, 2007 at 09:55:45AM -0400, beth kon wrote:
Daniel Veillard wrote:
which would return an XML instance as in virConnectGetCapabilities. I
toyed with the idea of extending virConnectGetCapabilities() to add a
topology section in case of NUMA support at the hypervisor level, but
it
On Tue, Sep 11, 2007 at 03:08:46AM +0100, Daniel P. Berrange wrote:
On Mon, Sep 10, 2007 at 09:52:46PM -0400, beth kon wrote:
Daniel,
I'm taking a stab at this work and want to be sure I'm taking the right
approach. I'm new to xen and even newer to libvirt, so have a bit of a
Daniel Veillard wrote:
- the ssh process dies
- libvirt based application takes some time to notice it
- the OS span a new process with the same PID after a PID rollabck
Can not happen as long as libvirt hasn't asked for the exist status via
waitpid() because the pid is still in use
On Tue, Sep 11, 2007 at 11:35:46AM +0200, Gerd Hoffmann wrote:
Daniel Veillard wrote:
- the ssh process dies
- libvirt based application takes some time to notice it
- the OS span a new process with the same PID after a PID rollabck
Can not happen as long as libvirt hasn't asked
Daniel Veillard wrote:
On Tue, Sep 11, 2007 at 11:35:46AM +0200, Gerd Hoffmann wrote:
Daniel Veillard wrote:
- the ssh process dies
- libvirt based application takes some time to notice it
- the OS span a new process with the same PID after a PID rollabck
Can not happen as long as
Daniel Veillard wrote:
On Fri, Sep 07, 2007 at 09:55:45AM -0400, beth kon wrote:
Daniel Veillard wrote:
which would return an XML instance as in virConnectGetCapabilities. I
toyed with the idea of extending virConnectGetCapabilities() to add a
topology section in case of NUMA support
As promised, a patch to protect the 80-character device id buffer from
overflow by the unbounded device= XML attribute. Before, a large
device attribute gave a stack overflow error; now it merely results in
an obscure (but non-fatal) xend error like so:
libvir: Xen Daemon error : POST
Daniel Veillard wrote:
On Tue, Sep 11, 2007 at 11:35:46AM +0200, Gerd Hoffmann wrote:
Daniel Veillard wrote:
- the ssh process dies
- libvirt based application takes some time to notice it
- the OS span a new process with the same PID after a PID rollabck
Can not happen as long as
Richard W.M. Jones schrieb:
Thomas Antony wrote:
Mon, 10 Sep 2007 20:38:31 ERRORvirDomainCreateLinux() failed POST
operation failed: (xend.err Error creating domain: (12, 'Cannot
allocate memory'))
I think I've seen this one, and if so then it has been fixed but the
problem may not have
Okay enclosed is a first patch to add the new entry point for getting
the available memeory in the NUMA cells:
/**
* virNodeGetCellFreeMemory:
* @conn: pointer to the hypervisor connection
* @freeMems: pointer to the array of unsigned long
* @nbCells: number of entries available in freeMems
Thomas Antony wrote:
I tried virsh setmaxmem 0 512000 and then the system hung and i had to
Oh that's nasty. Were there any logs produced at the time the system
hung? Basically that's a bug in Xen anyway -- all that 'virsh
setmaxmem' does is to make a Xen hypercall to balloon down
Daniel Veillard wrote:
yes, and right remote is something I didn't tried to look at yet, I hope
returning arrays of values won't be a problem.
It's no problem at all ... otherwise all the CPU pinning stuff wouldn't
work (it does, I checked it all by hand).
Rich.
--
Emerging Technologies,
On Tue, Sep 11, 2007 at 06:51:29PM +0200, Thomas Antony wrote:
I'm running F7 on a Dell PE2950 with 8GB RAM.
It would be nice if you could explain how much RAM i should allocate
to Dom0 and what are the minimum requirements for Dom0.
I would expect that allocating 512 MB to Dom0 as you did
On Tue, Sep 11, 2007 at 05:49:08PM +0100, John Levon wrote:
I just saw an email about unsigned long and max memory fly by along with
a comment like 32-bit will never have more than 'X' Gb ...
This raises an obvious question: is libvirt explictly not 32/64 clean?
On Solaris we build
On Wed, Sep 12, 2007 at 03:40:49AM +0100, John Levon wrote:
On Wed, Sep 12, 2007 at 03:08:32AM +0100, Daniel P. Berrange wrote:
We definitely need to support 32-bit tools on 64-bit HV
Thanks. Mark Johnson pointed out that we get away with a 32-bit
virt-install right now simply because the
On Wed, Sep 12, 2007 at 03:50:23AM +0100, Daniel P. Berrange wrote:
Thanks. Mark Johnson pointed out that we get away with a 32-bit
virt-install right now simply because the hypercall libvirt backend
fails, and falls back to calling into xend. In general this works well,
but seems to have
The XML config for PXE boot is being parsed/formatted incorrectly by the
KVM tools. It is using 'net' instead of 'network' for the boot tag. I
had even made this mistake in the test suite :-) Patch is simple - also
fixed a flaw in the test suite code
Dan.
--
|=- Red Hat, Engineering, Emerging
19 matches
Mail list logo
