Re: [libvirt] [ruby PATCH] Fix default values for node_cpu_stats() and node_memory_stats()

[Chris Lalancette]

On Fri, Nov 22, 2019 at 7:53 PM Cole Robinson  wrote:

> > CCing clalance who is the primary ruby-libvirt maintainer, but if he
> > doesn't get to it by next week then I'll figure out how to build test
> > it, and push
> >
>
> I've pushed this now
>

Sorry I missed this.  Thanks for the patch, and thanks to Cole for merging
it.

Chris
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] ANNOUNCE: Oz 0.17.0 release

[Chris Lalancette]

All,
    I'm pleased to announce release 0.17.0 of Oz.  Oz is a program for 
doing automated installation of guest operating systems with limited 
input from the user.  Release 0.17.0 switches Oz to be python3 only, 
since Python 2 support is ending soon.  There are also some minor fixes 
in here, along with the addition of support for some new OSs.


A tarball and zipfile of this release is available on the Github 
releases page: https://github.com/clalancette/oz/releases . Packages for 
Fedora-30 and Rawhide will be built in Koji and will eventually make 
their way to stable.  Instructions on how to get and use Oz are 
available at http://github.com/clalancette/oz/wiki .



If you have questions or comments about Oz, please feel free to contact 
me at clalancette at gmail.com, or open up an issue on the github page: 
http://github.com/clalancette/oz/issues .


Thanks to everyone who contributed to this release through bug reports, 
patches, and suggestions for improvement.


Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] ANNOUNCE: ruby-libvirt 0.7.1

[Chris Lalancette]

I'm pleased to release ruby-libvirt 0.7.1.  ruby-libvirt is a ruby wrapper
around the libvirt API.  The changelog between 0.7.0 and 0.7.1 is:

  * Fix a bad bug in block_resize (Marius Rieder)
  * Fix up some problems pointed out by clang
  * Fix up the tests for small semantic differences in how libvirt works


Version 0.7.1 is available from http://libvirt.org/ruby:

Tarball: http://libvirt.org/ruby/download/ruby-libvirt-0.7.1.tgz
Gem: http://libvirt.org/ruby/download/ruby-libvirt-0.7.1.gem

It is also available from rubygems.org; to get the latest version, run:

$ gem install ruby-libvirt

Packages for it are also built for Fedora, and will be released shortly.

As usual, if you run into questions, problems, or bugs, please feel free to
mail me (clalancette at gmail.com) and the libvirt mailing list.

Thanks to those who contributed to this release.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] ANNOUNCE: Oz 0.16.0 release

[Chris Lalancette]

All,
I'm pleased to announce release 0.16.0 of Oz.  Oz is a program for
doing automated installation of guest operating systems with limited input
from the user.  Release 0.16.0 is a bugfix and feature release for Oz.
Some of the highlights between Oz 0.15.0 and 0.16.0 are:

* Windows 10 and 2016 support
* All timeouts are now configurable
* Ubuntu 16.04, 16.10, 17.04 support
* Mageia 2, 3, 4, 5 support
* Properly find UEFI firmware, which should fix aarch64 installs
* Fedora 24, 25, 26 support
* FreeBSD 11 support
* Replace internal use of pycurl with requests
* OpenSUSE Leap support
* Timeouts are now based on time, not the number of iterations of the loop
* Modern Fedora and RHEL guests will print out a lot more anaconda
debugging information to the terminal that oz-install was launched from

A tarball and zipfile of this release is available on the Github releases
page: https://github.com/clalancette/oz/releases .  Packages for Fedora
rawhide and 26 have been built in Koji and will eventually make their way
to stable.  Instructions on how to get and use Oz are available at
http://github.com/clalancette/oz/wiki .

If you have questions or comments about Oz, please feel free to contact me
at clalancette at gmail.com, or open up an issue on the github page:
http://github.com/clalancette/oz/issues .

Thanks to everyone who contributed to this release through bug reports,
patches, and suggestions for improvement.

Chris Lalancette
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] news: document libxl tunnelled migration support

[Chris Lalancette]

On Wed, Feb 15, 2017 at 8:24 PM, Jim Fehlig  wrote:

>
> Heh, as a native speaker I'm not sure which spelling is correct, but seem
> to recall a prior discussion on the list proclaiming 'tunneled'. If folks
> prefer I can revert the s/tunnelled/tunneled/ commit.
>
>
I think you have me to blame for "tunnelled".  At the time I initially
wrote tunnelled migration support, I did a Google search similar to what
you have done, and determined that tunnelled seemed to be slightly
preferred.  Subsequently almost everyone has balked at it, but I think the
horse has left the barn on it and we should probably stick with "tunnelled".

Chris
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] ANNOUNCE: ruby-libvirt 0.7.0

[Chris Lalancette]

I'm pleased to release ruby-libvirt 0.7.0.  ruby-libvirt is a ruby wrapper
around the libvirt API.  The changelog between 0.6.0 and 0.7.0 is:

  * Fix network lease API to allow arguments that libvirt allows
  * Implement VIRT_STORAGE_POOL_CREATE flags
  * Implement more VIR_STORAGE_VOL flags
  * Implement VIR_DOMAIN_QEMU_AGENT_COMMAND_SHUTDOWN
  * Implement virDomainDefineXMLFlags
  * Implement virDomainRename
  * Implement virDomainSetUserPassword
  * Implement VIR_DOMAIN_TIME_SYNC
  * Fix the return value from virStreamSourceFunc so volume upload works

Version 0.7.0 is available from http://libvirt.org/ruby:

Tarball: http://libvirt.org/ruby/download/ruby-libvirt-0.7.0.tgz
Gem: http://libvirt.org/ruby/download/ruby-libvirt-0.7.0.gem

It is also available from rubygems.org; to get the latest version, run:

$ gem install ruby-libvirt

Packages for it are also built for Fedora, and will be released shortly.

As usual, if you run into questions, problems, or bugs, please feel free to
mail me (clalancette at gmail.com) and the libvirt mailing list.

Thanks to those who contributed to this release.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] ruby-libvirt latest release doesn't work with fog-libvirt

[Chris Lalancette]

Eek.  I just haven't had time to do it.  I'll see if I can get a release
out this week.  Sorry about that.

Chris Lalancette

On Mon, Sep 19, 2016 at 9:30 AM, Darragh Bailey <daragh.bai...@gmail.com>
wrote:

>
> A number of months ago it was requested whether a new ruby-libvirt release
> could be made to include some new functionality that fog-libvirt wished to
> make use of, see https://www.redhat.com/archives/libvir-list/2016-
> March/msg00241.html.
>
> Any update on this?
>
>
> Currently any attempt to use vagrant-libvirt with fog-libvirt newer than
> 0.0.3 with the current release of ruby-libvirt will result in the following
> error:
>
> /home/baileybd/.vagrant.d/gems/gems/fog-libvirt-0.0.4/
> lib/fog/libvirt/requests/compute/dhcp_leases.rb:8:in `dhcp_leases': NULL
> pointer given (ArgumentError)
> from /home/baileybd/.vagrant.d/gems/gems/fog-libvirt-0.0.4/
> lib/fog/libvirt/requests/compute/dhcp_leases.rb:8:in `dhcp_leases'
> from /home/baileybd/.vagrant.d/gems/gems/fog-libvirt-0.0.4/
> lib/fog/libvirt/models/compute/network.rb:20:in `dhcp_leases'
> from /home/baileybd/.vagrant.d/gems/gems/fog-libvirt-0.0.4/
> lib/fog/libvirt/models/compute/server.rb:272:in `block in addresses'
> from 
> /home/baileybd/.vagrant.d/gems/gems/fog-core-1.42.0/lib/fog/core/collection.rb:19:in
> `each'
> from 
> /home/baileybd/.vagrant.d/gems/gems/fog-core-1.42.0/lib/fog/core/collection.rb:19:in
> `each'
> from /home/baileybd/.vagrant.d/gems/gems/fog-libvirt-0.0.4/
> lib/fog/libvirt/models/compute/server.rb:270:in `addresses'
> from /home/baileybd/.vagrant.d/gems/gems/vagrant-libvirt-0.0.
> 32.hp.2/lib/vagrant-libvirt/action/wait_till_up.rb:44:in `block (3
> levels) in call'
> from 
> /home/baileybd/.vagrant.d/gems/gems/fog-core-1.42.0/lib/fog/core/model.rb:72:in
> `instance_eval'
> from 
> /home/baileybd/.vagrant.d/gems/gems/fog-core-1.42.0/lib/fog/core/model.rb:72:in
> `block in wait_for'
> from 
> /home/baileybd/.vagrant.d/gems/gems/fog-core-1.42.0/lib/fog/core/wait_for.rb:7:in
> `block in wait_for'
> from 
> /home/baileybd/.vagrant.d/gems/gems/fog-core-1.42.0/lib/fog/core/wait_for.rb:6:in
> `loop'
> from 
> /home/baileybd/.vagrant.d/gems/gems/fog-core-1.42.0/lib/fog/core/wait_for.rb:6:in
> `wait_for'
> from 
> /home/baileybd/.vagrant.d/gems/gems/fog-core-1.42.0/lib/fog/core/model.rb:69:in
> `wait_for'
>
>
> It appears the patch required to resolve was landed in January:
> http://libvirt.org/git/?p=ruby-libvirt.git;a=commit;h=
> c2d4192ebf28b8030b753b715a72f0cdf725d313
>
> --
> Darragh Bailey
> "Nothing is foolproof to a sufficiently talented fool"
>
> --
> libvir-list mailing list
> libvir-list@redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [ruby-libvirt 2/2] Add volume upload example

[Chris Lalancette]

On Sun, Jun 12, 2016 at 7:33 AM, Guido Günther  wrote:

> ---
>  examples/upload_volume.rb | 36 
>  1 file changed, 36 insertions(+)
>  create mode 100644 examples/upload_volume.rb
>
>
That example is great, thanks.  I cleaned it up a little bit, moved it into
doc/site/examples, and added some comments.  Thanks again!

Chris
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [ruby-libvirt] Don't make volume upload zero bytes

[Chris Lalancette]

On Fri, Jun 10, 2016 at 11:10 AM, Guido Günther  wrote:

> The virStreamSourceFunc internal_sendall currently returns the first
> value passed in from the block, which according the ruby-libvirt docs
> should be zero:
>
>   The send block should return an array of 2 elements; the first element
>   should be the return code from the block (-1 for error, 0 otherwise)
>
> But according to the libvirt docs of virStreamSourceFunc this indicates
> EOF:
>
>   Returns:  the number of bytes filled, 0 upon end of file, or -1 upon
> error
>
> So return the size of the buffer to unbreak volume uploads.


This looks OK to me, so I applied it, thanks.  I really should add an
example of virStream to the examples on the website; do you happen to have
a relatively simple example that I could put up there?

Thanks,
Chris
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] ruby-libvirt mixed storage migration

[Chris Lalancette]

On Mon, Mar 7, 2016 at 10:48 AM, Tim Förster - Hetzner Online AG <
tim.foers...@hetzner.de> wrote:

> Hi,
>
> rebuilding the gem is not quite easy. I am not able to find the actual
> gemspec. There are also some
>

The gemspec is in the git repository.  You should be able to clone git://
libvirt.org/ruby-libvirt.git, then run "rake gem" to get a new gem.


> missing features, which are available though virsh. Such as 'virsh
> domblklist' to find out the
> actual registered block targets or rate limiting with iotune the burst
> iops.
>
>
ruby-libvirt aims to expose the libvirt API through ruby, not the virsh
API.  Sometimes virsh provides additional functionality on top of the
libvirt API, which will not necessarily be implemented in ruby-libvirt.  In
this particular case, virsh domblklist parses virDomainGetXMLDesc() to
output a list of block devices.  virDomainGetXMLDesc() is supported by
ruby-libvirt, but domblklist itself would not be.  That being said, it
should be fairly straightforward to implement it in ruby by first calling
dom.xml_desc(), and then parsing the output with your favorite ruby XML
parsing library.

Chris
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] ruby-libvirt mixed storage migration

[Chris Lalancette]

Hi there,

On Thu, Mar 3, 2016 at 11:10 AM, Tim Förster - Hetzner Online AG <
tim.foers...@hetzner.de> wrote:

> Heyho guys,
>
> is there any reason why mixed storage migration is restriced. I am unable
> to serve parameter
> "migrate_disks" through #migrate_to_uri3. It looks like there is a missing
> macro here.
>
> http://libvirt.org/git/?p=ruby-libvirt.git;a=blob;f=ext/libvirt/domain.c#l3858.
> Could you please
> verify this?
>

This is probably one of those enums I just haven't gotten to yet.  I can
look at implementing it for the next release.  Note, though, that all of
these fields are integers, so as a temporary workaround you should be able
to just use the correct number.

Chris
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] ANNOUNCE: Oz 0.15.0 release

[Chris Lalancette]

All,
 I'm pleased to announce release 0.15.0 of Oz.  Oz is a program for
doing automated installation of guest operating systems with limited input
from the user.  Release 0.15.0 is a bugfix and feature release for Oz.
Some of the highlights between Oz 0.14.0 and 0.15.0 are:

* Make sure openssh-clients is included in CentOS builds
* Add support for Fedora-23
* Add customization support for Debian
* Use the ssh -i option to avoid "Too many authentication failures" with
many ssh keys
* Support "rawhide" as a Fedora version
* Add in Ubuntu 15.10 support
* Add in OpenSUSE 13.2 support
* Improve Oz's free port selection

A tarball and zipfile of this release is available on the Github releases
page: https://github.com/clalancette/oz/releases .  Packages for Fedora-22,
Fedora-23, and EPEL-7 have been built in Koji and will eventually make
their way to stable.  Instructions on how to get and use Oz are available
at http://github.com/clalancette/oz/wiki .

If you have questions or comments about Oz, please feel free to contact me
at clalancette at gmail.com, or open up an issue on the github page:
http://github.com/clalancette/oz/issues .

Thanks to everyone who contributed to this release through bug reports,
patches, and suggestions for improvement.

Chris Lalancette
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] ruby-libvirt: Don't crash in leases_wrap() by passing NULLs to rb_str_new2()

[Chris Lalancette]

On Thu, Jan 14, 2016 at 9:38 PM, Chris Lalancette <clalance...@gmail.com>
wrote:

> Hi!
>
> On Thu, Jan 14, 2016 at 2:56 PM, Dan Williams <d...@redhat.com> wrote:
>
>> On Thu, 2016-01-14 at 13:19 -0500, Laine Stump wrote:
>> > On 01/14/2016 11:01 AM, Dan Williams wrote:
>> > > On Thu, 2016-01-07 at 11:12 -0600, Dan Williams wrote:
>> > > > Not all lease values are mandatory, and when they aren't supplied
>> > > > by the libvirt driver they get set to NULL.  That makes
>> > > > rb_str_new2() bail out.
>> > > Ping?  Does this patch look OK or is there anything else I need to
>> > > do
>> > > with it?  Is the submission procure for ruby-libvirt different than
>> > > normal libvirt?
>> >
>> > As far as I can see, posting to libvir-list is the correct thing for
>> > ruby-libvirt patches, I think it's just that very few people use it,
>> > so
>> > most of us don't feel comfortable ACKing anything for it.
>>
>> Thanks!  I'd bet a lot more people use it than you think, since it's a
>> dependency of vagrant-libvirt by way of fog.  So you can't stand up a
>> vagrant machine using libvirt without it...
>>
>>
> Dan
>>
>> > It looks like Chris Lalancette is the maintainer and has been the
>> > author
>> > of nearly every patch in the last couple years, so I'm Cc'ing him to
>> > be
>> > sure it see it
>
>
> For whatever reason, I didn't see your earlier patches.  I'll take a look
> and get back to you.
>


I've now applied the patch.  Thanks for the contribution!

Chris
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] ruby-libvirt: Don't crash in leases_wrap() by passing NULLs to rb_str_new2()

[Chris Lalancette]

Hi!

On Thu, Jan 14, 2016 at 2:56 PM, Dan Williams <d...@redhat.com> wrote:

> On Thu, 2016-01-14 at 13:19 -0500, Laine Stump wrote:
> > On 01/14/2016 11:01 AM, Dan Williams wrote:
> > > On Thu, 2016-01-07 at 11:12 -0600, Dan Williams wrote:
> > > > Not all lease values are mandatory, and when they aren't supplied
> > > > by the libvirt driver they get set to NULL.  That makes
> > > > rb_str_new2() bail out.
> > > Ping?  Does this patch look OK or is there anything else I need to
> > > do
> > > with it?  Is the submission procure for ruby-libvirt different than
> > > normal libvirt?
> >
> > As far as I can see, posting to libvir-list is the correct thing for
> > ruby-libvirt patches, I think it's just that very few people use it,
> > so
> > most of us don't feel comfortable ACKing anything for it.
>
> Thanks!  I'd bet a lot more people use it than you think, since it's a
> dependency of vagrant-libvirt by way of fog.  So you can't stand up a
> vagrant machine using libvirt without it...
>
>
Dan
>
> > It looks like Chris Lalancette is the maintainer and has been the
> > author
> > of nearly every patch in the last couple years, so I'm Cc'ing him to
> > be
> > sure it see it.
>

For whatever reason, I didn't see your earlier patches.  I'll take a look
and get back to you.

Chris
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] ANNOUNCE: ruby-libvirt 0.6.0

[Chris Lalancette]

All,
I'm pleased to release ruby-libvirt 0.6.0.  ruby-libvirt is a ruby
wrapper around the libvirt API.  The changelog between 0.5.2 and 0.6.0
is:

  * Fix possible buffer overflow
  * Fix storage volume creation error messages
  * Add additional storage pool defines
  * Implement Network dhcp_leases method
  * Implement Connect node_alloc_pages method
  * Implement Domain time method
  * Implement Connect domain_capabilities method
  * Implement Domain core_dump_with_format method
  * Implement Domain fs_freeze method
  * Implement Domain fs_info method
  * Implement Connect node_free_pages method

Version 0.6.0 is available from http://libvirt.org/ruby:

Tarball: http://libvirt.org/ruby/download/ruby-libvirt-0.5.2.tgz
Gem: http://libvirt.org/ruby/download/ruby-libvirt-0.5.2.gem

It is also available from rubygems.org; to get the latest version, run:

$ gem install ruby-libvirt

Packages for it are also built for Fedora, and will be released shortly.

As usual, if you run into questions, problems, or bugs, please feel free to
mail me (clalancette gmail com) and the libvirt mailing list.

Thanks to those who contributed to this release.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] ANNOUNCE: Oz 0.14.0 release

[Chris Lalancette]

All,
I'm pleased to announce release 0.14.0 of Oz.  Oz is a program
for doing automated installation of guest operating systems with
limited input from the user.  Release 0.14.0 is a bugfix and feature
release for Oz.  Some of the highlights between Oz 0.13.0 and 0.14.0
are:

* Fix a bug in checksum checking (this should work again)
* Add a global lock around pool refresh; should get rid of a
user-visible failure
* Support for Debian 8
* Support for Ubuntu 15.04
* Support for Fedora 22
* Support for installing aarch64 guests
* Support for installing POWER guests
* Support for install arm 32-bit guests

A tarball and zipfile of this release is available on the Github
releases page: https://github.com/clalancette/oz/releases .  Packages
for Fedora-21, Fedora-22, EPEL-7, and EPEL-6 have been built in Koji and will
eventually make their way to stable.  Instructions on how to get and
use Oz are available at http://github.com/clalancette/oz/wiki .

If you have questions or comments about Oz, please feel free to
contact me at clalancette at gmail.com, or open up an issue on the
github page: http://github.com/clalancette/oz/issues .

Thanks to everyone who contributed to this release through bug reports,
patches, and suggestions for improvement.

Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] GITHUB readonly mirror site

[Chris Lalancette]

On Fri, May 22, 2015 at 7:48 PM, Chris Lalancette clalance...@gmail.com wrote:
 On Fri, May 22, 2015 at 4:13 PM, Daniel P. Berrange berra...@redhat.com 
 wrote:
 And in ruby-libvirt.git

 remote: error: object acb8c8a2c6b3b33cf02c4f03eeb8bc0b803e6b24:invalid 
 author/committer line - bad date

Hey Dan,
 Sorry it took a while, but I re-wrote the history on ruby-libvirt
to get rid of the problematic commit.  You should now be able to
mirror ruby-libvirt on github.  Let me know if there are any other
problems.

Thanks,
Chris

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] GITHUB readonly mirror site

[Chris Lalancette]

On Fri, May 22, 2015 at 4:13 PM, Daniel P. Berrange berra...@redhat.com wrote:
 And in ruby-libvirt.git

 remote: error: object acb8c8a2c6b3b33cf02c4f03eeb8bc0b803e6b24:invalid 
 author/committer line - bad date
 remote: fatal: Error in object
 error: pack-objects died of signal 13
 error: pack-objects died with strange error
 error: failed to push some refs to 'g...@gitlab.com:libvirt/ruby-libvirt.git'
 remote: error: object acb8c8a2c6b3b33cf02c4f03eeb8bc0b803e6b24:invalid 
 author/committer line - bad date
 remote: fatal: Error in object
 error: unpack failed: index-pack abnormal exit


 I've been reading up online and AFAICT, the only way to fix this is to
 re-write GIT history entirely in the affected repos. This doesn't change
 the content, but it'll invalidate everyone's current checkouts :-(

 Perhaps these 3 modules are niche / small enough that we're fine rewriting
 historyor maybe Eric knows another workaround ?

Honestly, I have very few committers on ruby-libvirt besides myself,
so I would be OK rewriting history on it.  I'm definitely not going to
get to it this weekend, but I could get to it next week if someone
else doesn't get to it first.  Just let me know if someone does it :).

Chris

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] ANNOUNCE: Oz 0.13.0 release

[Chris Lalancette]

All,
I'm pleased to announce release 0.13.0 of Oz.  Oz is a program
for doing automated installation of guest operating systems with
limited input from the user.  Release 0.13.0 is a bugfix and feature
release for Oz.  Some of the highlights between Oz 0.12.0 and 0.13.0
are:

- For Fedora, if the user specifies a version, but that isn't
supported yet, try the last supported version (in this case), as that
will often work.
- Fix a regression where we forgot to force the qcow2 image type
- Allow installs that use more than one installation device
- Add support for RHEL 6.5
- Rename OEL-6 to OL-6
- Add support for Ubuntu 14.04
- Add Windows 8.1 support
- Add CentOS-7 support
- Add the ability to specify kernel parameters in the TDL
- Make sure to remove dhcp leases from guests after the install
- Fix support for FreeBSD
- Add in support for TDL precommands; these are commands that are
run *before* package installation
- Fix up file locking
- Add support for RHEL 5.11
- Remove Ubuntu ssh keys at the end of installation
- Add support for Ubuntu 14.10
- Add support for XInclude, for merging various TDLs together
- Add Fedora 21 support
- Add support for ppc64 and ppc64le

A tarball and zipfile of this release is available on the Github
releases page: https://github.com/clalancette/oz/releases .  Packages
for Fedora-20, Fedora-21, Fedora-22, EPEL-6, and EPEL-7 have been
built in Koji and will eventually make their way to stable.
Instructions on how to get and
use Oz are available at http://github.com/clalancette/oz/wiki .

If you have questions or comments about Oz, please feel free to
contact me at clalancette at gmail.com, or open up an issue on the
github page: http://github.com/clalancette/oz/issues .

Thanks to everyone who contributed to this release through bug reports,
patches, and suggestions for improvement.

Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [libvirt-ruby] [PATCH] fix storage volume creation error messages

[Chris Lalancette]

Hi there,

On Thu, Oct 16, 2014 at 6:59 PM, Adam Spiers aspi...@suse.com wrote:
  Sorry, I forgot to say that this patch is for the ruby-libvirt tree.
  I'm a total newbie to libvirt development, so apologies if I was
  supposed to send this elsewhere.

 This is the right place, but it might get more attention from the right
 people if you do 'git config format.subjectprefix ruby PATCH'.

 OK thanks for the tip Eric - I've applied that setting for any future
 submissions!

Yep, exactly as Eric says; I'm the maintainer of ruby-libvirt, and
lurk here on the libvirt list.  But I usually only look at things
specifically mentioning ruby-libvirt, so putting that in the subject
is helpful in the future.

In any case, you are right, and this was a silly copy-n-paste error.
I've now applied your patch; thanks!

Chris

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] run qemu-agent-command via binding (ruby/python/php)

[Chris Lalancette]

On Thu, Aug 28, 2014 at 9:34 AM, Eric Blake ebl...@redhat.com wrote:
 On 08/28/2014 07:12 AM, Vasiliy Tolstov wrote:
 Hi! Does it possible(featured, planned) to run some qemu-agent-command
 via libvirt binding (i'm interesting on ruby and php).?

 I'm not sure the time-schedule of the ruby and php bindings maintainers,
 but ideally, ALL libvirt API should eventually have exposure in each
 language binding.

The ruby bindings support virDomainQemuAgentCommand() since 0.5.2.  I
haven't really tested it, though, so your mileage may vary.  I
definitely accept bug reports and patches.

Chris

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Ruby]How to retrieve nodes in devices ?

[Chris Lalancette]

On Sun, Jan 12, 2014 at 6:09 PM, Teto matta...@gmail.com wrote:
 Hi,
 Thanks to your advice, I was able to make it work using nokogiri.
 I am now trying to attach new devices (shared folders) via my custom function:
 =
 def attach_device(uuid , device)
   puts CAlled with uuid #{uuid}

   client.lookup_domain_by_uuid(uuid).update_device(device.to_s, 0)
 end
 =
 device.to_s returns a correct xml for filesystem. I then have the
 following error:

CAlled with uuid 8cc185ef-4bf1-4b78-9caa-cd14c70cd1b3
/home/teto/fog/lib/fog/libvirt/requests/compute/attach_device.rb:38:in 
`update_device': Call to virDomainUpdateDeviceFlags failed: Operation not 
supported: persistent update of device 'filesystem' is not supported 
(Libvirt::Error)

 Does that mean I need to undefine my domain and then recreate it if I
 want to keep the update persistent ?

Sorry, I don't really know about that.  Hopefully someone else will be
able to answer.

Chris

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Ruby]How to retrieve nodes in devices ?

[Chris Lalancette]

On Thu, Jan 9, 2014 at 11:04 AM, Teto matta...@gmail.com wrote:
 Hi,

 I would like to list devices (for instance I would like to retrieve
 the filesystem part in devicesfilesystem
 type=mount.../filesystem/devices) embedded in a domain via the
 ruby bindings ?

The steps are roughly:
1.  require 'libvirt'
2.  Connect to libvirt using the open method
3.  Find the domain you care about using lookup_domain_by_name
4.  Get the XML for the domain
5.  Parse the domain XML using nokogiri or similar

It would look something like this (the details will be somewhat
different depending on which connection URI and domain you are using):

require 'libvirt'

conn = Libvirt::open('qemu:///system')

dom = conn.lookup_domain_by_name('f19')

xml_doc = Nokogiri::XML(dom.xml_desc)

devs = xml_doc.xpath('/domain/devices')

After that last line, you'll have the ability to iterate over the
devices, and do whatever you want with them.  Hope this helps!

Chris

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] ANNOUNCE: ruby-libvirt 0.5.2

[Chris Lalancette]

All,
This is a release notification for ruby-libvirt 0.5.2.
ruby-libvirt is a ruby wrapper around the libvirt API.  The changelog
between 0.5.1 and 0.5.2 is:

* Fix to make sure we don't free more entries than retrieved (potential crash)

Version 0.5.2 is available from http://libvirt.org/ruby:

Tarball: http://libvirt.org/ruby/download/ruby-libvirt-0.5.2.tgz
Gem: http://libvirt.org/ruby/download/ruby-libvirt-0.5.2.gem

It is also available from rubygems.org; to get the latest version, run:

$ gem install ruby-libvirt

As usual, if you run into questions, problems, or bugs, please feel free to
mail me (clalancette gmail com) and the libvirt mailing list.

Thanks to Guido Günther for the patch to fix this problem.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [ruby-libvirt] Don't free more entries than we retrieved

[Chris Lalancette]

On Tue, Jan 7, 2014 at 3:24 PM, Guido Günther a...@sigxcpu.org wrote:
 The vir*List* functions return the number of fetched entries. We mustn't
 free more, otherwise we'll crash like

  #0  0xb779d424 in __kernel_vsyscall ()
  #1  0xb733981f in __GI_raise (sig=sig@entry=6) at 
 ../nptl/sysdeps/unix/sysv/linux/raise.c:56
  #2  0xb733ccd3 in __GI_abort () at abort.c:90
  #3  0xb7376275 in __libc_message (do_abort=do_abort@entry=2, 
 fmt=fmt@entry=0xb74767d0 *** Error in `%s': %s: 0x%s ***\n) at 
 ../sysdeps/unix/sysv/linux/libc_fatal.c:199
  #4  0xb7380e52 in malloc_printerr (action=optimized out, str=optimized 
 out, ptr=0xb7087000) at malloc.c:4923
  #5  0xb7381b90 in _int_free (av=0xb74b7440 main_arena, p=0xb7086ff8, 
 have_lock=0) at malloc.c:3779
  #6  0xb75c059f in ruby_xfree () from /usr/lib/libruby-1.9.1.so.1.9
  #7  0xb7076448 in ruby_libvirt_generate_list () from 
 /usr/lib/ruby/vendor_ruby/1.9.1/i486-linux/_libvirt.so
 ...

 since we're trying to free random addresses.

Hm, this is pretty weird.  At all ruby_libvirt_generate_list() call
sites, there is a line of code that precedes it that checks for r  0.
 If r is less than 0, then we generate an exception, which means that
the code that follows should never be called, and thus we should never
need this patch.

Can you explain a bit more why this patch helps, and/or give me a test
case that will cause it to fail?

Thanks,
Chris

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [ruby-libvirt] Don't free more entries than we retrieved

[Chris Lalancette]

On Tue, Jan 7, 2014 at 4:04 PM, Guido Günther a...@sigxcpu.org wrote:
 The check for  0 might be superfluos but freeing num entries instead of
 only r ones looks wrong to me since r is the number of allocated names,
 not num. I'm happy to send a patch dropping the  0 part.

Oh, bah humbug.  Yeah, you are definitely right about that.

Please do send a patch with just the num - r bit.  That is definitely a bug.

Thanks,
Chris

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [ruby-libvirt] Allow to set URI via environment variable

[Chris Lalancette]

On Tue, Jan 7, 2014 at 4:11 PM, Guido Günther a...@sigxcpu.org wrote:
 This allows us to run tests with the destdriver like:

   RUBY_LIBVIRT_TEST_URI=test:///default \
   RUBYLIB=lib/:ext/libvirt/ \
   ruby tests/test_open.rb
 ---
 I've only converted three modules so far since they were simple but
 these already help to run tests during package build.

Looks like a good change.  Applied.  Thanks!

Chris

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH ruby-libvirt v2] Don't free more entries than we retrieved

[Chris Lalancette]

On Tue, Jan 7, 2014 at 4:54 PM, Guido Günther a...@sigxcpu.org wrote:
 The vir*List* functions return the number of fetched entries. We mustn't
 free more, otherwise we'll crash like

  #0  0xb779d424 in __kernel_vsyscall ()
  #1  0xb733981f in __GI_raise (sig=sig@entry=6) at 
 ../nptl/sysdeps/unix/sysv/linux/raise.c:56
  #2  0xb733ccd3 in __GI_abort () at abort.c:90
  #3  0xb7376275 in __libc_message (do_abort=do_abort@entry=2, 
 fmt=fmt@entry=0xb74767d0 *** Error in `%s': %s: 0x%s ***\n) at 
 ../sysdeps/unix/sysv/linux/libc_fatal.c:199
  #4  0xb7380e52 in malloc_printerr (action=optimized out, str=optimized 
 out, ptr=0xb7087000) at malloc.c:4923
  #5  0xb7381b90 in _int_free (av=0xb74b7440 main_arena, p=0xb7086ff8, 
 have_lock=0) at malloc.c:3779
  #6  0xb75c059f in ruby_xfree () from /usr/lib/libruby-1.9.1.so.1.9
  #7  0xb7076448 in ruby_libvirt_generate_list () from 
 /usr/lib/ruby/vendor_ruby/1.9.1/i486-linux/_libvirt.so
 ...

 since we're trying to free random addresses.

Thanks, I've applied this patch now.  This is probably worthy of
another release, since it could be quite a bad bug.  That being said,
are you actively doing additional testing?  If so, I'll wait a bit
longer to see if you come up with anything else.

Chris

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] ANNOUNCE: Oz 0.12.0 release

[Chris Lalancette]

All,
I'm pleased to announce release 0.12.0 of Oz.  Oz is a program for
doing automated installation of guest operating systems with limited
input from the user.  Release 0.12.0 is a bugfix and feature release
for Oz.  Some of the highlights between Oz 0.11.0 and 0.12.0 are:

* Fixes to concurrent oz-install invocations
* Python 3 compatibility in the test suites
* Support for Ubuntu 12.04.3
* Support for Mageia
* Allow a MAC address to be passed in (instead of auto-generated)
* Support for RHEL5.10
* Support for Ubuntu 13.10
* Use lxml instead of libxml2 for XML document processing (it has much
better error messages)
* Remove the unused tunnels functionality
* Support FreeBSD 10.0
* Remove deprecated functions from the Guest class
* Speed up guest customization on guests that support NetworkManager
* Follow subprocess commands as they are executed (makes debugging easier)
* Ensure that any paths from the user are absolute, otherwise things
don't work properly
* Add support for OpenSUSE 13.1
* Add support for Fedora 20
* Add support for RHEL-7

A tarball and zipfile of this release is available on the Github
releases page: https://github.com/clalancette/oz/releases .  Packages
for Fedora-19, Fedora-20, and EPEL-6 have been built in Koji and will
eventually make their way to stable.  Instructions on how to get and
use Oz are available at http://github.com/clalancette/oz/wiki .

If you have questions or comments about Oz, please feel free to
contact me at clalancette at gmail.com, or open up an issue on the
github page: http://github.com/clalancette/oz/issues .

Thanks to everyone who contributed to this release through bug
reports, patches, and suggestions for improvement.

Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] ANNOUNCE: ruby-libvirt 0.5.1

[Chris Lalancette]

I'm pleased to announce the release of ruby-libvirt 0.5.1.
ruby-libvirt is a ruby wrapper around the libvirt API.
The changelog between 0.5.0 and 0.5.1 is:

* Fixes to compile against older libvirt
* Fixes to compile against ruby 1.8

Version 0.5.1 is available from http://libvirt.org/ruby:

Tarball: http://libvirt.org/ruby/download/ruby-libvirt-0.5.1.tgz
Gem: http://libvirt.org/ruby/download/ruby-libvirt-0.5.1.gem

It is also available from rubygems.org; to get the latest version, run:

$ gem install ruby-libvirt

As usual, if you run into questions, problems, or bugs, please feel free to
mail me (clalance...@gmail.com) and/or the libvirt mailing list.

Thanks to everyone who contributed patches and submitted bugs.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] ANNOUNCE: ruby-libvirt 0.5.0

[Chris Lalancette]

On Wed, Dec 11, 2013 at 3:28 AM, Dominic Cleal dcl...@redhat.com wrote:
 Thanks for the fix Chris.  A new release would be much appreciated as
 we're hitting this issue on gems, not RPMs.  Our CI for Foreman
 (http://theforeman.org/) runs under a few Ruby versions and picked up
 this new version of the gem, so we'll need to pin to  0.5 otherwise.

OK, I'll put out a new release.  I may not get to it until tomorrow
night; just FYI.

Chris

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] ANNOUNCE: ruby-libvirt 0.5.0

[Chris Lalancette]

Hi there,

On Tue, Dec 10, 2013 at 7:47 AM, Dominic Cleal dcl...@redhat.com wrote:
 Hi Chris,

 On 10/12/13 01:52, Chris Lalancette wrote:
 All,
  I'm pleased to announce the release of ruby-libvirt 0.5.0.  ruby-libvirt
 is a ruby wrapper around the libvirt API.  Version 0.5.0 brings new APIs, 
 more
 documentation, and bugfixes:

 With ruby-libvirt 0.5.0, I'm now seeing compilation errors using Ruby
 1.8.7p371.  Was dropping of 1.8 support in this update deliberate?

 gcc -I. -I.
 -I/usr/local/rvm/rubies/ruby-1.8.7-p371/lib/ruby/1.8/x86_64-linux -I.
 -DRUBY_EXTCONF_H=\extconf.h\-fPIC -g -O2  -fPIC -c common.c
 common.c: In function ‘ruby_libvirt_typed_parameter_assign’:
 common.c:385: error: ‘ST_CONTINUE’ undeclared (first use in this function)
 common.c:385: error: (Each undeclared identifier is reported only once
 common.c:385: error: for each function it appears in.)
 common.c: In function ‘ruby_libvirt_set_typed_parameters’:
 common.c:405: error: dereferencing pointer to incomplete type
 make: *** [common.o] Error 1

No, it wasn't deliberate.  Interesting, though; I thought that the
ST_CONTINUE symbol existed in ruby 1.8.  I'll take a look tonight and
see if I can find where the problem is.

Thanks for the report.

Chris

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] ANNOUNCE: ruby-libvirt 0.5.0

[Chris Lalancette]

On Tue, Dec 10, 2013 at 8:35 AM, Chris Lalancette clalance...@gmail.com wrote:
 gcc -I. -I.
 -I/usr/local/rvm/rubies/ruby-1.8.7-p371/lib/ruby/1.8/x86_64-linux -I.
 -DRUBY_EXTCONF_H=\extconf.h\-fPIC -g -O2  -fPIC -c common.c
 common.c: In function ‘ruby_libvirt_typed_parameter_assign’:
 common.c:385: error: ‘ST_CONTINUE’ undeclared (first use in this function)
 common.c:385: error: (Each undeclared identifier is reported only once
 common.c:385: error: for each function it appears in.)
 common.c: In function ‘ruby_libvirt_set_typed_parameters’:
 common.c:405: error: dereferencing pointer to incomplete type
 make: *** [common.o] Error 1

Yeah, it turns out that ST_CONTINUE is in st.h in ruby 1.8 and
ruby/st.h in later versions.  Luckily the old st.h still works on
later version (albeit with a warning).  I fixed that, and also added a
compatibility hack in the Rakefile that allows it to build on ruby
1.8.  With both of those in place, I'm now able to build on
CentOS-6.4.  I've pushed these compatibility hacks to the main
ruby-libvirt repository.

At the moment, I'm not planning to put out a new release for this
minor fix.  Dominic, if you really want this in an official release,
let me know and I can do a 0.5.1.  Otherwise I'll just let you handle
it when building a package for RHEL-6/CentOS-6.

Thanks again for the bug report.

Chris

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] ANNOUNCE: ruby-libvirt 0.5.0

[Chris Lalancette]

All,
 I'm pleased to announce the release of ruby-libvirt 0.5.0.  ruby-libvirt
is a ruby wrapper around the libvirt API.  Version 0.5.0 brings new APIs, more
documentation, and bugfixes:

  * Updated Network class, implementing almost all libvirt APIs
  * Updated Domain class, implementing almost all libvirt APIs
  * Updated Connection class, implementing almost all libvirt APIs
  * Updated DomainSnapshot class, implementing almost all libvirt APIs
  * Updated NodeDevice class, implementing almost all libvirt APIs
  * Updated Storage class, implementing almost all libvirt APIs
  * Add constants for almost all libvirt defines
  * Improved performance in the library by using alloca

Version 0.5.0 is available from http://libvirt.org/ruby:

Tarball: http://libvirt.org/ruby/download/ruby-libvirt-0.5.0.tgz
Gem: http://libvirt.org/ruby/download/ruby-libvirt-0.5.0.gem

It is also available from rubygems.org; to get the latest version, run:

$ gem install ruby-libvirt

As usual, if you run into questions, problems, or bugs, please feel free to
mail me (clalance...@gmail.com) and/or the libvirt mailing list.

Thanks to everyone who contributed patches and submitted bugs.

Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [Ruby] Next release?

[Chris Lalancette]

Sorry about that.  Things are pretty much settled down with it; I
really just need to finish up the testing with it and get it out.
I'll try to do that in the next week.

Chris

(FYI: if you want to get me directly, you'll need to use
clalance...@gmail.com now)


On Sun, Dec 8, 2013 at 9:28 AM, Hiroshi Miura miur...@linux.com wrote:
 Hi Chris,

 I'm waiting a next release of ruby-libvitrt in 4 month.
 Recent development git snapshot works well with
 vagnrant-kvm that I worked.

 thank you for hard work.

 Hiroshi

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH][Ruby] support: virNetworkUpdate

[Chris Lalancette]

On Tue, Aug 13, 2013 at 10:19 AM, Hiroshi Miura miur...@linux.com wrote:
 Hi Chris,

 On 2013年08月13日 09:55, Chris Lalancette wrote:

 Thanks for the patch, that is great!

 I've now applied it to the main ruby-libvirt repository.  Let me know
 if you have any problems with it.


 Looks good. No problem.

 IMHO, there are many progress from 0.4.0 release, it is chance to release 
 0.5.0 :-)

Yeah, I have a few other patches outstanding.  I'll try to get to them
and do a release in the near future.


 There is a small problem that a commit in 2008 had a wrong date record.
 (That makes warn when pushing it on github.com)
 https://github.com/miurahr/ruby-libvirt/compare/master...fixInvalidCommit

Yeah, I see what you mean.  That is unfortunate.  However, I'm not
inclined to rewrite the whole history of the repository, as that will
break all downstream cloners.  Unless it is a major problem for you,
I'm just going to leave it as-is.

Thanks,
Chris

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] Using unix domain sockets with serial devices

[Chris Lalancette]

Hello,
 The Oz automated install program (http://github.com/clalancette/oz)
uses a serial device inside a guest to communicate the guest IP address to
a listener on the host; once the host has the IP address, other
customization steps can take place.
 This serial device in the guest is currently backed by a TCP socket on
the host.  I use the following libvirt XML snippet to set this up:

serial type=tcp
  source mode=bind host=127.0.0.1 service=9412/
  protocol type=raw/
  target port=1/
/serial

DanB points out that this is probably insecure, and we should use named
pipes or Unix domain sockets instead.  I was able to implement Unix domain
sockets with a few minor changes to Oz, but I'm running into a permissions
problem.
Essentially, the problem is that when you run Oz as a regular, non-root
user, there is no convenient place on the filesystem where both the qemu
user can read and write the socket, and where the user that is running Oz
can read the socket.  I've tried using /var/lib/libvirt/qemu/*.port, but
that directory is 0650, so the regular user has no permission to it.
Similarly, the qemu user may not have permission to read the users home
directory, so I can't really put it there either.
Does anyone have any ideas of what I might do here?  I'm open to
changing to any of Unix domain sockets, pipes, UDP sockets, or whatever,
but it has to work for both root and non-root users.

Thanks in advance,
Chris
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] ANNOUNCE: ruby-libvirt 0.4.0

[Chris Lalancette]

All,
 I'm pleased to announce the release of ruby-libvirt 0.4.0.  ruby-libvirt
is a ruby wrapper around the libvirt API.  Version 0.4.0 brings new APIs, more
documentation, and bugfixes:

  * Updated Domain class, implementing dom.memory_parameters=,
dom.memory_parameters, dom.updated?, dom.migrate2, dom.migrate_to_uri2,
dom.migrate_set_max_speed, dom.qemu_monitor_command, dom.blkio_parameters,
dom.blkio_parameters=, dom.state, dom.open_console, dom.screenshot, and
dom.inject_nmi
  * Implementation of the Stream class, which covers the libvirt virStream APIs
  * Add the ability to build against non-system libvirt libraries
  * Updated Error object, which now includes the libvirt code, component and
level of the error, as well as all of the error constants from libvirt.h
  * Updated Connect class, implementing conn.sys_info, conn.stream,
conn.interface_change_begin, conn.interface_change_commit, and
conn.interface_change_rollback
  * Updated StorageVol class, implementing vol.download and vol.upload
  * Various bugfixes

Version 0.4.0 is available from http://libvirt.org/ruby:

Tarball: http://libvirt.org/ruby/download/ruby-libvirt-0.4.0.tgz
Gem: http://libvirt.org/ruby/download/ruby-libvirt-0.4.0.gem

It is also available from rubygems.org; to get the latest version, run:

$ gem install ruby-libvirt

As usual, if you run into questions, problems, or bugs, please feel free to
mail me (clala...@redhat.com) and/or the libvirt mailing list.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] ruby libvirt restore is broken

[Chris Lalancette]

On 05/28/11 - 05:46:21PM, Ronen Narkis wrote:
 Hey dear libvirt users /dev
 
 Im trying to use ruby's bindings to libvirt and Im unable to use the domain
 restore
 
 
 ruby-1.8.7-p334 :014  dom.restore(/tmp/puppet-client.state)
 Libvirt::Error: Call to virDomainRestore failed
 from (irb):14:in `restore'
 from (irb):14

Unfortunately, dom.restore doesn't work.  I suspect it is an object lifetime
issue, since once you have done a dom.save, the underlying VM is killed and
I think libvirt will drop the object.

What you really want to use is:

Libvirt::Domain::Restore(conn, /tmp/puppet-client.state)

Which should do the trick.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [ruby-libvirt PATCH] Fix compile error due to missing semicolon

[Chris Lalancette]

On 03/09/11 - 11:23:01AM, Matthias Bolte wrote:
 I pushed this under the trivial build breaker rule.
 
 Matthias

 From fd48bb491477843d520a14f226e79fde3e053da7 Mon Sep 17 00:00:00 2001
 From: Matthias Bolte matthias.bo...@googlemail.com
 Date: Wed, 9 Mar 2011 11:17:34 +0100
 Subject: [ruby-libvirt PATCH] Fix compile error due to missing semicolon
 
 ---
  ext/libvirt/connect.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/ext/libvirt/connect.c b/ext/libvirt/connect.c
 index 0228a7a..a9e9923 100644
 --- a/ext/libvirt/connect.c
 +++ b/ext/libvirt/connect.c
 @@ -1808,7 +1808,7 @@ static VALUE libvirt_conn_get_sys_info(int argc, VALUE 
 *argv, VALUE c) {
  flags = INT2NUM(0);
  
  gen_call_string(virConnectGetSysinfo, conn(c), 1, connect_get(c),
 -NUM2UINT(flags))
 +NUM2UINT(flags));
  }
  #endif

Eek.  Thanks.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH ruby-libvirt] Add a control file for automated builds

[Chris Lalancette]

On 02/10/11 - 06:07:26PM, Daniel P. Berrange wrote:
 * autobuild.sh: Automated build control
 * ruby-libvirt.spec: Add autobuild release tag
 ---
  autobuild.sh  |   29 +
  ruby-libvirt.spec |2 +-
  2 files changed, 30 insertions(+), 1 deletions(-)
  create mode 100755 autobuild.sh

Thanks, I've pushed this.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Support for qemu aio drive option

[Chris Lalancette]

On 01/03/11 - 04:43:06PM, Eric Blake wrote:
 On 05/17/2010 03:31 PM, Eric Blake wrote:
  [adding Matthias on cc]
 
 Reviving an old thread, as it is something I plan on working in the near
 future.
 
  
  On 05/17/2010 03:07 PM, Chris Lalancette wrote:
  On 05/12/2010 11:26 PM, Eric Blake wrote:
  From: Matthias Dahl mdv...@designassembly.de
 
  qemu allows the user to choose what io storage api should be used, either 
  the
  default (threads) or native (linux aio) which in the latter case can 
  result in
  better performance.
 
 
  The implementation looks perfectly reasonable.  I'm just concerned that the
  concept of what we are doing is too qemu specific, though.  Basically, I 
  think
  what we are trying to model here is the concept of an I/O backend 
  implementation,
  correct?  Should we maybe change this to be iobackend type='%s'/, and 
  then
  have available enums like:
 
  aiothreads
  aionative
  ...
 
  That way, for other hypervisors that do something different (like 
  VirtualBox,
  which just has AIO on/off), we can have additional enums to describe their
  behavior.  Even further, if a given hypervisor wanted to do something like
  Direct I/O for the I/O backend (as an example), we could also use this 
  element
  to specify that.  What do you think?
  
  Indeed, having a more-generic attribute type, where only a subset of
  known enum values are appropriate per a given hypervisor, makes sense to
  me.
 
 I'm thinking that the following XML changes make the most sense for this
 (note that the choice of aio mode is per-disk), where the change is the
 addition of the new iobackend element:
 
 domain ...
   devices
 disk type='block' device='disk'
   driver name='qemu' type='qcow2' cache='none'/
   source dev='...'/
   target dev='hda' bus='ide'/
   iobackend type='aiothreads'/
 /disk
   /devices
 /domain
 
 If iobackend is missing, it is the same as type='default'; type can be
 'default' (whatever qemu prefers, which may differ over qemu versions),
 'aiothreads' (use ,aio=threads in qemu -drive argument), or 'aionative'
 (use ,aio=native in qemu -drive argument); where we can add other types
 later if needed.
 
 Does this deserve a new iobackend element, or should it merely be a
 new optional attribute of the existing driver element, as in:
 
 driver name='qemu' type='qcow2' cache='none' iobackend='aiothreads'/

I slightly prefer making it a new attribute of driver.  The only reason I
can see to make it a new iobackend element is if we think it will get
significantly more complex in the future (necessitating new XML elements).  Do
we think that?

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] hypervisor feature - hardware assisted paging

[Chris Lalancette]

On 01/04/11 - 10:41:07AM, Jim Fehlig wrote:
 I'm looking into a bug where a libvirt-created xen HVM guest boots
 *very* slowly on an EPT-enabled machine, particularly when the guest has
 a dedicated PCI device.
 
 xen-unstable c/s 16931 [1] introduced a per-guest HAP (hardware assisted
 paging) setting.  Unfortunately, the sane default of hap=1 is done by xm
 client tool instead of xend, so an HVM guest created with xm tool
 (hap=1) boots as expected but takes much longer when created through
 libvirt (hap=0).
 
 Should libvirt expose this feature in domain XML?  Should it be possible
 to enable/disable hardware assisted paging on a per-guest level with
 libvirt?  If so, where does such a setting belong?  It seems analogous
 to enabling/disabling PAE and as such belongs under hypervisor
 features.  On IRC, Eric suggested it might fall under memoryBacking like
 huge page support in KVM.
 
 If folks feel this setting should not be exposed, it could be
 unconditionally set in the xen driver for HVM guests, similar to the way
 usb setting is currently handled (see attached patch).  Note that the
 xen domain builder will ignore this setting on hardware without the feature.

My personal feeling is that this is something we should expose.  It is useful
for testing sometimes, so I think that we could expose it under the hypervisor
features with apic, acpi, etc like you suggest.

However, I would caution you to beware adding the hap flag unconditionally.
Especially on older Xen distributions (I'm thinking something like RHEL-5),
sending a hap value that xend does not understand may cause domain creation to
fail.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] error: avoid API breakage with vmware

[Chris Lalancette]

;
 +break;
 +case VIR_WAR_NO_SECRET:
 +if (thiscall-err.domain == VIR_FROM_QEMU)
 +thiscall-err.code = VIR_ERR_OPERATION_TIMEOUT;
 +break;
 +case VIR_ERR_INVALID_SECRET:
 +if (thiscall-err.domain == VIR_FROM_XEN)
 +thiscall-err.code = VIR_ERR_MIGRATE_PERSIST_FAILED;
 +break;
 +default:
 +/* Nothing to alter. */
 +break;
 +}
 +
  /* See if caller asked us to keep quiet about missing RPCs
   * eg for interop with older servers */
  if (flags  REMOTE_CALL_QUIET_MISSING_RPC 

Clever.  Make sure it is of the right domain, and if not, you know you are
talking to an older server.  At first I thought it was confusing, but this
will do the right thing in *almost* all situations, so I like it.

ACK to this; as DV says, maybe we can make a make check or
make syntax-check to automatically catch it in the future, but this at least
fixes the current breakage.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] API break from the VMware player driver

[Chris Lalancette]

All,
 I'll preface this by saying that I'm not 100% sure I'm correct.  But I
still think there may be an API break that was introduced with the VMware
player driver.  In include/libvirt/virterror.h, VIR_FROM_VMWARE was added to
the *middle* of the enum for virErrorDomain.  If any clients of libvirt happen
to be using hardcoded numbers, then they will now have the wrong number for
everything after VIR_FROM_VMWARE.

Looking back through the history of virErrorDomain, it doesn't seem like this
is the first time this has happened.  What's the thinking with virErrorDomain?
Part of the API, or up to the clients to properly use the named enums?

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] ANNOUNCE: ruby-libvirt bindings 0.3.0

[Chris Lalancette]

All,
 I'm pleased to announce the release of 0.3.0 of the ruby-libvirt bindings.
This release has a number of updates:

 * Implementation of Libvirt::open_auth, Libvirt::event_register_impl
 * Updated Connect class, implementing conn.compare_cpu, conn.baseline_cpu,
   conn.domain_event_register_any, conn.domain_event_deregister_any,
   conn.domain_event_register, conn.domain_event_deregister, and
   conn.create_domain_xml.
 * Updated Domain class, implementing dom.get_vcpus, dom.update_device,
   dom.scheduler_type, dom.scheduler_parameters, dom.scheduler_parameters=,
   dom.num_vcpus, dom.vcpus_flags=, and dom.qemu_monitor_command.
 * Updated Interface class, implementing interface.free
 * Many potential memory leaks have been fixed.
 * Many bugfixes.
 * Documentation update of many methods, including all of the lookup methods
   that were missing before.

With the above list, almost all of the APIs up to and including libvirt 0.8.6
are covered.  There are a few that I have not yet had time to implement; you
can look at the list in the README file in the source tree to see which ones
are missing.

The tarballs and source RPMs are here: http://libvirt.org/ruby/download/
The git repository is here: http://libvirt.org/git/?p=ruby-libvirt.git;a=summary
The documentation for all of the APIs are here: 
http://libvirt.org/ruby/api/index.html
I've uploaded some examples on how to use the bindings:
http://libvirt.org/ruby/documentation.html
I've also pushed a new gem to rubygems.org; you should be able to use
'gem install ruby-libvirt' (if you haven't installed them before) or
'gem update ruby-libvirt' (if you have them installed already).

If you have time, and are interested in the bindings, please give these new
ones a whirl and let me know if they work for you.  Note that release 0.3.0
is intended to be fully backwards compatible with release 0.2.0 and 0.1.0.
If you find that they are not, or find any other problems with the ruby
bindings, please report it to the libvirt development mailing list
(and CC me) so that I can take a look at them.

Thanks,
-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Mac OS X and ruby-libvirt

[Chris Lalancette]

On 11/24/10 - 05:31:41PM, Jaromír Červenka wrote:
 Hello,
 
 I've just compiled libvirt 0.8.5 on my Mac OS X 10.6.5 and it looks
 fine - virish works (also for remote connection: qemu+tcp). I would
 like to install ruby-libvirt gem, but I get this error:
 http://paste.opensuse.org/10756697
 
 Could anybody help me, please? I think that it is necessary point to
 source of libvirt, because ruby-libvirt tries to compile gem for my
 system. But I don't know how to do that.

Sorry for the delay.  At the moment, there isn't a great way to do this.  What
you'll have to do is edit ext/libvirt/extconf.rb, and replace all instances
of libvirt/libvirt.h with the full path to your development headers.  You
might still have some issues finding the library to link against, so you might
also have to diddle with pkg_config to point it at your development directory
again.

Unfortunately I'm having some trouble getting my development setup working at
the moment, so I can't test it out at the moment.  If you do figure out how to
do it, I would appreciate knowing so that I can either make it easier to do
and/or document it on the website.

Thanks,
-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] ruby-libvirt issue

[Chris Lalancette]

On 11/21/10 - 11:25:09PM, Pawel Krzesniak wrote:
 On 29.07.2010 20:32, Chris Lalancette wrote:
 Ah, OK. So then the question becomes whether the problem is in the ruby
 bindings not releasing the object in certain circumstances, or in rails
 holding onto the object too long.  Unfortunately I'm not really that familiar
 with rails or passenger, so I'm not entirely sure how to figure out where the
 problem is.
 
 I'll see if I can do a bit of testing and look at object lifetimes from the
 point-of-view of ruby-libvirt to try and eliminate that from the equation.
 
 following testcase confirms that problem is in bindings itself:

OK, I see what the problem is.  I'm not entirely sure if it is actually a
problem in the bindings, but the behavior is a bit surprising in a
garbage-collected language.  See below.

 ree-1.8.7-2010.02  require 'libvirt'
  = true
 ree-1.8.7-2010.02puts `netstat -na|grep -v LISTENING |grep -c
 libvirt-sock`
 0
  = nil
 ree-1.8.7-2010.02  c = Libvirt::open 'qemu:///system'
  = #Libvirt::Connect:0x265b718
 ree-1.8.7-2010.02  puts `netstat -na|grep -v LISTENING |grep -c
 libvirt-sock`
 1

After this point, we have a single connection.

  = nil
 ree-1.8.7-2010.02  d = c.lookup_domain_by_name 'abc'
  = #Libvirt::Domain:0x2705128
 ree-1.8.7-2010.02  puts `netstat -na|grep -v LISTENING |grep -c
 libvirt-sock`
 1

Still the same connection.

  = nil
 ree-1.8.7-2010.02  c.close

Here's where the problem is.  Because you are doing c.close before cleaning up
the domain object, the libvirt library keeps a connection open.  If you do
either:

d = nil
GC.start

or

d.free

before the c.close, then everything would be cleaned up correctly.

In terms of making this automatically happen during connection closing, I'm
not entirely sure what we can (and should) do.  I guess we could keep some sort
of list of objects that depend on this connection object, and then during
connection close  free them all up.  Does anyone know how the python bindings
handle this?

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 0/6] Fix state driver hotplug semantics

[Chris Lalancette]

On 11/22/10 - 04:35:28PM, Cole Robinson wrote:
 Currently, domain hotplug operations in the state drivers (QEMU, LXC, ...)
 have strange semantics: a hotplug config change will stick around in memory
 until the domain is either redefined or libvirtd is restarted.
 
 This series fixes hotplug config changes to be discarded when the VM is
 stopped, which AFAICT is the expected behavior. A few bugs with setvcpus
 implementations are also addressed.

By the way, this sort of assumption/behavior is exactly the type of thing
we should be documenting for people.  Justin, care to document this somewhere?

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] arbitrary qemu command feature

[Chris Lalancette]

On 11/20/10 - 02:17:50PM, Bruce Hohl wrote:
 Hello List, I had a problem with the recently added qemu command
 feature (no one on user list could help):
 
 This feature:
 http://libvirt.org/news.html
 0.8.3: Aug 4 2010
 Improvements:
 Handle arbitrary qemu command-lines in qemuParseCommandLine.
 Qemu arbitrary command-line arguments.
 
 Also described here:
 http://www.spinics.net/linux/fedora/libvir/msg26687.html
 [PATCH v4 0/8]: Add arbitrary qemu command-line and monitor commands
 
 I am using the following libvirt 0.8.3 packages from unbuntu 10.10:
 libvirt-bin 0.8.3-1ubuntu14
 libvirt0 0.8.3-1ubuntu14
 python-libvirt 0.8.3-1ubuntu14
 
 Example of problem: $ virsh edit my.xml refuses to add / will not
 save the following to a domain (for this domain graphics type='sdl')
 using the specified format:
 
 qemu:commandline
   qemu:arg value='-ctrl-grab'/
 /qemu:commandline
 
 If I edit and save the xml directly the change is not recognized upon
 start-up of the domain.  That is, I must use ctrl+alt instead of the
 right ctrl for mouse capture.
 
 Am I missing a library or package needed? Am I using this feature
 correctly? Is there a working example or additional documentation
 somewhere? Any suggestions?

Yes, you are using it incorrectly.  Because this is being done as an XML
namespace, besides adding the XML elements that you want, you also need to
add the namespace to the top of the XML:

domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'
  ...
  qemu:commandline
qemu:arg value='-ctrl-grab'/
  /qemu:commandline
/domain

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Introduce yet another migration version in API.

[Chris Lalancette]

On 11/02/10 - 01:08:53PM, Daniel P. Berrange wrote:
 This patch attempts to introduce a version 3 that uses the
 improved 5 step sequence
 
  *  Src: Begin
   - Generate XML to pass to dst
   - Generate optional cookie to pass to dst
 
  *  Dst: Prepare
   - Get ready to accept incoming VM
   - Generate optional cookie to pass to src
 
  *  Src: Perform
   - Start migration and wait for send completion
   - Generate optional cookie to pass to dst
 
  *  Dst: Finish
   - Wait for recv completion and check status
   - Kill off VM if failed, resume if success
   - Generate optional cookie to pass to src
 
  *  Src: Confirm
   - Kill off VM if success, resume if failed
 
 The API is designed to allow both input and output cookies
 in all methods where applicable. This lets us pass around
 arbitrary extra driver specific data between src  dst during
 migration. Combined with the extra 'Begin' method this lets
 us pass lease information from source to dst at the start of
 migration
 
 Moving the killing of the source VM out of Perform and
 into Confirm, means we can now recover if the dst host
 can't successfully Finish receiving migration data.

Yeah, this seems like a pretty good sequence.  Like mentioned below, if the
last step fails, there isn't a whole lot we can do, except make sure to report
it and let management kill it off.  One comment inline...

snip

 diff --git a/src/libvirt.c b/src/libvirt.c
 index e24fb9e..04a7cd0 100644
 --- a/src/libvirt.c
 +++ b/src/libvirt.c
...
 +/*
 + * Sequence v3:
 + *
 + *  Src: Begin
 + *- Generate XML to pass to dst
 + *- Generate optional cookie to pass to dst
 + *
 + *  Dst: Prepare
 + *- Get ready to accept incoming VM
 + *- Generate optional cookie to pass to src
 + *
 + *  Src: Perform
 + *- Start migration and wait for send completion
 + *- Generate optional cookie to pass to dst
 + *
 + *  Dst: Finish
 + *- Wait for recv completion and check status
 + *- Kill off VM if failed, resume if success
 + *- Generate optional cookie to pass to src
 + *
 + *  Src: Confirm
 + *- Kill off VM if success, resume if failed
 + *
 + */
 +static virDomainPtr
 +virDomainMigrateVersion3 (virDomainPtr domain,
 +  virConnectPtr dconn,
 +  unsigned long flags,
 +  const char *dname,
 +  const char *uri,
 +  unsigned long bandwidth)
 +{
 +virDomainPtr ddomain = NULL;
 +char *uri_out = NULL;
 +char *cookiesrc = NULL;
 +char *cookiedst = NULL;
 +char *dom_xml = NULL;
 +int cookiesrclen = 0;
 +int cookiedstlen = 0;
 +int ret;
 +virDomainInfo info;
 +virErrorPtr orig_err = NULL;
 +
 +if (!domain-conn-driver-domainMigrateBegin3) {
 +virLibConnError (domain-conn, VIR_ERR_INTERNAL_ERROR, __FUNCTION__);
 +virDispatchError(domain-conn);
 +return NULL;
 +}
 +dom_xml = domain-conn-driver-domainMigrateBegin3
 +(domain-conn, cookiesrc, cookiesrclen, uri, flags, dname,
 + bandwidth);
 +if (!dom_xml)
 +goto done;
 +
 +ret = virDomainGetInfo (domain, info);
 +if (ret == 0  info.state == VIR_DOMAIN_PAUSED) {
 +flags |= VIR_MIGRATE_PAUSED;
 +}
 +
 +ret = dconn-driver-domainMigratePrepare3
 +(dconn, cookiesrc, cookiesrclen, cookiedst, cookiedstlen,
 + uri, uri_out, flags, dname, bandwidth, dom_xml);
 +VIR_FREE (dom_xml);
 +if (ret == -1)
 +goto done;
 +
 +if (uri == NULL  uri_out == NULL) {
 +virLibConnError (domain-conn, VIR_ERR_INTERNAL_ERROR,
 + _(domainMigratePrepare2 did not set uri));
 +virDispatchError(domain-conn);
 +goto done;
 +}
 +if (uri_out)
 +uri = uri_out; /* Did domainMigratePrepare2 change URI? */
 +assert (uri != NULL);

I think we should get rid of this whole uri_out concept, while we are
adding a new protocol.  Basically, it allows the destination to tell the
source where to migrate to, but there is no way to really discover that.  What
you really need are:

1)  The ability to let the user specify which network should be used for
migration.
2)  The ability to determine the default network, in the absence of 1).

We already get 1) from the passed in uri, if it is specified.  We can easily
figure out 2) from the source, since we know we can reach the destination via
dconn.  So if nothing is specified for 1), we can just default to the same
network that the libvirt transport is using.

This will eliminate a lot of the headaches we have with migration protocol
version 2 with trying to determine the hostname on the destination side.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] Implement virsh qemu-monitor-command.

[Chris Lalancette]

Now that the virsh parsing has been revamped, we can
implement qemu-monitor-command.  This is basically the same
as it was in previous iterations, but has now been tested to
work both with the plain text monitor and the QMP monitor.

Signed-off-by: Chris Lalancette clala...@redhat.com
---
 tools/Makefile.am |1 +
 tools/virsh.c |   55 +
 tools/virsh.pod   |   16 +++
 3 files changed, 72 insertions(+), 0 deletions(-)

diff --git a/tools/Makefile.am b/tools/Makefile.am
index bfe4455..f83da42 100644
--- a/tools/Makefile.am
+++ b/tools/Makefile.am
@@ -45,6 +45,7 @@ virsh_LDADD = 
\
$(STATIC_BINARIES)  \
$(WARN_CFLAGS)  \
../src/libvirt.la   \
+   ../src/libvirt-qemu.la  \
../gnulib/lib/libgnu.la \
$(VIRSH_LIBS)
 virsh_CFLAGS = \
diff --git a/tools/virsh.c b/tools/virsh.c
index b485eff..e704799 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -50,6 +50,7 @@
 #include util.h
 #include memory.h
 #include xml.h
+#include libvirt/libvirt-qemu.h
 
 static char *progname;
 
@@ -9808,6 +9809,58 @@ cleanup:
 }
 
 /*
+ * qemu-monitor-command command
+ */
+static const vshCmdInfo info_qemu_monitor_command[] = {
+{help, N_(Qemu Monitor Command)},
+{desc, N_(Qemu Monitor Command)},
+{NULL, NULL}
+};
+
+static const vshCmdOptDef opts_qemu_monitor_command[] = {
+{domain, VSH_OT_DATA, VSH_OFLAG_REQ, N_(domain name, id or uuid)},
+{cmd, VSH_OT_DATA, VSH_OFLAG_REQ, N_(command)},
+{NULL, 0, 0, NULL}
+};
+
+static int
+cmdQemuMonitorCommand(vshControl *ctl, const vshCmd *cmd)
+{
+virDomainPtr dom = NULL;
+int ret = FALSE;
+char *monitor_cmd;
+char *result = NULL;
+
+if (!vshConnectionUsability(ctl, ctl-conn))
+goto cleanup;
+
+dom = vshCommandOptDomain(ctl, cmd, NULL);
+if (dom == NULL)
+goto cleanup;
+
+monitor_cmd = vshCommandOptString(cmd, cmd, NULL);
+if (monitor_cmd == NULL) {
+vshError(ctl, %s, _(missing monitor command));
+goto cleanup;
+}
+
+if (virDomainQemuMonitorCommand(dom, monitor_cmd, result, 0)  0)
+goto cleanup;
+
+printf(%s\n, result);
+
+ret = TRUE;
+
+cleanup:
+VIR_FREE(result);
+if (dom)
+virDomainFree(dom);
+
+return ret;
+}
+
+
+/*
  * Commands
  */
 static const vshCmdDef commands[] = {
@@ -9976,6 +10029,8 @@ static const vshCmdDef commands[] = {
 {snapshot-list, cmdSnapshotList, opts_snapshot_list, info_snapshot_list},
 {snapshot-revert, cmdDomainSnapshotRevert, opts_snapshot_revert, 
info_snapshot_revert},
 
+{qemu-monitor-command, cmdQemuMonitorCommand, opts_qemu_monitor_command, 
info_qemu_monitor_command},
+
 {NULL, NULL, NULL, NULL}
 };
 
diff --git a/tools/virsh.pod b/tools/virsh.pod
index 5932aaa..ec57f2b 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -1138,6 +1138,22 @@ variables, and defaults to Cvi.
 
 =back
 
+=head1 QEMU-SPECIFIC COMMANDS
+
+NOTE: Use of the following commands is Bstrongly discouraged.  They
+can cause libvirt to become confused and do the wrong thing on subsequent
+operations.  Once you have used this command, please do not report
+problems to the libvirt developers; the reports will be ignored.
+
+=over 4
+
+=item Bqemu-monitor-command Idomain Icommand
+
+Send an arbitrary monitor command Icommand to domain Idomain through the
+qemu monitor.  The results of the command will be printed on stdout.
+
+=back
+
 =head1 ENVIRONMENT
 
 The following environment variables can be set to alter the behaviour
-- 
1.7.3.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH V2] virsh: rework command parsing

[Chris Lalancette]

On 11/05/10 - 05:20:02PM, Lai Jiangshan wrote:
 Hi, Chris
 
 The V3 patchset(virsh: rework command parsing) was sent and accepted,
 I'm sorry that I forgot to CC you.
 
 Could you resend your qemu-monitor-command patch? We need it,
 and I will review and test it.

Thanks for reminding me.  I've just sent the updated patch to the list.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] Update ruby-libvirt gem on rubygems.org

[Chris Lalancette]

All,
 I know it has been a long time, but I was finally able to get push access
to the rubygems.org ruby-libvirt gem.  I have now pushed ruby-libvirt-0.2.0
to rubygems.org, so installing it should be as simple as:

gem install ruby-libvirt

Please let me know if you have problems with this package, and I will be happy
to help.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Implement virsh qemu-monitor-command.

[Chris Lalancette]

On 11/05/10 - 04:52:58PM, Daniel Veillard wrote:
 On Fri, Nov 05, 2010 at 10:29:06AM -0400, Chris Lalancette wrote:
  Now that the virsh parsing has been revamped, we can
  implement qemu-monitor-command.  This is basically the same
  as it was in previous iterations, but has now been tested to
  work both with the plain text monitor and the QMP monitor.
 
   Ah cool, we should have done that for previous release :-)
 
 [...]
  +=head1 QEMU-SPECIFIC COMMANDS
  +
  +NOTE: Use of the following commands is Bstrongly discouraged.  They
  +can cause libvirt to become confused and do the wrong thing on subsequent
  +operations.  Once you have used this command, please do not report
  +problems to the libvirt developers; the reports will be ignored.
 
   Heh, that's stong wording, but we probably need to safeguard ourselves
 
  +=over 4
  +
  +=item Bqemu-monitor-command Idomain Icommand
  +
  +Send an arbitrary monitor command Icommand to domain Idomain through 
  the
  +qemu monitor.  The results of the command will be printed on stdout.
  +
  +=back
  +
   =head1 ENVIRONMENT
   
   The following environment variables can be set to alter the behaviour
 
   ACK,

Thanks, I pushed this as-is.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH V2] virsh: rework command parsing

[Chris Lalancette]

On 09/16/10 - 05:36:11PM, Lai Jiangshan wrote:
 
 Old virsh command parsing mashes all the args back into a string and
 miss the quotes, this patch fixes it. It is also needed for introducing
 qemu-monitor-command which is very useful.
 
 This patch split the command-parsing into 2 phrases:
 1) parse command string and make it into args, argv style arguments.
 2) parse args, argv style arguments and make it into vshCmd structure.

This is some nice work, and indeed does seem to fix the behavior for
qemu-monitor-command.  I have a few comments inline.

snip

 --- libvirt-0.8.4.old/tools/virsh.c   2010-09-10 20:47:06.0 +0800
 +++ libvirt-0.8.4/tools/virsh.c   2010-09-16 17:13:55.0 +0800
...
 @@ -10257,130 +10333,42 @@ vshCommandParse(vshControl *ctl, char *c
  
  str = cmdstr;
  while (str  *str) {
 -vshCmdOpt *last = NULL;
 -const vshCmdDef *cmd = NULL;
 -int tk = VSH_TK_NONE;
 -int data_ct = 0;
 -
 -first = NULL;
 -
 -while (tk != VSH_TK_END) {
 -char *end = NULL;
 -const vshCmdOptDef *opt = NULL;
 -
 -tkdata = NULL;
 -
 -/* get token */
 -tk = vshCommandGetToken(ctl, str, end, tkdata);
 -
 -str = end;
 -
 -if (tk == VSH_TK_END) {
 -VIR_FREE(tkdata);
 -break;
 -}
 -if (tk == VSH_TK_ERROR)
 +vshCmd *c;
 +int args = 0;
 +char *argv[20];

Why argv[20] here?  It seems like an arbitrary number, and the check below
seems like an arbitrary check.  Can we just make this unlimited and allocate
memory as needed?

 +char *arg;
 +int last_arg = 0;
 +
 +while ((arg = vshCmdStrGetArg(ctl, str, str, last_arg)) != NULL) {
 +if (args == sizeof(argv) / sizeof(argv[0])) {
 +vshError(ctl, _(too many args));
  goto syntaxError;
 -

snip

 @@ -10939,7 +10927,8 @@ static void
  vshUsage(void)
  {
  const vshCmdDef *cmd;
 -fprintf(stdout, _(\n%s [options] [commands]\n\n
 +fprintf(stdout, _(\n%s [options]... [command_name args...]
 +  \n%s [options]... command_string\n\n
  options:\n
-c | --connect urihypervisor connection 
 URI\n
-r | --readonly connect readonly\n
 @@ -10949,7 +10938,7 @@ vshUsage(void)
-t | --timing   print timing 
 information\n
-l | --log file   output logging to file\n
-v | --version  program version\n\n
 -commands (non interactive mode):\n), progname);
 +commands (non interactive mode):\n), progname, 
 progname);
  
  for (cmd = commands; cmd-name; cmd++)
  fprintf(stdout,
 @@ -11069,25 +11058,25 @@ vshParseArgv(vshControl *ctl, int argc, 

Very minor note, but I think you should be able to remove the forward prototype
of vshParseArgv at the top of virsh.c.

  
  if (argc  end) {
  /* parse command */
 -char *cmdstr;
 -int sz = 0, ret;
 +int ret = TRUE;
  
  ctl-imode = FALSE;
  
 -for (i = end; i  argc; i++)
 -sz += strlen(argv[i]) + 1;  /* +1 is for blank space between 
 items */
 -
 -cmdstr = vshCalloc(ctl, sz + 1, 1);
 -
 -for (i = end; i  argc; i++) {
 -strncat(cmdstr, argv[i], sz);
 -sz -= strlen(argv[i]);
 -strncat(cmdstr,  , sz--);
 +if (argc - end == 1) {
 +char *cmdstr = vshStrdup(ctl, argv[end]);
 +vshDebug(ctl, 2, commands: \%s\\n, cmdstr);
 +ret = vshCommandParse(ctl, cmdstr);
 +VIR_FREE(cmdstr);
 +} else {
 +if (ctl-cmd) {
 +vshCommandFree(ctl-cmd);
 +ctl-cmd = NULL;
 +}

I don't think you need to free up ctl-cmd here.  From what I can tell
vshParseArgv can only be called during virsh startup, so there should never
be a previous command.

Other than that, it looks pretty good.  I did some basic testing of it with
my qemu-monitor-command patch, and things seemed to work pretty well with it.
The code is still a bit more complicated than I would like, but given what it
has to do that is probably unavoidable.  Once you've made the changes I
suggested above (or tell me why they aren't needed), I would be happy to ACK
this.

Thanks!
-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Question, how to use virDomainQemuMonitorCommand()

[Chris Lalancette]

On 09/09/10 - 04:52:25PM, Lai Jiangshan wrote:
 On 09/07/2010 09:22 PM, Chris Lalancette wrote:
  On 09/07/10 - 04:08:13PM, Lai Jiangshan wrote:
  Hi, Chris,
 
  I saw virDomainQemuMonitorCommand() in libvirt-qemu.c,
  I think it will help me to send arbitrary qemu-monitor command to
  qemu via libvirtd.
 
  But how can I use virDomainQemuMonitorCommand()?
  Can I use it by just using current tools(virsh or other) without writing 
  any code?
  
  Unfortunately, no.  There is a bug in the current virsh command that 
  prevents
  it from properly parsing the command-lines necessary to send monitor 
  commands
  to the qemu monitor.  Until we fix that bug, we won't push the support into
  virsh.
  
 
 Thanks,
 
 We need this feature, could you tell me the detail of the bug,
 we will try to fix it or do assists.

I've outlined it before on this list, but the gist of it is that the way that
virsh parses command-line arguments loses the formatting.  Thus, if you were
enter a command like:

# virsh qemu-monitor-command f13guest info cpus

Then virsh main() will get 4 arguments:

argv[0] = virsh;
argv[1] = qemu-monitor-command;
argv[2] = f13guest;
argv[3] = info cpus;

So far, all is good.  However, during the parsing of these command-line
arguments, virsh takes all of these arguments and smashes them back together
as a single string:

command = virsh qemu-monitor-command f13guest info cpus;

And then it reparses the whole thing.  Notice that we've lost the quoting,
though, so now it's an invalid command.

The problem is further complicated by some of the other features of virsh,
including the support for separating multiple commands with semicolons.  For
example, the following is a legal command:

# virsh 'define D.xml; dumpxml D'

In any case, the answer is probably to re-write the command-line parsing of
virsh to not lose quoting.  I have not had time to do this, so if you have
the time to look at it and make it work, patches are definitely appreciated!

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Question, how to use virDomainQemuMonitorCommand()

[Chris Lalancette]

On 09/07/10 - 04:08:13PM, Lai Jiangshan wrote:
 Hi, Chris,
 
 I saw virDomainQemuMonitorCommand() in libvirt-qemu.c,
 I think it will help me to send arbitrary qemu-monitor command to
 qemu via libvirtd.
 
 But how can I use virDomainQemuMonitorCommand()?
 Can I use it by just using current tools(virsh or other) without writing any 
 code?

Unfortunately, no.  There is a bug in the current virsh command that prevents
it from properly parsing the command-lines necessary to send monitor commands
to the qemu monitor.  Until we fix that bug, we won't push the support into
virsh.

For that reason you will need to write a custom program to call
virDomainQemuMonitorCommand as appropriate.  The absolute easiest program you
can write looks something like (untested):

#include stdio.h
#include stdlib.h
#include libvirt/libvirt.h

int main()
{
virConnectPtr conn;
virDomainPtr dom;
char *reply;

conn = virConnectOpen(NULL);
dom = virDomainLookupByName(conn, mydomain);

virDomainQemuMonitorCommand(dom, info cpus, reply, 0);
fprintf(stderr, Reply: %s\n, reply);
free(reply);
virConnectClose(conn);

return 0;
}

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] ruby-libvirt / rubygems

[Chris Lalancette]

On 09/03/10 - 09:23:48PM, Roland Moriz wrote:
 Hello Chris,
 
 could you publish the updated ruby-libvirt bindings to rubygems.org?
 There is still only version 0.1.0 of 2008 available:
 
 http://rubygems.org/gems/ruby-libvirt
 
 Thank you!

Hello,
 I'd be happy to update the gem on rubygems.org.  Unfortunately I don't
have permission to do so, so I can't right at the moment.  I've written to
the previous maintainer of ruby-libvirt to see if he can give me access to
update the gems there.  As soon as I get that access, I'll push a new version
of the gem and let you know.

Thanks,
-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 2/3] Managed save compression flags.

[Chris Lalancette]

On 08/13/10 - 04:06:24PM, Daniel P. Berrange wrote:
 On Fri, Aug 13, 2010 at 10:53:48AM -0400, Chris Lalancette wrote:
  Add in the ability to specify compression flags from the
  managed save API.  We map these to the supported QEMU
  compression flags internally.
 
 I'm not really convinced we need todo this. I think the host
 level setting in /etc/libvirt/qemu.conf is sufficient already.

Don't get me wrong, I don't think this is a killer feature.  But when I
initially implemented compression, I definitely would have done it through
the API if we had had a flags parameter available for virDomainSave().  Now
that we have a ManagedSave that does have a flags parameter, I figured we do
it the right way.  I think it's a little cleaner, and more intuitive, to do
it through the API, and it makes the feature available to hypervisors other
than qemu.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 1/3] Fix up qemu domain save/managed save locking.

[Chris Lalancette]

On 08/16/10 - 10:17:09AM, Eric Blake wrote:
 On 08/13/2010 08:53 AM, Chris Lalancette wrote:
  The current version of the qemu managed save implementation
  is subject to a race where the domain shuts down between
  the time that we start the command and the time that we
  actually try to do the save.  Close this race by making
  qemuDomainSaveFlags() expect both the driver and the passed-in
  vm object to be locked before executing.
  
  Signed-off-by: Chris Lalancette clala...@redhat.com
  ---
   src/qemu/qemu_driver.c |   79 
  ++-
   1 files changed, 30 insertions(+), 49 deletions(-)
 
 ACK.

Thanks, I've pushed this one.  I'll wait on the other two until we finish
disucssing.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Move the tunnelled migration unix socket to /var/lib/libvirt/qemu

[Chris Lalancette]

On 08/12/10 - 01:55:28PM, Eric Blake wrote:
 On 08/12/2010 10:57 AM, Chris Lalancette wrote:
  Since the qemu process is running as qemu:qemu, it can't actually
  look at the unix socket in /var/run/libvirt/qemu which is owned by
  root and has permission 700.  Move the unix socket to
  /var/lib/libvirt/qemu, which is already owned by qemu:qemu.
  
  Thanks to Justin Clift for test this out for me.
  
  Signed-off-by: Chris Lalancette clala...@redhat.com
  ---
   src/qemu/qemu_driver.c |4 ++--
   1 files changed, 2 insertions(+), 2 deletions(-)
  
  diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
  index b6b6633..007b09a 100644
  --- a/src/qemu/qemu_driver.c
  +++ b/src/qemu/qemu_driver.c
  @@ -10470,7 +10470,7 @@ qemudDomainMigratePrepareTunnel(virConnectPtr dconn,
   vm-def-id = -1;
   
   if (virAsprintf(unixfile, %s/qemu.tunnelmigrate.dest.%s,
  -driver-stateDir, vm-def-name)  0) {
  +driver-libDir, vm-def-name)  0) {
 
 ACK.

Thanks, pushed.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Fix tunnelled migration with qemu running as qemu:qemu.

[Chris Lalancette]

On 08/12/10 - 01:54:18PM, Eric Blake wrote:
 On 08/12/2010 08:25 AM, Chris Lalancette wrote:
  The problem is that on the source of the migration, libvirtd
  is responsible for creating the unix socket over which the data
  will flow.  Since libvirtd is running as root, this file will
  be created as root.  When the qemu process running as qemu:qemu
  goes to access the unix file to write data to it, it will get
  permission denied and fail.  Make sure to change the owner
  of the unix file to qemu:qemu.
  
  Thanks to Justin Clift for testing this patch out for me.
  
  Signed-off-by: Chris Lalancette clala...@redhat.com
  ---
   src/qemu/qemu_driver.c |7 +++
   1 files changed, 7 insertions(+), 0 deletions(-)
  
  diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
  index 3dfd1ae..b6b6633 100644
  --- a/src/qemu/qemu_driver.c
  +++ b/src/qemu/qemu_driver.c
  @@ -10975,6 +10975,13 @@ static int doTunnelMigrate(virDomainPtr dom,
   goto cleanup;
   }
   
  +if (chown(unixfile, qemu_driver-user, qemu_driver-group)  0) {
  +virReportSystemError(errno,
  + _(Cannot change unix socket '%s' owner),
  + unixfile);
  +goto cleanup;
  +}
 
 ACK.

Thanks, pushed.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 0/3] Managed save updates

[Chris Lalancette]

A couple of updates to the managed save code in qemu.  Details
are in the individual patches.

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 3/3] Plumb managedsave compression through to virsh.

[Chris Lalancette]

Signed-off-by: Chris Lalancette clala...@redhat.com
---
 tools/virsh.c |   22 +-
 1 files changed, 21 insertions(+), 1 deletions(-)

diff --git a/tools/virsh.c b/tools/virsh.c
index 352d44a..5e97293 100644
--- a/tools/virsh.c
+++ b/tools/virsh.c
@@ -1404,6 +1404,7 @@ static const vshCmdInfo info_managedsave[] = {
 };
 
 static const vshCmdOptDef opts_managedsave[] = {
+{compression, VSH_OT_STRING, 0, N_(compress save image)},
 {domain, VSH_OT_DATA, VSH_OFLAG_REQ, N_(domain name, id or uuid)},
 {NULL, 0, 0, NULL}
 };
@@ -1414,14 +1415,33 @@ cmdManagedSave(vshControl *ctl, const vshCmd *cmd)
 virDomainPtr dom;
 char *name;
 int ret = TRUE;
+char *compress = NULL;
+unsigned int flags = 0;
 
 if (!vshConnectionUsability(ctl, ctl-conn))
 return FALSE;
 
+compress = vshCommandOptString(cmd, compression, NULL);
+if (compress) {
+if (STREQ(compress, gzip))
+flags |= VIR_DOMAIN_SAVE_COMPRESS_GZIP;
+else if (STREQ(compress, bzip2))
+flags |= VIR_DOMAIN_SAVE_COMPRESS_BZIP2;
+else if (STREQ(compress, xz))
+flags |= VIR_DOMAIN_SAVE_COMPRESS_XZ;
+else if (STREQ(compress, lzop))
+flags |= VIR_DOMAIN_SAVE_COMPRESS_LZOP;
+else {
+vshError(ctl, %s,
+ _(Invalid compression type; it must be one of 'gzip', 
'bzip2', 'xz', or 'lzop'));
+return FALSE;
+}
+}
+
 if (!(dom = vshCommandOptDomain(ctl, cmd, name)))
 return FALSE;
 
-if (virDomainManagedSave(dom, 0) == 0) {
+if (virDomainManagedSave(dom, flags) == 0) {
 vshPrint(ctl, _(Domain %s state saved by libvirt\n), name);
 } else {
 vshError(ctl, _(Failed to save domain %s state), name);
-- 
1.7.2.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH 1/3] Fix up qemu domain save/managed save locking.

[Chris Lalancette]

The current version of the qemu managed save implementation
is subject to a race where the domain shuts down between
the time that we start the command and the time that we
actually try to do the save.  Close this race by making
qemuDomainSaveFlags() expect both the driver and the passed-in
vm object to be locked before executing.

Signed-off-by: Chris Lalancette clala...@redhat.com
---
 src/qemu/qemu_driver.c |   79 ++-
 1 files changed, 30 insertions(+), 49 deletions(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 31cf1fe..b72aace 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -5213,12 +5213,11 @@ endjob:
 return ret;
 }
 
-
-static int qemudDomainSaveFlag(virDomainPtr dom, const char *path,
+/* this internal function expects the driver lock to already be held on entry 
*/
+static int qemudDomainSaveFlag(struct qemud_driver *driver, virDomainPtr dom,
+   virDomainObjPtr vm, const char *path,
int compressed)
 {
-struct qemud_driver *driver = dom-conn-privateData;
-virDomainObjPtr vm = NULL;
 char *xml = NULL;
 struct qemud_save_header header;
 struct fileOpHookData hdata;
@@ -5236,19 +5235,8 @@ static int qemudDomainSaveFlag(virDomainPtr dom, const 
char *path,
 memcpy(header.magic, QEMUD_SAVE_MAGIC, sizeof(header.magic));
 header.version = QEMUD_SAVE_VERSION;
 
-qemuDriverLock(driver);
-
 header.compressed = compressed;
 
-vm = virDomainFindByUUID(driver-domains, dom-uuid);
-
-if (!vm) {
-char uuidstr[VIR_UUID_STRING_BUFLEN];
-virUUIDFormat(dom-uuid, uuidstr);
-qemuReportError(VIR_ERR_NO_DOMAIN,
-_(no domain with matching uuid '%s'), uuidstr);
-goto cleanup;
-}
 priv = vm-privateData;
 
 if (qemuDomainObjBeginJobWithDriver(driver, vm)  0)
@@ -5533,12 +5521,9 @@ cleanup:
 VIR_FREE(xml);
 if (ret != 0  is_reg)
 unlink(path);
-if (vm)
-virDomainObjUnlock(vm);
 if (event)
 qemuDomainEventQueue(driver, event);
 virCgroupFree(cgroup);
-qemuDriverUnlock(driver);
 return ret;
 }
 
@@ -5546,8 +5531,11 @@ static int qemudDomainSave(virDomainPtr dom, const char 
*path)
 {
 struct qemud_driver *driver = dom-conn-privateData;
 int compressed;
+int ret = -1;
+virDomainObjPtr vm = NULL;
+
+qemuDriverLock(driver);
 
-/* Hm, is this safe against qemudReload? */
 if (driver-saveImageFormat == NULL)
 compressed = QEMUD_SAVE_FORMAT_RAW;
 else {
@@ -5560,7 +5548,23 @@ static int qemudDomainSave(virDomainPtr dom, const char 
*path)
 }
 }
 
-return qemudDomainSaveFlag(dom, path, compressed);
+vm = virDomainFindByUUID(driver-domains, dom-uuid);
+if (!vm) {
+char uuidstr[VIR_UUID_STRING_BUFLEN];
+virUUIDFormat(dom-uuid, uuidstr);
+qemuReportError(VIR_ERR_NO_DOMAIN,
+_(no domain with matching uuid '%s'), uuidstr);
+goto cleanup;
+}
+
+ret = qemudDomainSaveFlag(driver, dom, vm, path, compressed);
+
+cleanup:
+if (vm)
+virDomainObjUnlock(vm);
+qemuDriverUnlock(driver);
+
+return ret;
 }
 
 static char *
@@ -5593,48 +5597,25 @@ qemuDomainManagedSave(virDomainPtr dom, unsigned int 
flags)
 virUUIDFormat(dom-uuid, uuidstr);
 qemuReportError(VIR_ERR_NO_DOMAIN,
 _(no domain with matching uuid '%s'), uuidstr);
-goto error;
-}
-
-if (!virDomainObjIsActive(vm)) {
-qemuReportError(VIR_ERR_OPERATION_INVALID,
-%s, _(domain is not running));
-goto error;
+goto cleanup;
 }
 
 name = qemuDomainManagedSavePath(driver, vm);
 if (name == NULL)
-goto error;
+goto cleanup;
 
 VIR_DEBUG(Saving state to %s, name);
 
-/* FIXME: we should take the flags parameter, and use bits out
- * of there to control whether we are compressing or not
- */
 compressed = QEMUD_SAVE_FORMAT_RAW;
-
-/* we have to drop our locks here because qemudDomainSaveFlag is
- * going to pick them back up.  Unfortunately it opens a race window
- * between us dropping and qemudDomainSaveFlag picking it back up, but
- * if we want to allow other operations to be able to happen while
- * qemuDomainSaveFlag is running (possibly for a long time), I'm not
- * sure if there is a better solution
- */
-virDomainObjUnlock(vm);
-qemuDriverUnlock(driver);
-
-ret = qemudDomainSaveFlag(dom, name, compressed);
+ret = qemudDomainSaveFlag(driver, dom, vm, name, compressed);
 
 cleanup:
-VIR_FREE(name);
-
-return ret;
-
-error:
 if (vm)
 virDomainObjUnlock(vm);
 qemuDriverUnlock(driver);
-goto cleanup;
+VIR_FREE(name);
+
+return ret;
 }
 
 static int
-- 
1.7.2.1

--
libvir-list mailing list
libvir-list@redhat.com

[libvirt] [PATCH 2/3] Managed save compression flags.

[Chris Lalancette]

Add in the ability to specify compression flags from the
managed save API.  We map these to the supported QEMU
compression flags internally.

Signed-off-by: Chris Lalancette clala...@redhat.com
---
 include/libvirt/libvirt.h.in |7 +++
 src/qemu/qemu_driver.c   |   25 +++--
 2 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index 2ff484d..e4e7c84 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
@@ -648,6 +648,13 @@ int virDomainRestore
(virConnectPtr conn,
 /*
  * Managed domain save
  */
+typedef enum {
+VIR_DOMAIN_SAVE_COMPRESS_RAW = 0,
+VIR_DOMAIN_SAVE_COMPRESS_GZIP = 1  0,
+VIR_DOMAIN_SAVE_COMPRESS_BZIP2 = 1  1,
+VIR_DOMAIN_SAVE_COMPRESS_XZ = 1  2,
+VIR_DOMAIN_SAVE_COMPRESS_LZOP = 1  3,
+} virDomainSaveCompression;
 intvirDomainManagedSave (virDomainPtr dom,
  unsigned int flags);
 intvirDomainHasManagedSaveImage(virDomainPtr dom,
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index b72aace..637cf28 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -79,6 +79,7 @@
 #include domain_nwfilter.h
 #include hooks.h
 #include storage_file.h
+#include count-one-bits.h
 
 
 #define VIR_FROM_THIS VIR_FROM_QEMU
@@ -5588,7 +5589,28 @@ qemuDomainManagedSave(virDomainPtr dom, unsigned int 
flags)
 int ret = -1;
 int compressed;
 
-virCheckFlags(0, -1);
+if (count_one_bits(flags)  1) {
+qemuReportError(VIR_ERR_OPERATION_INVALID,
+_(Too many compression flags specified 0x%x), flags);
+return -1;
+}
+
+/* this is in lieu of virCheckFlags */
+if (flags == 0)
+compressed = QEMUD_SAVE_FORMAT_RAW;
+else if (flags  VIR_DOMAIN_SAVE_COMPRESS_GZIP)
+compressed = QEMUD_SAVE_FORMAT_GZIP;
+else if (flags  VIR_DOMAIN_SAVE_COMPRESS_BZIP2)
+compressed = QEMUD_SAVE_FORMAT_BZIP2;
+else if (flags  VIR_DOMAIN_SAVE_COMPRESS_XZ)
+compressed = QEMUD_SAVE_FORMAT_XZ;
+else if (flags  VIR_DOMAIN_SAVE_COMPRESS_LZOP)
+compressed = QEMUD_SAVE_FORMAT_LZOP;
+else {
+qemuReportError(VIR_ERR_OPERATION_INVALID,
+_(Invalid compression flags 0x%x), flags);
+return -1;
+}
 
 qemuDriverLock(driver);
 vm = virDomainFindByUUID(driver-domains, dom-uuid);
@@ -5606,7 +5628,6 @@ qemuDomainManagedSave(virDomainPtr dom, unsigned int 
flags)
 
 VIR_DEBUG(Saving state to %s, name);
 
-compressed = QEMUD_SAVE_FORMAT_RAW;
 ret = qemudDomainSaveFlag(driver, dom, vm, name, compressed);
 
 cleanup:
-- 
1.7.2.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] Fix tunnelled migration with qemu running as qemu:qemu.

[Chris Lalancette]

The problem is that on the source of the migration, libvirtd
is responsible for creating the unix socket over which the data
will flow.  Since libvirtd is running as root, this file will
be created as root.  When the qemu process running as qemu:qemu
goes to access the unix file to write data to it, it will get
permission denied and fail.  Make sure to change the owner
of the unix file to qemu:qemu.

Thanks to Justin Clift for testing this patch out for me.

Signed-off-by: Chris Lalancette clala...@redhat.com
---
 src/qemu/qemu_driver.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 3dfd1ae..b6b6633 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -10975,6 +10975,13 @@ static int doTunnelMigrate(virDomainPtr dom,
 goto cleanup;
 }
 
+if (chown(unixfile, qemu_driver-user, qemu_driver-group)  0) {
+virReportSystemError(errno,
+ _(Cannot change unix socket '%s' owner),
+ unixfile);
+goto cleanup;
+}
+
 /* check that this qemu version supports the unix migration */
 if (qemudExtractVersionInfo(vm-def-emulator, NULL, qemuCmdFlags)  0) {
 qemuReportError(VIR_ERR_INTERNAL_ERROR,
-- 
1.7.2.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] Move the tunnelled migration unix socket to /var/lib/libvirt/qemu

[Chris Lalancette]

Since the qemu process is running as qemu:qemu, it can't actually
look at the unix socket in /var/run/libvirt/qemu which is owned by
root and has permission 700.  Move the unix socket to
/var/lib/libvirt/qemu, which is already owned by qemu:qemu.

Thanks to Justin Clift for test this out for me.

Signed-off-by: Chris Lalancette clala...@redhat.com
---
 src/qemu/qemu_driver.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index b6b6633..007b09a 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -10470,7 +10470,7 @@ qemudDomainMigratePrepareTunnel(virConnectPtr dconn,
 vm-def-id = -1;
 
 if (virAsprintf(unixfile, %s/qemu.tunnelmigrate.dest.%s,
-driver-stateDir, vm-def-name)  0) {
+driver-libDir, vm-def-name)  0) {
 virReportOOMError();
 goto endjob;
 }
@@ -10941,7 +10941,7 @@ static int doTunnelMigrate(virDomainPtr dom,
 /* Stage 1. setup local support infrastructure */
 
 if (virAsprintf(unixfile, %s/qemu.tunnelmigrate.src.%s,
-driver-stateDir, vm-def-name)  0) {
+driver-libDir, vm-def-name)  0) {
 virReportOOMError();
 goto cleanup;
 }
-- 
1.7.2.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] ruby-libvirt issue

[Chris Lalancette]

On 08/05/10 - 12:35:03PM, Daniel P. Berrange wrote:
 On Thu, Jul 29, 2010 at 02:32:06PM -0400, Chris Lalancette wrote:
  On 07/29/10 - 07:41:26PM, Jaromír Červenka wrote:
   Hi,
   
   i think that I know where is the problem. My messages log says:
   
   Jul 29 19:36:41 divinus libvirtd: 19:36:41.032: error :
   qemudDispatchServer:1315 : Too many active clients (100), dropping
   connection
   
   It looks like that ruby-libvirt doesn't closing connection, when it's
   running under passenger/rails/apache. The 100 is my defined number in
   /etc/libvirt/libvirtd.conf
  
  Ah, OK.  So then the question becomes whether the problem is in the ruby
  bindings not releasing the object in certain circumstances, or in rails
  holding onto the object too long.  Unfortunately I'm not really that 
  familiar
  with rails or passenger, so I'm not entirely sure how to figure out where 
  the
  problem is.
  
  I'll see if I can do a bit of testing and look at object lifetimes from the
  point-of-view of ruby-libvirt to try and eliminate that from the equation.
 
 Does ruby-libvirt rely on garbage collection to close the
 connection, or is there an explicit 'close' method on the
 virConnect binding. It is generally not workable to rely
 on garbage collection for closing connections because of
 the unpredictability of  when that may run.

It's an explicit close method.  So my guess is that somewhere a close is
being missed in Jaromír's application.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] NUMA cell?

[Chris Lalancette]

On 08/05/10 - 06:47:08PM, adrian wyssen wrote:
 Hi,
 I have a question regarding the documentation of libvirt. There is a
 structure called 'virNodeInfo' and in the doc, you speak about NUMA cell. I

A NUMA cell in libvirt terms is a NUMA node in other terms.  Unfortunately
the word node is horribly overloaded in libvirt, so we choose another name.

 was wondering what that is. And what do you understand by 'the number of
 threads per core'?

For processors that support hyperthreading, this is the number of hyperthreads
they have per core.  On a machine that doesn't support hyperthreading, this
will be 1.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 1/3] Attempt to load tun module on tap add error

[Chris Lalancette]

On 08/05/10 - 02:12:36PM, Doug Goldstein wrote:
 When attempting to add a tap device, the error message is fairly cryptic
 as to what really happened. If possible, try to load the tun module and
 then try again to add the tap device again to improve the user
 experience.
 
 Signed-off-by: Doug Goldstein car...@gentoo.org
 ---
  src/util/bridge.c |   21 +++--
  1 files changed, 19 insertions(+), 2 deletions(-)
 
 diff --git a/src/util/bridge.c b/src/util/bridge.c
 index 7d0caae..ca4bcc9 100644
 --- a/src/util/bridge.c
 +++ b/src/util/bridge.c
 @@ -486,12 +486,29 @@ brAddTap(brControl *ctl,
  {
  int fd;
  struct ifreq ifr;
 +const char * const argv[] = { modprobe, tun, NULL };
 +int err, exitstatus = 0;

Hm, I can't say I like this.  Libvirt really shouldn't be in the business
of loading kernel modules (I know, we actually do this in the pci passthrough
code, but I don't think we should).  Besides being pretty gross, this will
cause havoc with security policies (like SELinux): you'll need to make the
security module allow libvirtd the ability to modprobe any module, which means
that any flaw in libvirtd turns into a possible system-wide compromise.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 2/3] Add a detailed message when tap device add fails

[Chris Lalancette]

On 08/05/10 - 02:12:44PM, Doug Goldstein wrote:
 Added a more detailed error message when adding a tap devices fails and
 the kernel is missing tun support.
 
 Signed-off-by: Doug Goldstein car...@gentoo.org
 ---
  src/qemu/qemu_conf.c |7 +++
  1 files changed, 7 insertions(+), 0 deletions(-)
 
 diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
 index 2ca3350..e92021a 100644
 --- a/src/qemu/qemu_conf.c
 +++ b/src/qemu/qemu_conf.c
 @@ -1694,6 +1694,13 @@ qemudNetworkIfaceConnect(virConnectPtr conn,
  qemuReportError(VIR_ERR_INTERNAL_ERROR,
  _(Failed to add tap interface to bridge. 
%s is not a bridge device), brname);
 +} else if (err == ENOENT) {
 +/* When the tun drive is missing, give a better message. */
 +qemuReportError(VIR_ERR_INTERNAL_ERROR, %s,
 +_(Failed to add tap interface to bridge. 
 +  Your kernel is missing the 'tun' module or 
 +  CONFIG_TUN or you need to add the 
 +  /dev/net/tun device node.));
  } else if (template_ifname) {
  virReportSystemError(err,
   _(Failed to add tap interface to
 bridge '%s'),

Yeah, this is a better error message.

ACK

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH 3/3] Fix return value usage

[Chris Lalancette]

On 08/05/10 - 02:12:52PM, Doug Goldstein wrote:
 Fix the error checking to use the return value from brAddTap() instead
 of checking the current errno value which might have been changed by
 clean up calls inside of brAddTap().
 
 Signed-off-by: Doug Goldstein car...@gentoo.org
 ---
  src/qemu/qemu_conf.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
 index e92021a..7c0e354 100644
 --- a/src/qemu/qemu_conf.c
 +++ b/src/qemu/qemu_conf.c
 @@ -1689,7 +1689,7 @@ qemudNetworkIfaceConnect(virConnectPtr conn,
  tapmac,
  vnet_hdr,
  tapfd))) {
 -if (errno == ENOTSUP) {
 +if (err == ENOTSUP) {
  /* In this particular case, give a better diagnostic. */
  qemuReportError(VIR_ERR_INTERNAL_ERROR,
  _(Failed to add tap interface to bridge. 

Makes sense to me.

ACK

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Fix a bogus warning when parsing hostdev

[Chris Lalancette]

On 07/30/10 - 11:54:03AM, Eric Blake wrote:
 On 07/30/2010 11:37 AM, Chris Lalancette wrote:
  When parsing hostdev, the following message would be emitted:
  
  10:17:19.052: error : virDomainHostdevDefParseXML:3748 : internal error 
  unknown node alias
  
  However, alias is appropriately parsed in
  virDomainDeviceInfoParseXML anyway.  Disable the error message
  in the initial XML parsing loop.
 
 ACK, and thanks for the comments in the code.

Thanks, pushed.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Don't put a semicolon on the end of a VIR_ENUM_IMPL.

[Chris Lalancette]

On 07/30/10 - 11:55:39AM, Eric Blake wrote:
 On 07/30/2010 11:37 AM, Chris Lalancette wrote:
  Signed-off-by: Chris Lalancette clala...@redhat.com
  ---
   src/conf/domain_conf.c |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
  
  diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
  index 04c417e..ca4bc6e 100644
  --- a/src/conf/domain_conf.c
  +++ b/src/conf/domain_conf.c
  @@ -99,7 +99,7 @@ VIR_ENUM_IMPL(virDomainDeviceAddress, 
  VIR_DOMAIN_DEVICE_ADDRESS_TYPE_LAST,
 none,
 pci,
 drive,
  -  virtio-serial);
  +  virtio-serial)
   
 
 ACK; practically qualifies as trivial.

Yeah, I was going to push it as trivial, but I was posting other patches
anyway so I just posted it as well.  Thanks, pushed.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Free up memballoon def.

[Chris Lalancette]

On 07/30/10 - 11:56:04AM, Eric Blake wrote:
 On 07/30/2010 11:37 AM, Chris Lalancette wrote:
  Forgetting to do this was causing a memory leak.
  
  Signed-off-by: Chris Lalancette clala...@redhat.com
  ---
   src/conf/domain_conf.c |2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)
  
  diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
  index ca4bc6e..1ddea0a 100644
  --- a/src/conf/domain_conf.c
  +++ b/src/conf/domain_conf.c
  @@ -768,6 +768,8 @@ void virDomainDefFree(virDomainDefPtr def)
   
   virDomainWatchdogDefFree(def-watchdog);
   
  +virDomainMemballoonDefFree(def-memballoon);
 
 ACK.

Thanks, pushed.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Fix the ACS checking in the PCI code.

[Chris Lalancette]

 *parent;
   
  -parent = pciGetParentDevice(dev);
  +if (pciGetParentDevice(dev, parent)  0)
  +return -1;
   if (!parent) {
   /* if we have no parent, and this is the root bus, ACS doesn't come
* into play since devices on the root bus can't P2P without going
  @@ -1400,6 +1451,7 @@ pciDeviceIsBehindSwitchLackingACS(pciDevice *dev)
   do {
   pciDevice *tmp;
   int acs;
  +int ret;
   
   acs = pciDeviceDownstreamLacksACS(parent);
   
  @@ -1412,8 +1464,10 @@ pciDeviceIsBehindSwitchLackingACS(pciDevice *dev)
   }
   
   tmp = parent;
  -parent = pciGetParentDevice(parent);
  +ret = pciGetParentDevice(parent, parent);
   pciFreeDevice(tmp);
  +if (ret  0)
  +return -1;
   } while (parent);
   
   return 0;
 
 Acked-by: Chris Wright chr...@redhat.com

Thanks, I've pushed this now.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Check that virsh -d argument is numeric

[Chris Lalancette]

On 08/02/10 - 09:22:26PM, Daniel Veillard wrote:
 On Mon, Aug 02, 2010 at 12:19:54PM -0600, Eric Blake wrote:
  On 08/02/2010 09:30 AM, Daniel Veillard wrote:
 Having been bitten one more time by the use of -d to pass the
   hypervisor URI instead of -c (confusion coming from CVS using
   -d to specify the root), I suggest to drop atoi and use the
   function with checking and error out with proper explanation instead
   of silently failing !
  
  Hear hear - atoi() is inherently stupid.  There's a 'make syntax-check'
  that we could turn on to prohibit all use of atoi(), but I don't know if
  the code base is ready for that, so I'll save it for another patch on
  another day.
 
   let's try to clean this up after 0.8.3

Yeah, agreed.  There aren't a huge number of uses of atoi() in the codebase,
but there are enough to require a bit of churn.  Best left until after the
release.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] Fix the ACS checking in the PCI code.

[Chris Lalancette]

When trying to assign a PCI device to a guest, we have
to check that all bridges upstream of that device support
ACS.  That means that we have to find the parent bridge of
the current device, check for ACS, then find the parent bridge
of that device, check for ACS, etc.  As it currently stands,
the code to do this iterates through all PCI devices on the
system, looking for a device that has a range of busses that
included the current device's bus.

That check is not restrictive enough, though.  Depending on
how we iterated through the list of PCI devices, we could first
find the *topmost* bridge in the system; since it necessarily had
a range of busses including the current device's bus, we
would only ever check the topmost bridge, and not check
any of the intermediate bridges.

Note that this also caused a fairly serious bug in the
secondary bus reset code, where we could erroneously
find and reset the topmost bus instead of the inner bus.

This patch changes pciGetParentDevice() so that it first
checks if a bridge device's secondary bus exactly matches
the bus of the device we are looking for.  If it does, we've
found the correct parent bridge and we are done.  If it does not,
then we check to see if this bridge device's busses *include* the
bus of the device we care about.  If so, we mark this bridge device
as best, and go on.  If we later find another bridge device whose
busses include this device, but is more restrictive, then we
free up the previous best and mark the new one as best.  This
algorithm ensures that in the normal case we find the direct
parent, but in the case that the parent bridge secondary bus
is not exactly the same as the device, we still find the
correct bridge.

This patch was tested by me on a 4-port NIC with a
bridge without ACS (where assignment failed), a 4-port
NIC with a bridge with ACS (where assignment succeeded),
and a 2-port NIC with no bridges (where assignment
succeeded).

Signed-off-by: Chris Lalancette clala...@redhat.com
---
 src/util/pci.c |   78 +++
 1 files changed, 66 insertions(+), 12 deletions(-)

diff --git a/src/util/pci.c b/src/util/pci.c
index 26d55b8..f2890bd 100644
--- a/src/util/pci.c
+++ b/src/util/pci.c
@@ -283,6 +283,7 @@ pciIterDevices(pciIterPredicate predicate,
 DIR *dir;
 struct dirent *entry;
 int ret = 0;
+int rc;
 
 *matched = NULL;
 
@@ -322,11 +323,20 @@ pciIterDevices(pciIterPredicate predicate,
 break;
 }
 
-if (predicate(dev, check, data)) {
+rc = predicate(dev, check, data);
+if (rc  0) {
+/* the predicate returned an error, bail */
+pciFreeDevice(check);
+ret = -1;
+break;
+}
+else if (rc == 1) {
 VIR_DEBUG(%s %s: iter matched on %s, dev-id, dev-name, 
check-name);
 *matched = check;
+ret = 1;
 break;
 }
+
 pciFreeDevice(check);
 }
 closedir(dir);
@@ -510,10 +520,11 @@ pciBusContainsActiveDevices(pciDevice *dev,
 
 /* Is @check the parent of @dev ? */
 static int
-pciIsParent(pciDevice *dev, pciDevice *check, void *data ATTRIBUTE_UNUSED)
+pciIsParent(pciDevice *dev, pciDevice *check, void *data)
 {
 uint16_t device_class;
 uint8_t header_type, secondary, subordinate;
+pciDevice **best = data;
 
 if (dev-domain != check-domain)
 return 0;
@@ -533,16 +544,54 @@ pciIsParent(pciDevice *dev, pciDevice *check, void *data 
ATTRIBUTE_UNUSED)
 
 VIR_DEBUG(%s %s: found parent device %s, dev-id, dev-name, 
check-name);
 
-/* No, it's superman! */
-return (dev-bus = secondary  dev-bus = subordinate);
+/* if the secondary bus exactly equals the device's bus, then we found
+ * the direct parent.  No further work is necessary
+ */
+if (dev-bus == secondary)
+return 1;
+
+/* otherwise, SRIOV allows VFs to be on different busses then their PFs.
+ * In this case, what we need to do is look for the best match; i.e.
+ * the most restrictive match that still satisfies all of the conditions.
+ */
+if (dev-bus  secondary  dev-bus = subordinate) {
+if (*best == NULL) {
+*best = pciGetDevice(check-domain, check-bus, check-slot,
+ check-function);
+if (*best == NULL)
+return -1;
+}
+else {
+/* OK, we had already recorded a previous best match for the
+ * parent.  See if the current device is more restrictive than the
+ * best, and if so, make it the new best
+ */
+if (secondary  pciRead8(*best, PCI_SECONDARY_BUS)) {
+pciFreeDevice(*best);
+*best = pciGetDevice(check-domain, check-bus, check-slot,
+ check-function);
+if (*best == NULL)
+return -1

[libvirt] [PATCH] Fix a memory leak in the qemudBuildCommandLine.

[Chris Lalancette]

ADD_ARG_LIT should only be used for literal arguments,
since it duplicates the memory.  Since virBufferContentAndReset
is already allocating memory, we should only use ADD_ARG.

Signed-off-by: Chris Lalancette clala...@redhat.com
---
 src/qemu/qemu_conf.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 172986e..d0655fd 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -4110,7 +4110,7 @@ int qemudBuildCommandLine(virConnectPtr conn,
 goto error;
 }
 
-ADD_ARG_LIT(virBufferContentAndReset(boot_buf));
+ADD_ARG(virBufferContentAndReset(boot_buf));
 }
 
 if (def-os.kernel) {
-- 
1.7.1.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Fix a memory leak in the qemudBuildCommandLine.

[Chris Lalancette]

On 07/30/10 - 08:02:08AM, Eric Blake wrote:
 On 07/30/2010 07:47 AM, Chris Lalancette wrote:
  ADD_ARG_LIT should only be used for literal arguments,
  since it duplicates the memory.  Since virBufferContentAndReset
  is already allocating memory, we should only use ADD_ARG.
 
 ACK.
 
 Hmm, wondering if there is a way to make use of gcc's
 __builtin_constant_p() to enforce that ADD_ARG_LIT is passed a string
 constant.

Interesting idea.  I know danpb wanted to remove all of the macros used in
qemudBuildCommandLine, though, so you may want to consult with him before
spending too much time on it.

--
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] Fix DMI uuid parsing.

[Chris Lalancette]

valgrind was complaining that virUUIDParse was depending on
an uninitialized value.  Indeed it was; virSetHostUUIDStr()
didn't initialize the dmiuuid buffer to 0's, meaning that
anything after the string read from /sys was uninitialized.
Clear out the dmiuuid buffer before use, and make sure to
always leave a \0 at the end.

Signed-off-by: Chris Lalancette clala...@redhat.com
---
 src/util/uuid.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/src/util/uuid.c b/src/util/uuid.c
index f188148..9cafc2a 100644
--- a/src/util/uuid.c
+++ b/src/util/uuid.c
@@ -286,7 +286,8 @@ virSetHostUUIDStr(const char *uuid)
 return EEXIST;
 
 if (!uuid) {
-if (!getDMISystemUUID(dmiuuid, sizeof(dmiuuid))) {
+memset(dmiuuid, 0, sizeof(dmiuuid));
+if (!getDMISystemUUID(dmiuuid, sizeof(dmiuuid) - 1)) {
 if (!virUUIDParse(dmiuuid, host_uuid))
 return 0;
 }
-- 
1.7.1.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Fix DMI uuid parsing.

[Chris Lalancette]

On 07/30/10 - 04:35:27PM, Daniel Veillard wrote:
 On Fri, Jul 30, 2010 at 10:22:20AM -0400, Chris Lalancette wrote:
  valgrind was complaining that virUUIDParse was depending on
  an uninitialized value.  Indeed it was; virSetHostUUIDStr()
  didn't initialize the dmiuuid buffer to 0's, meaning that
  anything after the string read from /sys was uninitialized.
  Clear out the dmiuuid buffer before use, and make sure to
  always leave a \0 at the end.
  
  Signed-off-by: Chris Lalancette clala...@redhat.com
  ---
   src/util/uuid.c |3 ++-
   1 files changed, 2 insertions(+), 1 deletions(-)
  
  diff --git a/src/util/uuid.c b/src/util/uuid.c
  index f188148..9cafc2a 100644
  --- a/src/util/uuid.c
  +++ b/src/util/uuid.c
  @@ -286,7 +286,8 @@ virSetHostUUIDStr(const char *uuid)
   return EEXIST;
   
   if (!uuid) {
  -if (!getDMISystemUUID(dmiuuid, sizeof(dmiuuid))) {
  +memset(dmiuuid, 0, sizeof(dmiuuid));
  +if (!getDMISystemUUID(dmiuuid, sizeof(dmiuuid) - 1)) {
   if (!virUUIDParse(dmiuuid, host_uuid))
   return 0;
   }
 
   ACK,

Thanks, pushed.

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] qemu: Fix PCI address allocation

[Chris Lalancette]

On 07/30/10 - 04:56:47PM, Jiri Denemark wrote:
 When attaching a PCI device which doesn't explicitly set its PCI
 address, libvirt allocates the address automatically. The problem is
 that when checking which PCI address is unused, we only check for those
 with slot number higher than the highest slot number ever used.
 
 Thus attaching/detaching such device several times in a row (31 is the
 theoretical limit, less then 30 tries are enough in practise) makes any
 further device attachment fail. Furthermore, attaching a device with
 predefined PCI address to 0:0:31 immediately forbids attachment of any
 PCI device without explicit address.
 
 This patch changes the logic so that we always check all PCI addresses
 before we say there is no PCI address available.

Yes, makes perfect sense.  Most of the patch is adding VIR_DEBUG() lines
and removing the nextslot; the real change is this line:

 @@ -2217,7 +2212,7 @@ int 
 qemuDomainPCIAddressSetNextAddr(qemuDomainPCIAddressSetPtr addrs,
  {
  int i;
  
 -for (i = addrs-nextslot ; i = QEMU_PCI_ADDRESS_LAST_SLOT ; i++) {
 +for (i = 0 ; i = QEMU_PCI_ADDRESS_LAST_SLOT ; i++) {
  virDomainDeviceInfo maybe;
  char *addr;
  

ACK

-- 
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] Free up memballoon def.

[Chris Lalancette]

Forgetting to do this was causing a memory leak.

Signed-off-by: Chris Lalancette clala...@redhat.com
---
 src/conf/domain_conf.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index ca4bc6e..1ddea0a 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -768,6 +768,8 @@ void virDomainDefFree(virDomainDefPtr def)
 
 virDomainWatchdogDefFree(def-watchdog);
 
+virDomainMemballoonDefFree(def-memballoon);
+
 virSecurityLabelDefFree(def);
 
 virCPUDefFree(def-cpu);
-- 
1.7.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] Fix a bogus warning when parsing hostdev

[Chris Lalancette]

When parsing hostdev, the following message would be emitted:

10:17:19.052: error : virDomainHostdevDefParseXML:3748 : internal error unknown 
node alias

However, alias is appropriately parsed in
virDomainDeviceInfoParseXML anyway.  Disable the error message
in the initial XML parsing loop.

Signed-off-by: Chris Lalancette clala...@redhat.com
---
 src/conf/domain_conf.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 8721dd1..04c417e 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -3723,6 +3723,9 @@ virDomainHostdevDefParseXML(const xmlNodePtr node,
 goto error;
 }
 } else if (xmlStrEqual(cur-name, BAD_CAST address)) {
+/* address is parsed as part of virDomainDeviceInfoParseXML */
+} else if (xmlStrEqual(cur-name, BAD_CAST alias)) {
+/* alias is parsed as part of virDomainDeviceInfoParseXML */
 } else {
 virDomainReportError(VIR_ERR_INTERNAL_ERROR,
  _(unknown node %s), cur-name);
-- 
1.7.2

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Eliminate memory leak in xenUnifiedDomainInfoListFree

[Chris Lalancette]

On 07/29/10 - 09:47:53AM, Laine Stump wrote:
 From: Laine Stump la...@redhat.com
 
 This fixes a leak described in
 
https://bugzilla.redhat.com/show_bug.cgi?id=590073
 
 xenUnifiedDomainInfoList has a pointer to a list of pointers to
 xenUnifiedDomain. We were freeing up all the domains, but neglecting
 to free the list.
 
 This was found by Paolo Bonzini pbonz...@redhat.com.
 ---
  src/xen/xen_driver.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/src/xen/xen_driver.c b/src/xen/xen_driver.c
 index d121ea4..ddbfa7a 100644
 --- a/src/xen/xen_driver.c
 +++ b/src/xen/xen_driver.c
 @@ -2044,6 +2044,7 @@ 
 xenUnifiedDomainInfoListFree(xenUnifiedDomainInfoListPtr list)
  VIR_FREE(list-doms[i]-name);
  VIR_FREE(list-doms[i]);
  }
 +VIR_FREE(list-doms);
  VIR_FREE(list);
  }

Ouch.

ACK

--
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Fix --with-xen-proxy related compile error

[Chris Lalancette]

On 07/29/10 - 04:07:08PM, Matthias Bolte wrote:
 Move virDomainChrTargetTypeToString out of the #ifndef PROXY
 block, because it's used outside of it.
 ---
  src/conf/domain_conf.c |   40 
  1 files changed, 20 insertions(+), 20 deletions(-)
 
 diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
 index 82e5ce7..883c682 100644
 --- a/src/conf/domain_conf.c
 +++ b/src/conf/domain_conf.c
 @@ -2441,26 +2441,6 @@ out:
  return ret;
  }
  
 -static const char *
 -virDomainChrTargetTypeToString(int deviceType,
 -   int targetType)
 -{
 -const char *type = NULL;
 -
 -switch (deviceType) {
 -case VIR_DOMAIN_CHR_DEVICE_TYPE_CHANNEL:
 -type = virDomainChrChannelTargetTypeToString(targetType);
 -break;
 -case VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE:
 -type = virDomainChrConsoleTargetTypeToString(targetType);
 -break;
 -default:
 -break;
 -}
 -
 -return type;
 -}
 -
  static int
  virDomainChrDefParseTargetXML(virCapsPtr caps,
virDomainChrDefPtr def,
 @@ -3952,6 +3932,26 @@ virDomainDeviceDefPtr 
 virDomainDeviceDefParse(virCapsPtr caps,
  #endif /* !PROXY */
  
  
 +static const char *
 +virDomainChrTargetTypeToString(int deviceType,
 +   int targetType)
 +{
 +const char *type = NULL;
 +
 +switch (deviceType) {
 +case VIR_DOMAIN_CHR_DEVICE_TYPE_CHANNEL:
 +type = virDomainChrChannelTargetTypeToString(targetType);
 +break;
 +case VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE:
 +type = virDomainChrConsoleTargetTypeToString(targetType);
 +break;
 +default:
 +break;
 +}
 +
 +return type;
 +}
 +
  static void
  virVirtualPortProfileFormat(virBufferPtr buf,
  virVirtualPortProfileParamsPtr virtPort,

Makes sense to me, ACK

--
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Fix a potential race in pciInitDevice.

[Chris Lalancette]

On 07/28/10 - 02:39:38PM, Chris Wright wrote:
 * Chris Lalancette (clala...@redhat.com) wrote:
  If detecting the FLR flag of a pci device fails, then we
  could run into the situation of trying to close a file
  descriptor twice, once in pciInitDevice() and once in pciFreeDevice().
  Fix that by removing the pciCloseConfig() in pciInitDevice() and
  just letting pciFreeDevice() handle it.
  
  Thanks to Chris Wright for pointing out this problem.
  
  While we are at it, fix an error check.  While it would actually
  work as-is (since success returns 0), it's still more clear to
  check for  0 (as the rest of the code does).
  
  Signed-off-by: Chris Lalancette clala...@redhat.com

Thanks, I've pushed this patch.

--
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] Fix the ACS checking in the PCI code.

[Chris Lalancette]

The code in libvirt that does ACS checking has a pretty
serious bug that was essentially rendering the check useless.
When trying to assign a device, we have to check that all
bridges upstream of this device support ACS.  That means
that we have to find the parent of the current device,
check for ACS, then find the parent of that device, check
for ACS, etc.

However, the code to find the parent of the device had a
much too relaxed check.  It would iterate through all PCI
devices on the system, looking for a device that had a range
of busses that included the current device's bus.

That's not correct, though.  Depending on how we iterated
through the list of PCI devices, we could first find the
*topmost* bridge in the system; since it necessarily had
a range of busses including the current device's bus, we
would only ever check the topmost bridge, and not check
any of the intermediate bridges.

This patch is simple in that it looks for the PCI device
whose secondary device *exactly* equals the bus of the
device we are looking for.  That means that one, and only one
bridge will be found, and it will be the correct device.

Note that this also caused a fairly serious bug in the
secondary bus reset code, where we could erroneously
reset the topmost bus instead of the inner bus.

This patch was tested by me on a 4-port NIC with a
bridge without ACS (where assignment failed), a 4-port
NIC with a bridge with ACS (where assignment succeeded),
and a 2-port NIC with no bridges (where assignment
succeeded).

Signed-off-by: Chris Lalancette clala...@redhat.com
---
 src/util/pci.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/src/util/pci.c b/src/util/pci.c
index 26d55b8..df30e04 100644
--- a/src/util/pci.c
+++ b/src/util/pci.c
@@ -513,7 +513,7 @@ static int
 pciIsParent(pciDevice *dev, pciDevice *check, void *data ATTRIBUTE_UNUSED)
 {
 uint16_t device_class;
-uint8_t header_type, secondary, subordinate;
+uint8_t header_type, secondary;
 
 if (dev-domain != check-domain)
 return 0;
@@ -529,12 +529,11 @@ pciIsParent(pciDevice *dev, pciDevice *check, void *data 
ATTRIBUTE_UNUSED)
 return 0;
 
 secondary   = pciRead8(check, PCI_SECONDARY_BUS);
-subordinate = pciRead8(check, PCI_SUBORDINATE_BUS);
 
 VIR_DEBUG(%s %s: found parent device %s, dev-id, dev-name, 
check-name);
 
 /* No, it's superman! */
-return (dev-bus = secondary  dev-bus = subordinate);
+return (dev-bus == secondary);
 }
 
 static pciDevice *
-- 
1.7.1.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Force FLR on for buggy SR-IOV devices.

[Chris Lalancette]

On 07/26/10 - 01:45:29PM, Eric Blake wrote:
 On 07/26/2010 12:51 PM, Chris Lalancette wrote:
  Some buggy PCI devices actually support FLR, but
  forget to advertise that fact in their PCI config space.
  However, Virtual Functions on SR-IOV devices are
  *required* to support FLR by the spec, so force has_flr
  on if this is a virtual function.
  
  Signed-off-by: Chris Lalancette clala...@redhat.com
  ---
   src/util/pci.c |   48 
   1 files changed, 44 insertions(+), 4 deletions(-)
   
  +/* there are some buggy devices that do support FLR, but forget to
  + * advertise that fact in their capabilities.  However, FLR is 
  *required*
  + * to be present for virtual functions (VFs), so if we see that this
  + * device is a VF, we just assume FLR works
  + */
  +
  +if (virAsprintf(path, PCI_SYSFS devices/%s/physfn, dev-name)  0) {
  +virReportOOMError();
  +return -1;
 
 ACK - this fixed my concerns from v1.

Thanks, I've pushed this.

--
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH] Force FLR on for buggy SR-IOV devices.

[Chris Lalancette]

On 07/23/10 - 01:34:23PM, Eric Blake wrote:
 On 07/23/2010 01:21 PM, Chris Lalancette wrote:
 Some buggy PCI devices actually support FLR, but
 forget to advertise that fact in their PCI config space.
 However, Virtual Functions on SR-IOV devices are
 *required* to support FLR by the spec, so force has_flr
 on if this is a virtual function.
 
 +
 +if (virAsprintf(path, PCI_SYSFS devices/%s/physfn, dev-name)  0) {
 
 Weird spacing around 

Yeah, I think Paolo is right, this might be a thunderbird bug.  It looks OK
in the original patch I sent.

 
 +VIR_ERROR(Failed to allocate memory when checking FLR for device 
 %s,
 +  dev-id);
 
 If this fails, it is likely that other code will run out of memory
 soon, too.  Why not just call the standard git OOM handler here?

I could go either way on this one.  Up until now we only ever returned 0 or
1 from this function, but with the memory allocation, we can also have -1
(for failure).  I guess I'll re-code it to return -1, and then I can use
virOOMError here.

Thanks for the review.

--
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] Force FLR on for buggy SR-IOV devices.

[Chris Lalancette]

Some buggy PCI devices actually support FLR, but
forget to advertise that fact in their PCI config space.
However, Virtual Functions on SR-IOV devices are
*required* to support FLR by the spec, so force has_flr
on if this is a virtual function.

Signed-off-by: Chris Lalancette clala...@redhat.com
---
 src/util/pci.c |   48 
 1 files changed, 44 insertions(+), 4 deletions(-)

diff --git a/src/util/pci.c b/src/util/pci.c
index c45b179..41e91af 100644
--- a/src/util/pci.c
+++ b/src/util/pci.c
@@ -183,6 +183,16 @@ pciOpenConfig(pciDevice *dev)
 return 0;
 }
 
+static void
+pciCloseConfig(pciDevice *dev)
+{
+if (!dev)
+return;
+
+if (dev-fd = 0)
+close(dev-fd);
+}
+
 static int
 pciRead(pciDevice *dev, unsigned pos, uint8_t *buf, unsigned buflen)
 {
@@ -380,11 +390,16 @@ pciFindExtendedCapabilityOffset(pciDevice *dev, unsigned 
capability)
 return 0;
 }
 
-static unsigned
+/* detects whether this device has FLR.  Returns 0 if the device does
+ * not have FLR, 1 if it does, and -1 on error
+ */
+static int
 pciDetectFunctionLevelReset(pciDevice *dev)
 {
 uint32_t caps;
 uint8_t pos;
+char *path;
+int found;
 
 /* The PCIe Function Level Reset capability allows
  * individual device functions to be reset without
@@ -413,6 +428,25 @@ pciDetectFunctionLevelReset(pciDevice *dev)
 }
 }
 
+/* there are some buggy devices that do support FLR, but forget to
+ * advertise that fact in their capabilities.  However, FLR is *required*
+ * to be present for virtual functions (VFs), so if we see that this
+ * device is a VF, we just assume FLR works
+ */
+
+if (virAsprintf(path, PCI_SYSFS devices/%s/physfn, dev-name)  0) {
+virReportOOMError();
+return -1;
+}
+
+found = virFileExists(path);
+VIR_FREE(path);
+if (found) {
+VIR_DEBUG(%s %s: buggy device didn't advertise FLR, but is a VF; 
forcing flr on,
+  dev-id, dev-name);
+return 1;
+}
+
 VIR_DEBUG(%s %s: no FLR capability found, dev-id, dev-name);
 
 return 0;
@@ -626,6 +660,8 @@ pciTryPowerManagementReset(pciDevice *dev)
 static int
 pciInitDevice(pciDevice *dev)
 {
+int flr;
+
 if (pciOpenConfig(dev)  0) {
 virReportSystemError(errno,
  _(Failed to open config space file '%s'),
@@ -635,7 +671,12 @@ pciInitDevice(pciDevice *dev)
 
 dev-pcie_cap_pos   = pciFindCapabilityOffset(dev, PCI_CAP_ID_EXP);
 dev-pci_pm_cap_pos = pciFindCapabilityOffset(dev, PCI_CAP_ID_PM);
-dev-has_flr= pciDetectFunctionLevelReset(dev);
+flr = pciDetectFunctionLevelReset(dev);
+if (flr  0) {
+pciCloseConfig(dev);
+return flr;
+}
+dev-has_flr= flr;
 dev-has_pm_reset   = pciDetectPowerManagementReset(dev);
 dev-initted= 1;
 return 0;
@@ -1098,8 +1139,7 @@ pciFreeDevice(pciDevice *dev)
 if (!dev)
 return;
 VIR_DEBUG(%s %s: freeing, dev-id, dev-name);
-if (dev-fd = 0)
-close(dev-fd);
+pciCloseConfig(dev);
 VIR_FREE(dev);
 }
 
-- 
1.7.1.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 4/8] Qemu Monitor API entry point.

[Chris Lalancette]

On 07/20/10 - 11:56:52AM, Daniel P. Berrange wrote:
 This needs to be a in a separate libvirt_qemu_public.syms since
 this symbol is in a separate library. Also make sure to give
 it a different version name, eg  LIBVIRT_QEMU_0.8.3

Here's a diff-diff, which shows the changes I've done to address this
concern.  Assuming you are OK with this, I'll push this series (minus the
virsh patch) today.

--
Chris Lalancette
--- /tmp/04.patch   2010-07-23 10:53:00.535977382 -0400
+++ 0004-Qemu-Monitor-API-entry-point.patch 2010-07-23 10:55:45.501976791 
-0400
@@ -96,10 +45,31 @@ Signed-off-by: Chris Lalancette clalanc
  src/vbox/vbox_tmpl.c   |1 +
  src/xen/xen_driver.c   |1 +
  src/xenapi/xenapi_driver.c |1 +
- 19 files changed, 144 insertions(+), 1 deletions(-)
+ 20 files changed, 156 insertions(+), 1 deletions(-)
  create mode 100644 include/libvirt/libvirt-qemu.h
  create mode 100644 src/libvirt-qemu.c
+ create mode 100644 src/libvirt_qemu.syms
 
+diff --git a/configure.ac b/configure.ac
+index eece723..08b7eb6 100644
+--- a/configure.ac
 b/configure.ac
+@@ -1833,6 +1833,7 @@ CYGWIN_EXTRA_PYTHON_LIBADD=
+ MINGW_EXTRA_LDFLAGS=
+ WIN32_EXTRA_CFLAGS=
+ LIBVIRT_SYMBOL_FILE=libvirt.syms
++LIBVIRT_QEMU_SYMBOL_FILE=libvirt_qemu.syms
+ case $host in
+   *-*-cygwin*)
+ CYGWIN_EXTRA_LDFLAGS=-no-undefined
+@@ -1872,6 +1873,7 @@ AC_SUBST([CYGWIN_EXTRA_PYTHON_LIBADD])
+ AC_SUBST([MINGW_EXTRA_LDFLAGS])
+ AC_SUBST([WIN32_EXTRA_CFLAGS])
+ AC_SUBST([LIBVIRT_SYMBOL_FILE])
++AC_SUBST([LIBVIRT_QEMU_SYMBOL_FILE])
+ AC_SUBST([VERSION_SCRIPT_FLAGS])
+ 
+ 
 diff --git a/include/libvirt/Makefile.am b/include/libvirt/Makefile.am
 index 8589dc5..b2c2b76 100644
 --- a/include/libvirt/Makefile.am
@@ -166,7 +136,7 @@ index ece18a6..9cf9d67 100644
  libvirt_test_la_CFLAGS = $(COVERAGE_CFLAGS)
  
 +libvirt_qemu_la_SOURCES = libvirt-qemu.c
-+libvirt_qemu_la_LDFLAGS = $(VERSION_SCRIPT_FLAGS)$(LIBVIRT_SYMBOL_FILE) \
++libvirt_qemu_la_LDFLAGS = $(VERSION_SCRIPT_FLAGS)$(LIBVIRT_QEMU_SYMBOL_FILE) \
 +  -version-info $(LIBVIRT_VERSION_INFO) \
 +  $(CYGWIN_EXTRA_LDFLAGS) $(MINGW_EXTRA_LDFLAGS)
 +libvirt_qemu_la_CFLAGS = $(COVERAGE_CFLAGS)
@@ -309,21 +279,28 @@ index 778ceb1..fe8f4c9 100644
  
  
  # xml.h
-diff --git a/src/libvirt_public.syms b/src/libvirt_public.syms
-index 849c163..302b012 100644
 a/src/libvirt_public.syms
-+++ b/src/libvirt_public.syms
-@@ -405,4 +405,10 @@ LIBVIRT_0.8.2 {
- virDomainCreateWithFlags;
- } LIBVIRT_0.8.1;
- 
-+
-+LIBVIRT_0.8.3 {
+diff --git a/src/libvirt_qemu.syms b/src/libvirt_qemu.syms
+new file mode 100644
+index 000..5702d36
+--- /dev/null
 b/src/libvirt_qemu.syms
+@@ -0,0 +1,16 @@
++#
++# Officially exported symbols, for which header
++# file definitions are installed in /usr/include/libvirt
++# from libvirt-qemu.h
++#
++# Versions here are *fixed* to match the libvirt version
++# at which the symbol was introduced. This ensures that
++# a new client app requiring symbol foo() can't accidentally
++# run with old libvirt-qemu.so not providing foo() - the global
++# soname version info can't enforce this since we never
++# change the soname
++#
++LIBVIRT_QEMU_0.8.3 {
 +global:
 +virDomainQemuMonitorCommand;
-+} LIBVIRT_0.8.2;
-+
- #  define new API here using predicted next version number 
++};
 diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c
 index 462bc9c..4fc1ecd 100644
 --- a/src/lxc/lxc_driver.c
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] [PATCH] Force FLR on for buggy SR-IOV devices.

[Chris Lalancette]

Some buggy PCI devices actually support FLR, but
forget to advertise that fact in their PCI config space.
However, Virtual Functions on SR-IOV devices are
*required* to support FLR by the spec, so force has_flr
on if this is a virtual function.

Signed-off-by: Chris Lalancette clala...@redhat.com
---
 src/util/pci.c |   22 ++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/src/util/pci.c b/src/util/pci.c
index c45b179..4bfad2c 100644
--- a/src/util/pci.c
+++ b/src/util/pci.c
@@ -385,6 +385,7 @@ pciDetectFunctionLevelReset(pciDevice *dev)
 {
 uint32_t caps;
 uint8_t pos;
+char *path;
 
 /* The PCIe Function Level Reset capability allows
  * individual device functions to be reset without
@@ -413,6 +414,27 @@ pciDetectFunctionLevelReset(pciDevice *dev)
 }
 }
 
+/* there are some buggy devices that do support FLR, but forget to
+ * advertise that fact in their capabilities.  However, FLR is *required*
+ * to be present for virtual functions (VFs), so if we see that this
+ * device is a VF, we just assume FLR works
+ */
+
+if (virAsprintf(path, PCI_SYSFS devices/%s/physfn, dev-name)  0) {
+VIR_ERROR(Failed to allocate memory when checking FLR for device %s,
+  dev-id);
+return 0;
+}
+
+if (virFileExists(path)) {
+VIR_FREE(path);
+VIR_DEBUG(%s %s: buggy device didn't advertise FLR, but is a VF; 
forcing flr on,
+  dev-id, dev-name);
+return 1;
+}
+
+VIR_FREE(path);
+
 VIR_DEBUG(%s %s: no FLR capability found, dev-id, dev-name);
 
 return 0;
-- 
1.7.1.1

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 0/8]: Add arbitrary qemu command-line and monitor commands

[Chris Lalancette]

On 07/22/10 - 06:48:40PM, Daniel Veillard wrote:
 On Tue, Jul 20, 2010 at 08:34:41AM -0400, Chris Lalancette wrote:
  On 07/20/10 - 11:58:40AM, Daniel P. Berrange wrote:
   On Wed, Jul 07, 2010 at 05:33:25PM -0400, Chris Lalancette wrote:
As we discussed previously, here is the patch series to add the ability
to specify arbitrary qemu command-line parameters and environment 
variables,
and also give arbitrary monitor commands to a guest.  Because these
extra arguments have a good shot at confusing libvirt, the use of them
is not supported, but left available for advanced users and developers.
They are also in a separate library and have a separate on-the-wire
protocol.

There is one bug left that I have not yet been able to fix.  Because of 
the
complicated way that virsh parses command-line arguments, it is not 
possible
to pass through spaces and quotes when using the qemu-monitor-command.
Unfortunately, the qemu monitor commands (and in particular when using 
QMP)
depend heavily on quoting and spacing, so using virsh to send through
command-lines is difficult.  I'll have to think about how to better 
resolve
this issue, but it should not hold up the rest of the series.
   
   Aside from the bug about the libvirt_public.sym file I think this series
   is ok to commit. Given that we don't have a solution for this virsh
   quoting problem though, we should leave out the virsh patch. We don't
   want to lock ourselves into current syntax of 'qemu-monitor-command'
   in case the solution to quoting problem requires changes. 
  
  OK, that's reasonable.  I'll go back and try to bang on the virsh problem
  in the next few days and see what I can come up with for a solution.
 
   Chris, I think this is ripe too, virsh may be a bit late but I would
 rather commit this before 0.8.3. ACK,
 
   For virsh there is always the possibility to do this from virsh shell
 where we have more control over how the input line get parsed. Maybe
 the solution is to make sure this works well from inside virsh shell and
 add a warning at the command help level indicating that using them
 from the shell invocation may lead to surprizes.

Given the reviews and consensus, I've pushed the series without the virsh
patches.  I'll have another go at trying to get that working more sanely.

Thanks for all of the review!
--
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] kvm savevm/loadvm

[Chris Lalancette]

On 07/22/10 - 10:40:44AM, Serge Hallyn wrote:
 Quoting Chris Lalancette (clala...@redhat.com):
  On 07/20/10 - 05:17:43AM, Serge Hallyn wrote:
   Hi,
   
   virsh has save/restore to do a one-time save+shutdown.  But it
   does not expose kvm's savevm/restorevm, which let's me do
   incremental snapshots.  Is there a specific reason why that
   is not exposed in libvirt, or is it just that noone has
   implemented it?
  
  The save/restore API only does a memory snapshot.  If you are referring
 
 Jinkeys, I guess so - my first tests were confounded by the page
 cache being reverted and then synced back to disk :)
 
  to the savevm/loadvm/delvm, which take a disk+memory snapshot, then that is
  implemented in terms of the libvirt snapshot API.  You can start here:
  
  http://libvirt.org/html/libvirt-libvirt.html#virDomainSnapshotCreateXML
 
 Ok, so the snapshot created by virDomainSnapshotCreateXML is not what
 is used by 'virsh snapshot-create'?  Are there any plans of exporting
 this through virsh?

No, these two things are the same; virsh snapshot-create calls
virDomainSnapshotCreateXML (which eventually calls savevm in the qemu monitor).

--
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] A problem in live migration

[Chris Lalancette]

On 07/21/10 - 11:59:49AM, florian chazal wrote:
 I know that, I had the same issue due to the fact  one of my host  had its
 name in front of the localhost address in my /etc/hosts (like : 127.0.0.1
 localhost linux72  ) ... But it's maybe not the same problem

The particular problem of having both localhost and your local hostname
(like linux72) resolve to 127.0.0.1 should now work in libvirt 0.8.2 without
modification.  But the original reporter's problem is that after going through
the (rather delicate) algorithm to detect hostname, it still couldn't resolve
to anything other than localhost.  Either via /etc/hosts, or through DNS, the
hostname of the destination machine has to resolve to something besides
localhost.

--
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] [PATCH v4 0/8]: Add arbitrary qemu command-line and monitor commands

[Chris Lalancette]

On 07/20/10 - 11:58:40AM, Daniel P. Berrange wrote:
 On Wed, Jul 07, 2010 at 05:33:25PM -0400, Chris Lalancette wrote:
  As we discussed previously, here is the patch series to add the ability
  to specify arbitrary qemu command-line parameters and environment variables,
  and also give arbitrary monitor commands to a guest.  Because these
  extra arguments have a good shot at confusing libvirt, the use of them
  is not supported, but left available for advanced users and developers.
  They are also in a separate library and have a separate on-the-wire
  protocol.
  
  There is one bug left that I have not yet been able to fix.  Because of the
  complicated way that virsh parses command-line arguments, it is not possible
  to pass through spaces and quotes when using the qemu-monitor-command.
  Unfortunately, the qemu monitor commands (and in particular when using QMP)
  depend heavily on quoting and spacing, so using virsh to send through
  command-lines is difficult.  I'll have to think about how to better resolve
  this issue, but it should not hold up the rest of the series.
 
 Aside from the bug about the libvirt_public.sym file I think this series
 is ok to commit. Given that we don't have a solution for this virsh
 quoting problem though, we should leave out the virsh patch. We don't
 want to lock ourselves into current syntax of 'qemu-monitor-command'
 in case the solution to quoting problem requires changes. 

OK, that's reasonable.  I'll go back and try to bang on the virsh problem
in the next few days and see what I can come up with for a solution.

Thanks,
--
Chris Lalancette

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list