headers
Atsushi SAKAI | 1 Mar 2007 01:40
Favicon

Re: Request for libvirt/ChangeLog

Hi, Dan

Thank you for showing your policy.
I am consider local counting rule based on your policy.

Anyway I usually see it with "cvs log libvirt/ChangeLog" 
not bare "vi libvirt/ChangeLog".
It shows commiters name.:-)

Thanks
Atsushi SAKAI

"Daniel P. Berrange" <berrange <at> redhat.com> wrote:

> On Wed, Feb 28, 2007 at 07:41:00PM +0900, Atsushi SAKAI wrote:
> > Hi, Karel
> > 
> >  Thank you for your suggestion.
> > 
> > I need to count our company contribution based on # of patches 
> > to report our managers.
> > This patch counting method is available 
> > for virtinst/virtmanager/Xen but not for libvirt.
> 
> Look at the ChangeLog file - although I've not always included the
> person's email address, their name should be mentioned against
> each change. Each contributor's full name & email addresses are also
> in AUTHORS
> 
> Regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Masayuki Sunou | 1 Mar 2007 02:02

[PATCH] check the maximum of virtual CPU

Hi

The maximum of virtual CPU is not guarded in virsh setvcpus now.
Then, when 32767 was set to virtual CPU of virsh setvcpus, the problem
that Xend became abnormal was detected.

example:
----------------------------------------------------------------------
  # virsh setvcpus 0 32767
  libvir: Xen Daemon error : POST operation failed: (xend.err "(9, 'Bad file descriptor')")
  libvir: Xen error : failed Xen syscall  ioctl  3166208
  libvir: error : library call virDomainSetVcpus failed, possibly not supported

  # xm list -l
  Error: (9, 'Bad file descriptor')
  Usage: xm list [options] [Domain, ...]

  List information about all/some domains.
    -l, --long                     Output all VM details in SXP
    --label                        Include security labels
    --state=<state>                Select only VMs with the specified state
----------------------------------------------------------------------

Therefore, I propose the correction that adjusts the maximum of virtual
CPU to the same value as Xen. 

This patch is over 200lines.
If you request, I am ready to repost it with split this patch.

Signed-off-by: Masayuki Sunou <fj1826dm <at> aa.jp.fujitsu.com>
(Continue reading)

Permalink | Reply | 14 comments |
headers
Richard W.M. Jones | 1 Mar 2007 09:19
Picon
Favicon
Gravatar

Re: [PATCH] check the maximum of virtual CPU

Masayuki Sunou wrote:
> Hi
> 
> The maximum of virtual CPU is not guarded in virsh setvcpus now.
> Then, when 32767 was set to virtual CPU of virsh setvcpus, the problem
> that Xend became abnormal was detected.
> 
> example:
> ----------------------------------------------------------------------
>   # virsh setvcpus 0 32767
>   libvir: Xen Daemon error : POST operation failed: (xend.err "(9, 'Bad file descriptor')")
>   libvir: Xen error : failed Xen syscall  ioctl  3166208
>   libvir: error : library call virDomainSetVcpus failed, possibly not supported
>   
>   # xm list -l
>   Error: (9, 'Bad file descriptor')
>   Usage: xm list [options] [Domain, ...]
>   
>   List information about all/some domains.
>     -l, --long                     Output all VM details in SXP
>     --label                        Include security labels
>     --state=<state>                Select only VMs with the specified state
> ----------------------------------------------------------------------
> 
> 
> Therefore, I propose the correction that adjusts the maximum of virtual
> CPU to the same value as Xen. 
> 
> 
> This patch is over 200lines.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tatsuro Enokura | 1 Mar 2007 10:11

Re: [PATCH] patch for virsh domname <uuid> command error

Hi, Dan

Daniel P. Berrange wrote:
 >> and shut-off domain's information is got from xend.
 >> I make a patch for xend_internal.c
 >>
 >> The attached patch resolve this issue in the following way:
 >>
 >>   1) If the domain's name can't be pulled out from
 >>      the running domains list by uuid, request xend by
 >>      "/xend/domains/≤uuid>".
 >>   2) If the domain's data can be teken from xend, pull out
 >>      the domain's name.
 >
 > It looks like a reasonable patch - I'll do a little testing and if
 > it works on Fedora 7 I'll add it to CVS.

Could you tell me the test result on this patch?
If the test is fine, please commit it.

Thanks,
Tatusro Enokura.
Permalink | Reply | 2 comments |
headers
Mark McLoughlin | 1 Mar 2007 10:25
Picon
Favicon

Re: [PATCH] export virConf* symbols (second version)

Hi Rich,

On Wed, 2007-02-28 at 17:33 +0000, Richard W.M. Jones wrote:

> +#define virConfNew() (_virConfNew())

	I wouldn't bother doing this, it just adds confusion - e.g. it helps to
know that the symbol is private from the calling site too, so just use
_virConfNew() everywhere ...

	Also suggest surrounding everything with:

#ifdef LIBVIRT_PRIVATE_API_DO_NOT_USE

	in src/conf.h (even though it's not installed) so that people have no
excuse if they use this ...

Cheers,
Mark.
Permalink | Reply | 2 comments |
headers
Mark McLoughlin | 1 Mar 2007 10:38
Picon
Favicon

Re: Patch: driver->open functions return declined or error status

On Wed, 2007-02-28 at 16:18 +0000, Richard W.M. Jones wrote:
> +             case VIR_DRV_OPEN_ERROR: goto failed;
> +             case VIR_DRV_OPEN_DECLINED:
> +               /*
> +                * For a default connect to Xen make sure we manage to contact
> +                * all related drivers.
> +                */
> +               if (for_xen &&
> +                   strncasecmp(virDriverTab[i]->name, "xen", 3) == 0 &&
> +                   virDriverTab[i]->no != VIR_DRV_XEN_PROXY)
> +                 goto failed;
> +               break; 

	Are there no current cases where we should return VIR_DRV_OPEN_ERROR?

	Also, can we change the existing open methods to use DECLINED? I was
confused for a minute because I presumed ERROR was -1 ...

Cheers,
Mark.
Permalink | Reply | 1 comment |
headers
Mark McLoughlin | 1 Mar 2007 10:46
Picon
Favicon

Re: Patch: Fix documentation and code of virGetDomain function

On Wed, 2007-02-28 at 16:24 +0000, Richard W.M. Jones wrote:
>  virGetDomain(virConnectPtr conn, const char *name, const unsigned char *uuid) {
>      virDomainPtr ret = NULL;
>  
> -    if ((!VIR_IS_CONNECT(conn)) || ((name == NULL) && (uuid == NULL)) ||
> +    if ((!VIR_IS_CONNECT(conn)) || (name == NULL) || (uuid == NULL) || 

	Need the same fix in virGetNetwork()

	(And DV obviously has a parenthesis fetish ... I don't know what's
wrong with:

    if (!VIR_IS_CONNECT(conn) || !name || !uuid || !conn->hashes->mux)

	:-)

Cheers,
Mark.
Permalink | Reply | 4 comments |
headers
Mark McLoughlin | 1 Mar 2007 10:52
Picon
Favicon

Re: Patch: Driver private data

On Wed, 2007-02-28 at 17:06 +0000, Daniel P. Berrange wrote:
> On Wed, Feb 28, 2007 at 04:27:05PM +0000, Richard W.M. Jones wrote:
> > This patch is more aspirational than currently useful.  Only the remote 
> > patch would use driver->private, but I think others should be changed to 
> > do so too.
> 
> Certainly - I'll update the QEMU & Test drivers at least once we've got 
> this in. The Xen driver can be best addressed when they are merged.

	Cool, be careful with the QEMU driver, though.

	i.e. you can have a situation where one driver is used for domains, and
the QEMU driver is used for networks. Or, indeed, the QEMU driver might
be used for both.

	We probably want a networkPrivate pointer which will also contain the
qemuPrivate data and the driver will always prefer networkPrivate if it
is non-NULL. Something like that.

Cheers,
Mark.
Permalink | Reply | 0 comments |
headers
Masayuki Sunou | 1 Mar 2007 11:02

Re: [PATCH] check the maximum of virtual CPU

Hi, Rich

> The patch looks pretty sensible to me.  Needs the same check added to 
> virt-manager too?
> 
Virt-manager seems to check maximums of the number of CPU. 

However, virt-manager checks the number of CPU by fixed value (32). 
Therefore, I think that the check of architecture is needed in the future. 

Thanks,
Masayuki Sunou.

In message <45E68CA1.3030406 <at> redhat.com>
   "Re: [Libvir] [PATCH] check the maximum of virtual CPU"
   ""Richard W.M. Jones" <rjones <at> redhat.com>" wrote:

> Masayuki Sunou wrote:
> > Hi
> > 
> > The maximum of virtual CPU is not guarded in virsh setvcpus now.
> > Then, when 32767 was set to virtual CPU of virsh setvcpus, the problem
> > that Xend became abnormal was detected.
> > 
> > example:
> > ----------------------------------------------------------------------
> >   # virsh setvcpus 0 32767
> >   libvir: Xen Daemon error : POST operation failed: (xend.err "(9, 'Bad file descriptor')")
> >   libvir: Xen error : failed Xen syscall  ioctl  3166208
> >   libvir: error : library call virDomainSetVcpus failed, possibly not supported
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark McLoughlin | 1 Mar 2007 11:22
Picon
Favicon

Re: ABI compatibility question: static strings returned from some functions

On Tue, 2007-02-20 at 23:32 -0500, Daniel Veillard wrote:
> On Mon, Feb 19, 2007 at 02:46:43PM +0000, Mark McLoughlin wrote:
> > >   Unfortunately I don't see a good thing to do in 
> > > this case except to change the semantics of virConnectGetType, which 
> > > arguably breaks ABI compatibility.
> > > 
> > > Suggestions from anyone?
> > 
> > 	Okay, suggest:
> > 
> >   1) Add a new function with a different name which returns an 
> >      allocated string. Mark the old function as deprecated.
> > 
> >   2) Retain the old function, and have a list of likely static strings 
> >      which you can return if it matches the string you got from the 
> >      remote side, and if not return (and leak) an allocated string
> 
>   I would go from 2) but keep an array of existing returned entries, so
> we only keep one list of the set of OS type handled. That list will be finite
> and relatively short, that should not be a problem.

	I was suggesting both 1) and 2), btw.

Cheers,
Mark.
Permalink | Reply | 0 comments |

Gmane