Re: [libvirt] openvz support in libvirt

2008-09-18 Thread Atsushi SAKAI
Hi, About libvirt functionality for openVZ. see the struct openvzDriver in libvirt/src/openvz_driver.c (around line 957) http://git.et.redhat.com/?p=libvirt.git;a=blob;f=src/openvz_driver.c Thanks Atsushi SAKAI "Anton Protopopov" <[EMAIL PROTECTED]> wrote: > Hello. > > To start with, I have th

[libvirt] [RFC] Events API

2008-09-18 Thread David Lively
Hi - We have some folks looking into the implementation of events (just VM state transition events, for now) in libvirtd. I've been assuming that events will be XML strings, something like: 22 nostate running where the contents of the element are determined by the even

[libvirt] openvz support in libvirt

2008-09-18 Thread Anton Protopopov
Hello. To start with, I have the following questions: Does libvirt support the xml format for openvz driver described in the next thread? http://www.redhat.com/archives/libvir-list/2008-July/msg00312.html (I think, that it does not. But will it support it in future? :)) What libvirt functionalit

Re: [libvirt] [PATCH] read network config in OpenVZ driver

2008-09-18 Thread Evgeniy Sokolov
On Wed, Sep 17, 2008 at 08:28:56PM +0400, Evgeniy Sokolov wrote: I attached patch without hunk which was commited by Daniel. Please commit if you are agree with it. A few comments inline.. So you're not artifically restricting the max length of the network name. It is limit in OpenV

RE: [libvirt] [PATCH] Don't remove devel files in spec

2008-09-18 Thread Ben Guthro
Hrm. My apologies for missing this piece. I thought I tested that prior to the second submission...but clearly I missed it. +1 for me. Ben -Original Message- From: [EMAIL PROTECTED] on behalf of Daniel P. Berrange Sent: Thu 9/18/2008 6:20 AM To: Cole Robinson Cc: libvir-list@redhat.com

Re: [libvirt] [PATCH] Don't remove devel files in spec

2008-09-18 Thread Daniel P. Berrange
On Wed, Sep 17, 2008 at 02:20:17PM -0400, Cole Robinson wrote: > The second iteration of the spec file enhancements > didn't fully remove some pieces that were dependent > on the devel package switch. The attached patch fixes > 'make rpm' to work again. I've just applied the very same fix myself.

Re: [libvirt] cpu flags

2008-09-18 Thread Daniel P. Berrange
On Wed, Sep 17, 2008 at 09:52:08AM -0400, Ben Guthro wrote: > > > > I think the most likely place for exposing CPU flags would be in the > > capabilities XML format. We do in fact already expose 3 flags there, > > PAE, VMX and SVM. > > This looks like all of the info that I need - I guess I ove

Re: [libvirt] cpu flags

2008-09-18 Thread Richard W.M. Jones
On Wed, Sep 17, 2008 at 09:52:08AM -0400, Ben Guthro wrote: > We should not have to re-write the scanning of /proc/cpuinfo in > every hypervisor driver, IMHO. Yes, sharing code like that is the way to go. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-

Re: [libvirt] [PATCH] Add documentation for C# "binding" and fix Windows documentation

2008-09-18 Thread Daniel P. Berrange
On Wed, Sep 17, 2008 at 04:23:22PM +0100, Richard W.M. Jones wrote: > > This patch changes the bindings page so that the language names are > emboldened and so that Java and C# are listed too. I've also listed > Windows on that page, not strictly because it is a language, but > because it's a pla

Re: [libvirt] Re: [PATCH alternative 1/2] virDomainGetID2

2008-09-18 Thread Daniel P. Berrange
On Wed, Sep 03, 2008 at 05:19:20PM +0100, Richard W.M. Jones wrote: > On Wed, Sep 03, 2008 at 05:18:16PM +0100, Richard W.M. Jones wrote: > > This adds virDomainGetID2 which uses a pointer to int parameter, > > allowing the -1 (non-running) domain ID to be returned safely. > > With the patch this

Re: [libvirt] [PATCH alternative 2/2] Change contract of virDomainGetID to make it safer

2008-09-18 Thread Daniel P. Berrange
On Wed, Sep 03, 2008 at 05:22:45PM +0100, Richard W.M. Jones wrote: > This changes the contract of the existing virDomainGetID call so that > it is guaranteed to return the ID provided that the @domain parameter > is not NULL or corrupted. Actually this isn't entirely an accurate description. Inac