Paolo Bonzini | 1 Dec 10:19 2009
Picon

[libvirt] [PATCH 2/2 v2] add --live support to "virsh dump"

This is trivial for QEMU since you just have to not stop the vm before
starting the dump.  And for Xen, you just pass the flag down to xend.

* include/libvirt/libvirt.h.in (virDomainCoreDumpFlags): Add
VIR_DUMP_LIVE.
* src/qemu/qemu_driver.c (qemudDomainCoreDump): Support live dumping.
* src/xen/xend_internal.c (xenDaemonDomainCoreDump): Support live dumping.
* tools/virsh.c (opts_dump): Add --live.
(cmdDump): Map it to VIR_DUMP_LIVE.
---
	Since there was consensus, here is the patch with the Xen
	driver support.  Applies on top of the --crash patch.

 include/libvirt/libvirt.h.in |    1 +
 src/qemu/qemu_driver.c       |    7 +++----
 src/xen/xend_internal.c      |    3 ++-
 tools/virsh.c                |    3 +++
 4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
index c04b552..b4a7ef1 100644
--- a/include/libvirt/libvirt.h.in
+++ b/include/libvirt/libvirt.h.in
 <at>  <at>  -337,6 +337,7  <at>  <at>  typedef virDomainInterfaceStatsStruct *virDomainInterfaceStatsPtr;
 /* Domain core dump flags. */
 typedef enum {
     VIR_DUMP_CRASH   = (1 << 0), /* crash after dump */
+    VIR_DUMP_LIVE    = (1 << 1), /* live dump */
 } virDomainCoreDumpFlags;

(Continue reading)

Daniel P. Berrange | 1 Dec 11:37 2009
Picon

Re: [libvirt] Eventtest unit test failure

On Mon, Nov 30, 2009 at 10:17:55PM +0100, Soren Hansen wrote:
> On Mon, Nov 30, 2009 at 10:26:12AM +0000, Daniel P. Berrange wrote:
> >> I've changed the libvirt package in Ubuntu to run the test suite with
> >> every build. However, on our build daemons, the eventtest unit test
> >> seems to almost[1] consistently fail. You can see an example build
> >> log here:
> >> 
> >>    http://launchpadlibrarian.net/36196282/buildlog_ubuntu-lucid-amd64.libvirt_0.7.0-1ubuntu15_FAILEDTOBUILD.txt.gz
> >> 
> >> Does this look familiar to anyone? Any idea what might be causing
> >> this?  FWIW, I cannot reproduce it locally, so it's likely
> >> environmental, but at this point, I don't really know where to begin
> >> to look.
> > What HZ setting are the kernels on the problem host running with ?
> > IIRC we had someone else report a problem with this test suite on a
> > kernel built with HZ=100, rather than the more common HZ=1000
> 
> Ah, indeed they are running with HZ=100.
> 
> So this is a known problem? Is there a known fix?

Can you see if this makes any difference

diff --git a/daemon/event.c b/daemon/event.c
index 10847c4..ed11e78 100644
--- a/daemon/event.c
+++ b/daemon/event.c
 <at>  <at>  -413,7 +413,7  <at>  <at>  static int virEventDispatchTimeouts(void) {
         if (eventLoop.timeouts[i].deleted || eventLoop.timeouts[i].frequency < 0)
             continue;
(Continue reading)

Daniel P. Berrange | 1 Dec 12:09 2009
Picon

[libvirt] Re: [PATCH 2/2 v2] add --live support to "virsh dump"

On Tue, Dec 01, 2009 at 10:19:55AM +0100, Paolo Bonzini wrote:
> This is trivial for QEMU since you just have to not stop the vm before
> starting the dump.  And for Xen, you just pass the flag down to xend.
> 
> * include/libvirt/libvirt.h.in (virDomainCoreDumpFlags): Add
> VIR_DUMP_LIVE.
> * src/qemu/qemu_driver.c (qemudDomainCoreDump): Support live dumping.
> * src/xen/xend_internal.c (xenDaemonDomainCoreDump): Support live dumping.
> * tools/virsh.c (opts_dump): Add --live.
> (cmdDump): Map it to VIR_DUMP_LIVE.
> ---
> 	Since there was consensus, here is the patch with the Xen
> 	driver support.  Applies on top of the --crash patch.

ACK, looks good now

Daniel
--

-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Dave Allan | 1 Dec 16:33 2009
Picon

[libvirt] [PATCH] expose SR IOV physical/virtual function relationships

Attached is a patch that exposes the relationships between physical and 
virtual functions on SR IOV capable devices.

Dave
>From cc5b72f99cd472aa0c07d8115e0abc970feab704 Mon Sep 17 00:00:00 2001
From: David Allan <dallan <at> redhat.com>
Date: Mon, 30 Nov 2009 15:58:47 -0500
Subject: [PATCH 1/2] Add SR IOV physical and virtual function relationships

---
 src/conf/node_device_conf.c               |   16 ++++
 src/conf/node_device_conf.h               |    3 +
 src/node_device/node_device_driver.h      |   10 +++
 src/node_device/node_device_hal.c         |    6 ++
 src/node_device/node_device_linux_sysfs.c |  122 ++++++++++++++++++++++++++++-
 5 files changed, 156 insertions(+), 1 deletions(-)

diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
index 6003ab1..4b5d17c 100644
--- a/src/conf/node_device_conf.c
+++ b/src/conf/node_device_conf.c
 <at>  <at>  -246,6 +246,7  <at>  <at>  char *virNodeDeviceDefFormat(virConnectPtr conn,
 {
     virBuffer buf = VIR_BUFFER_INITIALIZER;
     virNodeDevCapsDefPtr caps;
+    unsigned int i = 0;
     char *tmp;

(Continue reading)

Daniel P. Berrange | 1 Dec 17:02 2009
Picon

Re: [libvirt] [PATCH] expose SR IOV physical/virtual function relationships

On Tue, Dec 01, 2009 at 10:33:08AM -0500, Dave Allan wrote:
> Attached is a patch that exposes the relationships between physical and 
> virtual functions on SR IOV capable devices.
> 

> +            if (data->pci_dev.physical_function) {
> +                virBufferEscapeString(&buf, "    <physical_function>%s</physical_function>\n",
> +                                      data->pci_dev.physical_function);
> +            }
> +            if (data->pci_dev.num_virtual_functions > 0) {
> +                for (i = 0 ; i < data->pci_dev.num_virtual_functions ; i++) {
> +                    virBufferEscapeString(&buf, "    <virtual_function>%s</virtual_function>\n",
> +                                          data->pci_dev.virtual_functions[i]);
> +                }
> +            }

What is the actual content of those two new elements ?  Are they
the names of the corresponding device, suitble for a virNodeDevLooupByName() ?

REgards,
Daniel
--

-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

Cole Robinson | 1 Dec 17:43 2009
Picon

[libvirt] [PATCH] nodedev: Add removable storage 'media_label' prop

Provides the CDROM label for current media. Only implemented for the udev
backend.

Signed-off-by: Cole Robinson <crobinso <at> redhat.com>
---
 docs/schemas/nodedev.rng                   |    5 +++++
 src/conf/node_device_conf.c                |    8 ++++++++
 src/conf/node_device_conf.h                |    1 +
 src/node_device/node_device_udev.c         |    5 +++++
 tests/nodedevschemadata/DVD_with_media.xml |   16 ++++++++++++++++
 tests/nodedevxml2xmltest.c                 |    1 +
 6 files changed, 36 insertions(+), 0 deletions(-)
 create mode 100644 tests/nodedevschemadata/DVD_with_media.xml

diff --git a/docs/schemas/nodedev.rng b/docs/schemas/nodedev.rng
index 7060274..797b1af 100644
--- a/docs/schemas/nodedev.rng
+++ b/docs/schemas/nodedev.rng
 <at>  <at>  -314,6 +314,11  <at>  <at> 
       <element name='media_size'>
 	<ref name='uint'/>
       </element>
+      <optional>
+        <element name='media_label'>
+          <text/>
+        </element>
+      </optional>
     </element>
   </define>

(Continue reading)

Cole Robinson | 1 Dec 17:47 2009
Picon

Re: [libvirt] [PATCH] expose SR IOV physical/virtual function relationships

On 12/01/2009 10:33 AM, Dave Allan wrote:
> Attached is a patch that exposes the relationships between physical and 
> virtual functions on SR IOV capable devices.
> 
> Dave
> 

> 
> diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
> index 6003ab1..4b5d17c 100644
> --- a/src/conf/node_device_conf.c
> +++ b/src/conf/node_device_conf.c
>  <at>  <at>  -246,6 +246,7  <at>  <at>  char *virNodeDeviceDefFormat(virConnectPtr conn,
>  {
>      virBuffer buf = VIR_BUFFER_INITIALIZER;
>      virNodeDevCapsDefPtr caps;
> +    unsigned int i = 0;
>      char *tmp;
> 
>      virBufferAddLit(&buf, "<device>\n");
>  <at>  <at>  -318,6 +319,16  <at>  <at>  char *virNodeDeviceDefFormat(virConnectPtr conn,
>                                        data->pci_dev.vendor_name);
>              else
>                  virBufferAddLit(&buf, " />\n");
> +            if (data->pci_dev.physical_function) {
> +                virBufferEscapeString(&buf, "    <physical_function>%s</physical_function>\n",
> +                                      data->pci_dev.physical_function);
> +            }
> +            if (data->pci_dev.num_virtual_functions > 0) {
> +                for (i = 0 ; i < data->pci_dev.num_virtual_functions ; i++) {
(Continue reading)

Jamie Strandboge | 1 Dec 18:00 2009

[libvirt] [PATCH] add AppArmor test and examples to dist

tests/virt-aa-helper-test and examples/apparmor are not included in
official tarballs, but should be. Attached is a patch to fix that
which works when apparmor is and is not available. Thanks to Daniel P.
Berrange for pointing me in the right direction.

Jamie

-- 
Jamie Strandboge             | http://www.canonical.com
tests/virt-aa-helper-test and examples/apparmor are not included in
official tarballs, but should be. Attached is a patch to fix that
which works when apparmor is and is not available. Thanks to Daniel P.
Berrange for pointing me in the right direction.

Jamie

--

-- 
Jamie Strandboge             | http://www.canonical.com
Dave Allan | 1 Dec 18:03 2009
Picon

Re: [libvirt] [PATCH] expose SR IOV physical/virtual function relationships

Daniel P. Berrange wrote:
> On Tue, Dec 01, 2009 at 10:33:08AM -0500, Dave Allan wrote:
>> Attached is a patch that exposes the relationships between physical and 
>> virtual functions on SR IOV capable devices.
>>
> 
> 
>> +            if (data->pci_dev.physical_function) {
>> +                virBufferEscapeString(&buf, "    <physical_function>%s</physical_function>\n",
>> +                                      data->pci_dev.physical_function);
>> +            }
>> +            if (data->pci_dev.num_virtual_functions > 0) {
>> +                for (i = 0 ; i < data->pci_dev.num_virtual_functions ; i++) {
>> +                    virBufferEscapeString(&buf, "    <virtual_function>%s</virtual_function>\n",
>> +                                          data->pci_dev.virtual_functions[i]);
>> +                }
>> +            }
> 
> 
> What is the actual content of those two new elements ?  Are they
> the names of the corresponding device, suitble for a virNodeDevLooupByName() ?

They are the PCI device BDF or config address, e.g.:

     <virtual_function>0000:01:10.0</virtual_function>

so, no, they aren't suitable for lookup by name.  Using the names of the 
corresponding devices was my first attempt, but there is a dependency 
problem there.  At the time that we process one device, the others 
aren't necessarily created in libvirt, so it's not possible to look them 
(Continue reading)

Dave Allan | 1 Dec 18:22 2009
Picon

Re: [libvirt] [PATCH] expose SR IOV physical/virtual function relationships

Cole Robinson wrote:
> On 12/01/2009 10:33 AM, Dave Allan wrote:
>> Attached is a patch that exposes the relationships between physical and 
>> virtual functions on SR IOV capable devices.
>>
>> Dave
>>
> 
>> diff --git a/src/conf/node_device_conf.c b/src/conf/node_device_conf.c
>> index 6003ab1..4b5d17c 100644
>> --- a/src/conf/node_device_conf.c
>> +++ b/src/conf/node_device_conf.c
>>  <at>  <at>  -246,6 +246,7  <at>  <at>  char *virNodeDeviceDefFormat(virConnectPtr conn,
>>  {
>>      virBuffer buf = VIR_BUFFER_INITIALIZER;
>>      virNodeDevCapsDefPtr caps;
>> +    unsigned int i = 0;
>>      char *tmp;
>>
>>      virBufferAddLit(&buf, "<device>\n");
>>  <at>  <at>  -318,6 +319,16  <at>  <at>  char *virNodeDeviceDefFormat(virConnectPtr conn,
>>                                        data->pci_dev.vendor_name);
>>              else
>>                  virBufferAddLit(&buf, " />\n");
>> +            if (data->pci_dev.physical_function) {
>> +                virBufferEscapeString(&buf, "    <physical_function>%s</physical_function>\n",
>> +                                      data->pci_dev.physical_function);
>> +            }
>> +            if (data->pci_dev.num_virtual_functions > 0) {
>> +                for (i = 0 ; i < data->pci_dev.num_virtual_functions ; i++) {
(Continue reading)


Gmane