Can't connect to lxc driver

Hi Dan,

I updated today to the latest CVS and can no longer connect to the lxc driver.
I've tracked it down to this check in doRemoteOpen() in remote_internal.c:

    if ((
#ifdef HAVE_XMLURI_QUERY_RAW
         uri->query_raw =
#else
         uri->query =
#endif
         qparam_get_query (vars)) == NULL) goto failed;

Looking at the recent VirBuffer changes, it looks like they changed the behavior
of qparam_get_query.  With the old VirBuffer, qparam_get_query returned a
non-NULL result because virBufferNew allocated space.  The new VirBuffer doesn't
allocate space until something is added and hence this function returns NULL if
nothing is ever put in the buffer.  I'm not familiar enough with the intended
behavior to know what the fix should be here.

Thanks!
--

-- 
Best Regards,
Dave Leskovec
IBM Linux Technology Center
Open Virtualization

Re: PATCH: Support network interface model in Xen and QEMU driver

On Wed, Apr 30, 2008 at 11:36:33PM +0100, Daniel P. Berrange wrote:
> WRT to the network interface type attribute, I advised Soren at the
> virt summit in Austin, that since Rich Jones had already posted the
> patch and we'd all basically agreed on syntax it was reasonably to
> include the patch in Ubuntu. It was only a matter of time before we
> merged it - as I have done today.

Thanks very much. That strikes that bit off of my "Stuff I might need to
worry about" list. :)

> Now, the disk model syntax supporting virtio is where I agree with Daniel
> that it should have been posted upstream before inclusion in a product Even
> if the code was just a quick hack, not in a state fit for merging - it is
> always beneficial to post as early as possible just  for the sake of 
> visibility & comment.

This is good advice. Thanks.

> This said I believe the proposed 'bus' atribute for disks is the
> optimal way to handle virtio for disks. 

I agree. A <model type='foo' /> element in the disk definition could
still be used to specify which particular SCSI controller you'd like.

> Just for future enhancements please post ideas to this list asap. 

I'll keep that in mind. I'm truly sorry for the stir I've caused and I
have every intention of making sure it won't happen again.

> I myself have posted ideas more than 1 year before actually getting

Re: Can't connect to lxc driver

On Wed, Apr 30, 2008 at 05:22:22PM -0700, Dave Leskovec wrote:
> Hi Dan,
> 
> I updated today to the latest CVS and can no longer connect to the lxc driver.
> I've tracked it down to this check in doRemoteOpen() in remote_internal.c:
> 
>     if ((
> #ifdef HAVE_XMLURI_QUERY_RAW
>          uri->query_raw =
> #else
>          uri->query =
> #endif
>          qparam_get_query (vars)) == NULL) goto failed;
> 
> Looking at the recent VirBuffer changes, it looks like they changed the behavior
> of qparam_get_query.  With the old VirBuffer, qparam_get_query returned a
> non-NULL result because virBufferNew allocated space.  The new VirBuffer doesn't
> allocate space until something is added and hence this function returns NULL if
> nothing is ever put in the buffer.  I'm not familiar enough with the intended
> behavior to know what the fix should be here.

So two things - with the old code it was impossible for qparam_get_query
to return NULL, so the NULL check was redundant. Aside from that, it
looks like it is valid for uri->query to be set to NULL anway to indicate
that no variables are set. So I'd suggest you try just removing the
NULL check & goto failed. If that doesn't work, then modify get_query
to return "", if the buffer is NULL.

Regards,
Dan.

Re: Can't connect to lxc driver

Thanks!  Removing the if == NULL goto fail works.  Patch is attached.

Daniel P. Berrange wrote:
> On Wed, Apr 30, 2008 at 05:22:22PM -0700, Dave Leskovec wrote:
>> Hi Dan,
>>
>> I updated today to the latest CVS and can no longer connect to the lxc driver.
>> I've tracked it down to this check in doRemoteOpen() in remote_internal.c:
>>
>>     if ((
>> #ifdef HAVE_XMLURI_QUERY_RAW
>>          uri->query_raw =
>> #else
>>          uri->query =
>> #endif
>>          qparam_get_query (vars)) == NULL) goto failed;
>>
>> Looking at the recent VirBuffer changes, it looks like they changed the behavior
>> of qparam_get_query.  With the old VirBuffer, qparam_get_query returned a
>> non-NULL result because virBufferNew allocated space.  The new VirBuffer doesn't
>> allocate space until something is added and hence this function returns NULL if
>> nothing is ever put in the buffer.  I'm not familiar enough with the intended
>> behavior to know what the fix should be here.
> 
> So two things - with the old code it was impossible for qparam_get_query
> to return NULL, so the NULL check was redundant. Aside from that, it
> looks like it is valid for uri->query to be set to NULL anway to indicate
> that no variables are set. So I'd suggest you try just removing the
> NULL check & goto failed. If that doesn't work, then modify get_query
> to return "", if the buffer is NULL.

[PATCH] lxc: handle SIGCHLD from exiting container

This patch allows the lxc driver to handle SIGCHLD signals from exiting
containers.  The handling will perform some cleanup such as waiting for
the container process and killing/waiting the tty process.  This is also
required as a first step towards providing some kind of client container exit
notification.  Additional support is needed for that but this SIGCHLD handling
is what would trigger the notification.

libvirtd was already catching SIGCHLD although it was just ignoring it.  I
implemented a mechanism to distribute the signal to any other drivers in the
daemon that registered a function to handle them.  This required some changes to
the way libvirtd was catching signals (to get the pid of the sending process) as
well as an addition to the state driver structure.  The intent was to provide
future drivers access to signals as well.

--

-- 
Best Regards,
Dave Leskovec
IBM Linux Technology Center
Open Virtualization

This patch allows the lxc driver to handle SIGCHLD signals from exiting
containers.  The handling will perform some cleanup such as waiting for
the container process and killing/waiting the tty process.  This is also
required as a first step towards providing some kind of client container exit
notification.  Additional support is needed for that but this SIGCHLD handling
is what would trigger the notification.

Re: build problems on RHEL5, at least some are now fixed

> All versions of libvirt should build successfully with RHEL-5. It is one of
> our supported platforms - we intend to support any Linux distro with 
> software of RHEL-5 vintage or later.
>
>
>   

ok thanks - i will give that a go

Re: Can't connect to lxc driver

On Wed, Apr 30, 2008 at 11:13:18PM -0700, Dave Leskovec wrote:
> Thanks!  Removing the if == NULL goto fail works.  Patch is attached.

Ok. comitted this.

Dan.
--

-- 
|: Red Hat, Engineering, Boston   -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 :|

Re: [et-mgmt-tools] [RFE] virtual networks without DHCP

On Mon, Apr 28, 2008 at 08:52:12AM +0100, Richard W.M. Jones wrote:
> On Sun, Apr 27, 2008 at 02:57:54PM +0200, Geert Jansen wrote:
> > I think it would be nice if it were possible to create a virtual network 
> > with virt-manager without DHCP and DNS services. This is useful when you 
> > want to use a host-only network for testing a setup that includes a DHCP 
> > server.
> >
> > I am not sure whether this is a limitation in virt-manager or in libvirt.
> 
> It's a libvirt thing.  Replies redirected to libvir-list.
> 
> My understanding is that if the network doesn't contain a <ip...>
> element in the network XML then no DHCP server will be created.
> 
>   http://libvirt.org/formatnetwork.html

As Rich mentions, this is already supported in libvirt - simply omit
the <dhcp> tag. This is not exposed in the virt-manager UI though - it
always requires DHCP, so you'll need to use the command line to configure
this.

Dan
--

-- 
|: Red Hat, Engineering, Boston   -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 :|

[PATCH] Add /usr/sbin to path when searching for iptables

iptables resides in /usr/sbin on SuSE distros.  Add it to path when
searching for iptables.

Regards,
Jim

iptables resides in /usr/sbin on SuSE distros.  Add it to path when
searching for iptables.

Regards,
Jim

Re: [PATCH] Add /usr/sbin to path when searching for iptables

On Mon, May 05, 2008 at 01:51:38PM -0600, Jim Fehlig wrote:
> iptables resides in /usr/sbin on SuSE distros.  Add it to path when
> searching for iptables.

Thanks, I've comitted this patch.

Dan.
--

-- 
|: Red Hat, Engineering, Boston   -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 :|