Re: [libvirt] [PATCHv4] add-vcpu-usage
On Thu, May 31, 2012 at 01:24:11PM +0100, Richard W.M. Jones wrote: On Thu, May 31, 2012 at 06:54:47PM +0800, Hu Tao wrote: Hi Rich, The libvirt counterpart have been already in, do you have time to look at the ocaml-libvirt and virt-top patches? I am intending to look at them, don't worry about that, but I'm busy for the next week. I hope it is still on your todo list to review these two patches:) -- Thanks, Hu Tao -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCHv2 3/3] test: Add test case for nodeinfotest if host machine doesn't have NUMA
Test filling of nodeinfo structure if /sys/devices/system/node does not exist. (Based on dump from a real machine) --- Diff to v1: - add output file --- .../linux-nodeinfo-sysfs-test-5-cpu-x86-output.txt |1 + .../linux-nodeinfo-sysfs-test-5-x86.cpuinfo| 100 .../cpu/cpu0/topology/core_id |1 + .../cpu/cpu0/topology/core_siblings|1 + .../cpu/cpu0/topology/core_siblings_list |1 + .../cpu/cpu0/topology/physical_package_id |1 + .../cpu/cpu0/topology/thread_siblings |1 + .../cpu/cpu0/topology/thread_siblings_list |1 + .../linux-nodeinfo-sysfs-test-5/cpu/cpu1/online|1 + .../cpu/cpu1/topology/core_id |1 + .../cpu/cpu1/topology/core_siblings|1 + .../cpu/cpu1/topology/core_siblings_list |1 + .../cpu/cpu1/topology/physical_package_id |1 + .../cpu/cpu1/topology/thread_siblings |1 + .../cpu/cpu1/topology/thread_siblings_list |1 + .../linux-nodeinfo-sysfs-test-5/cpu/cpu2/online|1 + .../cpu/cpu2/topology/core_id |1 + .../cpu/cpu2/topology/core_siblings|1 + .../cpu/cpu2/topology/core_siblings_list |1 + .../cpu/cpu2/topology/physical_package_id |1 + .../cpu/cpu2/topology/thread_siblings |1 + .../cpu/cpu2/topology/thread_siblings_list |1 + .../linux-nodeinfo-sysfs-test-5/cpu/cpu3/online|1 + .../cpu/cpu3/topology/core_id |1 + .../cpu/cpu3/topology/core_siblings|1 + .../cpu/cpu3/topology/core_siblings_list |1 + .../cpu/cpu3/topology/physical_package_id |1 + .../cpu/cpu3/topology/thread_siblings |1 + .../cpu/cpu3/topology/thread_siblings_list |1 + tests/nodeinfotest.c |1 + 30 files changed, 129 insertions(+), 0 deletions(-) create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5-cpu-x86-output.txt create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5-x86.cpuinfo create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu0/topology/core_id create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu0/topology/core_siblings create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu0/topology/core_siblings_list create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu0/topology/physical_package_id create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu0/topology/thread_siblings create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu0/topology/thread_siblings_list create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu1/online create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu1/topology/core_id create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu1/topology/core_siblings create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu1/topology/core_siblings_list create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu1/topology/physical_package_id create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu1/topology/thread_siblings create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu1/topology/thread_siblings_list create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu2/online create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu2/topology/core_id create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu2/topology/core_siblings create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu2/topology/core_siblings_list create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu2/topology/physical_package_id create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu2/topology/thread_siblings create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu2/topology/thread_siblings_list create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu3/online create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu3/topology/core_id create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu3/topology/core_siblings create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu3/topology/core_siblings_list create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu3/topology/physical_package_id create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu3/topology/thread_siblings create mode 100644 tests/nodeinfodata/linux-nodeinfo-sysfs-test-5/cpu/cpu3/topology/thread_siblings_list diff --git
[libvirt] [PATCHv2 2/3] test: Add new test case for nodeinfotest
This patch adds test data that describe a machine that has two physical processors that don't share same core id's on their cores. On this data the virsh nodeinfo reported that the machine had 10 cores per socket while the processor had only 8. (Before fixing nodeinfo gathering code). --- Diff to v1: --added output file --- .../linux-nodeinfo-sysfs-test-4-cpu-x86-output.txt |1 + .../linux-nodeinfo-sysfs-test-4-x86.cpuinfo| 400 .../cpu/cpu0/topology/core_id |1 + .../cpu/cpu0/topology/physical_package_id |1 + .../cpu/cpu0/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/cpu/cpu1/online|1 + .../cpu/cpu1/topology/core_id |1 + .../cpu/cpu1/topology/physical_package_id |1 + .../cpu/cpu1/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/cpu/cpu10/online |1 + .../cpu/cpu10/topology/core_id |1 + .../cpu/cpu10/topology/physical_package_id |1 + .../cpu/cpu10/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/cpu/cpu11/online |1 + .../cpu/cpu11/topology/core_id |1 + .../cpu/cpu11/topology/physical_package_id |1 + .../cpu/cpu11/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/cpu/cpu12/online |1 + .../cpu/cpu12/topology/core_id |1 + .../cpu/cpu12/topology/physical_package_id |1 + .../cpu/cpu12/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/cpu/cpu13/online |1 + .../cpu/cpu13/topology/core_id |1 + .../cpu/cpu13/topology/physical_package_id |1 + .../cpu/cpu13/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/cpu/cpu14/online |1 + .../cpu/cpu14/topology/core_id |1 + .../cpu/cpu14/topology/physical_package_id |1 + .../cpu/cpu14/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/cpu/cpu15/online |1 + .../cpu/cpu15/topology/core_id |1 + .../cpu/cpu15/topology/physical_package_id |1 + .../cpu/cpu15/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/cpu/cpu2/online|1 + .../cpu/cpu2/topology/core_id |1 + .../cpu/cpu2/topology/physical_package_id |1 + .../cpu/cpu2/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/cpu/cpu3/online|1 + .../cpu/cpu3/topology/core_id |1 + .../cpu/cpu3/topology/physical_package_id |1 + .../cpu/cpu3/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/cpu/cpu4/online|1 + .../cpu/cpu4/topology/core_id |1 + .../cpu/cpu4/topology/physical_package_id |1 + .../cpu/cpu4/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/cpu/cpu5/online|1 + .../cpu/cpu5/topology/core_id |1 + .../cpu/cpu5/topology/physical_package_id |1 + .../cpu/cpu5/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/cpu/cpu6/online|1 + .../cpu/cpu6/topology/core_id |1 + .../cpu/cpu6/topology/physical_package_id |1 + .../cpu/cpu6/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/cpu/cpu7/online|1 + .../cpu/cpu7/topology/core_id |1 + .../cpu/cpu7/topology/physical_package_id |1 + .../cpu/cpu7/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/cpu/cpu8/online|1 + .../cpu/cpu8/topology/core_id |1 + .../cpu/cpu8/topology/physical_package_id |1 + .../cpu/cpu8/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/cpu/cpu9/online|1 + .../cpu/cpu9/topology/core_id |1 + .../cpu/cpu9/topology/physical_package_id |1 + .../cpu/cpu9/topology/thread_siblings |1 + .../linux-nodeinfo-sysfs-test-4/node/node0/cpu0|1 + .../linux-nodeinfo-sysfs-test-4/node/node0/cpu1|1 + .../linux-nodeinfo-sysfs-test-4/node/node0/cpu2|1 + .../linux-nodeinfo-sysfs-test-4/node/node0/cpu3|1 + .../linux-nodeinfo-sysfs-test-4/node/node0/cpu4|1 + .../linux-nodeinfo-sysfs-test-4/node/node0/cpu5|1 + .../linux-nodeinfo-sysfs-test-4/node/node0/cpu6|1 + .../linux-nodeinfo-sysfs-test-4/node/node0/cpu7|1 + .../linux-nodeinfo-sysfs-test-4/node/node0/meminfo | 29 ++ .../linux-nodeinfo-sysfs-test-4/node/node1/cpu10 |1 + .../linux-nodeinfo-sysfs-test-4/node/node1/cpu11 |1 +
[libvirt] [PATCH] [libvirt-java] Fix JNA passing of scheduler parameters
trying to use setSchedulerParameters for the cpu_share was always
ending up setting the value to 2. in practice the JNA code was not
passing the parameter value, letting it uninitialized to zero and
the kernel accepts 2 as the closest value leading to that behaviour.
The code was actually telling JNA which type to use from the enum
but the JNA refused to take it into account possibly because multiple
C types maps to the same Java types and in that case it refuses to
accept setType(class) and simply act as if the information had not
been given (no warning/no error at runtime) !
The workaround is to actually tell it the field name in the enum,
that is accepted and the function works properly once done.
diff --git a/src/main/java/org/libvirt/SchedParameter.java
b/src/main/java/org/libvirt/SchedParameter.java
index ab988e9..1dece56 100644
--- a/src/main/java/org/libvirt/SchedParameter.java
+++ b/src/main/java/org/libvirt/SchedParameter.java
@@ -52,33 +52,33 @@ public abstract class SchedParameter {
switch (param.getType()) {
case (1):
returnValue.value.i = ((SchedIntParameter) param).value;
-returnValue.value.setType(int.class);
+returnValue.value.setType(i);
break;
case (2):
returnValue.value.ui = ((SchedUintParameter) param).value;
-returnValue.value.setType(int.class);
+returnValue.value.setType(ui);
break;
case (3):
returnValue.value.l = ((SchedLongParameter) param).value;
-returnValue.value.setType(long.class);
+returnValue.value.setType(l);
break;
case (4):
returnValue.value.ul = ((SchedUlongParameter) param).value;
-returnValue.value.setType(long.class);
+returnValue.value.setType(ul);
break;
case (5):
returnValue.value.d = ((SchedDoubleParameter) param).value;
-returnValue.value.setType(double.class);
+returnValue.value.setType(d);
break;
case (6):
returnValue.value.b = (byte) (((SchedBooleanParameter)
param).value ? 1 : 0);
-returnValue.value.setType(byte.class);
+returnValue.value.setType(b);
break;
}
return returnValue;
}
-
+
public static byte[] copyOf(byte[] original, int length) {
byte[] returnValue = new byte[length];
int originalLength = original.length ;
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
dan...@veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt-glib v3 2/2] Add GVirConfigDomainCpu class
ACK On Wed, Jun 27, 2012 at 07:35:29PM +0300, Zeeshan Ali (Khattak) wrote: From: Zeeshan Ali (Khattak) zeesha...@gnome.org API to handle 'domain/cpu' nodes. --- libvirt-gconfig/Makefile.am |2 + libvirt-gconfig/libvirt-gconfig-domain-cpu.c | 138 ++ libvirt-gconfig/libvirt-gconfig-domain-cpu.h | 88 libvirt-gconfig/libvirt-gconfig-domain.c | 38 +++ libvirt-gconfig/libvirt-gconfig-domain.h |4 + libvirt-gconfig/libvirt-gconfig.h|1 + libvirt-gconfig/libvirt-gconfig.sym | 14 +++ 7 files changed, 285 insertions(+) create mode 100644 libvirt-gconfig/libvirt-gconfig-domain-cpu.c create mode 100644 libvirt-gconfig/libvirt-gconfig-domain-cpu.h pgpHTaVScBrzk.pgp Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt-glib v3 1/2] Make GVirConfigCapabilitiesCpu.get_features virtual
ACK On Wed, Jun 27, 2012 at 07:35:28PM +0300, Zeeshan Ali (Khattak) wrote: From: Zeeshan Ali (Khattak) zeesha...@gnome.org Also provide helper function for subclasses that will have the exact same implementation except that they'll return instances of another type (subclasses of GVirConfigDomainCpuFeature rather than GVirConfigDomainCpuFeature itself). --- libvirt-gconfig/Makefile.am|1 + .../libvirt-gconfig-capabilities-cpu-private.h | 35 libvirt-gconfig/libvirt-gconfig-capabilities-cpu.c | 42 +++- libvirt-gconfig/libvirt-gconfig-capabilities-cpu.h |4 +- libvirt-gconfig/libvirt-gconfig-private.h |1 + 5 files changed, 71 insertions(+), 12 deletions(-) create mode 100644 libvirt-gconfig/libvirt-gconfig-capabilities-cpu-private.h pgpLoE2ES1T5f.pgp Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] adding more element to interface
Hello people, I am considering adding more elements into interface name space in order to support more features of different hypervisors (specificly qemu). I have discuss thishttps://www.redhat.com/archives/libvirt-users/2012-June/msg00141.htmlin user thread, and I have been told to propose an xml syntax for it. What exactly I have in mind is adding elements like dns, hostname and etc. to set the these variables from within the interface instead of having qemu:commandline at the end of the file, in case of using qemu. So the final xml file should look something like below: domain type='qemu' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0' . . . interface type='user' mac address=/ model type=/ bandwidth /bandwidth address=/* **hostname=/ dns=/ * . . . /interface . . . /domain I am wondering, firstly if such a thing is plausible. And if so, how I can contribute and where I can start from. Thank you in advance. Zamani -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Added the attribute vendor_id to the cpu model
On 27.06.2012 18:29, Michal Privoznik wrote:
On 27.06.2012 18:09, Hendrik Schwartke wrote:
Thank you Michal and Eric for fast
On 27.06.2012 17:22, Eric Blake wrote:
On 06/27/2012 09:14 AM, Michal Privoznik wrote:
On 21.06.2012 16:58, Hendrik Schwartke wrote:
Introducing the attribute vendor_id to force the CPUID instruction
in a kvm guest to return the specified vendor.
---
+optional
+attribute name=vendor_id
+data type=string
+param name='pattern'.{12}/param
Rather than using '.', use [a-zA-Z...] to limit the RNG to the same set
of characters as the C code (I'm not sure what the official set is,
though). I can understand rejecting a too-long name, but do we really
also want to reject a too-short name?
Ok, that right. I will fix the pattern. The reason for rejecting
too-short names is that the CPUID instruction returns the vendor id in
EBX, ECX and EDX, thus the vendor id must be exactly 12 characters long.
So it would be necessary to pad short names in some way. I think the
best way to handle them is to reject them.
+def-mode != VIR_CPU_MODE_HOST_PASSTHROUGH) {
+
+ if(virXPathBoolean(boolean(./model[1]/@fallback),
ctxt)) {
Style: space after 'if'
+ }
+
+ if(virXPathBoolean(boolean(./model[1]/@vendor_id),
ctxt)) {
+ char *vendor_id;
+
+ vendor_id =
virXPathString(string(./model[1]/@vendor_id), ctxt);
+ if(!vendor_id ||
strlen(vendor_id)!=VIR_CPU_VENDOR_ID_LENGTH) {
two more instances. Also, space on both sides of '!='
+ }
+ for(i=0; istrlen(vendor_id); i++) {
space after 'for'
+ if(!isprint(vendor_id[i]) ||
isspace(vendor_id[i])) {
and 'if'
+#define VIR_CPU_VENDOR_ID_LENGTH 12
+
Insert one space between '#' and define so this is indented properly.
'make syntax-check' with 'cppi' installed will flag this for you.
Thanks a lot, that's a very good hint!
@@ -3924,6 +3926,8 @@ qemuBuildCpuArgStr(const struct qemud_driver
*driver,
goto cleanup;
virBufferAdd(buf, guest-model, -1);
+if(guest-vendor_id)
space after 'if'
Otherwise looking good. Can somebody chime in and provide more light on
allowed characters in vendor id?
Well, the Intel instruction manual doesn't make any statement about the
allowed characters.
There are two reasons why I check for printable characters and spaces.
The first is that I think the CPUID instruction is intended that way.
The second is that I want to prevent problems calling qemu. It's for
example not possible to pass spaces in the vendor id to qemu.
Sorry, I can't help there. But I think we've pointed out enough issues
to warrant a v2 submission.
I will rework the patch and post it tomorrow.
According to Wikipedia, it's possible to have spaces in vendor ID:
http://en.wikipedia.org/wiki/CPUID#EAX.3D0:_Get_vendor_ID
e.g. VIA VIA VIA . In that case we need to find a way of telling this
to qemu. What about simple argument closing into quotation marks?
Michal
Yes, you're right. I tested again. The reason for my problem with spaces
was the shell. I had a look at the qemu code and the only character
which is not usable is ','.
I will post the patch shortly.
Hendrik
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Fwd: In Use tracker for network and pci-passthrough devices
This is a conversation that I started with Laine Stump for the implementation of the in-use tracker for network and pci devices. I want to make this conversation more public in order to receive everyone's view on the topic. I will also post the responses I got from Laine and Osier Yang. Many Thanks, Regards, Shradha Shah Original Message Subject: In Use tracker for network and pci-passthrough devices Date: Tue, 26 Jun 2012 12:23:52 +0100 From: Shradha Shah ss...@solarflare.com To: Laine Stump la...@laine.org Laine, I have submitted my v2 patches for forward mode='hostdev' and am planning to work on the in-use tracker for network and pci-passthrough devices. I am unable to wrap my head around how I should be implementing this functionality. I am unable to decide at what level I should be implementing this (network, domain or qemu). May I ask for your guidance in order to implement this functionality? -- Many Thanks, Regards, Shradha Shah -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Added the attribute vendor_id to the cpu model
Introducing the attribute vendor_id to force the CPUID instruction
in a kvm guest to return the specified vendor.
---
docs/schemas/domaincommon.rng |7 +
src/conf/cpu_conf.c | 64 +
src/conf/cpu_conf.h |3 ++
src/qemu/qemu_command.c |6 +++-
tests/testutilsqemu.c |1 +
5 files changed, 68 insertions(+), 13 deletions(-)
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 46e539d..5c55269 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -2820,6 +2820,13 @@
/choice
/attribute
/optional
+ optional
+attribute name=vendor_id
+ data type=string
+param name='pattern'[^,]{12}/param
+ /data
+/attribute
+ /optional
choice
text/
empty/
diff --git a/src/conf/cpu_conf.c b/src/conf/cpu_conf.c
index b520f7c..b3098d8 100644
--- a/src/conf/cpu_conf.c
+++ b/src/conf/cpu_conf.c
@@ -22,6 +22,7 @@
*/
#include config.h
+#include c-ctype.h
#include virterror_internal.h
#include memory.h
@@ -68,6 +69,7 @@ virCPUDefFreeModel(virCPUDefPtr def)
VIR_FREE(def-model);
VIR_FREE(def-vendor);
+VIR_FREE(def-vendor_id);
for (i = 0; i def-nfeatures; i++)
VIR_FREE(def-features[i].name);
@@ -104,6 +106,7 @@ virCPUDefCopyModel(virCPUDefPtr dst,
if ((src-model !(dst-model = strdup(src-model)))
|| (src-vendor !(dst-vendor = strdup(src-vendor)))
+|| (src-vendor_id !(dst-vendor_id = strdup(src-vendor_id)))
|| VIR_ALLOC_N(dst-features, src-nfeatures) 0)
goto no_memory;
dst-nfeatures_max = dst-nfeatures = src-nfeatures;
@@ -288,18 +291,46 @@ virCPUDefParseXML(const xmlNodePtr node,
}
if (def-type == VIR_CPU_TYPE_GUEST
-def-mode != VIR_CPU_MODE_HOST_PASSTHROUGH
-virXPathBoolean(boolean(./model[1]/@fallback), ctxt)) {
-const char *fallback;
-
-fallback = virXPathString(string(./model[1]/@fallback), ctxt);
-if (fallback) {
-def-fallback = virCPUFallbackTypeFromString(fallback);
-VIR_FREE(fallback);
-if (def-fallback 0) {
-virCPUReportError(VIR_ERR_XML_ERROR, %s,
- _(Invalid fallback attribute));
-goto error;
+def-mode != VIR_CPU_MODE_HOST_PASSTHROUGH) {
+
+if (virXPathBoolean(boolean(./model[1]/@fallback), ctxt)) {
+const char *fallback;
+
+fallback =
+virXPathString(string(./model[1]/@fallback), ctxt);
+if (fallback) {
+def-fallback = virCPUFallbackTypeFromString(fallback);
+VIR_FREE(fallback);
+if (def-fallback 0) {
+virCPUReportError(VIR_ERR_XML_ERROR, %s,
+ _(Invalid fallback attribute));
+goto error;
+}
+}
+
+if (virXPathBoolean(boolean(./model[1]/@vendor_id), ctxt)) {
+char *vendor_id;
+
+vendor_id =
+virXPathString(string(./model[1]/@vendor_id), ctxt);
+if (!vendor_id
+|| strlen(vendor_id) != VIR_CPU_VENDOR_ID_LENGTH) {
+virCPUReportError(VIR_ERR_XML_ERROR,
+ _(vendor_id must be exactly %d
characters long),
+ VIR_CPU_VENDOR_ID_LENGTH);
+VIR_FREE(vendor_id);
+goto error;
+}
+/* ensure that the string can be passed to qemu*/
+for (i = 0; i strlen(vendor_id); i++) {
+if (vendor_id[i]==',') {
+virCPUReportError(VIR_ERR_XML_ERROR, %s,
+ _(vendor id is invalid));
+VIR_FREE(vendor_id);
+goto error;
+}
+}
+def-vendor_id = vendor_id;
}
}
}
@@ -588,6 +619,8 @@ virCPUDefFormatBuf(virBufferPtr buf,
return -1;
}
virBufferAsprintf(buf, fallback='%s', fallback);
+if (def-vendor_id)
+virBufferAsprintf(buf, vendor_id='%s', def-vendor_id);
}
if (formatModel def-model) {
virBufferAsprintf(buf, %s/model\n, def-model);
@@ -738,6 +771,13 @@ virCPUDefIsEqual(virCPUDefPtr src,
goto cleanup;
}
+if (STRNEQ_NULLABLE(src-vendor_id, dst-vendor_id)) {
+virCPUReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _(Target CPU model %s does not match source %s),
+ NULLSTR(dst-vendor_id), NULLSTR(src-vendor_id));
+goto cleanup;
+}
+
if (src-sockets != dst-sockets) {
Re: [libvirt] Fwd: In Use tracker for network and pci-passthrough devices: Laine response
This is a reply I got from Laine Stump = (NB: I'm Cc'ing Osier on this email, as he's quite knowledgeable about the PCI passthrough device allocation tracking code. You should probably move this discussion to the mailing list sooner rather than later though, as a public discussion of the design will give you a better chance of your first revision getting successfully past review :-)) On 06/26/2012 07:23 AM, Shradha Shah wrote: Laine, I have submitted my v2 patches for forward mode='hostdev' and am planning to work on the in-use tracker for network and pci-passthrough devices. I am unable to wrap my head around how I should be implementing this functionality. I am unable to decide at what level I should be implementing this (network, domain or qemu). May I ask for your guidance in order to implement this functionality? Yes, but I'm currently on vacation (in Turkey) so I won't have much time to respond until July 9 when I return. In the meantime, I think the right way to do this is by integrating with the code in the qemu driver that keeps track of which PCI devices are in use. This already happens at the very basic level of if the device allocated by the network driver is in use, the attempt to assign the device will fail; instead, the network driver should be able to ask qemu if the device it wants to allocate to the guest is already in use (and reserve it, in one atomic operation). Of course, once the network driver has reserved the device from qemu's PCI passthrough code, it would return that device to the qemu driver code that wants to attach the interface, and it would fail because it would be told the device is already in use (well, yeah! *We* just marked it as in-use!). To make that work, I guess some sort of cookie/handle/pointer would need to be passed from qemu's pci passthrough code back to the network driver, and the network driver would return it back to qemu's network interface attach code, which would then use that special cookie/handle/pointer to attach the device (saying yeah, I know it's already in use, and here's my pass-card). (Talking about this makes me think that the code that keeps track of PCI device allocation shouldn't really be a part of qemu, but should be a separate module, so that the network driver can still function properly even if the qemu driver isn't loaded.) Another twist to this that should be considered - if any particular device is in use by at least one guest for one of the macvtap modes, that device also needs to be marked as in-use in libvirt's pci device table - it would be disastrous if another guest decided to use that device for standard PCI Passthrough. (Keep in mind that I wrote everything above without even once looking at the code or any other reference, so you should take it with a grain of salt!) Many Thanks, Regards, Shradha Shah On 06/28/2012 11:19 AM, Shradha Shah wrote: This is a conversation that I started with Laine Stump for the implementation of the in-use tracker for network and pci devices. I want to make this conversation more public in order to receive everyone's view on the topic. I will also post the responses I got from Laine and Osier Yang. Many Thanks, Regards, Shradha Shah Original Message Subject: In Use tracker for network and pci-passthrough devices Date: Tue, 26 Jun 2012 12:23:52 +0100 From: Shradha Shah ss...@solarflare.com To: Laine Stump la...@laine.org Laine, I have submitted my v2 patches for forward mode='hostdev' and am planning to work on the in-use tracker for network and pci-passthrough devices. I am unable to wrap my head around how I should be implementing this functionality. I am unable to decide at what level I should be implementing this (network, domain or qemu). May I ask for your guidance in order to implement this functionality? -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Fwd: In Use tracker for network and pci-passthrough devices: Laine response
This is a reply from Osier Yang
On 2012年06月27日 04:02, Laine Stump wrote:
(NB: I'm Cc'ing Osier on this email, as he's quite knowledgeable about
the PCI passthrough device allocation tracking code. You should probably
move this discussion to the mailing list sooner rather than later
though, as a public discussion of the design will give you a better
chance of your first revision getting successfully past review :-))
On 06/26/2012 07:23 AM, Shradha Shah wrote:
Laine,
I have submitted my v2 patches for forward mode='hostdev' and am planning to
work on the in-use tracker for network
and pci-passthrough devices.
I am unable to wrap my head around how I should be implementing this
functionality. I am unable to decide at what
level I should be implementing this (network, domain or qemu).
May I ask for your guidance in order to implement this functionality?
Yes, but I'm currently on vacation (in Turkey) so I won't have much time
to respond until July 9 when I return.
In the meantime, I think the right way to do this is by integrating with
the code in the qemu driver that keeps track of which PCI devices are in
use. This already happens at the very basic level of if the device
allocated by the network driver is in use, the attempt to assign the
device will fail; instead, the network driver should be able to ask
qemu if the device it wants to allocate to the guest is already in use
(and reserve it, in one atomic operation).
Hi, Shradha, Laine,
I have not read your patches for forward=hostdev carefully, so
not sure if I can give right direction, but let me try:
It looks like what you will do is just reserve the vf or pf from host,
and when the vf/pf is attached to domain or used in other ways, you
want it to be marked as in-use, am I correct?
If so, it should be not hard to do, for each PCI device, we have a
field named used_by, to stores the domain name which uses it, and in
qemu driver, we have two list activePciHostdevs, inactivePciHostdevs
of pciDeviceList type.
activePciHostdevs holds the PCI devices which are in used by all
the qemu domains, and inactivePciHostdevs holds the PCI devices
detached from the host, and not used by any domain. Basicly the purpose
of inactivePciHostdevs is to resolve the problem of pci device
resetting on two PCI devices share the same bus. See commit 6be610bf
for more details.
So that means, updating the used_by field of the pci device,
activePciHostdevs, and inactivePciHostdevs all happens
while attaching the interface to domain, or detaching it from the
domain, or when domain starting, or when the domain is shutdown.
E.g, attaching the interface to domain (assuming the attachment
succeeded), it needs to do:
1) Set used_by as the domain name
2) Insert the device to activePciHostdevs list.
3) Remove the device from inactivePciHostdevs list if it was
there.
Porcess of detaching is just opposite with above. However, the
whole process is much more complicated than the 3 listed steps.
I found you introduce new members for virNetworkForwardIfDef:
struct _virNetworkForwardIfDef {
-char *dev; /* name of device */
+int type;
+union {
+virDevicePCIAddress pci; /*PCI Address of device */
+/* when USB devices are supported a new variable to be added here */
+char *dev; /* name of device */
+}device;
+int usageCount; /* how many guest interfaces are bound to this device? */
+};
So why don't use pciDevice. e.g.
struct _virNetworkForwardIfDef {
char *dev; /* name of device */
int type;
union {
pciDevice pci; /*PCI Address of device */
/* when USB devices are supported a new variable to be added here */
char *dev; /* name of device */
} device;
int usageCount; /* how many guest interfaces are bound to this device? */
};
You can add usbDevice there once it's supported. That means
you can reuse the existed codes for pci and devices management
of qemu driver.
Of course, once the network driver has reserved the device from qemu's
PCI passthrough code, it would return that device to the qemu driver
code that wants to attach the interface, and it would fail because it
would be told the device is already in use (well, yeah! *We* just marked
it as in-use!). To make that work, I guess some sort of
cookie/handle/pointer would need to be passed from qemu's pci
passthrough code back to the network driver, and the network driver
would return it back to qemu's network interface attach code, which
would then use that special cookie/handle/pointer to attach the device
(saying yeah, I know it's already in use, and here's my pass-card).
(Talking about this makes me think that the code that keeps track of PCI
device allocation shouldn't really be a part of qemu, but should be a
separate module, so that the network driver can still
Re: [libvirt] Fwd: In Use tracker for network and pci-passthrough devices: Laine response
On 06/27/2012 09:03 AM, Osier Yang wrote:
On 2012年06月27日 04:02, Laine Stump wrote:
(NB: I'm Cc'ing Osier on this email, as he's quite knowledgeable about
the PCI passthrough device allocation tracking code. You should probably
move this discussion to the mailing list sooner rather than later
though, as a public discussion of the design will give you a better
chance of your first revision getting successfully past review :-))
On 06/26/2012 07:23 AM, Shradha Shah wrote:
Laine,
I have submitted my v2 patches for forward mode='hostdev' and am
planning to work on the in-use tracker for network
and pci-passthrough devices.
I am unable to wrap my head around how I should be implementing this
functionality. I am unable to decide at what
level I should be implementing this (network, domain or qemu).
May I ask for your guidance in order to implement this functionality?
Yes, but I'm currently on vacation (in Turkey) so I won't have much time
to respond until July 9 when I return.
In the meantime, I think the right way to do this is by integrating with
the code in the qemu driver that keeps track of which PCI devices are in
use. This already happens at the very basic level of if the device
allocated by the network driver is in use, the attempt to assign the
device will fail; instead, the network driver should be able to ask
qemu if the device it wants to allocate to the guest is already in use
(and reserve it, in one atomic operation).
Hi, Shradha, Laine,
I have not read your patches for forward=hostdev carefully, so
not sure if I can give right direction, but let me try:
It looks like what you will do is just reserve the vf or pf from host,
and when the vf/pf is attached to domain or used in other ways, you
want it to be marked as in-use, am I correct?
Correct. Currently the network driver picks a device from its pool and
returns it to qemu having no idea if maybe that device is already used
in some other way. By the time we get back to qemu and learn that the
device is already used, the best we can do is fail, which is less than
ideal :-)
If so, it should be not hard to do, for each PCI device, we have a
field named used_by, to stores the domain name which uses it, and in
qemu driver, we have two list activePciHostdevs, inactivePciHostdevs
of pciDeviceList type.
activePciHostdevs holds the PCI devices which are in used by all
the qemu domains, and inactivePciHostdevs holds the PCI devices
detached from the host, and not used by any domain. Basicly the purpose
of inactivePciHostdevs is to resolve the problem of pci device
resetting on two PCI devices share the same bus. See commit 6be610bf
for more details.
So that means, updating the used_by field of the pci device,
activePciHostdevs, and inactivePciHostdevs all happens
while attaching the interface to domain, or detaching it from the
domain, or when domain starting, or when the domain is shutdown.
E.g, attaching the interface to domain (assuming the attachment
succeeded), it needs to do:
1) Set used_by as the domain name
2) Insert the device to activePciHostdevs list.
3) Remove the device from inactivePciHostdevs list if it was
there.
The trick is to do enough of that in networkAllocateActualDevice to
assure that 1) the device won't be used by someone else, 2) the guest
that's grabbing the device *can* use it, and 3) the right thing will
happen if libvirtd is restarted sometime after the device is reserved
but before the guest is started.
Porcess of detaching is just opposite with above. However, the
whole process is much more complicated than the 3 listed steps.
I found you introduce new members for virNetworkForwardIfDef:
struct _virNetworkForwardIfDef {
-char *dev; /* name of device */
+int type;
+union {
+virDevicePCIAddress pci; /*PCI Address of device */
+/* when USB devices are supported a new variable to be added
here */
+char *dev; /* name of device */
+}device;
+int usageCount; /* how many guest interfaces are bound to this
device? */
+};
So why don't use pciDevice. e.g.
In general I think it would be a good idea to unify pciDevice,
virDevicePCIAddress, and pci_config_address as much as possible, but
pciDevice itself has a lot of fields that don't make sense in a
configuration object, and anyway currently all the other conf code
(including hostdev definitions) uses virDevicePCIAddress, and there is
already code to parse/format to/from a virDevicePCIAddress. As a matter
of fact, pciDevice is defined in pci.c, so it can't be used anywhere
else, and the API presented by pci.h uses individual components (domain,
bus, slot, function) when it needs to describe a PCI device.
So for now at least, I think virNetworkForwardIfDef should use
virDevicePCIAddress, like the other *_conf code; when the network driver
needs to call the APIs
Re: [libvirt] Fwd: In Use tracker for network and pci-passthrough devices: Laine response
On 06/28/2012 11:33 AM, Shradha Shah wrote: This is a reply I got from Laine Stump = (NB: I'm Cc'ing Osier on this email, as he's quite knowledgeable about the PCI passthrough device allocation tracking code. You should probably move this discussion to the mailing list sooner rather than later though, as a public discussion of the design will give you a better chance of your first revision getting successfully past review :-)) On 06/26/2012 07:23 AM, Shradha Shah wrote: Laine, I have submitted my v2 patches for forward mode='hostdev' and am planning to work on the in-use tracker for network and pci-passthrough devices. I am unable to wrap my head around how I should be implementing this functionality. I am unable to decide at what level I should be implementing this (network, domain or qemu). May I ask for your guidance in order to implement this functionality? Yes, but I'm currently on vacation (in Turkey) so I won't have much time to respond until July 9 when I return. In the meantime, I think the right way to do this is by integrating with the code in the qemu driver that keeps track of which PCI devices are in use. This already happens at the very basic level of if the device allocated by the network driver is in use, the attempt to assign the device will fail; instead, the network driver should be able to ask qemu if the device it wants to allocate to the guest is already in use (and reserve it, in one atomic operation). Of course, once the network driver has reserved the device from qemu's PCI passthrough code, it would return that device to the qemu driver code that wants to attach the interface, and it would fail because it would be told the device is already in use (well, yeah! *We* just marked it as in-use!). To make that work, I guess some sort of cookie/handle/pointer would need to be passed from qemu's pci passthrough code back to the network driver, and the network driver would return it back to qemu's network interface attach code, which would then use that special cookie/handle/pointer to attach the device (saying yeah, I know it's already in use, and here's my pass-card). Wouldn't this approach require network driver to call functions from the qemu driver? I think this is not good for the hierarchical structure we are trying to maintain. (Talking about this makes me think that the code that keeps track of PCI device allocation shouldn't really be a part of qemu, but should be a separate module, so that the network driver can still function properly even if the qemu driver isn't loaded.) Would this mean moving code to a new driver called device_driver.c or devicetracker_driver.c (which consumes device_conf.ch) and is called by network, domain and qemu drivers? If so, I like this approach. Another twist to this that should be considered - if any particular device is in use by at least one guest for one of the macvtap modes, that device also needs to be marked as in-use in libvirt's pci device table - it would be disastrous if another guest decided to use that device for standard PCI Passthrough. Agreed. (Keep in mind that I wrote everything above without even once looking at the code or any other reference, so you should take it with a grain of salt!) Many Thanks, Regards, Shradha Shah On 06/28/2012 11:19 AM, Shradha Shah wrote: This is a conversation that I started with Laine Stump for the implementation of the in-use tracker for network and pci devices. I want to make this conversation more public in order to receive everyone's view on the topic. I will also post the responses I got from Laine and Osier Yang. Many Thanks, Regards, Shradha Shah Original Message Subject: In Use tracker for network and pci-passthrough devices Date: Tue, 26 Jun 2012 12:23:52 +0100 From: Shradha Shah ss...@solarflare.com To: Laine Stump la...@laine.org Laine, I have submitted my v2 patches for forward mode='hostdev' and am planning to work on the in-use tracker for network and pci-passthrough devices. I am unable to wrap my head around how I should be implementing this functionality. I am unable to decide at what level I should be implementing this (network, domain or qemu). May I ask for your guidance in order to implement this functionality? -- 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] adding more element to interface
On 28.06.2012 10:23, Rashid Zamani wrote: Hello people, I am considering adding more elements into interface name space in order to support more features of different hypervisors (specificly qemu). I have discuss this https://www.redhat.com/archives/libvirt-users/2012-June/msg00141.html in user thread, and I have been told to propose an xml syntax for it. What exactly I have in mind is adding elements like dns, hostname and etc. to set the these variables from within the interface instead of having qemu:commandline at the end of the file, in case of using qemu. So the final xml file should look something like below: domain type='qemu' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0' . . . interface type='user' mac address=/ model type=/ bandwidth /bandwidth address=/* **hostname=/ dns=/ * . . . /interface . . . /domain I am wondering, firstly if such a thing is plausible. And if so, how I can contribute and where I can start from. Thank you in advance. Zamani There is how-to add an XML extension on libvirt site: http://libvirt.org/api_extension.html Since you'll be adding just an XML elements not an API you may skip some steps there. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Fwd: In Use tracker for network and pci-passthrough devices: Laine response
Osier, Many thanks for your input.
Comments inline.
On 06/28/2012 11:48 AM, Shradha Shah wrote:
This is a reply from Osier Yang
On 2012年06月27日 04:02, Laine Stump wrote:
(NB: I'm Cc'ing Osier on this email, as he's quite knowledgeable about
the PCI passthrough device allocation tracking code. You should probably
move this discussion to the mailing list sooner rather than later
though, as a public discussion of the design will give you a better
chance of your first revision getting successfully past review :-))
On 06/26/2012 07:23 AM, Shradha Shah wrote:
Laine,
I have submitted my v2 patches for forward mode='hostdev' and am planning
to work on the in-use tracker for network
and pci-passthrough devices.
I am unable to wrap my head around how I should be implementing this
functionality. I am unable to decide at what
level I should be implementing this (network, domain or qemu).
May I ask for your guidance in order to implement this functionality?
Yes, but I'm currently on vacation (in Turkey) so I won't have much time
to respond until July 9 when I return.
In the meantime, I think the right way to do this is by integrating with
the code in the qemu driver that keeps track of which PCI devices are in
use. This already happens at the very basic level of if the device
allocated by the network driver is in use, the attempt to assign the
device will fail; instead, the network driver should be able to ask
qemu if the device it wants to allocate to the guest is already in use
(and reserve it, in one atomic operation).
Hi, Shradha, Laine,
I have not read your patches for forward=hostdev carefully, so
not sure if I can give right direction, but let me try:
It looks like what you will do is just reserve the vf or pf from host,
and when the vf/pf is attached to domain or used in other ways, you
want it to be marked as in-use, am I correct?
If so, it should be not hard to do, for each PCI device, we have a
field named used_by, to stores the domain name which uses it, and in
qemu driver, we have two list activePciHostdevs, inactivePciHostdevs
of pciDeviceList type.
activePciHostdevs holds the PCI devices which are in used by all
the qemu domains, and inactivePciHostdevs holds the PCI devices
detached from the host, and not used by any domain. Basicly the purpose
of inactivePciHostdevs is to resolve the problem of pci device
resetting on two PCI devices share the same bus. See commit 6be610bf
for more details.
So that means, updating the used_by field of the pci device,
activePciHostdevs, and inactivePciHostdevs all happens
while attaching the interface to domain, or detaching it from the
domain, or when domain starting, or when the domain is shutdown.
E.g, attaching the interface to domain (assuming the attachment
succeeded), it needs to do:
1) Set used_by as the domain name
2) Insert the device to activePciHostdevs list.
3) Remove the device from inactivePciHostdevs list if it was
there.
Porcess of detaching is just opposite with above. However, the
whole process is much more complicated than the 3 listed steps.
This approach is easier to implement but this would mean that we
have to access the qemu driver from the network driver since we need
to make a decision about device usage in networkAllocateActualDevice.
This messes with the hierarchy I think.
I found you introduce new members for virNetworkForwardIfDef:
struct _virNetworkForwardIfDef {
-char *dev; /* name of device */
+int type;
+union {
+virDevicePCIAddress pci; /*PCI Address of device */
+/* when USB devices are supported a new variable to be added here */
+char *dev; /* name of device */
+}device;
+int usageCount; /* how many guest interfaces are bound to this device? */
+};
So why don't use pciDevice. e.g.
struct _virNetworkForwardIfDef {
char *dev; /* name of device */
int type;
union {
pciDevice pci; /*PCI Address of device */
/* when USB devices are supported a new variable to be added here */
char *dev; /* name of device */
} device;
int usageCount; /* how many guest interfaces are bound to this device? */
};
You can add usbDevice there once it's supported. That means
you can reuse the existed codes for pci and devices management
of qemu driver.
I was thinking of having a new driver called devicetracker_driver.c that
consumes device_conf.ch and is used in domain, network and qemu drivers.
Of course, once the network driver has reserved the device from qemu's
PCI passthrough code, it would return that device to the qemu driver
code that wants to attach the interface, and it would fail because it
would be told the device is already in use (well, yeah! *We* just marked
it as in-use!). To make that work, I
Re: [libvirt] Fwd: In Use tracker for network and pci-passthrough devices: Laine response
On 06/28/2012 05:21 AM, Shradha Shah wrote: In the meantime, I think the right way to do this is by integrating with the code in the qemu driver that keeps track of which PCI devices are in use. This already happens at the very basic level of if the device allocated by the network driver is in use, the attempt to assign the device will fail; instead, the network driver should be able to ask qemu if the device it wants to allocate to the guest is already in use (and reserve it, in one atomic operation). Of course, once the network driver has reserved the device from qemu's PCI passthrough code, it would return that device to the qemu driver code that wants to attach the interface, and it would fail because it would be told the device is already in use (well, yeah! *We* just marked it as in-use!). To make that work, I guess some sort of cookie/handle/pointer would need to be passed from qemu's pci passthrough code back to the network driver, and the network driver would return it back to qemu's network interface attach code, which would then use that special cookie/handle/pointer to attach the device (saying yeah, I know it's already in use, and here's my pass-card). Wouldn't this approach require network driver to call functions from the qemu driver? I think this is not good for the hierarchical structure we are trying to maintain. Agreed, we need to move device tracking out of qemu and into common reusable code. (Talking about this makes me think that the code that keeps track of PCI device allocation shouldn't really be a part of qemu, but should be a separate module, so that the network driver can still function properly even if the qemu driver isn't loaded.) Would this mean moving code to a new driver called device_driver.c or devicetracker_driver.c (which consumes device_conf.ch) and is called by network, domain and qemu drivers? Maybe even name it src/conf/nodedev_conf.[ch], since it deals with handling of node devices. But yes, the idea of a common file in src/conf that can then be shared between network and qemu drivers makes sense. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Wire up loader to set the QEMU BIOS path
On 04/10/2012 08:03 AM, Daniel P. Berrange wrote:
From: Daniel P. Berrange berra...@redhat.com
* src/qemu/qemu_command.c: Wire up -bios with loader
* tests/qemuxml2argvdata/qemuxml2argv-bios.args,
tests/qemuxml2argvdata/qemuxml2argv-bios.xml: Expand
existing BIOS test case to cover loader
---
src/qemu/qemu_command.c |9 +
tests/qemuxml2argvdata/qemuxml2argv-bios.args |3 ++-
tests/qemuxml2argvdata/qemuxml2argv-bios.xml |1 +
3 files changed, 12 insertions(+), 1 deletions(-)
I just realized (thanks to
https://bugzilla.redhat.com/show_bug.cgi?id=836145) that we never
documented how to use loader to influence whether a guest will be
started with a BIOS that advertises or suppresses S3 support (since
there are definitely guests that do not work if S3 is advertised). We
need a followup patch to formatdomain.html.in, since it currently claims
that the loader sublement is only useful for Xen.
+++ b/src/qemu/qemu_command.c
@@ -4052,6 +4052,11 @@ qemuBuildCommandLine(virConnectPtr conn,
if (enableKVM)
virCommandAddArg(cmd, -enable-kvm);
+if (def-os.loader) {
+virCommandAddArg(cmd, -bios);
+virCommandAddArg(cmd, def-os.loader);
+}
+
/* Set '-m MB' based on maxmem, because the lower 'memory' limit
* is set post-startup using the balloon driver. If balloon driver
* is not supported, then they're out of luck anyway. Update the
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv4 3/6] vbox: Add support for virConnectListAllDomains()
On 20.06.2012 15:33, Peter Krempa wrote:
VirtualBox doesn't use the common virDomainObj implementation so this
patch adds a separate implementation using the VirtualBox API.
This driver implementation supports all currently defined flags. As
VirtualBox does not support transient guests, managed save images and
autostarting we assume all guests are persistent, don't have a managed
save image and are not autostarted. Filtering for existence of those
properities results in empty list.
---
Diff to v3:
-tweaked style
-done some testing on useful flag combinations
-Did not change two problematic places pointed out by Eric in his review:
Explanation in older thread.
---
src/vbox/vbox_tmpl.c | 170
++
1 files changed, 170 insertions(+), 0 deletions(-)
diff --git a/src/vbox/vbox_tmpl.c b/src/vbox/vbox_tmpl.c
index 4b0ee2e..b83d577 100644
--- a/src/vbox/vbox_tmpl.c
+++ b/src/vbox/vbox_tmpl.c
@@ -57,6 +57,7 @@
#include virfile.h
#include fdstream.h
#include viruri.h
+#include virdomainlist.h
/* This one changes from version to version. */
#if VBOX_API_VERSION == 2002
@@ -9097,6 +9098,174 @@ endjob:
}
#endif /* VBOX_API_VERSION = 4000 */
+
+#define MATCH(FLAG) (flags (FLAG))
+static int
+vboxListAllDomains(virConnectPtr conn,
+ virDomainPtr **domains,
+ unsigned int flags)
+{
+VBOX_OBJECT_CHECK(conn, int, -1);
+vboxArray machines = VBOX_ARRAY_INITIALIZER;
+char *machineNameUtf8 = NULL;
+PRUnichar *machineNameUtf16 = NULL;
+unsigned char uuid[VIR_UUID_BUFLEN];
+vboxIID iid = VBOX_IID_INITIALIZER;
+PRUint32 state;
+nsresult rc;
+int i;
+virDomainPtr dom;
+virDomainPtr *doms = NULL;
+int count = 0;
+bool active;
+PRUint32 snapshotCount;
+
+virCheckFlags(VIR_CONNECT_LIST_FILTERS_ALL, -1);
+
+/* filter out flag options that will produce 0 results in vbox driver:
+ * - managed save: vbox guests don't have managed save images
+ * - autostart: vbox doesn't support autostarting guests
+ * - persistance: vbox doesn't support transient guests
+ */
+if ((MATCH(VIR_CONNECT_LIST_DOMAINS_TRANSIENT)
+ !MATCH(VIR_CONNECT_LIST_DOMAINS_PERSISTENT)) ||
+(MATCH(VIR_CONNECT_LIST_DOMAINS_AUTOSTART)
+ !MATCH(VIR_CONNECT_LIST_DOMAINS_NO_AUTOSTART)) ||
+(MATCH(VIR_CONNECT_LIST_DOMAINS_MANAGEDSAVE)
+ !MATCH(VIR_CONNECT_LIST_DOMAINS_NO_MANAGEDSAVE))) {
+if (domains
+VIR_ALLOC_N(*domains, 1) 0)
+goto no_memory;
+
+ret = 0;
+goto cleanup;
+}
+
+rc = vboxArrayGet(machines, data-vboxObj,
data-vboxObj-vtbl-GetMachines);
+if (NS_FAILED(rc)) {
+vboxError(VIR_ERR_INTERNAL_ERROR,
+ _(Could not get list of domains, rc=%08x), (unsigned)rc);
+goto cleanup;
+}
+
+if (domains
+VIR_ALLOC_N(doms, machines.count + 1) 0)
+goto no_memory;
+
+for (i = 0; i machines.count; i++) {
+IMachine *machine = machines.items[i];
+
+if (machine) {
+PRBool isAccessible = PR_FALSE;
+machine-vtbl-GetAccessible(machine, isAccessible);
+if (isAccessible) {
+machine-vtbl-GetState(machine, state);
+
+if (state = MachineState_FirstOnline
+state = MachineState_LastOnline)
+active = true;
+else
+active = false;
+
+/* filter by active state */
+if (MATCH(VIR_CONNECT_LIST_FILTERS_ACTIVE)
+!((MATCH(VIR_CONNECT_LIST_DOMAINS_ACTIVE) active) ||
+ (MATCH(VIR_CONNECT_LIST_DOMAINS_INACTIVE) !active)))
+continue;
+
+/* filter by snapshot existence */
+if (MATCH(VIR_CONNECT_LIST_FILTERS_SNAPSHOT)) {
+rc = machine-vtbl-GetSnapshotCount(machine,
snapshotCount);
+if (NS_FAILED(rc)) {
+vboxError(VIR_ERR_INTERNAL_ERROR,
+ _(could not get snapshot count for listed
domains));
+goto cleanup;
+}
+if (!((MATCH(VIR_CONNECT_LIST_DOMAINS_HAS_SNAPSHOT)
+ snapshotCount 0) ||
+ (MATCH(VIR_CONNECT_LIST_DOMAINS_NO_SNAPSHOT)
+ snapshotCount == 0)))
+continue;
+}
+
+/* filter by machine state */
+if (MATCH(VIR_CONNECT_LIST_FILTERS_STATE)
+!((MATCH(VIR_CONNECT_LIST_DOMAINS_RUNNING)
+ state == MachineState_Running) ||
+ (MATCH(VIR_CONNECT_LIST_DOMAINS_PAUSED)
+
Re: [libvirt] [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd
On Wed, 27 Jun 2012 10:58:01 +0200 Kevin Wolf kw...@redhat.com wrote: Am 26.06.2012 20:40, schrieb Corey Bryant: Here is a quick proof of concept (ie untested) patch to demonstrate what I mean. It relies on Cory's patch which converts everything to use qemu_open. It is also still valuable to make the change to qemu_open() to support /dev/fd/N for passing FDs during QEMU initial startup for CLI args. IMHO, what I propose here is preferrable for QMP clients that our current plan of requiring use of 3 monitor commands (passfd, X, closefd). Thanks for the PoC. Two other required updates that I can think of would be: 1) Update change, block_stream, block_reopen, snapshot_blkdev, and perhaps other monitor commands to support receiving fd's via SCM_RIGHTS. Nevermind my comment. I see that your PoC supports passing nfds for any QMP command. I'm curious what Kevin's thoughts are on this and the overall approach. I'm not against introducing this nfd thing as a general feature for QMP commands instead of a separate pass-fd command. It's not obvious to me that everyone would agree with that, so let's CC Luiz at least. I don't have objections either, but I want to point out two things. First, we've agreed on adding new commands instead of extending existing ones. I feel that not everyone is agreement with this and maybe we could revisit this topic, but in principle new commands should be added. Secondly, this is just a small suggestion, but we're in a point in time where several block commands are being added. I think it's a good moment to think hard how the ideal block API would look like and try to design new commands based on that. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv4 3/6] vbox: Add support for virConnectListAllDomains()
On 06/28/12 14:58, Michal Privoznik wrote:
On 20.06.2012 15:33, Peter Krempa wrote:
VirtualBox doesn't use the common virDomainObj implementation so this
patch adds a separate implementation using the VirtualBox API.
This driver implementation supports all currently defined flags. As
VirtualBox does not support transient guests, managed save images and
autostarting we assume all guests are persistent, don't have a managed
save image and are not autostarted. Filtering for existence of those
properities results in empty list.
---
...
+
+machine-vtbl-GetName(machine, machineNameUtf16);
+VBOX_UTF16_TO_UTF8(machineNameUtf16, machineNameUtf8);
+machine-vtbl-GetId(machine, iid.value);
+vboxIIDToUUID(iid, uuid);
+vboxIIDUnalloc(iid);
+
+dom = virGetDomain(conn, machineNameUtf8, uuid);
+
+if (machineNameUtf8) {
+VBOX_UTF8_FREE(machineNameUtf8);
+machineNameUtf8 = NULL;
+}
+
+if (machineNameUtf16) {
+VBOX_COM_UNALLOC_MEM(machineNameUtf16);
+machineNameUtf16 = NULL;
+}
These two checks for !NULL are useless.
Indeed. I verified that in the Vbox XPCOM code.
+
+if (!dom)
+goto no_memory;
+
+if (active)
...
+ignore_value(VIR_REALLOC_N(doms, count + 1));
+*domains = doms;
+}
+doms = NULL;
This assignment can be moved into the body of if statement. But that's
just small optimization.
+ret = count;
+
+cleanup:
+if (doms) {
+for (i = 0; i count; i++) {
+if (doms[i])
ACK with those nits fixed.
Michal
I've fix them and pushed. Thanks for the reveiw.
Peter
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv4 6/6] maint: include ignore-value in internal.h
On 06/20/12 15:33, Peter Krempa wrote: The ignore_value macro is used across libvirt. This patch includes it in the internal header and cleans all other includes. --- No change, just bumping if anybody has objections. --- Nobody objected by now, so following Eric's conditional ACK I went ahead and pushed this patch. Thanks. Peter -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] conf: Don't shadow error from virGetDomain()
virGetDomain() does a good job of reporting errors itself. This patch
removes shadowing of that error in virDomainListPopulate().
---
src/conf/virdomainlist.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/src/conf/virdomainlist.c b/src/conf/virdomainlist.c
index f9fbde8..2b0b878 100644
--- a/src/conf/virdomainlist.c
+++ b/src/conf/virdomainlist.c
@@ -117,8 +117,10 @@ virDomainListPopulate(void *payload,
return;
}
-if (!(dom = virGetDomain(data-conn, vm-def-name, vm-def-uuid)))
-goto no_memory;
+if (!(dom = virGetDomain(data-conn, vm-def-name, vm-def-uuid))) {
+data-error = true;
+goto cleanup;
+}
dom-id = vm-def-id;
@@ -127,11 +129,6 @@ virDomainListPopulate(void *payload,
cleanup:
virDomainObjUnlock(vm);
return;
-
-no_memory:
-virReportOOMError();
-data-error = true;
-goto cleanup;
}
#undef MATCH
--
1.7.8.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] [PATCH v4 0/7] file descriptor passing using pass-fd
On 06/27/2012 05:51 AM, Kevin Wolf wrote: Am 27.06.2012 11:20, schrieb Daniel P. Berrange: On Wed, Jun 27, 2012 at 11:16:32AM +0200, Kevin Wolf wrote: The really bad case that nobody thought of is that, when block-commit has finished, we need to switch back to read-only. This is an event that is not triggered by a certain monitor command, but that comes from inside qemu. I'm almost sure that we'll see more of this as we add more asynchronous commands. This only works if we can pass the new file descriptor in advance. It would work nicely if you go with pass-fd and actually maintain a list of file descriptors for each /dev/fd/N, along with the different flags the file descriptors are meant for. I can't see how it would work with the temporary /dev/fdlist/N or the fd:name approach because they both imply that the original file descriptors are closed by the time that the QMP command returns. What I don't understand though is that when you're reopening FDs, with the pass-fd command approach, you're merely dup'ing the original FDs that was passed in from the client. Why can't you alternatively just dup the FD you already have. That's easy: Because I don't know that I'm dealing with an FD. I think originally the whole point in this /dev/fd/ thing was that it would transparently enable the functionality for all parts of qemu: The block layer, of course, but also new char devices, migration targets, screenshot files or whatever else can deal with files. In this design the block layer doesn't even know that it's not a regular file. If we now decided to go for a design where the /dev/fd path isn't enough, but changes are needed to each subsystem where it should work, then this point doesn't apply any more and I cast my vote for abandoning everything starting with /dev/ and introducing a proper fd: protocol in the block layer, so that the block layer at least has a chance to know that it has to do treat this file specially. I don't see why we need to keep the original FD around forever. If the QMP command handler nees the temporary /dev/fdlist/N file to exist for longer than the duration of the command, it can simply dup() it to get a permanent copy of its own. If we're not going to make it transparent and if we don't care about QMP command bloat, we can choose completely different designs, yes. And then qemu could probably try to internally work around a suboptimal API. Kevin Are there any more thoughts on how to move forward with this? It seems like we're at a stand-still with the discussion. -- Regards, Corey -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] conf: Don't shadow error from virGetDomain()
On 06/28/2012 08:35 AM, Peter Krempa wrote: virGetDomain() does a good job of reporting errors itself. This patch removes shadowing of that error in virDomainListPopulate(). --- src/conf/virdomainlist.c | 11 --- 1 files changed, 4 insertions(+), 7 deletions(-) ACK. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] conf: Don't shadow error from virGetDomain()
On 06/28/12 17:21, Eric Blake wrote: On 06/28/2012 08:35 AM, Peter Krempa wrote: virGetDomain() does a good job of reporting errors itself. This patch removes shadowing of that error in virDomainListPopulate(). --- src/conf/virdomainlist.c | 11 --- 1 files changed, 4 insertions(+), 7 deletions(-) ACK. Pushed; Thanks! Peter -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] network_conf: Don't free uninitialized pointers while parsing DNS SRV
If the user specified invalid protocol type in a network's SRV record
the error path ended up in freeing uninitialized pointers causing a
daemon crash.
*network_conf.c: virNetworkDNSSrvDefParseXML(): initialize local
variables
---
src/conf/network_conf.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c
index 60cd888..515bc36 100644
--- a/src/conf/network_conf.c
+++ b/src/conf/network_conf.c
@@ -574,10 +574,10 @@ virNetworkDNSSrvDefParseXML(virNetworkDNSDefPtr def,
xmlNodePtr cur,
xmlXPathContextPtr ctxt)
{
-char *domain;
-char *service;
-char *protocol;
-char *target;
+char *domain = NULL;
+char *service = NULL;
+char *protocol = NULL;
+char *target = NULL;
int port;
int priority;
int weight;
--
1.7.8.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] network_conf: Don't free uninitialized pointers while parsing DNS SRV
On 06/28/2012 03:48 PM, Peter Krempa wrote: If the user specified invalid protocol type in a network's SRV record the error path ended up in freeing uninitialized pointers causing a daemon crash. *network_conf.c: virNetworkDNSSrvDefParseXML(): initialize local variables --- src/conf/network_conf.c |8 1 files changed, 4 insertions(+), 4 deletions(-) ACK. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] network_conf: Don't free uninitialized pointers while parsing DNS SRV
On 06/28/12 23:52, Eric Blake wrote: On 06/28/2012 03:48 PM, Peter Krempa wrote: If the user specified invalid protocol type in a network's SRV record the error path ended up in freeing uninitialized pointers causing a daemon crash. *network_conf.c: virNetworkDNSSrvDefParseXML(): initialize local variables --- src/conf/network_conf.c |8 1 files changed, 4 insertions(+), 4 deletions(-) ACK. Pushed; Thanks for a quick review. Peter -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCHv2] virsh: Cleanup virsh -V output
On 06/27/2012 09:52 PM, Osier Yang wrote: On 2012年06月28日 11:37, Eric Blake wrote: From: Doug Goldsteincar...@cardoe.com Fixed up virsh -V output by removing invalid WITH_PROXY WITH_ONE checks, adding several missing checks, and fixing the DTrace check. Signed-off-by: Doug Goldsteincar...@cardoe.com Signed-off-by: Eric Blakeebl...@redhat.com --- @@ -20838,6 +20841,9 @@ vshShowVersion(vshControl *ctl ATTRIBUTE_UNUSED) #ifdef WITH_NWFILTER vshPrint(ctl, Nwfilter); #endif +#ifdef WITH_INTERFACE +vshPrint(ctl, Interface); +#endif $ grep WITH_INTERFACE * -r daemon/libvirtd.c:# ifdef WITH_INTERFACE tests/virdrivermoduletest.c:#ifdef WITH_INTERFACE WITH_INTERFACE is never defined, and I think it's mispelling of WITH_NETCF. So instead of add WITH_INTERFACE here, we need to fix the WITH_INTERFACE use in the two .c files. Or Change WITH_NETCF into WITH_INTERFACE overall. Personally I like the later more, as interface is the term we use across the project. Oh my, I think you're right. I'll fix that in a followup patch, and have pushed this one using WITH_NETCF instead. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] build: define WITH_INTERFACE for the driver
Our code was mistakenly relying on an undefined macro, WITH_INTERFACE,
for determining whether to load the interface driver which wraps the
netcf library. Clean this situation up by having only one automake
conditional for the driver, and having both WITH_NETCF (library
detected) and WITH_INTERFACE (driver enabled) in C code, in case a
future patch ever adds a network management via means other than
the netcf library.
While at it, output more information at the conclusion of configure
about the various drivers we enabled.
* configure.ac: Enhance with_netcf, and add with_interface.
Improve output to list final decisions. Replace WITH_NETCF with
WITH_INTERFACE.
* src/interface/netcf_driver.c: Rename...
* src/interface/interface_driver.c: ...to this.
* src/interface/interface_driver.h: Likewise.
* daemon/Makefile.am (libvirtd_LDADD): Reflect better naming.
* src/Makefile.am (libvirt_driver_interface_la_*): Likewise.
(INTERFACE_DRIVER_SOURCES): Reflect file moves.
* daemon/libvirtd.c (daemonInitialize): Likewise.
* tools/virsh.c (vshShowVersion): Show both driver and library
decisions.
* libvirt.spec.in (with_interface): Tweak to deal with new usage
as a real switch.
---
I think this addresses the point that Osier raised here:
https://www.redhat.com/archives/libvir-list/2012-June/msg01266.html
but it is complex enough that I'd appreciate a careful review.
configure.ac | 44
daemon/Makefile.am |2 +-
daemon/libvirtd.c |6 +--
libvirt.spec.in| 10 +++--
src/Makefile.am|4 +-
.../{netcf_driver.c = interface_driver.c} |4 +-
.../{netcf_driver.h = interface_driver.h} |0
tools/virsh.c | 11 +++--
8 files changed, 59 insertions(+), 22 deletions(-)
rename src/interface/{netcf_driver.c = interface_driver.c} (99%)
rename src/interface/{netcf_driver.h = interface_driver.h} (100%)
diff --git a/configure.ac b/configure.ac
index 6436885..a29b3b2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1755,6 +1755,7 @@ if test $with_network = yes ; then
fi
AM_CONDITIONAL([WITH_NETWORK], [test $with_network = yes])
+dnl check whether helper code is needed for above selections
with_bridge=no
if test $with_qemu:$with_lxc:$with_network != no:no:no; then
with_bridge=yes
@@ -1762,16 +1763,31 @@ if test $with_qemu:$with_lxc:$with_network !=
no:no:no; then
fi
AM_CONDITIONAL([WITH_BRIDGE], [test $with_bridge = yes])
-dnl netcf library
+dnl check if the interface driver should be compiled
+
+AC_ARG_WITH([interface],
+ AC_HELP_STRING([--with-interface],
+[with host interface driver @:@default=check@:@]),[],
+[with_interface=check])
+
+dnl there's no use compiling the interface driver without the libvirt daemon
+if test $with_libvirtd = no; then
+ with_interface=no
+fi
+
+dnl The interface driver depends on the netcf library
AC_ARG_WITH([netcf],
AC_HELP_STRING([--with-netcf], [libnetcf support to configure physical host
network interfaces @:@default=check@:@]),
[], [with_netcf=check])
NETCF_CFLAGS=
NETCF_LIBS=
-if test $with_libvirtd = no ; then
+if test $with_libvirtd = no || test $with_interface = no; then
with_netcf=no
fi
+if test $with_interface:$with_netcf = yes:check; then
+ with_netcf=yes
+fi
if test $with_netcf = yes || test $with_netcf = check; then
PKG_CHECK_MODULES(NETCF, netcf = $NETCF_REQUIRED,
[with_netcf=yes], [
@@ -1792,11 +1808,21 @@ if test $with_netcf = yes || test $with_netcf =
check; then
fi
fi
fi
-AM_CONDITIONAL([WITH_NETCF], [test $with_netcf = yes])
AC_SUBST([NETCF_CFLAGS])
AC_SUBST([NETCF_LIBS])
+dnl Final decision on the interface driver
+if test $with_interface = check; then
+ with_interface=$with_netcf
+fi
+
+if test $with_interface = yes ; then
+ AC_DEFINE_UNQUOTED([WITH_INTERFACE], [1],
+[whether interface driver is enabled])
+fi
+AM_CONDITIONAL([WITH_INTERFACE], [test $with_interface = yes])
+dnl Check whether the Secrets driver is needed
AC_ARG_WITH([secrets],
AC_HELP_STRING([--with-secrets], [with local secrets management driver
@:@default=yes@:@]),[],[with_secrets=yes])
@@ -2807,11 +2833,12 @@ AC_MSG_NOTICE([ ESX: $with_esx])
AC_MSG_NOTICE([ Hyper-V: $with_hyperv])
AC_MSG_NOTICE([Test: $with_test])
AC_MSG_NOTICE([ Remote: $with_remote])
-AC_MSG_NOTICE([ Network: $with_network])
AC_MSG_NOTICE([Libvirtd: $with_libvirtd])
-AC_MSG_NOTICE([ netcf: $with_netcf])
-AC_MSG_NOTICE([ macvtap: $with_macvtap])
-AC_MSG_NOTICE([virtport: $with_virtualport])
+AC_MSG_NOTICE([ Network: $with_network])
+AC_MSG_NOTICE([ Iface: $with_interface])
+AC_MSG_NOTICE([ Secrets: $with_secrets])
+AC_MSG_NOTICE([ NodeDev: $with_nodedev])
+AC_MSG_NOTICE([NWfilter: $with_nwfilter])
AC_MSG_NOTICE([])
AC_MSG_NOTICE([Storage Drivers])
AC_MSG_NOTICE([])
@@ -2977,6 +3004,9
[libvirt] nwfilter: Fix memory leak
Below patch fixes this coverity report:
/libvirt/src/conf/nwfilter_conf.c:382:
leaked_storage: Variable varAccess going out of scope leaks the
storage it points to.
---
src/conf/nwfilter_conf.c |1 +
1 file changed, 1 insertion(+)
Index: libvirt-acl/src/conf/nwfilter_conf.c
===
--- libvirt-acl.orig/src/conf/nwfilter_conf.c
+++ libvirt-acl/src/conf/nwfilter_conf.c
@@ -379,6 +379,7 @@ virNWFilterRuleDefAddVar(virNWFilterRule
if (VIR_EXPAND_N(nwf-varAccess, nwf-nVarAccess, 1) 0) {
virReportOOMError();
+virNWFilterVarAccessFree(varAccess);
return -1;
}
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] network_conf: Don't free uninitialized pointers while parsing DNS SRV
On Thu, Jun 28, 2012 at 11:58:01PM +0200, Peter Krempa wrote: On 06/28/12 23:52, Eric Blake wrote: On 06/28/2012 03:48 PM, Peter Krempa wrote: If the user specified invalid protocol type in a network's SRV record the error path ended up in freeing uninitialized pointers causing a daemon crash. *network_conf.c: virNetworkDNSSrvDefParseXML(): initialize local variables --- src/conf/network_conf.c |8 1 files changed, 4 insertions(+), 4 deletions(-) ACK. Pushed; Thanks for a quick review. Thanks, Peter, that fixes the crash for me. Dave Peter -- 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] nwfilter: Fix memory leak
On 06/28/2012 06:38 PM, Stefan Berger wrote: Below patch fixes this coverity report: /libvirt/src/conf/nwfilter_conf.c:382: leaked_storage: Variable varAccess going out of scope leaks the storage it points to. --- src/conf/nwfilter_conf.c |1 + 1 file changed, 1 insertion(+) ACK. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] Intend to add fuse filesystem support for libvirt lxc
Hi Everyone, Now I'm working on making the container's system info(such as /proc/meminfo,cpuinfo..) isolate from the host. I made a patch which implement showing the /proc/meminfo base on container's memcg, and sent it to the community.(http://marc.info/?l=linux-mmm=133826035821338w=2) but I found it's difficult to be accepted, because this way is ugly, and somebody gave me some suggestions. the first way is making another kernel file(just like memory.limit_in_bytes),and mount it to the container. I don't like this way,because there will be many redundance information between this new kernel file and the existing kernel file,some files such as memory.stat already contains memcg information. the other way is adding fuse filesystem support for libvirt lxc. with this way, we can simply collect information from cgroup in fuse_operations.read function, and mount this file to the container. we can impletment isolate meminfo in userspace without changing kernel codes. I have impletment fuse support for libvrit now, and ready to impletement the meminfo isolated. I want to know if you have any comment or another ideas? please let me know. thanks. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/13] Support hypervisor-threads-pin in vcpupin.
Hi~ If anybody have time to take a look at these patches, please give some comments. Thanks.:) On 06/07/2012 03:45 AM, Eric Blake wrote: On 06/05/2012 02:08 AM, tangchen wrote: Hi~ Users can use vcpupin command to bind a vcpu thread to a specific physical cpu. But besides vcpu threads, there are alse some other threads created by qemu (known as hypervisor threads) that could not be explicitly bound to physical cpus. I haven't had a chance to look at this yet, but it's on my to-do list to review this in time for 0.9.13. Thanks for your patience. -- Best Regards, Tang chen -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu_agent: support guest-info command
Daniel
Thank you for your comment. And I rewrite the patch with
int virDomainQemuAgentCommand(virDomainPtr domain, const char *cmd,
char **result, unsigned int flags);
that you suggested.
The attached patch is against libvirt-0.9.13-rc2
virsh # qemu-agent-command RHEL58_64 guest-info
{return:{version:1.1.50,supported_commands:[{enabled:true,name:guest-network-get-interfaces},{enabled:true,name:guest-suspend-hybrid},{enabled:true,name:guest-suspend-ram},{enabled:true,name:guest-suspend-disk},{enabled:true,name:guest-fsfreeze-thaw},{enabled:true,name:guest-fsfreeze-freeze},{enabled:true,name:guest-fsfreeze-status},{enabled:true,name:guest-file-flush},{enabled:true,name:guest-file-seek},{enabled:true,name:guest-file-write},{enabled:true,name:guest-file-read},{enabled:true,name:guest-file-close},{enabled:true,name:guest-file-open},{enabled:true,name:guest-shutdown},{enabled:true,name:guest-info},{enabled:true,name:guest-ping},{enabled:true,name:guest-sync},{enabled:true,name:guest-sync-delimited}]}}
On Tue, Jun 26, 2012 at 12:42:03PM +0900, MATSUDA, Daiki wrote:
Currently, libvirt qemu agent supports some QEMU Guest Agent's commands
or use them. But they are not adapted to communication test to the
Domain OS.
So, QEMU Guest Agent provide 'guest-info' command to display its version
and their commands. And I wrote the codes for supporting it.
virsh # guest-agent-info RHEL62_32
Version: 1.1.0
Commands:
guest-network-get-interfaces
guest-suspend-hybrid
guest-suspend-ram
guest-suspend-disk
guest-fsfreeze-thaw
guest-fsfreeze-freeze
guest-fsfreeze-status
guest-file-flush
guest-file-seek
guest-file-write
guest-file-read
guest-file-close
guest-file-open
guest-shutdown
guest-info
guest-ping
guest-sync
guest-sync-delimited
I don't really think that this kind of API is relevant for the
libvirt public API. Individual agent commands are wired up to
specific libvirt public APIs as required. There is no compelling
reason why an end user needs to know what agent commands are
present.
I would, however, support the introduction of an API
int virDomainQemuAgentCommand(virDomainPtr domain, const char *cmd,
char **result, unsigned int flags);
and virsh command 'qemu-agent-command' as part of libvirt-qemu.h and
libvirt-qemu.so. Basically an equivalent of the existing QEMU specific
API virDomainQemuMonitorCommand(), but talking to the agent instead of
the monitor
Regards,
Daniel
diff -uNrp libvirt-0.9.13.orig/daemon/remote.c libvirt-0.9.13/daemon/remote.c
--- libvirt-0.9.13.orig/daemon/remote.c 2012-06-25 16:06:18.0 +0900
+++ libvirt-0.9.13/daemon/remote.c 2012-06-29 12:50:03.752806682 +0900
@@ -3923,6 +3923,42 @@ cleanup:
return rv;
}
+
+static int
+remoteDispatchDomainQemuAgentCommand(virNetServerPtr server ATTRIBUTE_UNUSED,
+ virNetServerClientPtr client
ATTRIBUTE_UNUSED,
+ virNetMessagePtr msg ATTRIBUTE_UNUSED,
+ virNetMessageErrorPtr rerr,
+ remote_domain_qemu_agent_command_args
*args,
+ remote_domain_qemu_agent_command_ret *ret)
+{
+virDomainPtr dom = NULL;
+int rv = -1;
+struct daemonClientPrivate *priv =
+virNetServerClientGetPrivateData(client);
+
+if (!priv-conn) {
+virNetError(VIR_ERR_INTERNAL_ERROR, %s, _(connection not open));
+goto cleanup;
+}
+
+if (!(dom = get_nonnull_domain(priv-conn, args-dom)))
+goto cleanup;
+
+if (virDomainQemuAgentCommand(dom, args-cmd, ret-result, args-flags)
0) {
+virNetError(VIR_ERR_INTERNAL_ERROR, %s, _(Guest Agent Error));
+goto cleanup;
+}
+
+rv = 0;
+cleanup:
+if (rv 0)
+virNetMessageSaveError(rerr);
+if (dom)
+virDomainFree(dom);
+return rv;
+}
+
/*- Helpers. -*/
/* get_nonnull_domain and get_nonnull_network turn an on-wire
diff -uNrp libvirt-0.9.13.orig/daemon/remote_dispatch.h
libvirt-0.9.13/daemon/remote_dispatch.h
--- libvirt-0.9.13.orig/daemon/remote_dispatch.h2012-06-25
19:48:08.0 +0900
+++ libvirt-0.9.13/daemon/remote_dispatch.h 2012-06-29 10:21:21.460454579
+0900
@@ -12889,6 +12889,28 @@ static int remoteDispatchSupportsFeature
+static int remoteDispatchDomainQemuAgentCommand(
+virNetServerPtr server,
+virNetServerClientPtr client,
+virNetMessagePtr msg,
+virNetMessageErrorPtr rerr,
+remote_domain_qemu_agent_command_args *args,
+remote_domain_qemu_agent_command_ret *ret);
+static int remoteDispatchDomainQemuAgentCommandHelper(
+virNetServerPtr server,
+virNetServerClientPtr client,
+virNetMessagePtr msg,
+virNetMessageErrorPtr rerr,
+
