Daniel P. Berrange | 22 Oct 19:14 2014
Picon

[libvirt] [PATCH 00/12] Split up large driver files

This patch series splits up the src/driver.h and src/libvirt.c
files into a number of smaller pieces.

The driver.h file gets split based on the the driver type,
while libvirt.c gets split slightly different based on the
object type. The reason for the difference is that the
hypervisor driver is rather large, so its useful to split
the domain, domain snapshot and connect/node APIs into
separate files.

There will be much more to follow this series. Just posting
this start now since it will be painful to rebase....

Daniel P. Berrange (12):
  Rename virDriver to virHypervisorDriver
  Split driver.h into multiple parts
  Move virDomainSnapshot related APIs out of libvirt.c
  Move virNetwork related APIs out of libvirt.c
  Move virInterface related APIs out of libvirt.c
  Move virNWFilter related APIs out of libvirt.c
  Move virNodeDevice related APIs out of libvirt.c
  Move virSecret related APIs out of libvirt.c
  Move virStream related APIs out of libvirt.c
  Move virStorage{Pool,Vol} related APIs out of libvirt.c
  Move virDomain related APIs out of libvirt.c
  Move virConnect/virNode related APIs out of libvirt.c

 cfg.mk                           |     4 +-
 docs/apibuild.py                 |    11 +
 docs/hvsupport.pl                |     2 +-
(Continue reading)

Peter Krempa | 22 Oct 17:51 2014
Picon

[libvirt] [PATCH] doc: HACKING: Regenerate after recent change

---
Pushed as trivial.

 HACKING | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/HACKING b/HACKING
index f8546cb..8f42e51 100644
--- a/HACKING
+++ b/HACKING
 <at>  <at>  -16,7 +16,7  <at>  <at>  listen to feedback.

 (2) Official upstream repository is kept in git ("git://libvirt.org/libvirt.git")
 and is browsable along with other libvirt-related repositories (e.g.
-libvirt-python) online <http://libvirt.org>.
+libvirt-python) online <http://libvirt.org/git/>.

 (3) Post patches in unified diff format, with git rename detection enabled. You
 need a one-time setup of:
--

-- 
2.1.0

John Ferlan | 22 Oct 17:34 2014
Picon

Re: [libvirt] [PATCH 2/3] lxc: Implement emulator pin API in lxc driver


On 09/04/2014 03:52 AM, Wang Rui wrote:
> From: Yue Wenyuan <yuewenyuan <at> huawei.com>
> 
> Implement the lxc driver method for virDomainPinEmulator
> to set container's cpuset.
> 
> Signed-off-by: Wang Rui <moon.wangrui <at> huawei.com>
> Signed-off-by: Yue Wenyuan <yuewenyuan <at> huawei.com>
> ---
>  src/lxc/lxc_cgroup.c |  20 ++++++++
>  src/lxc/lxc_cgroup.h |   3 ++
>  src/lxc/lxc_driver.c | 131 +++++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 154 insertions(+)
> 
> diff --git a/src/lxc/lxc_cgroup.c b/src/lxc/lxc_cgroup.c
> index f696bf8..7dc7c9b 100644
> --- a/src/lxc/lxc_cgroup.c
> +++ b/src/lxc/lxc_cgroup.c
>  <at>  <at>  -531,6 +531,26  <at>  <at>  int virLXCCgroupSetup(virDomainDefPtr def,
>      return ret;
>  }
>  
> +int
> +virLXCSetupCgroupEmulatorPin(virCgroupPtr cgroup,
> +                           virBitmapPtr cpumask)
> +{
> +    int ret = -1;
> +    char *new_cpus = NULL;
> +
(Continue reading)

John Ferlan | 22 Oct 17:34 2014
Picon

Re: [libvirt] [PATCH 1/3] lxc: Implement pin emulator for container startup


On 09/04/2014 03:52 AM, Wang Rui wrote:
> From: Yue Wenyuan <yuewenyuan <at> huawei.com>
> 
> This patch implements libvirt_lxc process pin with emulatorpin
> specified in xml.
> 
> Signed-off-by: Wang Rui <moon.wangrui <at> huawei.com>
> Signed-off-by: Yue Wenyuan <yuewenyuan <at> huawei.com>
> ---
>  src/lxc/lxc_cgroup.c     | 68 ++++++++++++++++++++++++++++++++++++++++++++++++
>  src/lxc/lxc_cgroup.h     |  4 +++
>  src/lxc/lxc_controller.c |  4 +++
>  3 files changed, 76 insertions(+)
> 

I'm not an LXC expert, but I'll give this a go since it's been sitting
around a while.

I am curious why only the CPUSET (eg, <vcpuset ... cpuset="1-4,^3,6"> or
<emulatorpin cpuset="1-3"/>) were handled and the <emulator_period> and
<emulator_quota> were not?

> diff --git a/src/lxc/lxc_cgroup.c b/src/lxc/lxc_cgroup.c
> index f9af31c..f696bf8 100644
> --- a/src/lxc/lxc_cgroup.c
> +++ b/src/lxc/lxc_cgroup.c
>  <at>  <at>  -530,3 +530,71  <at>  <at>  int virLXCCgroupSetup(virDomainDefPtr def,
>   cleanup:
>      return ret;
(Continue reading)

John Ferlan | 22 Oct 17:34 2014
Picon

Re: [libvirt] [PATCH 3/3] lxc: Implement geting emulator pin info API in lxc driver


Fix the $SUBJ   "s/geting/getting"

On 09/04/2014 03:52 AM, Wang Rui wrote:
> From: Yue Wenyuan <yuewenyuan <at> huawei.com>
> 
> Implement the lxc driver method for virDomainGetEmulatorPinInfo
> to get container's cpuset.
> 
> Signed-off-by: Wang Rui <moon.wangrui <at> huawei.com>
> Signed-off-by: Yue Wenyuan <yuewenyuan <at> huawei.com>
> ---
>  src/lxc/lxc_driver.c | 75 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 75 insertions(+)
> 
> diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c
> index 9e3a877..6694cf3 100644
> --- a/src/lxc/lxc_driver.c
> +++ b/src/lxc/lxc_driver.c
>  <at>  <at>  -1395,6 +1395,80  <at>  <at>  lxcDomainPinEmulator(virDomainPtr dom,
>      return ret;
>  }
>  

Since the following is essentially a copy of the qemu function with the
only changes being "LXC" for "QEMU" or "lxc" for "qemu" - it seems that
it should be possible to create some sort of common vir/util function
especially for all the lines between [1] and [2] below.  Of course
that's probably true in other areas, but since I was comparing here I
guess it
(Continue reading)

Fabiano FidĂȘncio | 22 Oct 16:16 2014
Picon

[libvirt] [PATCH] Show also short-ids when calling --list-{os, platform}

As the short-id can be used to set the os/platform in the example
program, let's expose them to the user.
---
 examples/virt-designer.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/examples/virt-designer.c b/examples/virt-designer.c
index 7628449..12faf04 100644
--- a/examples/virt-designer.c
+++ b/examples/virt-designer.c
 <at>  <at>  -107,8 +107,8  <at>  <at>  print_oses(const gchar *option_name,
     if (!db && !load_osinfo())
         goto cleanup;

-    printf("  Operating System ID\n"
-           "-----------------------\n");
+    printf("  Operating System ID (short ID)\n"
+           "--------------------------------\n");

     list = osinfo_db_get_os_list(db);
     if (!list)
 <at>  <at>  -119,6 +119,8  <at>  <at>  print_oses(const gchar *option_name,
         OsinfoOs *os = OSINFO_OS(os_iter->data);
         const char *id = osinfo_entity_get_param_value(OSINFO_ENTITY(os),
                                                        OSINFO_ENTITY_PROP_ID);
+        const char *short_id = osinfo_entity_get_param_value(OSINFO_ENTITY(os),
+                                                             OSINFO_PRODUCT_PROP_SHORT_ID);

         printf("%s\n", id);
     }
(Continue reading)

Chapman, James P | 22 Oct 14:02 2014
Picon

[libvirt] [RFC] Add support for NIC offload discovery

 

Currently libvirt provides lots of useful information on the HW capabilities of the host and its attached devices. I’m interested in extending the HW capability discovery of libvirt, to a point where it is capable of discovering the HW offload capabilities of host PCI devices. Take a NIC for example, this feature would enable libvirt discover the supported NIC offload features, csum, tso, etc.

 

So where might a feature like this be used. Consider an Openstack deployment, a VM may have a workload that depends on specific NIC HW offload capabilities in order to stay within certain throughput, CPU utilisation or latency thresholds. For this scenario, it’s important that the VM is placed on a host with PCI devices that provide the required NIC HW offload capabilities. If libvirt could provide this functionality, this information could be used during the VM scheduling phase when all nodes are evaluated for their suitability.

 

From what I understand, libvirt currently uses ioctl’s to get the NIC state, MTU, etc. Could the ethtool ioctl framework be used to discover the HW offload features provided by the hosts network controllers.

E.g.

·         ETHTOOL_GRXCSUM

·         ETHTOOL_GTXCSUM

·         ETHTOOL_GTSO

·         ETHTOOL_GFLAGS

 

So I’m looking for your opinions on this feature proposal, does it make sense, is it already being worked on.

 

Thanks

James

 

<div>
<div class="WordSection1">
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Currently libvirt provides lots of useful information on the HW capabilities of the host and its attached devices. I&rsquo;m interested in extending the HW capability discovery of libvirt, to a point where it is capable of discovering the HW
 offload capabilities of host PCI devices. Take a NIC for example, this feature would enable libvirt discover the supported NIC offload features, csum, tso, etc.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">So where might a feature like this be used. Consider an Openstack deployment, a VM may have a workload that depends on specific NIC HW offload capabilities in order to stay within certain throughput, CPU utilisation or latency thresholds.
 For this scenario, it&rsquo;s important that the VM is placed on a host with PCI devices that provide the required NIC HW offload capabilities. If libvirt could provide this functionality, this information could be used during the VM scheduling phase when all nodes
 are evaluated for their suitability.<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">From what I understand, libvirt currently uses ioctl&rsquo;s to get the NIC state, MTU, etc. Could the ethtool ioctl framework be used to discover the HW offload features provided by the hosts network controllers.
<p></p></p>
<p class="MsoNormal">E.g.<p></p></p>
<p>
<span lang="EN-GB">&middot;</span><span lang="EN-GB">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span lang="EN-GB">ETHTOOL_GRXCSUM
<p></p></span></p>
<p>
<span lang="EN-GB">&middot;</span><span lang="EN-GB">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span lang="EN-GB">ETHTOOL_GTXCSUM
<p></p></span></p>
<p>
<span lang="EN-GB">&middot;</span><span lang="EN-GB">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span lang="EN-GB">ETHTOOL_GTSO
<p></p></span></p>
<p>
<span lang="EN-GB">&middot;</span><span lang="EN-GB">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span><span lang="EN-GB">ETHTOOL_GFLAGS<p></p></span></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">So I&rsquo;m looking for your opinions on this feature proposal, does it make sense, is it already being worked on<span>.</span><p></p></p>
<p class="MsoNormal"><span lang="EN-GB"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-GB">Thanks<p></p></span></p>
<p class="MsoNormal"><span lang="EN-GB">James<p></p></span></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
</div>
</div>
Martin Kletzander | 22 Oct 13:58 2014
Picon

[libvirt] [RFC] Can we error out early for unknown device models?

Hi everyone,

I had this idea that since we are probing QEMU binaries for devices
using 'qom-list-types', we could store that data in the capabilities
and check whether device models are supported before starting QEMU.
We do that for _some newer_ devices, but this would be global.  It
would help out particularly with devices like the following one, for
example:

 <interface type='network'>
   <source network='default'/>
   <model type='non-existing_device'/>
 </interface>

where we simply construct QEMU command-line with that device model and
it then properly errors out:

 error: internal error: process exited while connecting to monitor:
 qemu-system-x86_64: -device non-existing_device,...: Parameter
 'driver' expects device type

This would be easy to achieve with current data unless there are some
models hidden from qom-list-types' output.  I hope there are none.

When I checked the output of 'qemu-kvm -device \?', the devices listed
there are separated into categories and have buses assigned to them
and that lead me to another idea.  What if that data is added to
qom-list-types' output and used in libvirt as well?  We could then
solve another annoying cases like misusing devices or plugging them
into unsupported buses.  Although I don't know any person who would do
such a thing, even when solving the first idea, there'd still be a
possibility to do a thing like:

 <interface type='network'>
   <source network='default'/>
   <model type='AC97'/>
 </interface>

This idea is obviously meant for the QEMU driver, but if there's
something similar in other drivers, it might be useful as well.

I'd be interested in any feedback and welcome any ideas to whether it
is useful, how the storing should be done or even if it's something we
want to have or not.

Have a nice day,
Martin
Hi everyone,

I had this idea that since we are probing QEMU binaries for devices
using 'qom-list-types', we could store that data in the capabilities
and check whether device models are supported before starting QEMU.
We do that for _some newer_ devices, but this would be global.  It
would help out particularly with devices like the following one, for
example:

 <interface type='network'>
   <source network='default'/>
   <model type='non-existing_device'/>
 </interface>

where we simply construct QEMU command-line with that device model and
it then properly errors out:

 error: internal error: process exited while connecting to monitor:
 qemu-system-x86_64: -device non-existing_device,...: Parameter
 'driver' expects device type

This would be easy to achieve with current data unless there are some
models hidden from qom-list-types' output.  I hope there are none.

When I checked the output of 'qemu-kvm -device \?', the devices listed
there are separated into categories and have buses assigned to them
and that lead me to another idea.  What if that data is added to
qom-list-types' output and used in libvirt as well?  We could then
solve another annoying cases like misusing devices or plugging them
into unsupported buses.  Although I don't know any person who would do
such a thing, even when solving the first idea, there'd still be a
possibility to do a thing like:

 <interface type='network'>
   <source network='default'/>
   <model type='AC97'/>
 </interface>

This idea is obviously meant for the QEMU driver, but if there's
something similar in other drivers, it might be useful as well.

I'd be interested in any feedback and welcome any ideas to whether it
is useful, how the storing should be done or even if it's something we
want to have or not.

Have a nice day,
Martin
Pavel Hrdina | 22 Oct 13:53 2014
Picon

[libvirt] [libvirt-python PATCH 1/1] virDomainBlockCopy: initialize flags to 0

An optional argument if not passed isn't modified by the
PyArg_ParseTuple function.

Signed-off-by: Pavel Hrdina <phrdina <at> redhat.com>
---

Sigh :/, pushed as trivial

 libvirt-override.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libvirt-override.c b/libvirt-override.c
index a461eda..a53b46f 100644
--- a/libvirt-override.c
+++ b/libvirt-override.c
 <at>  <at>  -8171,7 +8171,7  <at>  <at>  libvirt_virDomainBlockCopy(PyObject *self ATTRIBUTE_UNUSED, PyObject *args)
     char *destxml = NULL;
     virTypedParameterPtr params = NULL;
     int nparams = 0;
-    unsigned int flags;
+    unsigned int flags = 0;
     int c_retval;

     if (!PyArg_ParseTuple(args, (char *) "Ozz|OI:virDomainBlockCopy",
--

-- 
2.0.4

Julio Faracco | 22 Oct 13:46 2014
Picon

[libvirt] Libvirt clock/time settings doubt.

Hi everyone!

What is the method/function responsible to setup time settings in libvirt?
Considering the example of libvirt documentation.

<clock offset='localtime'> <timer name='rtc' tickpolicy='catchup' track='guest'> <catchup threshold='123' slew='120' limit='10000'/> </timer> <timer name='pit' tickpolicy='delay'/> </clock> ...I know where this XML will be parsed. But I don't know where libvirt will pass clock/time settings to QEMU.

Can somebody explain to me or send me a documentation about it?

I passed two weeks trying to discover the sequence of function calls.

Thanks guys!

--
Julio Cesar Faracco
<div><div dir="ltr">
<div>
<div>
<div>
<div>Hi everyone!<br><br>
</div>What is the method/function responsible to setup time settings in libvirt?<br>
</div>Considering the example of libvirt documentation.<br><br>&lt;clock offset='localtime'&gt;
   &lt;timer name='rtc' tickpolicy='catchup' track='guest'&gt;
     &lt;catchup threshold='123' slew='120' limit='10000'/&gt;
   &lt;/timer&gt;
   &lt;timer name='pit' tickpolicy='delay'/&gt;
&lt;/clock&gt;
...I know where this XML will be parsed. But I don't know where libvirt will pass clock/time settings to QEMU.<br><br>
</div>Can somebody explain to me or send me a documentation about it?<br><br>
</div>
<div>I passed two weeks trying to discover the sequence of function calls.<br>
</div>
<div><br></div>Thanks guys!<br><div><div><div><div><div>
<br><div>--<br clear="all"><div>
<div>
<div>Julio Cesar Faracco</div>
</div>
</div>
</div>
</div></div></div></div></div>
</div></div>
Peter Krempa | 22 Oct 11:48 2014
Picon

[libvirt] [PATCH 0/3] Fix handling of data returned by XML hooks

Peter Krempa (3):
  util: string: Add helper to check whether string is empty
  qemu: restore: Fix restoring of VM when the restore hook returns empty
    XML
  qemu: migration: Make check for empty hook XML robust

 src/libvirt_private.syms  |  1 +
 src/qemu/qemu_driver.c    |  2 +-
 src/qemu/qemu_migration.c |  2 +-
 src/util/virstring.c      | 16 ++++++++++++++++
 src/util/virstring.h      |  2 ++
 5 files changed, 21 insertions(+), 2 deletions(-)

--

-- 
2.1.0


Gmane