Re: [libvirt] [PATCH] daemon: Don't just include admin RPC
On 06/17/2015 10:10 AM, Michal Privoznik wrote: So, it's a little paradox that we use the file twice. Firstly to build libvirt-admin.la (a client side of the Admin API), then once again to build the server side. Well, the problem is, this does not play nicely with the distclean since the file is generated. So while it's removed in the src/ the distclean running in daemon/ will not find the file and fail. The file is needed because it contains the RPC wrappers. So let's leave the client code as is and from the daemon/ just link the client library. The linker will find desired symbols and use them. Signed-off-by: Michal Privoznik mpriv...@redhat.com --- daemon/Makefile.am | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) ACK. diff --git a/daemon/Makefile.am b/daemon/Makefile.am index b9c089d..d3fc029 100644 --- a/daemon/Makefile.am +++ b/daemon/Makefile.am @@ -128,8 +128,7 @@ libvirtd_conf_la_LIBADD = $(LIBXML_LIBS) noinst_LTLIBRARIES += libvirtd_admin.la libvirtd_admin_la_SOURCES = \ - admin_server.c admin_server.h \ - ../src/admin/admin_protocol.c + admin_server.c admin_server.h Indeed, any makefile dependency on ../xxx is liable to cause distclean chaos. -- Eric Blake eblake 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] nodedev-dumpxml doesn't refresh supported offload NIC capabilities
On 06/17/2015 03:18 AM, Moshe Levi wrote: Hi Laine, I verified your fix and it working. Do I need to fill bug for this? It depends on where you need it. If you need it in the distro build of an already-released version of some distro, then you should file a bug in their tracking system. I did file a bug against RHEL7 so that the bug ID could be listed in the commit log (I just pushed it upstream): https://bugzilla.redhat.com/show_bug.cgi?id=1232880 Feel free to clone that bug if you want it fixed in Fedora 22, 21, or RHEL6.x. Thanks for the report, btw. *From:*sendmail [mailto:justsendmailnothinge...@gmail.com] *On Behalf Of *Laine Stump *Sent:* Tuesday, June 16, 2015 6:50 PM *To:* libvir-list@redhat.com *Cc:* Moshe Levi *Subject:* Re: [libvirt] nodedev-dumpxml doesn't refresh supported offload NIC capabilities On 06/16/2015 10:12 AM, Moshe Levi wrote: Hi, I was playing with the nodedev-dumpxml to see the supported offload NIC capabilities, and It seem that if I disable one of offloading capabilities using ethtool command nodedev-dumpxml it still return the feature as enabled. To get the correct offloading capabilities I have to restart libvirtd. I was wandering if that is an expected behavior in lbivirt . the nodedevice driver caches all the information it gets from udev, and tries to rely on udev generating events when something changes. In general this is a bad idea, and has led to at least 2 bug reports I can think of. The function update_caps() in the nodedev driver is intended to be filled in with code to update those attributes of a device that don't get properly updated via udev event responses. It looks like all that would be required in your situation would be to add a call to virNetDevGetFeatures() to the VIR_NODE_DEV_CAP_NET case of the switch in that function. It's complicated a bit by the fact that virNetDevGetFeatures() leaks any existing bitmap of features when it's called. I'm sending a short patch that should fix your problem, which should show up on the list in a few minutes. Please see example below with the rx capabilities disabled. virsh # nodedev-dumpxml net_enp4s0_f4_52_14_11_73_81 device namenet_enp4s0_f4_52_14_11_73_81/name path/sys/devices/pci:00/:00:02.0/:04:00.0/net/enp4s0/path parentpci__04_00_0/parent capability type='net' interfaceenp4s0/interface addressf4:52:14:11:73:81/address link speed='4' state='up'/ feature name='rx'/ feature name='tx'/ feature name='sg'/ feature name='tso'/ feature name='gso'/ feature name='gro'/ feature name='rxvlan'/ feature name='txvlan'/ feature name='rxhash'/ capability type='80203'/ /capability /device ethtool -K enp4s0 rx off virsh # nodedev-dumpxml net_enp4s0_f4_52_14_11_73_81 device namenet_enp4s0_f4_52_14_11_73_81/name path/sys/devices/pci:00/:00:02.0/:04:00.0/net/enp4s0/path parentpci__04_00_0/parent capability type='net' interfaceenp4s0/interface addressf4:52:14:11:73:81/address link speed='4' state='up'/ feature name='rx'/ feature name='tx'/ feature name='sg'/ feature name='tso'/ feature name='gso'/ feature
Re: [libvirt] [PATCH] qemu: Report all supported machine types in capabilities
On 06/12/2015 08:53 AM, Jiri Denemark wrote:
Some machine types are only reported as canonical names for other
machine types, which make it a bit harder to find what machine types are
supported by a specific QEMU binary. Ideally, one would just use
/capabilities/guest/arch[@name='...']/machine/text() XPath to get a list
of all supported machine types, but it doesn't work right now.
For example, we report
machine canonical='pc-i440fx-2.3' maxCpus='255'pc/machine
in guest capabilities, but the corresponding
machine maxCpus='255'pc-i440fx-2.3/machine
is missing.
This is a result of QMP probing. With -machine ? parsing QEMU sends
us two lines:
pc Standard PC (i440FX + PIIX, 1996) (alias of
pc-i440fx-2.3)
pc-i440fx-2.3Standard PC (i440FX + PIIX, 1996) (default)
while query-machines QMP command reports both in the same entry:
{name: pc-i440fx-2.3, is-default: true, cpu-max: 255, alias: pc}
Let's make sure we always report separate machine/ for both the
canonical name and its alias and using the canonical name as the default
machine type (i.e., inserting it before its alias) in case is-default is
true.
https://bugzilla.redhat.com/show_bug.cgi?id=1229666
Signed-off-by: Jiri Denemark jdene...@redhat.com
---
src/qemu/qemu_capabilities.c | 38 ++
1 file changed, 38 insertions(+)
There's no existing test for this? I guess I would have expected to see
differences in output and thus test adjustments as well.
The code seems to be doing what is stated though... and the
tests/capabilityschemadata/caps-qemu-kvm.xml seems to show the output as
desired.
ACK -
John
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index ca7a7c2..e9b3bb5 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -2223,6 +2223,44 @@ int virQEMUCapsGetMachineTypesCaps(virQEMUCapsPtr
qemuCaps,
mach-maxCpus = qemuCaps-machineMaxCpus[i];
}
+/* Make sure all canonical machine types also have their own entry so
that
+ * /capabilities/guest/arch[@name='...']/machine/text() XPath selects all
+ * supported machine types.
+ */
+i = 0;
+while (i *nmachines) {
+size_t j;
+bool found = false;
+virCapsGuestMachinePtr machine = (*machines)[i];
+
+if (!machine-canonical) {
+i++;
+continue;
+}
+
+for (j = 0; j *nmachines; j++) {
+if (STREQ(machine-canonical, (*machines)[j]-name)) {
+found = true;
+break;
+}
+}
+
+if (!found) {
+virCapsGuestMachinePtr mach;
+if (VIR_ALLOC(mach) 0)
+goto error;
+if (VIR_INSERT_ELEMENT_COPY(*machines, i, *nmachines, mach) 0)
{
+VIR_FREE(mach);
+goto error;
+}
+if (VIR_STRDUP(mach-name, machine-canonical) 0)
+goto error;
+mach-maxCpus = machine-maxCpus;
+i++;
+}
+i++;
+}
+
return 0;
error:
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] Overhead for a default cpu cg placement scheme
On Thu, Jun 11, 2015 at 4:30 PM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Jun 11, 2015 at 04:24:18PM +0300, Andrey Korolyov wrote: On Thu, Jun 11, 2015 at 4:13 PM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Jun 11, 2015 at 04:06:59PM +0300, Andrey Korolyov wrote: On Thu, Jun 11, 2015 at 2:33 PM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Jun 11, 2015 at 02:16:50PM +0300, Andrey Korolyov wrote: On Thu, Jun 11, 2015 at 2:09 PM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Jun 11, 2015 at 01:50:24PM +0300, Andrey Korolyov wrote: Hi Daniel, would it possible to adopt an optional tunable for a virCgroup mechanism which targets to a disablement of a nested (per-thread) cgroup creation? Those are bringing visible overhead for many-threaded guest workloads, almost 5% in non-congested host CPU state, primarily because the host scheduler should make a much more decisions with those cgroups than without them. We also experienced a lot of host lockups with currently exploited cgroup placement and disabled nested behavior a couple of years ago. Though the current patch is simply carves out the mentioned behavior, leaving only top-level per-machine cgroups, it can serve for an upstream after some adaptation, that`s why I`m asking about a chance of its acceptance. This message is a kind of 'request of a feature', it either can be accepted/dropped from our side or someone may give a hand and redo it from scratch. The detailed benchmarks are related to a host 3.10.y, if anyone is interested in the numbers for latest stable, I can update those. When you say nested cgroup creation, as you referring to the modern libvirt hierarchy, or the legacy hierarchy - as described here: http://libvirt.org/cgroups.html The current libvirt setup used for a year or so now is much shallower than previously, to the extent that we'd consider performance problems with it to be the job of the kernel to fix. Thanks, I`m referring to a 'new nested' hiearchy for an overhead mentioned above. The host crashes I mentioned happened with old hierarchy back ago, forgot to mention this. Despite the flattening of the topo for the current scheme it should be possible to disable fine group creation for the VM threads for some users who don`t need per-vcpu cpu pinning/accounting (though overhead caused by a placement for cpu cgroup, not by accounting/pinning ones, I`m assuming equal distribution with such disablement for all nested-aware cgroup types), that`s the point for now. Ok, so the per-vCPU cgroups are used for a couple of things - Setting scheduler tunables - period/quota/shares/etc - Setting CPU pinning - Setting NUMA memory pinning In addition to the per-VCPU cgroup, we have one cgroup fr each I/O thread, and also one more for general QEMU emulator threads. In the case of CPU pinning we already have automatic fallback to sched_setaffinity if the CPUSET controller isn't available. We could in theory start off without the per-vCPU/emulator/I/O cgroups and only create them as when the feature is actually used. The concern I would have though is that changing the cgroups layout on the fly may cause unexpected sideeffects in behaviour of the VM. More critically, there would be alot of places in the code where we would need to deal with this which could hurt maintainability. How confident are you that the performance problems you see are inherant to the actual use of the cgroups, and not instead as a result of some particular bad choice of default parameters we might have left in the cgroups ? In general I'd have a desire to try to work to eliminate the perf impact before we consider the complexity of disabling this feature Regards, Daniel Hm, what are you proposing to begin with in a testing terms? By my understanding the excessive cgroup usage along with small scheduler quanta *will* lead to some overhead anyway. Let`s look at the numbers which I would bring tomorrow, the mentioned five percents was catched on a guest 'perf numa xxx' for a different kind of mappings and host behavior (post-3.8): memory automigration on/off, kind of 'numa passthrough', like grouping vcpu threads according to the host and emulated guest NUMA topologies, totally scattered and unpinned threads within a single and within a multiple NUMA nodes. As the result for 3.10.y, there was a five-percent difference between best-performing case with thread-level cpu cgroups and a 'totally scattered' case on a simple mid-range two-headed node. If you think that the choice of an emulated workload is wrong, please let me know, I was afraid that the non-synthetic workload in the guest may suffer from a range of a side factors and therefore
Re: [libvirt] [PATCH] tests: Sort EXTRA_DIST in the Makefile
On 06/17/2015 10:13 AM, Michal Privoznik wrote: We tend to keep the folders in the EXTRA_DIST sorted alphabetically. However, we've failed sometimes and the list is not ordered anymore. Reorder it back. Signed-off-by: Michal Privoznik mpriv...@redhat.com --- tests/Makefile.am | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) ACK. -- Eric Blake eblake 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] [PATCHv2 01/13] conf: Fix virDomainObjGetDefs when getting persistent config on a live vm
On 06/15/2015 03:47 PM, Peter Krempa wrote: If @flags contains only VIR_DOMAIN_AFFECT_CONFIG and @vm is active, the function would return the active config rather than the persistent one that it should return. This happened due to the fact that virDomainObjGetDefs was checking the updated flags which may not contain VIR_DOMAIN_AFFECT_LIVE if it is not requested even if @vm is active. Additionally the function would not take the flags into account when setting the pointers which was later used to determine whether the code needs to update the given configuration. The mistake was caught by the virt-test suite. --- Version 2 actually fixes the function. src/conf/domain_conf.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) ACK John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 02/13] conf: Introduce helper to help getting correct def for getter functions
On 06/15/2015 03:47 PM, Peter Krempa wrote:
virDomainObjGetOneDef will help to retrieve the correct definition
pointer from @vm in cases where VIR_DOMAIN_AFFECT_LIVE and
VIR_DOMAIN_AFFECT_CONFIG are mutually exclusive. The function simply
returns the correct pointer. This similarly to virDomainObjGetDefs will
greatly simplify the code.
---
src/conf/domain_conf.c | 36
src/conf/domain_conf.h | 1 +
src/libvirt_private.syms | 1 +
3 files changed, 38 insertions(+)
I dunno - I just have this little voice asking is there some corner case
from the prior virDomainLiveConfigHelperMethod thruough possibly
creating 'newDef' in virDomainObjSetDefTransient that this new code will
miss... IOW - is there a condition where CONFIG is wanted, domain is
running, but newDef is NULL.
OTOH - one wonders if the previous code went through the patch into
virDomainObjSetDefTransient
All the callers check for NULL, so that's not an issue - just
considering some strange corner case for a transient domain.
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 3cc182b..35e1cb4 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -2948,6 +2948,42 @@ virDomainObjGetDefs(virDomainObjPtr vm,
}
+/**
+ * virDomainObjGetOneDef:
+ *
+ * @vm: Domain object
+ * @flags: for virDomainModificationImpact
+ *
+ * Helper function to resolve @flags and return the correct domain pointer
+ * object. This function returns one of @vm-def or @vm-persistentDef
+ * according to @flags. This helper should be used only in APIs that
guarantee
+ * that @flags contains exactly one of VIR_DOMAIN_AFFECT_LIVE,
s/,/ or/
+ * VIR_DOMAIN_AFFECT_CONFIG.
and to be really redundant ;-) - couldn't resist.
s/./ and not both./
ACK - although GetOneDef isn't my favorite, I don't have a better
suggestion either.
John
+ *
+ * Returns the correct definition pointer or NULL on error.
+ */
+virDomainDefPtr
+virDomainObjGetOneDef(virDomainObjPtr vm,
+ unsigned int flags)
+{
+if (flags VIR_DOMAIN_AFFECT_LIVE flags VIR_DOMAIN_AFFECT_CONFIG) {
+virReportInvalidArg(ctl, %s,
+_(Flags 'VIR_DOMAIN_AFFECT_LIVE' and
+ 'VIR_DOMAIN_AFFECT_CONFIG' are mutually
+ exclusive));
+return NULL;
+}
+
+if (virDomainObjUpdateModificationImpact(vm, flags) 0)
+return NULL;
+
+if (virDomainObjIsActive(vm) flags VIR_DOMAIN_AFFECT_CONFIG)
+return vm-newDef;
+else
+return vm-def;
+}
+
+
/*
* The caller must hold a lock on the driver owning 'doms',
* and must also have locked 'dom', to ensure no one else
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index ba17a8d..db49d46 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -2553,6 +2553,7 @@ int virDomainObjGetDefs(virDomainObjPtr vm,
unsigned int flags,
virDomainDefPtr *liveDef,
virDomainDefPtr *persDef);
+virDomainDefPtr virDomainObjGetOneDef(virDomainObjPtr vm, unsigned int
flags);
int
virDomainLiveConfigHelperMethod(virCapsPtr caps,
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index dc8a52d..858c00f 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -385,6 +385,7 @@ virDomainObjEndAPI;
virDomainObjFormat;
virDomainObjGetDefs;
virDomainObjGetMetadata;
+virDomainObjGetOneDef;
virDomainObjGetPersistentDef;
virDomainObjGetState;
virDomainObjListAdd;
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] libvirt proxy
Hello. I need libvirt proxy, but not simple proxy connection, but something like dedicated libvirt server, that can modify requests or doing something based on incoming request. I'm use go for this, i'm already parse xdr data, but i'm stuck at payload. Where i can find payloads examples or how can i determine needed payload for specific procedure ? (now i'm use wireshark with libvirt dissector). I don't need to provide all libvirt functions, now i need very basic sets like open/close, list, create , destroy domains.. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] incorrect memory size inside vm
On Thu, Jun 18, 2015 at 12:21 AM, Vasiliy Tolstov v.tols...@selfip.ru wrote:
2015-06-17 19:26 GMT+03:00 Vasiliy Tolstov v.tols...@selfip.ru:
This is band news =( i have debian wheezy that have old kernel...
Does it possible to get proper results with balloon ? For example by
patching qemu or something like this?
Yes, but I`m afraid that I don`t fully understand why do you need this
when pure hotplug mechanism is available, aside may be nice memory
stats from balloon and easy-to-use deflation. Just populate a couple
of static dimms with small enough 'base' e820 memory and use balloon
on this setup, you`ll get the reserved memory footprint as small as it
would be in setup with equal overall amount of memory populated via
BIOS. For example, you may use -m 128 ... {handful amount of memory
placed in memory slots} setup to achieve the thing you want.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] incorrect memory size inside vm
2015-06-18 1:40 GMT+03:00 Andrey Korolyov and...@xdel.ru:
Yes, but I`m afraid that I don`t fully understand why do you need this
when pure hotplug mechanism is available, aside may be nice memory
stats from balloon and easy-to-use deflation. Just populate a couple
of static dimms with small enough 'base' e820 memory and use balloon
on this setup, you`ll get the reserved memory footprint as small as it
would be in setup with equal overall amount of memory populated via
BIOS. For example, you may use -m 128 ... {handful amount of memory
placed in memory slots} setup to achieve the thing you want.
I have debian wheezy guests with 3.4 kernels (or 3.2..) and many
others like 32 centos 6, opensue , ubuntu, and other.
Does memory hotplug works with this distros (kernels)?
--
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] incorrect memory size inside vm
On Thu, Jun 18, 2015 at 1:44 AM, Vasiliy Tolstov v.tols...@selfip.ru wrote:
2015-06-18 1:40 GMT+03:00 Andrey Korolyov and...@xdel.ru:
Yes, but I`m afraid that I don`t fully understand why do you need this
when pure hotplug mechanism is available, aside may be nice memory
stats from balloon and easy-to-use deflation. Just populate a couple
of static dimms with small enough 'base' e820 memory and use balloon
on this setup, you`ll get the reserved memory footprint as small as it
would be in setup with equal overall amount of memory populated via
BIOS. For example, you may use -m 128 ... {handful amount of memory
placed in memory slots} setup to achieve the thing you want.
I have debian wheezy guests with 3.4 kernels (or 3.2..) and many
others like 32 centos 6, opensue , ubuntu, and other.
Does memory hotplug works with this distros (kernels)?
Whoosh... technically it is possible but it would be an incompatible
fork for the upstreams for both SeaBIOS and Qemu, because the generic
way of plugging DIMMs in is available down to at least generic 2.6.32.
Except may be Centos where broken kabi would bring great consequences,
it may be better to just provide a backport repository with newer
kernels, but it doesn`t sound very optimistic. For the history
records, the initial hotplug support proposal provided by Vasilis
Liaskovitis a couple of years ago worked in an exact way you are
suggesting to, but its resurrection would mean emulator and rom code
alteration, as I said above.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] incorrect memory size inside vm
2015-06-18 1:52 GMT+03:00 Andrey Korolyov and...@xdel.ru: Whoosh... technically it is possible but it would be an incompatible fork for the upstreams for both SeaBIOS and Qemu, because the generic way of plugging DIMMs in is available down to at least generic 2.6.32. Except may be Centos where broken kabi would bring great consequences, it may be better to just provide a backport repository with newer kernels, but it doesn`t sound very optimistic. For the history records, the initial hotplug support proposal provided by Vasilis Liaskovitis a couple of years ago worked in an exact way you are suggesting to, but its resurrection would mean emulator and rom code alteration, as I said above. Ok, i'm try to build latest libvirt and check all oses for memory hotplug support =). -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 07/13] qemu: Simplify qemuDomainGetVcpusFlags by using virDomainObjGetOneDef
On 06/15/2015 03:47 PM, Peter Krempa wrote:
virDomainObjGetOneDef is simpler to use than virDomainObjGetDefs
---
src/qemu/qemu_driver.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
ACK - 3/13 to 7/13
although there's an unrelated, but since I was here NIT below.
John
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index c878409..2cb0215 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -5479,7 +5479,6 @@ qemuDomainGetVcpusFlags(virDomainPtr dom, unsigned int
flags)
qemuDomainObjPrivatePtr priv;
virDomainObjPtr vm;
virDomainDefPtr def;
-virDomainDefPtr persistentDef;
int ret = -1;
qemuAgentCPUInfoPtr cpuinfo = NULL;
int ncpuinfo = -1;
@@ -5498,11 +5497,11 @@ qemuDomainGetVcpusFlags(virDomainPtr dom, unsigned
int flags)
if (virDomainGetVcpusFlagsEnsureACL(dom-conn, vm-def, flags) 0)
goto cleanup;
-if (virDomainObjGetDefs(vm, flags, def, persistentDef) 0)
+if (!(def = virDomainObjGetOneDef(vm, flags)))
goto cleanup;
if (flags VIR_DOMAIN_VCPU_GUEST) {
-if (persistentDef) {
+if (!virDomainObjIsActive(vm)) {
virReportError(VIR_ERR_INVALID_ARG, %s,
_(vCPU count provided by the guest agent can
only be
requested for live domains));
Existing, but there will be a double space in the output message...
@@ -5543,9 +5542,6 @@ qemuDomainGetVcpusFlags(virDomainPtr dom, unsigned int
flags)
ret++;
}
} else {
-if (!def)
-def = persistentDef;
-
if (flags VIR_DOMAIN_VCPU_MAXIMUM)
ret = def-maxvcpus;
else
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 08/13] qemu: Simplify qemuDomainSetInterfaceParameters by using virDomainObjGetDefs
On 06/15/2015 03:47 PM, Peter Krempa wrote:
---
src/qemu/qemu_driver.c | 40
1 file changed, 16 insertions(+), 24 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 2cb0215..ceadc31 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -11246,12 +11246,12 @@ qemuDomainSetInterfaceParameters(virDomainPtr dom,
virQEMUDriverPtr driver = dom-conn-privateData;
size_t i;
virDomainObjPtr vm = NULL;
-virDomainDefPtr persistentDef = NULL;
+virDomainDefPtr def;
+virDomainDefPtr persistentDef;
int ret = -1;
virDomainNetDefPtr net = NULL, persistentNet = NULL;
virNetDevBandwidthPtr bandwidth = NULL, newBandwidth = NULL;
virQEMUDriverConfigPtr cfg = NULL;
-virCapsPtr caps = NULL;
bool inboundSpecified = false, outboundSpecified = false;
virCheckFlags(VIR_DOMAIN_AFFECT_LIVE |
@@ -11280,31 +11280,24 @@ qemuDomainSetInterfaceParameters(virDomainPtr dom,
if (virDomainSetInterfaceParametersEnsureACL(dom-conn, vm-def, flags)
0)
goto cleanup;
-if (!(caps = virQEMUDriverGetCapabilities(driver, false)))
+if (qemuDomainObjBeginJob(driver, vm, QEMU_JOB_MODIFY) 0)
goto cleanup;
-if (qemuDomainObjBeginJob(driver, vm, QEMU_JOB_MODIFY) 0)
+if (virDomainObjGetDefs(vm, flags, def, persistentDef) 0)
goto cleanup;
^^ goto endjob;
NOTE:
I see this is also an existing issue for qemuDomainPinIOThread - that is
the failure to ObjGetDefs goes to cleanup after a BeginJob rather than
going to endjob.
I know - a separate issue, but it may as well be fixed in this series...
ACK with the change here...
John
-if (virDomainLiveConfigHelperMethod(caps, driver-xmlopt, vm, flags,
-persistentDef) 0)
+if (def
+!(net = virDomainNetFind(vm-def, device))) {
+virReportError(VIR_ERR_INVALID_ARG,
+ _(Can't find device %s), device);
goto endjob;
-
-if (flags VIR_DOMAIN_AFFECT_LIVE) {
-net = virDomainNetFind(vm-def, device);
-if (!net) {
-virReportError(VIR_ERR_INVALID_ARG,
- _(Can't find device %s), device);
-goto endjob;
-}
}
-if (flags VIR_DOMAIN_AFFECT_CONFIG) {
-persistentNet = virDomainNetFind(persistentDef, device);
-if (!persistentNet) {
-virReportError(VIR_ERR_INVALID_ARG,
- _(Can't find device %s), device);
-goto endjob;
-}
+
+if (persistentDef
+!(persistentNet = virDomainNetFind(persistentDef, device))) {
+virReportError(VIR_ERR_INVALID_ARG,
+ _(Can't find device %s), device);
+goto endjob;
}
if ((VIR_ALLOC(bandwidth) 0) ||
@@ -11340,7 +11333,7 @@ qemuDomainSetInterfaceParameters(virDomainPtr dom,
if (!bandwidth-out-average)
VIR_FREE(bandwidth-out);
-if (flags VIR_DOMAIN_AFFECT_LIVE) {
+if (net) {
if (VIR_ALLOC(newBandwidth) 0)
goto endjob;
@@ -11392,7 +11385,7 @@ qemuDomainSetInterfaceParameters(virDomainPtr dom,
goto endjob;
}
-if (flags VIR_DOMAIN_AFFECT_CONFIG) {
+if (persistentNet) {
if (!persistentNet-bandwidth) {
persistentNet-bandwidth = bandwidth;
bandwidth = NULL;
@@ -11426,7 +11419,6 @@ qemuDomainSetInterfaceParameters(virDomainPtr dom,
virNetDevBandwidthFree(bandwidth);
virNetDevBandwidthFree(newBandwidth);
virDomainObjEndAPI(vm);
-virObjectUnref(caps);
virObjectUnref(cfg);
return ret;
}
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] incorrect memory size inside vm
2015-06-17 19:26 GMT+03:00 Vasiliy Tolstov v.tols...@selfip.ru: This is band news =( i have debian wheezy that have old kernel... Does it possible to get proper results with balloon ? For example by patching qemu or something like this? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 13/13] conf: Move vcpu info parsing code into a separate function
On 06/15/2015 03:47 PM, Peter Krempa wrote: --- src/conf/domain_conf.c | 132 - 1 file changed, 76 insertions(+), 56 deletions(-) ACK 12-13 John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 11/13] qemu: Reuse virDomainObjGetDefs in qemuDomainGetMemoryParameters
On 06/15/2015 03:47 PM, Peter Krempa wrote: Simplify the code by restructuring control flow and reusing the better helper. --- src/qemu/qemu_driver.c | 27 --- 1 file changed, 8 insertions(+), 19 deletions(-) ACK 9-11 John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] libxl: rework reference counting
Anthony PERARD wrote: On Tue, Jun 16, 2015 at 10:53:15AM +0100, Anthony PERARD wrote: On Mon, Jun 15, 2015 at 08:36:47PM -0600, Jim Fehlig wrote: Similar to commit 540c339a for the QEMU driver, rework reference counting in the libxl driver to make it more deterministic and the code a bit cleaner. Signed-off-by: Jim Fehlig jfeh...@suse.com --- I've been testing this patch on and off for a few weeks now using libvirt-tck domain tests, local test scripts, and some manual tests for good measure. I sent the patch to Anthony Perard (cc'd) nearly two weeks ago for testing in his OpenStack+Xen+libvirt CI loop, although I haven't received any feedback thus far. Also included Martin in the cc since he encouraged this patch But I should be able to test the patch now. Hi, I gave this patch a try with OpenStack. I have applied the patch on top of libvirt 1.4.14 + (f86ae40 894d2ff 6dfec1e), which we are using for our CI. With the patch, libvirt works fine, Thanks for testing it! but I can still have the rare error domain 205 device model: startup timed out. I would have been surprised if the patch fixed that mysterious problem. Regards, Jim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] VIRTIO v1.0 15-day public review - ends July 2nd
OASIS members and other interested parties, The Virtual I/O Device (VIRTIO) TC members [1] have produced an updated Committee Specification Draft (CSD) and submitted this specification for 15-day public review: Virtual I/O Device (VIRTIO) Version 1.0 Committee Specification Draft 04 / Public Review Draft 04 28 May 2015 Specification overview: This document describes the specifications of the virtio family of devices. These devices are found in virtual environments, yet by design they are not all that different from physical devices, and this document treats them as such. This allows the guest to use standard drivers and discovery mechanisms. The purpose of virtio and this specification is that virtual environments and guests should have a straightforward, efficient, standard and extensible mechanism for virtual devices, rather than boutique per-environment or per-OS mechanisms. Among multiple other enhancements and corrections, the Virtio specification now includes support for the memory balloon device for managing guest memory. This puts Virtio 1.0 at feature parity with Virtio 0.9. This is the first public review of VIRTIO since it was approved as Committee Specification 02 (CS02). The files http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-diff.html and http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-diff.pdf include all changes since CS02 highlighted. TC Description: The goal of the OASIS Virtual I/O Device (VIRTIO) TC is to simplify virtual devices, making them more extensible and more recognizable. The purpose of VIRTIO is to ensure that virtual environments and guests have a straightforward, efficient, standard, and extensible mechanism for virtual devices, rather than boutique per-environment or per-OS mechanisms. Public Review Period: The public review starts 18 June 2015 at 00:00 UTC and ends 02 July 2015 at 23:59 UTC. This is the first public review of VIRTIO since it was approved as Committee Specification 02 (CS02). The files http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-diff.html and http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-diff.pdf include all changes since CS02 highlighted [2]. This 15-day review is limited in scope to these changes. This is an open invitation to comment. OASIS solicits feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of its technical work. Reviewers may provide comments directly from the comment-tag version of document. The file http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-COMMENT-TAGS.html contains the HTML version of the draft with a “[comment?]” link next to each section heading. Clicking on this link will launch your email application and begin a message to virtio-comm...@lists.oasis-open.org with the specific section number and title in the subject line. Simply enter your comment and click send. Note that you must be subscribed to the comment mailing list before sending feedback. Instructions on how to subscribe can be found at https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=virtio. URIs: The prose specification document and related files are available here: Editable source (Authoritative): http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/tex/ HTML: http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04.html HTML with inline tags for direct commenting: http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04-COMMENT-TAGS.html PDF: http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04.pdf ZIP distribution files (complete): For your convenience, OASIS provides a complete package of the prose specification and related files in a ZIP distribution file. You can download the ZIP file here: http://docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04.zip Additional information about this specification and the VIRTIO TC may be found on the TC's public home page located at: http://www.oasis-open.org/committees/virtio/ Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be accessed via the button labeled Send A Comment at the top of the TC public home page, or directly at: http://www.oasis-open.org/committees/comments/form.php?wg_abbrev=virtio Feedback submitted by TC non-members for this work and for other work of this TC is publicly archived and can be viewed at: http://lists.oasis-open.org/archives/virtio-comment/ All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. In connection with this public review of 'Virtual I/O Device (VIRTIO) Version 1.0', we call your attention to the OASIS IPR Policy [3] applicable especially [4]
Re: [libvirt] [PATCH] nodedev: update netdev feature bits before each dumpxml
On 06/17/2015 04:35 AM, Ján Tomko wrote: On Tue, Jun 16, 2015 at 12:03:55PM -0400, Laine Stump wrote: As with several other attributes of devices (link status, sriov VF list, IOMMU group list), the detdev feature bits aren't automatically s/det/net/ updated in the nodedev driver's cache when they change. In order to get a properly up-to-date list when getting the XML of a device, we must reget them in update-caps prior to each dumpxml. Reported-By: Moshe Levi mosh...@mellanox.com --- I dislike needing to put in the virBitmapFree and set the pointer to NULL before re-getting the features, but leaving it out would lead to a leak of the old bitmap, and I'm not sure I want virNetDevGetFeatures() to assume a valid pointer when it starts (it currently assumes the pointer contents is junk, and overwrites it with a newly allocated *virBitmap). Setting it to NULL is not strictly required, since the GetFeatures() call will always overwrite it. Yes, you are correct. I was being overly paranoid and assuming that an error return from that function might leave the pointer unmodified, but looking at it now I can verify it will always be valid on exit. So I'm going to remove the blah = NULL before I push. Maybe the code would be nicer if virBitmapFree also cleared the pointer and virNetDevGetFeatures returned the bitmap instead of an int? Having virBitmapFree() would make it cleaner to use and would make it more like the VIR_FREE() macro, but would make it behave differently from all the other vir*Free() functions in libvirt. So in the name of consistency, I thin we should leave it as it is. (and as you pointed out, it's not necessary to clear it in this case). src/node_device/node_device_driver.c | 4 1 file changed, 4 insertions(+) diff --git a/src/node_device/node_device_driver.c b/src/node_device/node_device_driver.c index 768db7f..31741b9 100644 --- a/src/node_device/node_device_driver.c +++ b/src/node_device/node_device_driver.c @@ -58,6 +58,10 @@ static int update_caps(virNodeDeviceObjPtr dev) case VIR_NODE_DEV_CAP_NET: if (virNetDevGetLinkInfo(cap-data.net.ifname, cap-data.net.lnk) 0) return -1; +virBitmapFree(cap-data.net.features); +cap-data.net.features = NULL; +if (virNetDevGetFeatures(cap-data.net.ifname, cap-data.net.features) 0) +return -1; break; case VIR_NODE_DEV_CAP_PCI_DEV: if (nodeDeviceSysfsGetPCIRelatedDevCaps(dev-def-sysfs_path, ACK with the typo fixed. Thanks! -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [sandbox PATCH 2/3] Add configuration object for disk support
On Wed, 2015-06-17 at 10:35 +0100, Daniel P. Berrange wrote:
On Wed, Jun 17, 2015 at 09:43:23AM +0200, Cedric Bosdonnat wrote:
Hi Daniel,
On Thu, 2015-06-11 at 14:47 +0100, Daniel P. Berrange wrote:
On Wed, Jun 10, 2015 at 01:40:09PM +0200, Eren Yagdiran wrote:
Add the config gobject, functions to store and load the new
configuration
fragments and test. This will allow creating sandboxes with attached
disk with a parameter formatted like
file:hda=/source/file.qcow2,format=qcow2
+/**
+ * gvir_sandbox_config_add_disk_strv:
+ * @config: (transfer none): the sandbox config
+ * @disks: (transfer none)(array zero-terminated=1): the list of disks
+ *
+ * Parses @disks whose elements are in the format
TYPE:TARGET=SOURCE,FORMAT=FORMAT
+ * creating #GVirSandboxConfigMount instances for each element. For
+ * example
+ *
+ * - file:hda=/var/lib/sandbox/demo/tmp.qcow2,format=qcow2
+ */
One of the goal of the libvirt sandbox code is to insulate apps from
needing to know hypervisor specific differences. The guest side disk
device name is one such big difference. Many hypervisors, including
kvm, will not even honour requested names - you just get whatever
name the guest decides to give you. Essentially the only thing that
libvirt guarantees is the disk ordering. ie if you configure two
disks one with hda and one hdb, libvirt will ensure hda appears
before hdb on the bus or controller.
So I don't think we should include the target device name in our
configuration syntax here. We should just document that disks
will be added to the guest in the same order that you supply
them to virt-sandbox command line in. The actual device names
will vary according to the hypevisor and guest os.
Right. But I think we then need to ask for the bus type then, so that we
know whether we'll have ide, scsi or whatever. Then we could have the
option like:
file:ide=/path/to/source,format=fmt
And of course document that the disks will be added in the same order.
Does it sound better for you?
Not really - that is still not achieving our goal that users should
not need to details about the hypervisor used when configuring a
sandbox.
The goal is that the CLI args to virt-sandbox should be unchanged,
no matter what libvirt URI is provided. Now of course in the case
of virtualized disks, what appears inside the sandbox could be
differently named - ideally we'd find a way to insulate users from
that aspect too.
In normal Linux there are various symlinks /dev/disk/by-{uuid,id,path}
available which link back to /dev/[sda,vda,hda,etc]. These are created
by udev, but we're not running that. I wonder if we could make use of
that concept though - create /dev/disk/by-tag directory and then in the
cli args we could allow a simple tag. eg
file:foobar=/path/to/source,format=fmt
and then populate a symlink /dev/disk/by-tag/foobar - /dev/sda
I love this idea :) That would nicely solve the problem.
--
Cedric
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [sandbox PATCH 2/3] Add configuration object for disk support
Hi Daniel,
On Thu, 2015-06-11 at 14:47 +0100, Daniel P. Berrange wrote:
On Wed, Jun 10, 2015 at 01:40:09PM +0200, Eren Yagdiran wrote:
Add the config gobject, functions to store and load the new configuration
fragments and test. This will allow creating sandboxes with attached
disk with a parameter formatted like
file:hda=/source/file.qcow2,format=qcow2
+/**
+ * gvir_sandbox_config_add_disk_strv:
+ * @config: (transfer none): the sandbox config
+ * @disks: (transfer none)(array zero-terminated=1): the list of disks
+ *
+ * Parses @disks whose elements are in the format
TYPE:TARGET=SOURCE,FORMAT=FORMAT
+ * creating #GVirSandboxConfigMount instances for each element. For
+ * example
+ *
+ * - file:hda=/var/lib/sandbox/demo/tmp.qcow2,format=qcow2
+ */
One of the goal of the libvirt sandbox code is to insulate apps from
needing to know hypervisor specific differences. The guest side disk
device name is one such big difference. Many hypervisors, including
kvm, will not even honour requested names - you just get whatever
name the guest decides to give you. Essentially the only thing that
libvirt guarantees is the disk ordering. ie if you configure two
disks one with hda and one hdb, libvirt will ensure hda appears
before hdb on the bus or controller.
So I don't think we should include the target device name in our
configuration syntax here. We should just document that disks
will be added to the guest in the same order that you supply
them to virt-sandbox command line in. The actual device names
will vary according to the hypevisor and guest os.
Right. But I think we then need to ask for the bus type then, so that we
know whether we'll have ide, scsi or whatever. Then we could have the
option like:
file:ide=/path/to/source,format=fmt
And of course document that the disks will be added in the same order.
Does it sound better for you?
--
Cedric
+gboolean gvir_sandbox_config_add_disk_strv(GVirSandboxConfig *config,
+ gchar **disks,
+ GError **error)
+{
+gsize i = 0;
+while (disks disks[i]) {
+if (!gvir_sandbox_config_add_disk_opts(config,
+ disks[i],
+ error))
+return FALSE;
+i++;
+}
+return TRUE;
+}
Regards,
Daniel
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [sandbox] configure: check for static libc
Missing static libc doesn't really prevent the build to finish, but it would cause errors when running qemu sandboxes. Checking in configure will save time for new developers. --- configure.ac | 2 ++ m4/virt-static.m4 | 33 + 2 files changed, 35 insertions(+) create mode 100644 m4/virt-static.m4 diff --git a/configure.ac b/configure.ac index 0e49a0a..ba5247a 100644 --- a/configure.ac +++ b/configure.ac @@ -87,6 +87,8 @@ LIBVIRT_SANDBOX_COVERAGE LIBVIRT_SANDBOX_RPCGEN LIBVIRT_SANDBOX_SELINUX +LIBVIRT_SANDBOX_STATIC_LIBC + GOBJECT_INTROSPECTION_CHECK([$GOBJECT_INTROSPECTION_REQUIRED]) dnl Should be in m4/virt-gettext.m4 but intltoolize is too diff --git a/m4/virt-static.m4 b/m4/virt-static.m4 new file mode 100644 index 000..8a40351 --- /dev/null +++ b/m4/virt-static.m4 @@ -0,0 +1,33 @@ +# LIBVIRT_SANDBOX_STATIC_LIB(NAME, CFLAGS, LDFLAGS, PROLOG, PROGRAM) +# -- +# Check if the program can be linked with static libraries only. +# +AC_DEFUN([LIBVIRT_SANDBOX_STATIC_LIB], [ +AC_MSG_CHECKING([for static $1]) + +SAVED_LDFLAGS=$LDFLAGS +SAVED_CFLAGS=$CFLAGS +CFLAGS=$2 +LDFLAGS=-static $3 +AC_LINK_IFELSE( +[AC_LANG_PROGRAM([$4], + [$5])], +[], +[AC_MSG_RESULT([no])] +[AC_MSG_ERROR([static $1 is required in order to build virt-sandbox-init-qemu])] +) +LDFLAGS=$SAVED_LDFLAGS +CFLAGS=$SAVED_CFLAGS + +AC_MSG_RESULT([yes]) +]) + +AC_DEFUN([LIBVIRT_SANDBOX_STATIC_LIBC], [ +LIBVIRT_SANDBOX_STATIC_LIB( + [LIBC], + [], + [], + [#include stdio.h], + [printf(bar);]) +]) + -- 2.1.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] nodedev-dumpxml doesn't refresh supported offload NIC capabilities
Hi Laine, I verified your fix and it working. Do I need to fill bug for this? From: sendmail [mailto:justsendmailnothinge...@gmail.com] On Behalf Of Laine Stump Sent: Tuesday, June 16, 2015 6:50 PM To: libvir-list@redhat.com Cc: Moshe Levi Subject: Re: [libvirt] nodedev-dumpxml doesn't refresh supported offload NIC capabilities On 06/16/2015 10:12 AM, Moshe Levi wrote: Hi, I was playing with the nodedev-dumpxml to see the supported offload NIC capabilities, and It seem that if I disable one of offloading capabilities using ethtool command nodedev-dumpxml it still return the feature as enabled. To get the correct offloading capabilities I have to restart libvirtd. I was wandering if that is an expected behavior in lbivirt . the nodedevice driver caches all the information it gets from udev, and tries to rely on udev generating events when something changes. In general this is a bad idea, and has led to at least 2 bug reports I can think of. The function update_caps() in the nodedev driver is intended to be filled in with code to update those attributes of a device that don't get properly updated via udev event responses. It looks like all that would be required in your situation would be to add a call to virNetDevGetFeatures() to the VIR_NODE_DEV_CAP_NET case of the switch in that function. It's complicated a bit by the fact that virNetDevGetFeatures() leaks any existing bitmap of features when it's called. I'm sending a short patch that should fix your problem, which should show up on the list in a few minutes. Please see example below with the rx capabilities disabled. virsh # nodedev-dumpxml net_enp4s0_f4_52_14_11_73_81 device namenet_enp4s0_f4_52_14_11_73_81/name path/sys/devices/pci:00/:00:02.0/:04:00.0/net/enp4s0/path parentpci__04_00_0/parent capability type='net' interfaceenp4s0/interface addressf4:52:14:11:73:81/address link speed='4' state='up'/ feature name='rx'/ feature name='tx'/ feature name='sg'/ feature name='tso'/ feature name='gso'/ feature name='gro'/ feature name='rxvlan'/ feature name='txvlan'/ feature name='rxhash'/ capability type='80203'/ /capability /device ethtool -K enp4s0 rx off virsh # nodedev-dumpxml net_enp4s0_f4_52_14_11_73_81 device namenet_enp4s0_f4_52_14_11_73_81/name path/sys/devices/pci:00/:00:02.0/:04:00.0/net/enp4s0/path parentpci__04_00_0/parent capability type='net' interfaceenp4s0/interface addressf4:52:14:11:73:81/address link speed='4' state='up'/ feature name='rx'/ feature name='tx'/ feature name='sg'/ feature name='tso'/ feature name='gso'/ feature name='gro'/ feature name='rxvlan'/ feature name='txvlan'/ feature name='rxhash'/ capability type='80203'/ /capability /device virsh # [root@r-ae-host05 bin]# ps -ef | grep libvirt root 16743 23086 0 16:43 pts/200:00:00 ../sbin/libvirtd root 17440 23086 0 16:47 pts/200:00:00 grep --color=auto libvirt [root@r-ae-host05 bin]# kill 16743 [root@r-ae-host05 bin]# ../sbin/libvirtd [2] 17489 [1] Done../sbin/libvirtd [root@r-ae-host05 bin]# [root@r-ae-host05 bin]# [root@r-ae-host05 bin]# ./virsh virsh # nodedev-dumpxml net_enp4s0_f4_52_14_11_73_81 device namenet_enp4s0_f4_52_14_11_73_81/name path/sys/devices/pci:00/:00:02.0/:04:00.0/net/enp4s0/path parentpci__04_00_0/parent capability type='net' interfaceenp4s0/interface addressf4:52:14:11:73:81/address link speed='4' state='up'/ feature name='tx'/ feature name='sg'/ feature name='tso'/ feature name='gso'/ feature name='gro'/ feature name='rxvlan'/ feature name='txvlan'/ feature name='rxhash'/ feature name='rdma'/ capability type='80203'/ /capability /device Thanks, Moshe Levi. -- libvir-list mailing list libvir-list@redhat.commailto: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] [libvirt-glib] gconfig: Fix small leak in test-domain-create
Ping? On Mon, Apr 13, 2015 at 11:09:31AM +0200, Christophe Fergeau wrote: The object returned by gvir_config_domain_disk_get_driver() must be unref'ed when no longer used. --- libvirt-gconfig/tests/test-domain-create.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libvirt-gconfig/tests/test-domain-create.c b/libvirt-gconfig/tests/test-domain-create.c index eb4b945..417d3d0 100644 --- a/libvirt-gconfig/tests/test-domain-create.c +++ b/libvirt-gconfig/tests/test-domain-create.c @@ -284,6 +284,7 @@ int main(int argc, char **argv) g_assert(gvir_config_domain_disk_driver_get_copy_on_read(driver)); g_assert(gvir_config_domain_disk_get_target_bus(disk) == GVIR_CONFIG_DOMAIN_DISK_BUS_IDE); g_str_const_check(gvir_config_domain_disk_get_target_dev(disk), hda); +g_object_unref(driver); /* network interfaces node */ -- 2.3.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list pgpt8Uf4AVikK.pgp Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [libvirt-glib] gconfig: Fix small leak in test-domain-create
On Wed, Jun 17, 2015 at 10:49:05AM +0200, Christophe Fergeau wrote: Ping? On Mon, Apr 13, 2015 at 11:09:31AM +0200, Christophe Fergeau wrote: The object returned by gvir_config_domain_disk_get_driver() must be unref'ed when no longer used. --- libvirt-gconfig/tests/test-domain-create.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libvirt-gconfig/tests/test-domain-create.c b/libvirt-gconfig/tests/test-domain-create.c index eb4b945..417d3d0 100644 --- a/libvirt-gconfig/tests/test-domain-create.c +++ b/libvirt-gconfig/tests/test-domain-create.c @@ -284,6 +284,7 @@ int main(int argc, char **argv) g_assert(gvir_config_domain_disk_driver_get_copy_on_read(driver)); g_assert(gvir_config_domain_disk_get_target_bus(disk) == GVIR_CONFIG_DOMAIN_DISK_BUS_IDE); g_str_const_check(gvir_config_domain_disk_get_target_dev(disk), hda); +g_object_unref(driver); /* network interfaces node */ ACK Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] nodedev: update netdev feature bits before each dumpxml
On Tue, Jun 16, 2015 at 12:03:55PM -0400, Laine Stump wrote: As with several other attributes of devices (link status, sriov VF list, IOMMU group list), the detdev feature bits aren't automatically s/det/net/ updated in the nodedev driver's cache when they change. In order to get a properly up-to-date list when getting the XML of a device, we must reget them in update-caps prior to each dumpxml. Reported-By: Moshe Levi mosh...@mellanox.com --- I dislike needing to put in the virBitmapFree and set the pointer to NULL before re-getting the features, but leaving it out would lead to a leak of the old bitmap, and I'm not sure I want virNetDevGetFeatures() to assume a valid pointer when it starts (it currently assumes the pointer contents is junk, and overwrites it with a newly allocated *virBitmap). Setting it to NULL is not strictly required, since the GetFeatures() call will always overwrite it. Maybe the code would be nicer if virBitmapFree also cleared the pointer and virNetDevGetFeatures returned the bitmap instead of an int? src/node_device/node_device_driver.c | 4 1 file changed, 4 insertions(+) diff --git a/src/node_device/node_device_driver.c b/src/node_device/node_device_driver.c index 768db7f..31741b9 100644 --- a/src/node_device/node_device_driver.c +++ b/src/node_device/node_device_driver.c @@ -58,6 +58,10 @@ static int update_caps(virNodeDeviceObjPtr dev) case VIR_NODE_DEV_CAP_NET: if (virNetDevGetLinkInfo(cap-data.net.ifname, cap-data.net.lnk) 0) return -1; +virBitmapFree(cap-data.net.features); +cap-data.net.features = NULL; +if (virNetDevGetFeatures(cap-data.net.ifname, cap-data.net.features) 0) +return -1; break; case VIR_NODE_DEV_CAP_PCI_DEV: if (nodeDeviceSysfsGetPCIRelatedDevCaps(dev-def-sysfs_path, ACK with the typo fixed. Jan signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [sandbox] configure: check for static libc
On Wed, Jun 17, 2015 at 10:11:20AM +0200, Cédric Bosdonnat wrote: Missing static libc doesn't really prevent the build to finish, but it would cause errors when running qemu sandboxes. Checking in configure will save time for new developers. --- configure.ac | 2 ++ m4/virt-static.m4 | 33 + 2 files changed, 35 insertions(+) create mode 100644 m4/virt-static.m4 ACK Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [sandbox PATCH 2/3] Add configuration object for disk support
On Wed, Jun 17, 2015 at 09:43:23AM +0200, Cedric Bosdonnat wrote:
Hi Daniel,
On Thu, 2015-06-11 at 14:47 +0100, Daniel P. Berrange wrote:
On Wed, Jun 10, 2015 at 01:40:09PM +0200, Eren Yagdiran wrote:
Add the config gobject, functions to store and load the new configuration
fragments and test. This will allow creating sandboxes with attached
disk with a parameter formatted like
file:hda=/source/file.qcow2,format=qcow2
+/**
+ * gvir_sandbox_config_add_disk_strv:
+ * @config: (transfer none): the sandbox config
+ * @disks: (transfer none)(array zero-terminated=1): the list of disks
+ *
+ * Parses @disks whose elements are in the format
TYPE:TARGET=SOURCE,FORMAT=FORMAT
+ * creating #GVirSandboxConfigMount instances for each element. For
+ * example
+ *
+ * - file:hda=/var/lib/sandbox/demo/tmp.qcow2,format=qcow2
+ */
One of the goal of the libvirt sandbox code is to insulate apps from
needing to know hypervisor specific differences. The guest side disk
device name is one such big difference. Many hypervisors, including
kvm, will not even honour requested names - you just get whatever
name the guest decides to give you. Essentially the only thing that
libvirt guarantees is the disk ordering. ie if you configure two
disks one with hda and one hdb, libvirt will ensure hda appears
before hdb on the bus or controller.
So I don't think we should include the target device name in our
configuration syntax here. We should just document that disks
will be added to the guest in the same order that you supply
them to virt-sandbox command line in. The actual device names
will vary according to the hypevisor and guest os.
Right. But I think we then need to ask for the bus type then, so that we
know whether we'll have ide, scsi or whatever. Then we could have the
option like:
file:ide=/path/to/source,format=fmt
And of course document that the disks will be added in the same order.
Does it sound better for you?
Not really - that is still not achieving our goal that users should
not need to details about the hypervisor used when configuring a
sandbox.
The goal is that the CLI args to virt-sandbox should be unchanged,
no matter what libvirt URI is provided. Now of course in the case
of virtualized disks, what appears inside the sandbox could be
differently named - ideally we'd find a way to insulate users from
that aspect too.
In normal Linux there are various symlinks /dev/disk/by-{uuid,id,path}
available which link back to /dev/[sda,vda,hda,etc]. These are created
by udev, but we're not running that. I wonder if we could make use of
that concept though - create /dev/disk/by-tag directory and then in the
cli args we could allow a simple tag. eg
file:foobar=/path/to/source,format=fmt
and then populate a symlink /dev/disk/by-tag/foobar - /dev/sda
Regards,
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [[libvirt-php][PATCH v1] fix memory functions] define memory functions
Signed-off-by: Vasiliy Tolstov v.tols...@selfip.ru
---
src/libvirt-php.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/libvirt-php.c b/src/libvirt-php.c
index d46fbb9..093623c 100644
--- a/src/libvirt-php.c
+++ b/src/libvirt-php.c
@@ -136,6 +136,9 @@ static zend_function_entry libvirt_functions[] = {
PHP_FE(libvirt_domain_create_xml, NULL)
PHP_FE(libvirt_domain_memory_peek,NULL)
PHP_FE(libvirt_domain_memory_stats,NULL)
+ PHP_FE(libvirt_domain_set_memory,NULL)
+ PHP_FE(libvirt_domain_set_max_memory,NULL)
+ PHP_FE(libvirt_domain_set_memory_flags,NULL)
PHP_FE(libvirt_domain_block_stats,NULL)
PHP_FE(libvirt_domain_block_resize,NULL)
PHP_FE(libvirt_domain_block_job_abort,NULL)
--
2.3.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/4] parallels: Fix false error messages in libvirt log
There was many errors in libvirt.log caused by prlsdkDelNet function because job variable was always initialized as PRL_INVALID_HANDLE In this patch job variable gets return value of PrlSrv_DeleteVirtualNetwork function() --- src/vz/vz_sdk.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c index c36dad6..98f7a57 100644 --- a/src/vz/vz_sdk.c +++ b/src/vz/vz_sdk.c @@ -2900,7 +2900,7 @@ static void prlsdkDelNet(vzConnPtr privconn, virDomainNetDefPtr net) pret = PrlVirtNet_SetNetworkId(vnet, net-data.network.name); prlsdkCheckRetGoto(pret, cleanup); -PrlSrv_DeleteVirtualNetwork(privconn-server, vnet, 0); +job = PrlSrv_DeleteVirtualNetwork(privconn-server, vnet, 0); if (PRL_FAILED(pret = waitJob(job))) goto cleanup; -- 1.7.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/4] parallels: Switch on DHCP for newly created network adapters
On 06/17/2015 08:35 AM, Mikhail Feoktistov wrote:
Let network adapter use DHCP server to get network configuration.
To do this we use PrlVmDevNet_SetConfigureWithDhcp to enable it and
PrlVmDevNet_SetAutoApply to makes necessary settings within guest OS
In linux case it creates network startup scripts
/etc/sysconfig/network-scripts/ifcfg-ethN and fills it with necessary
parameters.
(sorry for getting a bit off-topic)
The semantics of this are different for qemu - attaching a network
device only presents the hardware to the virtual machine; it doesn't
attempt to make any configuration changes in the guest OS. I *think*
that the xen and lxc drivers do configure the guest though (at least
they pay attention to the ip element in the interface). So this
isn't any criticism of your implementation, I'm just wondering whether
or not this will make a difference to any management apps using libvirt.
(actually this also brings to mind an idle thought I've had for awhile -
while it's possible to configure an IP address for a qemu guest from the
libvirt configuration in some cases (when the guest interface is
connected to a libvirt virtual network, you can add a static IP entry to
the network's dhcp config), it might be nice to recognize the ip
element in the interface, and use it to dynamically add a static IP
entry to the dnsmasq instance for the attached network. Does anyone have
an opinion on whether that would be useful/ugly/confusing?)
---
src/vz/vz_sdk.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index 98f7a57..090a3ad 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -2815,6 +2815,12 @@ static int prlsdkAddNet(PRL_HANDLE sdkdom,
pret = PrlVmDevNet_SetMacAddress(sdknet, macstr);
prlsdkCheckRetGoto(pret, cleanup);
+pret = PrlVmDevNet_SetConfigureWithDhcp(sdknet, true);
+prlsdkCheckRetGoto(pret, cleanup);
+
+pret = PrlVmDevNet_SetAutoApply(sdknet, true);
+prlsdkCheckRetGoto(pret, cleanup);
+
if (isCt) {
if (net-model)
VIR_WARN(Setting network adapter for containers is not
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/4] parallels: Implementation of attach/detach network devices and small network fixes
On 06/17/2015 04:05 PM, Maxim Nestratov wrote: 17.06.2015 15:35, Mikhail Feoktistov пишет: Mikhail Feoktistov (4): parallels: Fix initialization of buflen variable in each loop iteration parallels: Fix false error messages in libvirt log parallels: Switch on DHCP for newly created network adapters parallels: implementation of attach/detach network devices I think that using 'vz' tag instead of 'parallels' would be more accurate since we changed the name of the driver. Agree, it's ok for this series, but for new patches let's use vz: prefix. Best, Maxim -- Dmitry Guryanov -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2] virSysinfo: Introduce SMBIOS type 2 support
On 06/12/2015 06:02 AM, Michal Privoznik wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1220527 This type of information defines attributes of a system baseboard. With one caveat: in qemu they call it family, while in the specification it's referred to as type. I'm sticking with the latter. Perhaps should update this since 'family' and 'type' aren't processed by libvirt. Signed-off-by: Michal Privoznik mpriv...@redhat.com --- diff to v1: -I've dropped the 'family' attribute. It's not implemented in qemu yet. We can add it later. docs/formatdomain.html.in | 37 - docs/schemas/domaincommon.rng | 23 +++ src/conf/domain_conf.c | 63 src/libvirt_private.syms | 1 + src/qemu/qemu_command.c| 54 +++ src/util/virsysinfo.c | 170 - src/util/virsysinfo.h | 16 ++ .../qemuxml2argv-smbios-multiple-type2.xml | 58 +++ tests/qemuxml2argvdata/qemuxml2argv-smbios.args| 2 + tests/qemuxml2argvdata/qemuxml2argv-smbios.xml | 8 + tests/qemuxml2xmltest.c| 1 + 11 files changed, 427 insertions(+), 6 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-smbios-multiple-type2.xml There's a couple issues pointed out below, fixable without need for a v3 I believe... ACK with the adjustments John diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 0478cb2..977660e 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -375,6 +375,12 @@ lt;entry name='product'gt;Virt-Managerlt;/entrygt; lt;entry name='version'gt;0.9.4lt;/entrygt; lt;/systemgt; +lt;baseBoardgt; + lt;entry name='manufacturer'gt;LENOVOlt;/entrygt; + lt;entry name='product'gt;20BE0061MClt;/entrygt; + lt;entry name='version'gt;0B98401 Prolt;/entrygt; + lt;entry name='serial'gt;W1KS427111Elt;/entrygt; +lt;/baseBoardgt; lt;/sysinfogt; .../pre @@ -435,11 +441,32 @@ dtcodefamily/code/dt ddIdentify the family a particular computer belongs to./dd /dl -NB: Incorrectly supplied entries in either the codebios/code -or codesystem/code blocks will be ignored without error. -Other than codeuuid/code validation and codedate/code -format checking, all values are passed as strings to the -hypervisor driver. + /dd + dtcodebaseBoard/code/dt + dd +This is block 2 of SMBIOS. This element can be repeated multiple +times, to describe all the base boards. However, not all s/times,/times s/boards. However,/boards; however, +hypervisors support the repetition necessarily. The element can s/support the repetition necessarily/necessarily support the repitition or s/support the repetition necessarily./support multiple base boards./ +have the following children: +dl +dtcodemanufacturer/code/dt +ddManufacturer of BIOS/dd +dtcodeproduct/code/dt +ddProduct Name/dd +dtcodeversion/code/dt +ddVersion of the product/dd +dtcodeserial/code/dt +ddSerial number/dd +dtcodeasset/code/dt +ddAsset tag/dd +dtcodelocation/code/dt +ddLocation in chassis/dd +/dl +NB: Incorrectly supplied entries for the +codebios/code, codesystem/code or codebaseBoard/code +blocks will be ignored without error. Other than codeuuid/code +validation and codedate/code format checking, all values are +passed as strings to the hypervisor driver. /dd /dl /dd diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index e38b927..32d28cd 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -4248,6 +4248,18 @@ /oneOrMore /element /optional +zeroOrMore + element name=baseBoard +oneOrMore + element name=entry +attribute name=name + ref name=sysinfo-baseBoard-name/ +/attribute +ref name=sysinfo-value/ + /element +/oneOrMore + /element +/zeroOrMore /interleave /element /define @@ -4273,6 +4285,17 @@ /choice /define + define name=sysinfo-baseBoard-name +choice + valuemanufacturer/value + valueproduct/value + valueversion/value + valueserial/value +
Re: [libvirt] [[libvirt-php][PATCH v2] qemu-agent-command] fixes for installation and add another libvirt function
2015-06-17 15:47 GMT+03:00 Vasiliy Tolstov v.tols...@selfip.ru: * add libvirt_domain_qemu_agent_command * fix install target, because before this all stuff goes to /usr/usr dir Signed-off-by: Vasiliy Tolstov v.tols...@selfip.ru This version fixes segfault then return result. -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/4] parallels: Implementation of attach/detach network devices and small network fixes
17.06.2015 15:35, Mikhail Feoktistov пишет: Mikhail Feoktistov (4): parallels: Fix initialization of buflen variable in each loop iteration parallels: Fix false error messages in libvirt log parallels: Switch on DHCP for newly created network adapters parallels: implementation of attach/detach network devices I think that using 'vz' tag instead of 'parallels' would be more accurate since we changed the name of the driver. Best, Maxim -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] incorrect memory size inside vm
Hi. I have issue with incorrect memory side inside vm. I'm try utilize memory balloon (not memory hotplug, because i have guest without memory hotplug (may be)). When domain started with static memory all works fine, but then i'm specify in libvirt memory = 16384 , maxMemory = 16384 and currentMemory = 1024, guest in f/rpoc/meminfo says that have only 603608 Kb memory. Then i set memory via virsh setmem to 2Gb, guest see only 1652184 Kb memory. software versions libvirt: 1.2.10 qemu: 2.3.0 Guest OS: centos 6. qemu.log: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/root USER=root LOGNAME=root QEMU_AUDIO_DRV=none /usr/bin/kvm -name 26543 -S -machine pc-i440fx-1.7,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,maxcpus=4,sockets=4,cores=1,threads=1 -uuid 4521fb01-c2ca-4269-d2d6-035fd910 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/26543.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,num_queues=1,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/dev/vg4/26543,if=none,id=drive-scsi0-0-0-0,format=raw,cache=none,discard=unmap,aio=native,iops=5000 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive if=none,id=drive-scsi0-0-1-0,readonly=on,format=raw -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0 -netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=52 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:00:34:f7,bus=pci.0,addr=0x3,rombar=0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/26543.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-mouse,id=input0 -device usb-kbd,id=input1 -vnc [::]:8,password -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -object rng-random,id=rng0,filename=/dev/random -device virtio-rng-pci,rng=rng0,max-bytes=1024,period=2000,bus=pci.0,addr=0x7 -msg timestamp=on -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] PING: [PATCH v2 0/2] Allow PCI virtio on ARM virt machine
Knock-knock??? Sorry for possibly repeated PING, but i see that mailing list for some reason strips CC:'s if specified without real name, so retry with name this time. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -Original Message- From: libvir-list-boun...@redhat.com [mailto:libvir-list-boun...@redhat.com] On Behalf Of Pavel Fedin Sent: Thursday, June 11, 2015 9:41 AM To: libvir-list@redhat.com Cc: Pavel Fedin Subject: [libvirt] [PATCH v2 0/2] Allow PCI virtio on ARM virt machine Virt machine in qemu since v2.3.0 has PCI generic host controller, and can use PCI devices. This provides performance improvement as well as vhost-net with irqfd support for virtio-net. However libvirt still insists on virtio devices attached to virt machine to have MMIO bindings. This patch allows to use both. If the user doesn't specify address type='virtio-mmio', PCI will be used by default. Changes since v1: - Added capability based on qemu version number - Recognize also virt- prefix Pavel Fedin (2): Introduce QEMU_CAPS_ARM_VIRT_PCI Allow PCI virtio on ARM virt machine src/qemu/qemu_capabilities.c | 5 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 15 --- 3 files changed, 18 insertions(+), 3 deletions(-) -- 1.9.5.msysgit.0 -- 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
[libvirt] [PATCH 0/4] parallels: Implementation of attach/detach network devices and small network fixes
Mikhail Feoktistov (4): parallels: Fix initialization of buflen variable in each loop iteration parallels: Fix false error messages in libvirt log parallels: Switch on DHCP for newly created network adapters parallels: implementation of attach/detach network devices -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/4] parallels: Fix initialization of buflen variable in each loop iteration
We need to initialize buflen every time when we get network adapter's friendly name because we call PrlVmDev_GetFriendlyName in a loop --- src/vz/vz_sdk.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c index f9cde44..c36dad6 100644 --- a/src/vz/vz_sdk.c +++ b/src/vz/vz_sdk.c @@ -3150,6 +3150,7 @@ prlsdkGetDiskIndex(PRL_HANDLE sdkdom, virDomainDiskDefPtr disk) pret = PrlVmCfg_GetHardDisk(sdkdom, i, hdd); prlsdkCheckRetGoto(pret, cleanup); +buflen = 0; pret = PrlVmDev_GetFriendlyName(hdd, 0, buflen); prlsdkCheckRetGoto(pret, cleanup); -- 1.7.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/4] parallels: Switch on DHCP for newly created network adapters
Let network adapter use DHCP server to get network configuration.
To do this we use PrlVmDevNet_SetConfigureWithDhcp to enable it and
PrlVmDevNet_SetAutoApply to makes necessary settings within guest OS
In linux case it creates network startup scripts
/etc/sysconfig/network-scripts/ifcfg-ethN and fills it with necessary
parameters.
---
src/vz/vz_sdk.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index 98f7a57..090a3ad 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -2815,6 +2815,12 @@ static int prlsdkAddNet(PRL_HANDLE sdkdom,
pret = PrlVmDevNet_SetMacAddress(sdknet, macstr);
prlsdkCheckRetGoto(pret, cleanup);
+pret = PrlVmDevNet_SetConfigureWithDhcp(sdknet, true);
+prlsdkCheckRetGoto(pret, cleanup);
+
+pret = PrlVmDevNet_SetAutoApply(sdknet, true);
+prlsdkCheckRetGoto(pret, cleanup);
+
if (isCt) {
if (net-model)
VIR_WARN(Setting network adapter for containers is not
--
1.7.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 4/4] parallels: implementation of attach/detach network devices
In this patch we add VIR_DOMAIN_DEVICE_NET handlers implementation
for domainAttachDevice and domainDetachDevice callbacks.
As soon as we don't support this operation for hypervisor type domains,
we implement this functionality for containers only.
In detach procedure we find network device by MAC address.
Because PrlVmDevNet_GetMacAddress() returns MAC as a UTF-8 encoded
null-terminated string, we use memcmp() to compare it.
Also we remove corresponding virtual network by prlsdkDelNetAdapter call.
---
src/vz/vz_driver.c | 16 +++
src/vz/vz_sdk.c| 127
src/vz/vz_sdk.h|4 ++
3 files changed, 147 insertions(+), 0 deletions(-)
diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c
index cef3c77..d9ddd4f 100644
--- a/src/vz/vz_driver.c
+++ b/src/vz/vz_driver.c
@@ -1117,6 +1117,14 @@ static int vzDomainAttachDeviceFlags(virDomainPtr dom,
const char *xml,
goto cleanup;
}
break;
+case VIR_DOMAIN_DEVICE_NET:
+ret = prlsdkAttachNet(privdom, privconn, dev-data.net);
+if (ret) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(network attach failed));
+goto cleanup;
+}
+break;
default:
virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
_(device type '%s' cannot be attached),
@@ -1186,6 +1194,14 @@ static int vzDomainDetachDeviceFlags(virDomainPtr dom,
const char *xml,
goto cleanup;
}
break;
+case VIR_DOMAIN_DEVICE_NET:
+ret = prlsdkDetachNet(privdom, privconn, dev-data.net);
+if (ret) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(network detach failed));
+goto cleanup;
+}
+break;
default:
virReportError(VIR_ERR_OPERATION_UNSUPPORTED,
_(device type '%s' cannot be detached),
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index 090a3ad..0f92e52 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -2914,6 +2914,133 @@ static void prlsdkDelNet(vzConnPtr privconn,
virDomainNetDefPtr net)
PrlHandle_Free(vnet);
}
+int prlsdkAttachNet(virDomainObjPtr dom, parallelsConnPtr privconn,
virDomainNetDefPtr net)
+{
+int ret = -1;
+parallelsDomObjPtr privdom = dom-privateData;
+PRL_HANDLE job = PRL_INVALID_HANDLE;
+
+if (!IS_CT(dom-def)) {
+virReportError(VIR_ERR_OPERATION_UNSUPPORTED, %s,
+ _(network device cannot be attached));
+goto cleanup;
+}
+
+job = PrlVm_BeginEdit(privdom-sdkdom);
+if (PRL_FAILED(waitJob(job)))
+goto cleanup;
+
+ret = prlsdkAddNet(privdom-sdkdom, privconn, net, IS_CT(dom-def));
+if (ret == 0) {
+job = PrlVm_CommitEx(privdom-sdkdom, PVCF_DETACH_HDD_BUNDLE);
+if (PRL_FAILED(waitJob(job))) {
+ret = -1;
+goto cleanup;
+}
+}
+
+ cleanup:
+return ret;
+}
+
+static int
+prlsdkGetNetIndex(PRL_HANDLE sdkdom, virDomainNetDefPtr net)
+{
+int idx = -1;
+PRL_RESULT pret;
+PRL_UINT32 netCount;
+PRL_UINT32 i;
+PRL_HANDLE adapter = PRL_INVALID_HANDLE;
+PRL_UINT32 len;
+char adapterMac[PRL_MAC_STRING_BUFNAME];
+char netMac[PRL_MAC_STRING_BUFNAME];
+
+prlsdkFormatMac(net-mac, netMac);
+pret = PrlVmCfg_GetNetAdaptersCount(sdkdom, netCount);
+prlsdkCheckRetGoto(pret, cleanup);
+
+for (i = 0; i netCount; ++i) {
+
+pret = PrlVmCfg_GetNetAdapter(sdkdom, i, adapter);
+prlsdkCheckRetGoto(pret, cleanup);
+
+len = sizeof(adapterMac);
+memset(adapterMac, 0, sizeof(adapterMac));
+pret = PrlVmDevNet_GetMacAddress(adapter, adapterMac, len);
+prlsdkCheckRetGoto(pret, cleanup);
+
+if (memcmp(adapterMac, netMac, PRL_MAC_STRING_BUFNAME)) {
+
+PrlHandle_Free(adapter);
+adapter = PRL_INVALID_HANDLE;
+continue;
+}
+
+idx = i;
+break;
+}
+
+ cleanup:
+PrlHandle_Free(adapter);
+return idx;
+}
+
+static int prlsdkDelNetAdapter(PRL_HANDLE sdkdom, int idx)
+{
+int ret = -1;
+PRL_RESULT pret;
+PRL_HANDLE sdknet = PRL_INVALID_HANDLE;
+
+pret = PrlVmCfg_GetNetAdapter(sdkdom, idx, sdknet);
+prlsdkCheckRetGoto(pret, cleanup);
+
+pret = PrlVmDev_Remove(sdknet);
+prlsdkCheckRetGoto(pret, cleanup);
+
+ret = 0;
+
+ cleanup:
+PrlHandle_Free(sdknet);
+return ret;
+}
+
+int prlsdkDetachNet(virDomainObjPtr dom, parallelsConnPtr privconn,
virDomainNetDefPtr net)
+{
+int ret = -1, idx = -1;
+parallelsDomObjPtr privdom = dom-privateData;
+PRL_HANDLE job = PRL_INVALID_HANDLE;
+
+if (!IS_CT(dom-def)) {
+virReportError(VIR_ERR_OPERATION_UNSUPPORTED, %s,
+ _(network device cannot be detached));
+goto cleanup;
+}
+
+idx = prlsdkGetNetIndex(privdom-sdkdom, net);
+if (idx
[libvirt] [[libvirt-php][PATCH v2] qemu-agent-command] fixes for installation and add another libvirt function
* add libvirt_domain_qemu_agent_command
* fix install target, because before this all stuff goes to /usr/usr dir
Signed-off-by: Vasiliy Tolstov v.tols...@selfip.ru
---
configure.ac | 3 +++
src/Makefile.am | 19 ++-
src/libvirt-php.c | 28
src/libvirt-php.h | 2 ++
4 files changed, 43 insertions(+), 9 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9e9fee0..0afa2e2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -23,6 +23,9 @@ PKG_PROG_PKG_CONFIG
LIBVIRT_REQUIRED=0.6.2
PKG_CHECK_MODULES(LIBVIRT, libvirt = $LIBVIRT_REQUIRED)
+PKG_CHECK_MODULES(QEMU, libvirt-qemu)
+AC_SUBST([QEMU_CFLAGS])
+AC_SUBST([QEMU_LIBS])
dnl ==
dnl required minimum version of libxml2
diff --git a/src/Makefile.am b/src/Makefile.am
index cab0456..f270ec2 100644
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -6,10 +6,10 @@ WL=@WL@
SHLIB_FLAGS=@SHLIB_FLAGS@
install-exec-local:
- $(MKDIR_P) $(DESTDIR)$(prefix)$(PHPEDIR)
- $(MKDIR_P) $(DESTDIR)$(prefix)$(PHPCDIR)
- $(INSTALL) -m 644 -D .libs/$(PACKAGE).so
$(DESTDIR)$(prefix)$(PHPEDIR)/$(PACKAGE).so
- $(INSTALL) -m 755 -d $(DESTDIR)$(prefix)$(PHPCDIR)
+ $(MKDIR_P) $(DESTDIR)$(PHPEDIR)
+ $(MKDIR_P) $(DESTDIR)$(PHPCDIR)
+ $(INSTALL) -m 644 -D .libs/$(PACKAGE).so
$(DESTDIR)$(PHPEDIR)/$(PACKAGE).so
+ $(INSTALL) -m 755 -d $(DESTDIR)$(PHPCDIR)
$(ECHO) extension=$(PACKAGE).so libvirt-php.ini
$(ECHO) libvirt-php.ini
$(ECHO) [libvirt] libvirt-php.ini
@@ -19,21 +19,22 @@ install-exec-local:
$(ECHO) libvirt.image_path=/var/lib/libvirt/images libvirt-php.ini
$(ECHO) ; Limit maximum number of libvirt connections
libvirt-php.ini
$(ECHO) libvirt.max_connections=5 libvirt-php.ini
- $(INSTALL) -m 644 -D libvirt-php.ini
$(DESTDIR)$(prefix)$(PHPCDIR)/$(PACKAGE).ini
+ $(INSTALL) -m 644 -D libvirt-php.ini $(DESTDIR)$(PHPCDIR)/$(PACKAGE).ini
uninstall-local:
- $(RM) -f $(DESTDIR)$(prefix)$(PHPCDIR)/$(PACKAGE).ini
- $(RM) -f $(DESTDIR)$(prefix)$(PHPEDIR)/$(PACKAGE).so
+ $(RM) -f $(DESTDIR)$(PHPCDIR)/$(PACKAGE).ini
+ $(RM) -f $(DESTDIR)$(PHPEDIR)/$(PACKAGE).so
AM_CFLAGS = \
$(PHPINC) $(LIBXML_CFLAGS) \
- $(LIBVIRT_CFLAGS) $(DEFINES) \
+ $(LIBVIRT_CFLAGS) $(QEMU_CFLAGS) $(DEFINES) \
-I$(top_srcdir)/winsrc
AM_LDFLAGS = \
$(SHLIB_LDFLAGS) \
$(LIBXML_LIBS) \
- $(LIBVIRT_LIBS)
+ $(LIBVIRT_LIBS) \
+ $(QEMU_LIBS)
lib_LTLIBRARIES = libvirt-php.la
diff --git a/src/libvirt-php.c b/src/libvirt-php.c
index d46fbb9..f9d5557 100644
--- a/src/libvirt-php.c
+++ b/src/libvirt-php.c
@@ -161,6 +161,7 @@ static zend_function_entry libvirt_functions[] = {
PHP_FE(libvirt_domain_send_keys, NULL)
PHP_FE(libvirt_domain_send_pointer_event, NULL)
PHP_FE(libvirt_domain_update_device, NULL)
+ PHP_FE(libvirt_domain_qemu_agent_command, NULL)
/* Domain snapshot functions */
PHP_FE(libvirt_domain_has_current_snapshot, NULL)
PHP_FE(libvirt_domain_snapshot_create, NULL)
@@ -3943,6 +3944,33 @@ PHP_FUNCTION(libvirt_domain_get_name)
}
/*
+ Function name: libvirt_domain_qemu_agent_command
+ Since version: 0.5.2(-1)
+ Description:Function is used to send qemu-ga command
+ Arguments: @res [resource]: libvirt domain resource, e.g. from
libvirt_domain_lookup_by_*()
+ @timeout [int]: timeout for waiting (-2 block, -1
default, 0 no wait, 0 wait specific time
+ @flags [int]: ??
+ Returns:String on success and FALSE on error
+*/
+PHP_FUNCTION(libvirt_domain_qemu_agent_command)
+{
+ php_libvirt_domain *domain=NULL;
+ zval *zdomain;
+ const char *cmd;
+ int cmd_len;
+ char *ret;
+ long timeout = -1;
+ long flags = 0;
+
+ GET_DOMAIN_FROM_ARGS(rs|l|l, zdomain, cmd, cmd_len, timeout,
flags);
+
+ ret = virDomainQemuAgentCommand(domain-domain, cmd, timeout, flags);
+ if (ret == NULL) RETURN_FALSE;
+
+ RETURN_STRING(ret,1);
+}
+
+/*
Function name: libvirt_domain_get_uuid_string
Since version: 0.4.1(-1)
Description:Function is used to get the domain's UUID in string
format
diff --git a/src/libvirt-php.h b/src/libvirt-php.h
index 7c9a229..1d9c6ab 100644
--- a/src/libvirt-php.h
+++ b/src/libvirt-php.h
@@ -80,6 +80,7 @@
#include libvirt/libvirt.h
#include libvirt/virterror.h
+#include libvirt/libvirt-qemu.h
#include libxml/parser.h
#include libxml/xpath.h
#include fcntl.h
@@ -427,6 +428,7 @@ PHP_FUNCTION(libvirt_domain_send_keys);
PHP_FUNCTION(libvirt_domain_send_pointer_event);
PHP_FUNCTION(libvirt_domain_get_metadata);
PHP_FUNCTION(libvirt_domain_set_metadata);
+PHP_FUNCTION(libvirt_domain_qemu_agent_command);
/* Domain snapshot functions */
[libvirt] [PATCH 0/3] Fix yet again some Admin API bugs
Pushed under trivial and build-breaker rules. The 'make rpm' is broken. There is still one issue I'm chasing down. Running 'distcheck' shows some errors. Michal Privoznik (3): daemon: Distribute admin_server.h tests: Follow virnetserver to virnetdaemon transition libvirt.spec: Don't expect virt-admin in libvirt-admin yet daemon/Makefile.am | 2 +- libvirt.spec.in| 2 -- tests/Makefile.am | 2 +- 3 files changed, 2 insertions(+), 4 deletions(-) -- 2.3.6 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] incorrect memory size inside vm
On Wed, Jun 17, 2015 at 4:35 PM, Vasiliy Tolstov v.tols...@selfip.ru wrote: Hi. I have issue with incorrect memory side inside vm. I'm try utilize memory balloon (not memory hotplug, because i have guest without memory hotplug (may be)). When domain started with static memory all works fine, but then i'm specify in libvirt memory = 16384 , maxMemory = 16384 and currentMemory = 1024, guest in f/rpoc/meminfo says that have only 603608 Kb memory. Then i set memory via virsh setmem to 2Gb, guest see only 1652184 Kb memory. software versions libvirt: 1.2.10 qemu: 2.3.0 Guest OS: centos 6. qemu.log: LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin HOME=/root USER=root LOGNAME=root QEMU_AUDIO_DRV=none /usr/bin/kvm -name 26543 -S -machine pc-i440fx-1.7,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp 1,maxcpus=4,sockets=4,cores=1,threads=1 -uuid 4521fb01-c2ca-4269-d2d6-035fd910 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/26543.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,num_queues=1,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive file=/dev/vg4/26543,if=none,id=drive-scsi0-0-0-0,format=raw,cache=none,discard=unmap,aio=native,iops=5000 -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -drive if=none,id=drive-scsi0-0-1-0,readonly=on,format=raw -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=1,lun=0,drive=drive-scsi0-0-1-0,id=scsi0-0-1-0 -netdev tap,fd=30,id=hostnet0,vhost=on,vhostfd=52 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:00:34:f7,bus=pci.0,addr=0x3,rombar=0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/26543.agent,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device usb-mouse,id=input0 -device usb-kbd,id=input1 -vnc [::]:8,password -device VGA,id=video0,bus=pci.0,addr=0x2 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5 -object rng-random,id=rng0,filename=/dev/random -device virtio-rng-pci,rng=rng0,max-bytes=1024,period=2000,bus=pci.0,addr=0x7 -msg timestamp=on -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru The rest of visible memory is eaten by reserved kernel areas, for us this was a main reason to switch to a hotplug a couple of years ago. You would not be able to scale a VM by an order of magnitude with regular balloon mechanism without mentioned impact, unfortunately. Igor Mammedov posted hotplug-related patches for 2.6.32 a while ago, though RHEL6 never adopted them by some reason. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/5 v2] Corrections to SCSI logical unit handling
On 06/16/2015 11:29 PM, Eric Farman wrote: While working with the hostdev tag and SCSI LUNs, a problem was discovered with the XML schema (see commit message in patch 4). This spawned some further corrections to the handling of the logical unit field throughout libvirt. This series was split from a single patch, from this feedback: http://www.redhat.com/archives/libvir-list/2015-June/msg00489.html Eric Farman (5): Print SCSI logical unit as a positive integer Print SCSI logical unit as unsigned integer Convert SCSI logical unit from int to long long docs: Fix XML schema handling of LUN address in hostdev tag docs: Correct typos in scsi hostdev and address elements I get the value of small patches agree with the way patches 4 and 5 are split out, but patch 1 and 2 are completely replaced by patch 3 with a different type. These are pretty straightforward changes, so I'd suggest squashing patches 1-3 as a single patch that just goes from signed int -- unsigned long long and has a commit that explains why we needed to change both size and sign... I see now that it was a v1 comment from John, so I'll leave it to his judgment. Regardless, code still looks good to me so you can feel free to keep my reviewed-by tag for the set, whether patches 1-3 are squashed or not. Reviewed-by: Matthew Rosato mjros...@linux.vnet.ibm.com docs/formatdomain.html.in | 10 +++--- docs/schemas/domaincommon.rng | 14 -- src/conf/domain_audit.c | 2 +- src/conf/domain_conf.c| 4 ++-- src/conf/domain_conf.h| 2 +- src/qemu/qemu_command.h | 2 +- src/qemu/qemu_hotplug.c | 4 ++-- src/util/virhostdev.c | 6 +++--- src/util/virscsi.c| 16 src/util/virscsi.h| 8 tests/testutilsqemu.c | 2 +- tools/virsh-domain.c | 6 +++--- 12 files changed, 45 insertions(+), 31 deletions(-) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/3] parallels: add memory statistics
Implemented counters:
VIR_DOMAIN_MEMORY_STAT_SWAP_IN
VIR_DOMAIN_MEMORY_STAT_SWAP_OUT
VIR_DOMAIN_MEMORY_STAT_MINOR_FAULT
VIR_DOMAIN_MEMORY_STAT_MAJOR_FAULT
VIR_DOMAIN_MEMORY_STAT_AVAILABLE
VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON
VIR_DOMAIN_MEMORY_STAT_UNUSED
Comments.
1. Use vzDomObjFromDomainRef/virDomainObjEndAPI pair to get domain
object as we use prlsdkGetStatsParam. See previous statistics
comments.
2. Balloon statistics is not applicable to containers. Fault
statistics for containers not provided in PCS6 yet.
Signed-off-by: Nikolay Shirokovskiy nshirokovs...@parallels.com
---
src/vz/vz_driver.c | 73
1 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c
index 4197569..8dae7c4 100644
--- a/src/vz/vz_driver.c
+++ b/src/vz/vz_driver.c
@@ -1377,6 +1377,78 @@ vzDomainInterfaceStats(virDomainPtr domain,
return ret;
}
+static int
+vzDomainMemoryStats(virDomainPtr domain,
+ virDomainMemoryStatPtr stats,
+ unsigned int nr_stats,
+ unsigned int flags)
+{
+virDomainObjPtr dom = NULL;
+int ret = -1;
+long long v = 0, t = 0, u = 0;
+size_t i = 0;
+
+virCheckFlags(0, -1);
+if (!(dom = vzDomObjFromDomainRef(domain)))
+return -1;
+
+#define PARALLELS_GET_COUNTER(NAME, VALUE) \
+if (prlsdkGetStatsParam(dom, NAME, VALUE) 0) \
+goto cleanup; \
+
+#define PARALLELS_MEMORY_STAT_SET(TAG, VALUE) \
+if (i nr_stats) { \
+stats[i].tag = (TAG); \
+stats[i].val = (VALUE); \
+i++;\
+}
+
+#define PARALLELS_COUNTER_PROTECT(VALUE) VALUE == -1 : ?
+
+i = 0;
+
+// count to kb
+PARALLELS_GET_COUNTER(guest.ram.swap_in, v)
+if (v != -1)
+PARALLELS_MEMORY_STAT_SET(VIR_DOMAIN_MEMORY_STAT_SWAP_IN, v 12)
+
+PARALLELS_GET_COUNTER(guest.ram.swap_out, v)
+if (v != -1)
+PARALLELS_MEMORY_STAT_SET(VIR_DOMAIN_MEMORY_STAT_SWAP_OUT, v 12)
+
+PARALLELS_GET_COUNTER(guest.ram.minor_fault, v)
+if (v != -1)
+PARALLELS_MEMORY_STAT_SET(VIR_DOMAIN_MEMORY_STAT_MINOR_FAULT, v)
+
+PARALLELS_GET_COUNTER(guest.ram.major_fault, v)
+if (v != -1)
+PARALLELS_MEMORY_STAT_SET(VIR_DOMAIN_MEMORY_STAT_MAJOR_FAULT, v)
+
+PARALLELS_GET_COUNTER(guest.ram.total, v)
+if (v != -1)
+PARALLELS_MEMORY_STAT_SET(VIR_DOMAIN_MEMORY_STAT_AVAILABLE, v 10)
+
+PARALLELS_GET_COUNTER(guest.ram.balloon_actual, v)
+if (v != -1)
+PARALLELS_MEMORY_STAT_SET(VIR_DOMAIN_MEMORY_STAT_ACTUAL_BALLOON, v
10)
+
+PARALLELS_GET_COUNTER(guest.ram.usage, u)
+PARALLELS_GET_COUNTER(guest.ram.total, t)
+if (u != -1 t != -1)
+PARALLELS_MEMORY_STAT_SET(VIR_DOMAIN_MEMORY_STAT_UNUSED, (t - u) 10)
+
+
+#undef PARALLELS_GET_COUNTER
+#undef PARALLELS_MEMORY_STAT_SET
+
+ret = i;
+ cleanup:
+if (dom)
+virDomainObjEndAPI(dom);
+
+return ret;
+}
+
static virHypervisorDriver vzDriver = {
.name = vz,
.connectOpen = vzConnectOpen,/* 0.10.0 */
@@ -1429,6 +1501,7 @@ static virHypervisorDriver vzDriver = {
.domainBlockStats = vzDomainBlockStats, /* 1.3.0 */
.domainBlockStatsFlags = vzDomainBlockStatsFlags, /* 1.3.0 */
.domainInterfaceStats = vzDomainInterfaceStats, /* 1.3.0 */
+.domainMemoryStats = vzDomainMemoryStats, /* 1.3.0 */
};
static virConnectDriver vzConnectDriver = {
--
1.7.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/3] parallels: add vcpu statistics
Comments.
Replace vzDomObjFromDomain/virObjectUnlock pair
to vzDomObjFromDomainRef/virDomainObjEndAPI as we
use prlsdkGetStatsParam. See previous statistics
comments.
Signed-off-by: Nikolay Shirokovskiy nshirokovs...@parallels.com
---
src/vz/vz_driver.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c
index deac572..4197569 100644
--- a/src/vz/vz_driver.c
+++ b/src/vz/vz_driver.c
@@ -825,8 +825,9 @@ vzDomainGetVcpus(virDomainPtr domain,
size_t i;
int v, maxcpu, hostcpus;
int ret = -1;
+char *name = NULL;
-if (!(privdom = vzDomObjFromDomain(domain)))
+if (!(privdom = vzDomObjFromDomainRef(domain)))
goto cleanup;
if (!virDomainObjIsActive(privdom)) {
@@ -847,8 +848,18 @@ vzDomainGetVcpus(virDomainPtr domain,
if (info != NULL) {
memset(info, 0, sizeof(*info) * maxinfo);
for (i = 0; i maxinfo; i++) {
+long long vcpuTime = 0;
+
info[i].number = i;
info[i].state = VIR_VCPU_RUNNING;
+
+if (virAsprintf(name, guest.vcpu%u.time, (unsigned int)i)
0)
+goto cleanup;
+if (prlsdkGetStatsParam(privdom, name, vcpuTime) 0)
+goto cleanup;
+if (vcpuTime != -1)
+info[i].cpuTime = vcpuTime;
+VIR_FREE(name);
}
}
if (cpumaps != NULL) {
@@ -871,7 +882,8 @@ vzDomainGetVcpus(virDomainPtr domain,
cleanup:
if (privdom)
-virObjectUnlock(privdom);
+virDomainObjEndAPI(privdom);
+VIR_FREE(name);
return ret;
}
--
1.7.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/2] Support for the new watchdog action inject-nmi
This patches provides support for the new watchdog action inject-nmi which
allows to define an inject of a non-maskable interrupt into a guest.
Signed-off-by: Boris Fiuczynski fiu...@linux.vnet.ibm.com
Reviewed-by: Daniel Hansel daniel.han...@linux.vnet.ibm.com
Reviewed-by: Stefan Zimmermann s...@linux.vnet.ibm.com
Reviewed-by: Tony Krowiak akrow...@linux.vnet.ibm.com
---
docs/formatdomain.html.in| 3 +++
docs/schemas/domaincommon.rng| 1 +
include/libvirt/libvirt-domain.h | 1 +
src/conf/domain_conf.c | 3 ++-
src/conf/domain_conf.h | 1 +
src/qemu/qemu_monitor_json.c | 2 +-
tools/virsh-domain.c | 3 ++-
7 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 4e85b51..0ee555d 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -5704,6 +5704,9 @@ qemu-kvm -net nic,model=? /dev/null
li'none' mdash; do nothing/li
li'dump' mdash; automatically dump the guest
span class=sinceSince 0.8.7/span/li
+ li'inject-nmi' mdash; inject a non-maskable interrupt
+into the guest
+span class=sinceSince 1.3.0/span/li
/ul
p
Note 1: the 'shutdown' action requires that the guest
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index f0f7400..55dec4e 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -3272,6 +3272,7 @@
valuepause/value
valuenone/value
valuedump/value
+valueinject-nmi/value
/choice
/attribute
/optional
diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h
index d851225..ed34d53 100644
--- a/include/libvirt/libvirt-domain.h
+++ b/include/libvirt/libvirt-domain.h
@@ -2833,6 +2833,7 @@ typedef enum {
VIR_DOMAIN_EVENT_WATCHDOG_POWEROFF, /* Guest is forcibly powered off */
VIR_DOMAIN_EVENT_WATCHDOG_SHUTDOWN, /* Guest is requested to gracefully
shutdown */
VIR_DOMAIN_EVENT_WATCHDOG_DEBUG,/* No action, a debug message logged */
+VIR_DOMAIN_EVENT_WATCHDOG_INJECTNMI,/* Inject a non-maskable interrupt
into guest */
# ifdef VIR_ENUM_SENTINELS
VIR_DOMAIN_EVENT_WATCHDOG_LAST
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index ca55981..ecf7b0d 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -506,7 +506,8 @@ VIR_ENUM_IMPL(virDomainWatchdogAction,
VIR_DOMAIN_WATCHDOG_ACTION_LAST,
poweroff,
pause,
dump,
- none)
+ none,
+ inject-nmi)
VIR_ENUM_IMPL(virDomainVideo, VIR_DOMAIN_VIDEO_TYPE_LAST,
vga,
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index ba17a8d..e677f30 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1315,6 +1315,7 @@ typedef enum {
VIR_DOMAIN_WATCHDOG_ACTION_PAUSE,
VIR_DOMAIN_WATCHDOG_ACTION_DUMP,
VIR_DOMAIN_WATCHDOG_ACTION_NONE,
+VIR_DOMAIN_WATCHDOG_ACTION_INJECTNMI,
VIR_DOMAIN_WATCHDOG_ACTION_LAST
} virDomainWatchdogAction;
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index 13c57d2..aef7c44 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -557,7 +557,7 @@ static void qemuMonitorJSONHandleRTCChange(qemuMonitorPtr
mon, virJSONValuePtr d
VIR_ENUM_DECL(qemuMonitorWatchdogAction)
VIR_ENUM_IMPL(qemuMonitorWatchdogAction, VIR_DOMAIN_EVENT_WATCHDOG_LAST,
- none, pause, reset, poweroff, shutdown, debug);
+ none, pause, reset, poweroff, shutdown, debug,
inject-nmi);
static void qemuMonitorJSONHandleWatchdog(qemuMonitorPtr mon, virJSONValuePtr
data)
{
diff --git a/tools/virsh-domain.c b/tools/virsh-domain.c
index 4c47473..cc1e46d 100644
--- a/tools/virsh-domain.c
+++ b/tools/virsh-domain.c
@@ -11677,7 +11677,8 @@ VIR_ENUM_IMPL(vshDomainEventWatchdog,
N_(reset),
N_(poweroff),
N_(shutdown),
- N_(debug))
+ N_(debug),
+ N_(inject-nmi))
static const char *
vshDomainEventWatchdogToString(int action)
--
2.3.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/2] Support for new watchdog model diag288 and action inject-nmi
This patche set provides support for the new watchdog model diag288 including the new watchdog action inject-nmi. Boris Fiuczynski (2): Support for the new watchdog action inject-nmi Support for the new watchdog model diag288 docs/formatdomain.html.in| 5 + docs/schemas/domaincommon.rng| 2 ++ include/libvirt/libvirt-domain.h | 1 + src/conf/domain_conf.c | 6 -- src/conf/domain_conf.h | 2 ++ src/qemu/qemu_command.c | 6 +++--- src/qemu/qemu_monitor_json.c | 2 +- tools/virsh-domain.c | 3 ++- 8 files changed, 20 insertions(+), 7 deletions(-) -- 2.3.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/2] Support for the new watchdog model diag288
This patches provides support for the new watchdog model diag288.
Signed-off-by: Boris Fiuczynski fiu...@linux.vnet.ibm.com
Reviewed-by: Daniel Hansel daniel.han...@linux.vnet.ibm.com
Reviewed-by: Stefan Zimmermann s...@linux.vnet.ibm.com
Reviewed-by: Tony Krowiak akrow...@linux.vnet.ibm.com
---
docs/formatdomain.html.in | 2 ++
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_conf.c| 3 ++-
src/conf/domain_conf.h| 1 +
src/qemu/qemu_command.c | 6 +++---
5 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 0ee555d..e0ae40e 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -5683,6 +5683,8 @@ qemu-kvm -net nic,model=? /dev/null
li 'i6300esb' mdash; the recommended device,
emulating a PCI Intel 6300ESB /li
li 'ib700' mdash; emulating an ISA iBase IB700 /li
+ li 'diag288' mdash; emulating an S390 DIAG288 device
+span class=sinceSince 1.3.0/span/li
/ul
/dd
dtcodeaction/code/dt
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 55dec4e..1f26c53 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -3261,6 +3261,7 @@
choice
valuei6300esb/value
valueib700/value
+ valuediag288/value
/choice
/attribute
optional
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index ecf7b0d..c27c8c6 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -498,7 +498,8 @@ VIR_ENUM_IMPL(virDomainSmbiosMode, VIR_DOMAIN_SMBIOS_LAST,
VIR_ENUM_IMPL(virDomainWatchdogModel, VIR_DOMAIN_WATCHDOG_MODEL_LAST,
i6300esb,
- ib700)
+ ib700,
+ diag288)
VIR_ENUM_IMPL(virDomainWatchdogAction, VIR_DOMAIN_WATCHDOG_ACTION_LAST,
reset,
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index e677f30..d5f1cd9 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1304,6 +1304,7 @@ struct _virDomainSoundDef {
typedef enum {
VIR_DOMAIN_WATCHDOG_MODEL_I6300ESB,
VIR_DOMAIN_WATCHDOG_MODEL_IB700,
+VIR_DOMAIN_WATCHDOG_MODEL_DIAG288,
VIR_DOMAIN_WATCHDOG_MODEL_LAST
} virDomainWatchdogModel;
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 3886b4f..52bb1d1 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -2308,7 +2308,7 @@ qemuDomainAssignPCIAddresses(virDomainDefPtr def,
* - VirtIO block
* - VirtIO balloon
* - Host device passthrough
- * - Watchdog (not IB700)
+ * - Watchdog
* - pci serial devices
*
* Prior to this function being invoked, qemuCollectPCIAddress() will have
@@ -2545,9 +2545,9 @@ qemuAssignDevicePCISlots(virDomainDefPtr def,
goto error;
}
-/* A watchdog - skip IB700, it is not a PCI device */
+/* A watchdog - check if it is a PCI device */
if (def-watchdog
-def-watchdog-model != VIR_DOMAIN_WATCHDOG_MODEL_IB700
+def-watchdog-model == VIR_DOMAIN_WATCHDOG_MODEL_I6300ESB
def-watchdog-info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) {
if (virDomainPCIAddressReserveNextSlot(addrs, def-watchdog-info,
flags) 0)
--
2.3.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 3/3] libvirt.spec: Don't expect virt-admin in libvirt-admin yet
While Martin introduced the binary (and its manpage) in commit
4e7ccf87133 it was pushed by mistake. Therefore it was reverted in
220393bfb043. The problem is, the original commit was not quite right
as the binary was added into the spec file in a different commit:
55e0c840af. So as long as the binary does not exist, we must remove it
from the spec file too.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
libvirt.spec.in | 2 --
1 file changed, 2 deletions(-)
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 592e9b9..dcd174a 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -2221,8 +2221,6 @@ exit 0
%files admin
%defattr(-, root, root)
-%{_mandir}/man1/virt-admin.1*
-%{_bindir}/virt-admin
%{_libdir}/libvirt-admin.so.*
%files client -f %{name}.lang
--
2.3.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/3] tests: Follow virnetserver to virnetdaemon transition
In a4746114582 the virnetserver test was renamed to virnetdaemon. Moreover, as the test relies on some data stored under virnetserverdata/ the folder was renamed too. But this was not reflected in the Makefile. Therefore when building outside of the repository, the data folder was not distributed and test failed. Signed-off-by: Michal Privoznik mpriv...@redhat.com --- tests/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index cefe8b3..a1cca5c 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -137,8 +137,8 @@ EXTRA_DIST =\ virsh-uriprecedence \ vircgroupdata \ virfiledata \ + virnetdaemondata \ virnetdevtestdata \ - virnetserverdata \ virpcitestdata \ virscsidata \ virusbtestdata \ -- 2.3.6 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/3] daemon: Distribute admin_server.h
The Admin API consists of a few files on daemon side. Notably
daemon/admin_server.{ch}. While they are both on the repo, only
the .c file is mentioned in Makefile. Therefore, .h is not
distributed and 'make rpm' fails.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
daemon/Makefile.am | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/daemon/Makefile.am b/daemon/Makefile.am
index bb08d9f..b9c089d 100644
--- a/daemon/Makefile.am
+++ b/daemon/Makefile.am
@@ -128,7 +128,7 @@ libvirtd_conf_la_LIBADD = $(LIBXML_LIBS)
noinst_LTLIBRARIES += libvirtd_admin.la
libvirtd_admin_la_SOURCES = \
- admin_server.c \
+ admin_server.c admin_server.h \
../src/admin/admin_protocol.c
libvirtd_admin_la_CFLAGS = \
--
2.3.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/5 v2] Corrections to SCSI logical unit handling
On 06/17/2015 04:29 PM, Matthew Rosato wrote: On 06/16/2015 11:29 PM, Eric Farman wrote: While working with the hostdev tag and SCSI LUNs, a problem was discovered with the XML schema (see commit message in patch 4). This spawned some further corrections to the handling of the logical unit field throughout libvirt. This series was split from a single patch, from this feedback: http://www.redhat.com/archives/libvir-list/2015-June/msg00489.html Eric Farman (5): Print SCSI logical unit as a positive integer Print SCSI logical unit as unsigned integer Convert SCSI logical unit from int to long long docs: Fix XML schema handling of LUN address in hostdev tag docs: Correct typos in scsi hostdev and address elements I get the value of small patches agree with the way patches 4 and 5 are split out, but patch 1 and 2 are completely replaced by patch 3 with a different type. These are pretty straightforward changes, so I'd suggest squashing patches 1-3 as a single patch that just goes from signed int -- unsigned long long and has a commit that explains why we needed to change both size and sign... I see now that it was a v1 comment from John, so I'll leave it to his judgment. The recommendation came from John and since he can push... following it to get it upstream is ... OK. :-) Regardless, code still looks good to me so you can feel free to keep my reviewed-by tag for the set, whether patches 1-3 are squashed or not. Reviewed-by: Matthew Rosato mjros...@linux.vnet.ibm.com I agree with Mat! Reviewed-by: Boris Fiuczynski fiu...@linux.vnet.ibm.com Another side info: I will currently not revert your former patch and apply this patch set on branches devel and rebased but wait until I update to libvirt v1.3.0! If you disagree with this approach please let me know. -- Mit freundlichen Grüßen/Kind regards Boris Fiuczynski IBM Deutschland Research Development GmbH Vorsitzender des Aufsichtsrats: Martina Köderitz Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 1/3] parallels: add net dev statistiscs
Populate counters SDK currenly supports:
rx_bytes
rx_packets
tx_bytes
tx_packets
Comments.
1. Use vzDomObjFromDomainRef/virDomainObjEndAPI pair to get domain
object as we use prlsdkGetStatsParam that can release domain
object lock and thus we need a reference in case domain
is deleated meanwhile.
2. Introduce prlsdkGetAdapterIndex to convert from
device name to SDK device index. We need this index
as it is used in statistics data from SDK identify
network device. Unfortunately we need to enumerate
network devices to discover this mapping.
Signed-off-by: Nikolay Shirokovskiy nshirokovs...@parallels.com
---
src/vz/vz_driver.c | 44 +
src/vz/vz_sdk.c| 69 +++-
src/vz/vz_sdk.h|4 +++
3 files changed, 116 insertions(+), 1 deletions(-)
diff --git a/src/vz/vz_driver.c b/src/vz/vz_driver.c
index cef3c77..deac572 100644
--- a/src/vz/vz_driver.c
+++ b/src/vz/vz_driver.c
@@ -1321,6 +1321,49 @@ vzDomainBlockStatsFlags(virDomainPtr domain,
return ret;
}
+static int
+vzDomainInterfaceStats(virDomainPtr domain,
+ const char *path,
+ virDomainInterfaceStatsPtr stats)
+{
+virDomainObjPtr dom = NULL;
+int ret = -1;
+int net_index = -1;
+char *name = NULL;
+
+if (!(dom = vzDomObjFromDomainRef(domain)))
+return -1;
+
+net_index = prlsdkGetAdapterIndex(dom, path);
+if (net_index 0)
+return -1;
+
+#define PARALLELS_GET_NET_COUNTER(VAL, NAME)\
+if (virAsprintf(name, net.nic%d.%s, net_index, NAME) 0)\
+goto cleanup; \
+if (prlsdkGetStatsParam(dom, name, stats-VAL) 0)\
+goto cleanup; \
+VIR_FREE(name);
+
+PARALLELS_GET_NET_COUNTER(rx_bytes, bytes_in)
+PARALLELS_GET_NET_COUNTER(rx_packets, pkts_in)
+PARALLELS_GET_NET_COUNTER(tx_bytes, bytes_out)
+PARALLELS_GET_NET_COUNTER(tx_packets, pkts_out)
+stats-rx_errs = -1;
+stats-rx_drop = -1;
+stats-tx_errs = -1;
+stats-tx_drop = -1;
+
+#undef PARALLELS_GET_NET_COUNTER
+ret = 0;
+
+ cleanup:
+VIR_FREE(name);
+if (dom)
+virDomainObjEndAPI(dom);
+
+return ret;
+}
static virHypervisorDriver vzDriver = {
.name = vz,
@@ -1373,6 +1416,7 @@ static virHypervisorDriver vzDriver = {
.domainGetMaxMemory = vzDomainGetMaxMemory, /* 1.2.15 */
.domainBlockStats = vzDomainBlockStats, /* 1.3.0 */
.domainBlockStatsFlags = vzDomainBlockStatsFlags, /* 1.3.0 */
+.domainInterfaceStats = vzDomainInterfaceStats, /* 1.3.0 */
};
static virConnectDriver vzConnectDriver = {
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index f9cde44..0956b58 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -3562,7 +3562,7 @@ prlsdkExtractStatsParam(PRL_HANDLE sdkstats, const char
*name, long long *val)
#define PARALLELS_STATISTICS_TIMEOUT (60 * 1000)
-static int
+int
prlsdkGetStatsParam(virDomainObjPtr dom, const char *name, long long *val)
{
vzDomObjPtr privdom = dom-privateData;
@@ -3658,3 +3658,70 @@ prlsdkGetBlockStats(virDomainObjPtr dom,
virDomainDiskDefPtr disk, virDomainBloc
VIR_FREE(name);
return ret;
}
+
+static PRL_HANDLE
+prlsdkFindNetAdapter(virDomainObjPtr dom, const char *path)
+{
+PRL_UINT32 count = 0;
+vzDomObjPtr privdom = dom-privateData;
+PRL_UINT32 buflen = 0;
+PRL_RESULT pret;
+size_t i;
+char *name = NULL;
+PRL_HANDLE net = PRL_INVALID_HANDLE;
+
+pret = PrlVmCfg_GetNetAdaptersCount(privdom-sdkdom, count);
+prlsdkCheckRetGoto(pret, error);
+
+for (i = 0; i count; ++i) {
+pret = PrlVmCfg_GetNetAdapter(privdom-sdkdom, i, net);
+prlsdkCheckRetGoto(pret, error);
+
+pret = PrlVmDevNet_GetHostInterfaceName(net, NULL, buflen);
+prlsdkCheckRetGoto(pret, error);
+
+if (VIR_ALLOC_N(name, buflen) 0)
+goto error;
+
+pret = PrlVmDevNet_GetHostInterfaceName(net, name, buflen);
+prlsdkCheckRetGoto(pret, error);
+
+if (STREQ(name, path))
+break;
+
+VIR_FREE(name);
+PrlHandle_Free(net);
+net = PRL_INVALID_HANDLE;
+}
+
+if (net == PRL_INVALID_HANDLE)
+virReportError(VIR_ERR_INVALID_ARG,
+ _(invalid path, '%s' is not a known interface), path);
+return net;
+
+ error:
+VIR_FREE(name);
+PrlHandle_Free(net);
+return PRL_INVALID_HANDLE;
+}
+
+int
+prlsdkGetAdapterIndex(virDomainObjPtr dom, const char *path)
+{
+PRL_HANDLE net = PRL_INVALID_HANDLE;
+PRL_UINT32 net_index = -1;
+PRL_RESULT pret;
+int ret = -1;
+
+net = prlsdkFindNetAdapter(dom, path);
+if (net == PRL_INVALID_HANDLE)
+return -1;
+
+pret = PrlVmDev_GetIndex(net, net_index);
+prlsdkCheckRetGoto(pret, cleanup);
+
+ret = net_index;
+ cleanup:
+
Re: [libvirt] PING: [PATCH v2 0/2] Allow PCI virtio on ARM virt machine
Sorry I was offline 12-16, I'll review this before end of the week - Cole On 06/16/2015 04:06 AM, Pavel Fedin wrote: Hello ? Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -Original Message- From: libvir-list-boun...@redhat.com [mailto:libvir-list-boun...@redhat.com] On Behalf Of Pavel Fedin Sent: Thursday, June 11, 2015 9:41 AM To: libvir-list@redhat.com Cc: Pavel Fedin Subject: [libvirt] [PATCH v2 0/2] Allow PCI virtio on ARM virt machine Virt machine in qemu since v2.3.0 has PCI generic host controller, and can use PCI devices. This provides performance improvement as well as vhost-net with irqfd support for virtio-net. However libvirt still insists on virtio devices attached to virt machine to have MMIO bindings. This patch allows to use both. If the user doesn't specify address type='virtio-mmio', PCI will be used by default. Changes since v1: - Added capability based on qemu version number - Recognize also virt- prefix Pavel Fedin (2): Introduce QEMU_CAPS_ARM_VIRT_PCI Allow PCI virtio on ARM virt machine src/qemu/qemu_capabilities.c | 5 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 15 --- 3 files changed, 18 insertions(+), 3 deletions(-) -- 1.9.5.msysgit.0 -- 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] [PATCH 3/4] parallels: Switch on DHCP for newly created network adapters
17.06.2015 16:38, Laine Stump пишет:
On 06/17/2015 08:35 AM, Mikhail Feoktistov wrote:
Let network adapter use DHCP server to get network configuration.
To do this we use PrlVmDevNet_SetConfigureWithDhcp to enable it and
PrlVmDevNet_SetAutoApply to makes necessary settings within guest OS
In linux case it creates network startup scripts
/etc/sysconfig/network-scripts/ifcfg-ethN and fills it with necessary
parameters.
(sorry for getting a bit off-topic)
The semantics of this are different for qemu - attaching a network
device only presents the hardware to the virtual machine; it doesn't
attempt to make any configuration changes in the guest OS. I *think*
that the xen and lxc drivers do configure the guest though (at least
they pay attention to the ip element in the interface). So this
isn't any criticism of your implementation, I'm just wondering whether
or not this will make a difference to any management apps using libvirt.
(actually this also brings to mind an idle thought I've had for awhile -
while it's possible to configure an IP address for a qemu guest from the
libvirt configuration in some cases (when the guest interface is
connected to a libvirt virtual network, you can add a static IP entry to
the network's dhcp config), it might be nice to recognize the ip
element in the interface, and use it to dynamically add a static IP
entry to the dnsmasq instance for the attached network. Does anyone have
an opinion on whether that would be useful/ugly/confusing?)
I think it could be useful. Actually, I intended to make a comment to
this patch that we
should pay attention to ip element in the interface and set DHCP
only if address
isn't configured explicitly, otherwise we should call
PrlVmDevNet_SetNetAddresses
which will interact with guest tools (if any) and set specified IP
addresses with help
of guest agent.
As for automatic dnsmasq configuration it could be useful too if guest
agent is
absent. But I wonder, wouldn't this contradict with OpenStack usecase,
for example,
when dnsmasq is configured with certain IP addresses and other network
parameters, and
nothing is specified in libvirt config regarding adapter configuration?
---
src/vz/vz_sdk.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/vz/vz_sdk.c b/src/vz/vz_sdk.c
index 98f7a57..090a3ad 100644
--- a/src/vz/vz_sdk.c
+++ b/src/vz/vz_sdk.c
@@ -2815,6 +2815,12 @@ static int prlsdkAddNet(PRL_HANDLE sdkdom,
pret = PrlVmDevNet_SetMacAddress(sdknet, macstr);
prlsdkCheckRetGoto(pret, cleanup);
+pret = PrlVmDevNet_SetConfigureWithDhcp(sdknet, true);
+prlsdkCheckRetGoto(pret, cleanup);
+
+pret = PrlVmDevNet_SetAutoApply(sdknet, true);
+prlsdkCheckRetGoto(pret, cleanup);
+
if (isCt) {
if (net-model)
VIR_WARN(Setting network adapter for containers is not
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 2/2] qemu: fix a document issue as we support host-passthrough with features
From the documentation :With this mode, the CPU visible to the guest should be exactly the same as the host CPU even in the aspects that libvirt does not understand. So this place document need fix. Signed-off-by: Luyao Huang lhu...@redhat.com --- src/qemu/qemu_process.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c index 64ee049..3cd0ff4 100644 --- a/src/qemu/qemu_process.c +++ b/src/qemu/qemu_process.c @@ -4024,8 +4024,10 @@ qemuProcessVerifyGuestCPU(virQEMUDriverPtr driver, bool ret = false; size_t i; -/* no features are passed to QEMU with -cpu host - * so it makes no sense to verify them */ +/* Although we allow set features with host-passthrough + * cpu mode, we allow user require/disable the feature + * that libvirt does not understand, so it makes no sense + * to verify them */ if (def-cpu def-cpu-mode == VIR_CPU_MODE_HOST_PASSTHROUGH) return true; -- 1.8.3.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCHv1.5 1/2] cpu:x86: fix specified features will disappear after migrate/restore
https://bugzilla.redhat.com/show_bug.cgi?id=1207095
We allow set the feature with the host-passthrough cpu,
but won't save them in the migration xml, the features we
specified will disappear after migrate/restore. This is because
we skip the virCPUDefUpdateFeature if cpu mode is host-passthrough.
Signed-off-by: Luyao Huang lhu...@redhat.com
---
v1.5: just update the description.
src/cpu/cpu_x86.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/src/cpu/cpu_x86.c b/src/cpu/cpu_x86.c
index 2a14705..26601b6 100644
--- a/src/cpu/cpu_x86.c
+++ b/src/cpu/cpu_x86.c
@@ -2087,8 +2087,7 @@ x86UpdateCustom(virCPUDefPtr guest,
static int
x86UpdateHostModel(virCPUDefPtr guest,
- const virCPUDef *host,
- bool passthrough)
+ const virCPUDef *host)
{
virCPUDefPtr oldguest = NULL;
const struct x86_map *map;
@@ -2124,7 +2123,7 @@ x86UpdateHostModel(virCPUDefPtr guest,
}
}
}
-for (i = 0; !passthrough i oldguest-nfeatures; i++) {
+for (i = 0; i oldguest-nfeatures; i++) {
if (virCPUDefUpdateFeature(guest,
oldguest-features[i].name,
oldguest-features[i].policy) 0)
@@ -2149,11 +2148,11 @@ x86Update(virCPUDefPtr guest,
case VIR_CPU_MODE_HOST_MODEL:
guest-match = VIR_CPU_MATCH_EXACT;
-return x86UpdateHostModel(guest, host, false);
+return x86UpdateHostModel(guest, host);
case VIR_CPU_MODE_HOST_PASSTHROUGH:
guest-match = VIR_CPU_MATCH_MINIMUM;
-return x86UpdateHostModel(guest, host, true);
+return x86UpdateHostModel(guest, host);
case VIR_CPU_MODE_LAST:
break;
--
1.8.3.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH 0/3] parallels: add statistiscs
Add vz statistics for network, cpu and memory. src/vz/vz_driver.c | 133 +++- src/vz/vz_sdk.c| 69 ++- src/vz/vz_sdk.h|4 ++ -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] libxl: rework reference counting
On Tue, Jun 16, 2015 at 10:53:15AM +0100, Anthony PERARD wrote: On Mon, Jun 15, 2015 at 08:36:47PM -0600, Jim Fehlig wrote: Similar to commit 540c339a for the QEMU driver, rework reference counting in the libxl driver to make it more deterministic and the code a bit cleaner. Signed-off-by: Jim Fehlig jfeh...@suse.com --- I've been testing this patch on and off for a few weeks now using libvirt-tck domain tests, local test scripts, and some manual tests for good measure. I sent the patch to Anthony Perard (cc'd) nearly two weeks ago for testing in his OpenStack+Xen+libvirt CI loop, although I haven't received any feedback thus far. Also included Martin in the cc since he encouraged this patch But I should be able to test the patch now. Hi, I gave this patch a try with OpenStack. I have applied the patch on top of libvirt 1.4.14 + (f86ae40 894d2ff 6dfec1e), which we are using for our CI. With the patch, libvirt works fine, but I can still have the rare error domain 205 device model: startup timed out. Thanks, -- Anthony PERARD -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] incorrect memory size inside vm
2015-06-17 17:09 GMT+03:00 Andrey Korolyov and...@xdel.ru: The rest of visible memory is eaten by reserved kernel areas, for us this was a main reason to switch to a hotplug a couple of years ago. You would not be able to scale a VM by an order of magnitude with regular balloon mechanism without mentioned impact, unfortunately. Igor Mammedov posted hotplug-related patches for 2.6.32 a while ago, though RHEL6 never adopted them by some reason. Hmm.. Thanks for info, from what version of kernel memory hotplug works? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v4 0/9] Selective block device migration implementation
On Tue, Jun 16, 2015 at 01:42:02AM +0300, Pavel Boldin wrote:
[. . .]
Michal Privoznik (3):
virDomainDiskGetSource: Mark passed disk as 'const'
qemuMigrationBeginPhase: Fix function header indentation
qemuMigrationDriveMirror: Force raw format for NBD
Pavel Boldin (6):
util: multi-value virTypedParameter
util: multi-value parameters in virTypedParamsAdd*
util: virTypedParams{Filter,GetAllStrings}
util: add virTypedParamsAddStringList
qemu: migration: selective block device migration
virsh: selective block device migration
include/libvirt/libvirt-domain.h | 9 ++
include/libvirt/libvirt-host.h | 11 ++
src/conf/domain_conf.c | 2 +-
src/conf/domain_conf.h | 2 +-
src/libvirt_public.syms | 6 +
src/qemu/qemu_driver.c | 78 ---
src/qemu/qemu_migration.c| 264 +--
src/qemu/qemu_migration.h| 24 ++--
src/util/virtypedparam.c | 259 +++---
src/util/virtypedparam.h | 19 +++
tests/Makefile.am| 6 +
tests/virtypedparamtest.c| 295
+++
tools/virsh-domain.c | 23 +++
tools/virsh.pod | 21 +--
14 files changed, 854 insertions(+), 165 deletions(-)
create mode 100644 tests/virtypedparamtest.c
New test with this revision of patches applied.
Test env
- On source and destination host, libvirt is compiled with the above
patches:
$ git describe
v1.2.16-204-g7aee251
- Create SSH keys and copy to dest host:
# Create the SSH keys with empty passphrase
$ ssh-keygen -t rsa
# Copy the key to the remote host
$ ssh-copy-id root@devstack3
# `ssh root@devstack3` succeeds w/o password prompt
- Since I'm on a trusted network, on dest host:
$ cat /etc/libvirt/libvirtd.conf | grep -v ^$ | grep -v ^#
listen_tls = 0
listen_tcp = 1
auth_tcp = none
- Run the libvirtd daemon on destination (with --listen mode), as
root:
$ ./run daemon/libvirtd --listen
Test migration
~~
On source (from newly built libvirtd), as root:
$ ./run tools/virsh list
I have two disks:
$ ./run tools/virsh domblklist cvm1
Target Source
vda/var/lib/libvirt/images/cirros-0.3.3-x86_64-disk.img
vdb/export/disk2.img
So, let's try to migrate the 'vdb' disk:
$ ./virsh migrate --verbose --p2p --migratedisks vdb \
--live cvm1 qemu+ssh://root@devstack3/system
error: Timed out during operation: cannot acquire state change lock (held
by remoteDispatchDomainMigratePerform3Params)
From libvirt debug logs
~~~
libvirtd debug log[1] from source (destination log is empty)):
[. . .]
2015-06-17 15:13:53.317+: 781: debug : virDomainMigratePerform3Params:5202
: dom=0x7f2118f13c40, (VM: name=cvm1,
uuid=ab4c412b-6fdc-4fc4-b78c-f1d49db10d4e),
dconnuri=qemu+tcp://root@devstack3/system, params=0x7f2118f12a90, nparams=1,
cookiein=(nil), cookieinlen=0, cookieout=0x7f2106f38ba8,
cookieoutlen=0x7f2106f38ba4, flags=3
2015-06-17 15:13:53.317+: 781: debug : virDomainMigratePerform3Params:5203
: params[migrate_disks]=(string)vdb
2015-06-17 15:13:53.317+: 781: debug : qemuMigrationPerform:5238 :
driver=0x7f20f416b840, conn=0x7f20dc005c30, vm=0x7f20f41e9640, xmlin=null,
dconnuri=qemu+tcp://root@devstack3/system, uri=null, graphicsuri=null,
listenAddress=null, nmigrate_disks=1, migrate_disks=0x7f2118f13930,
cookiein=null, cookieinlen=0, cookieout=0x7f2106f38ba8,
cookieoutlen=0x7f2106f38ba4, flags=3, dname=null, resource=0, v3proto=1
2015-06-17 15:13:53.317+: 781: debug : qemuDomainObjBeginJobInternal:1397 :
Starting async job: none (async=migration out vm=0x7f20f41e9640 name=cvm1)
2015-06-17 15:13:53.317+: 781: debug : qemuDomainObjBeginJobInternal:1414 :
Waiting for async job (vm=0x7f20f41e9640 name=cvm1)
2015-06-17 15:13:53.821+: 782: debug : virThreadJobSet:96 : Thread 782
(virNetServerHandleJob) is now running job remoteDispatchDomainGetJobInfo
2015-06-17 15:13:53.821+: 782: debug : virDomainGetJobInfo:8808 :
dom=0x7f20dc008c30, (VM: name=cvm1, uuid=ab4c412b-6fdc-4fc4-b78c-f1d49db10d4e),
info=0x7f2106737b50
2015-06-17 15:13:53.821+: 782: debug : virThreadJobClear:121 : Thread 782
(virNetServerHandleJob) finished job remoteDispatchDomainGetJobInfo with ret=0
2015-06-17 15:13:54.325+: 780: debug : virThreadJobSet:96 : Thread 780
(virNetServerHandleJob) is now running job remoteDispatchDomainGetJobInfo
2015-06-17 15:13:54.325+: 780: debug : virDomainGetJobInfo:8808 :
dom=0x7f20dc008c30, (VM: name=cvm1, uuid=ab4c412b-6fdc-4fc4-b78c-f1d49db10d4e),
info=0x7f2107739b50
2015-06-17 15:13:54.325+: 780: debug : virThreadJobClear:121 : Thread 780
[libvirt] [RFC] qemu: Redesigning guest CPU configuration
Hi all (and sorry for the long email), The current way QEMU driver handles guest CPU configuration is not ideal. We detect host CPU capabilities only by querying the CPU and we don't check with QEMU what features it supports. We don't check QEMU's definitions of CPU models, which may be different from libvirt's definitions. All this results in several issues: - guest CPU may change druing migration, save/restore - libvirt may ask for a CPU which QEMU cannot provide; the guest will see a slightly different CPU but libvirt client won't know about it - libvirt may come up with a CPU that doesn't make sense and which won't work for a guest (the guest may even crash) Although usually everything just works, it is very fragile. Since we want to fix all these issues, we need to: - guarantee stable guest ABI (a single domain XML should always results in the same guest ABI). Once a domain is started, its CPU definition should never change (unless someone changes the XML, of course, similar to, e.g. PCI addresses). However, there are a few exceptions: - host-passthrough CPU mode will always result in -cpu host - host-model CPU mode should recompute the CPU model on every start, but the CPU must not change during migration - always make sure QEMU provides the CPU we asked for. Starting a domain should fail in case QEMU cannot provide exactly the CPU we asked for. - provide usable host-model mode and custom mode with minimum match. We need to generate CPU configurations that actually work, i.e., we need to ask QEMU what CPU it can provide on current host rather than requesting a bunch of features on top of a CPU model which does not always match the host CPU. QEMU already provides or will soon provide everything we need to meet these requirements: - we can cover every configurable part of a CPU in our cpu_map.xml and instead of asking QEMU for a specific CPU model we can use -cpu custom with a fully specified CPU - we can use the additional data about CPU models to choose the right one for a host CPU - when starting a domain we can check whether QEMU filtered out any of the features we asked for and refuse to start the domain - we can ask QEMU what would -cpu host look like and use that for host-model and minimum match CPUs (it won't work for TCG mode, though, but we can keep using the current CPUID detection code for TCG) Once we start maintaining CPU models with all the details, we will likely meet the same issues QEMU folks meet, i.e., we will need to fix bugs in existing CPU models. And it's not just about adding removing CPU features but also fixing other parameters, such as wrong level, etc. It's clear every change will require a new CPU model to be defined. But I think we should do it in a way that applications or users should not need (if they don't want to) to care about it. I'm thinking about doing something similar to machine types. Each CPU model could be defined in several versions and a CPU specs without a version would be an alias to the latest version. The problem is, we need to maintain backward compatibility and we should avoid breaking existing domains (shouldn't we?) which just work even though their guest CPUs do not exactly match the domain XML definitions. So either we need to define all existing CPU models in all their variants used for various machine types and have a mapping between (model without a version, machine type) to a specific version of the model (which may be quite hard) or we need to be able to distinguish between an existing domain and a new domain with no CPU model version. While host-model and host-passthrough CPU modes are easy because they are designed to change everytime a domain starts (which means we don't need to be able to distinguish between existing and new domains), custom CPU mode are tricky. Currently, the only at least a bit reasonable thing which came to my mind is to have a new CPU mode, but it still seems awkward so please share your ideas if you have any. BTW, I don't think we should try to expose every part of the CPU model definitions in domain XML, they should remain hidden behind the CPU model name. It would be hard to explain what each of the extra parameters mean, each model would have to include them anyway since we can't expect users to provide all the details correctly, and once visible in domain XML it could encourage users to play with the values. I'm looking forward to any comments or ideas. Jirka -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] incorrect memory size inside vm
2015-06-17 18:38 GMT+03:00 Andrey Korolyov and...@xdel.ru: Currently QEMU memory hotplug should work with 3.8 and onwards. Mentioned patches are an adaptation for an older frankenkernel of 3.8` functionality. This is band news =( i have debian wheezy that have old kernel... -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] daemon: only unref virNetServers once
After we add srv and srvAdm to the virNetDaemon,
it's its responsibility to unref them in virNetDaemonDispose.
Added by commits fa14207 and d5f4241.
---
daemon/libvirtd.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c
index 368e10c..9e6c489 100644
--- a/daemon/libvirtd.c
+++ b/daemon/libvirtd.c
@@ -1589,8 +1589,6 @@ int main(int argc, char **argv) {
virObjectUnref(adminProgram);
virNetDaemonClose(dmn);
virObjectUnref(dmn);
-virObjectUnref(srv);
-virObjectUnref(srvAdm);
virNetlinkShutdown();
if (statuswrite != -1) {
if (ret != 0) {
--
2.3.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] test: Refactor vcpu pinning and vcpu info retrieval
Drop internal data structures and use the proper fields in virDomainDef.
This allows to greatly simplify the code and allows to remove the
private data structure that was holding just redundant data.
This patch also fixes the bogous output where we'd report that a fresh
VM without vCPU pinning would not run on all vcpus.
---
This applies on top of [PATCH 0/8] Test driver refactors and fixes:
src/test/test_driver.c | 224 +++--
1 file changed, 49 insertions(+), 175 deletions(-)
diff --git a/src/test/test_driver.c b/src/test/test_driver.c
index 9e617a2..f17d353 100644
--- a/src/test/test_driver.c
+++ b/src/test/test_driver.c
@@ -64,14 +64,6 @@
VIR_LOG_INIT(test.test_driver);
-/* Driver specific info to carry with a domain */
-struct _testDomainObjPrivate {
-virVcpuInfoPtr vcpu_infos;
-
-unsigned char *cpumaps;
-};
-typedef struct _testDomainObjPrivate testDomainObjPrivate;
-typedef struct _testDomainObjPrivate *testDomainObjPrivatePtr;
#define MAX_CPUS 128
@@ -170,25 +162,6 @@ testObjectEventQueueUnlocked(testConnPtr driver,
testDriverUnlock(driver);
}
-static void *testDomainObjPrivateAlloc(void)
-{
-testDomainObjPrivatePtr priv;
-
-if (VIR_ALLOC(priv) 0)
-return NULL;
-
-return priv;
-}
-
-static void testDomainObjPrivateFree(void *data)
-{
-testDomainObjPrivatePtr priv = data;
-
-VIR_FREE(priv-vcpu_infos);
-VIR_FREE(priv-cpumaps);
-VIR_FREE(priv);
-}
-
#define TEST_NAMESPACE_HREF http://libvirt.org/schemas/domain/test/1.0;
typedef struct _testDomainNamespaceDef testDomainNamespaceDef;
@@ -313,18 +286,13 @@ testDomainDefNamespaceParse(xmlDocPtr xml
ATTRIBUTE_UNUSED,
static virDomainXMLOptionPtr
testBuildXMLConfig(void)
{
-virDomainXMLPrivateDataCallbacks priv = {
-.alloc = testDomainObjPrivateAlloc,
-.free = testDomainObjPrivateFree
-};
-
/* All our XML extensions are input only, so we only need to parse */
virDomainXMLNamespace ns = {
.parse = testDomainDefNamespaceParse,
.free = testDomainDefNamespaceFree,
};
-return virDomainXMLOptionNew(NULL, priv, ns);
+return virDomainXMLOptionNew(NULL, NULL, ns);
}
@@ -580,95 +548,6 @@ testDomainGenerateIfnames(virDomainDefPtr domdef)
return 0;
}
-/* Helper to update info for a single VCPU */
-static int
-testDomainUpdateVCPU(virDomainObjPtr dom,
- int vcpu,
- int maplen,
- int maxcpu)
-{
-testDomainObjPrivatePtr privdata = dom-privateData;
-virVcpuInfoPtr info = privdata-vcpu_infos[vcpu];
-unsigned char *cpumap = VIR_GET_CPUMAP(privdata-cpumaps, maplen, vcpu);
-size_t j;
-bool cpu;
-
-memset(info, 0, sizeof(virVcpuInfo));
-memset(cpumap, 0, maplen);
-
-info-number= vcpu;
-info-state = VIR_VCPU_RUNNING;
-info-cpuTime = 500;
-info-cpu = 0;
-
-if (dom-def-cpumask) {
-for (j = 0; j maxcpu j VIR_DOMAIN_CPUMASK_LEN; ++j) {
-if (virBitmapGetBit(dom-def-cpumask, j, cpu) 0)
-return -1;
-if (cpu) {
-VIR_USE_CPU(cpumap, j);
-info-cpu = j;
-}
-}
-} else {
-for (j = 0; j maxcpu; ++j) {
-if ((j % 3) == 0) {
-/* Mark of every third CPU as usable */
-VIR_USE_CPU(cpumap, j);
-info-cpu = j;
-}
-}
-}
-
-return 0;
-}
-
-/*
- * Update domain VCPU amount and info
- *
- * @conn: virConnectPtr
- * @dom : domain needing updates
- * @nvcpus: New amount of vcpus for the domain
- * @clear_all: If true, rebuild info for ALL vcpus, not just newly added vcpus
- */
-static int
-testDomainUpdateVCPUs(testConnPtr privconn,
- virDomainObjPtr dom,
- int nvcpus,
- unsigned int clear_all)
-{
-testDomainObjPrivatePtr privdata = dom-privateData;
-size_t i;
-int ret = -1;
-int cpumaplen, maxcpu;
-
-maxcpu = VIR_NODEINFO_MAXCPUS(privconn-nodeInfo);
-cpumaplen = VIR_CPU_MAPLEN(maxcpu);
-
-if (VIR_REALLOC_N(privdata-vcpu_infos, nvcpus) 0)
-goto cleanup;
-
-if (VIR_REALLOC_N(privdata-cpumaps, nvcpus * cpumaplen) 0)
-goto cleanup;
-
-/* Set running VCPU and cpumap state */
-if (clear_all) {
-for (i = 0; i nvcpus; ++i)
-if (testDomainUpdateVCPU(dom, i, cpumaplen, maxcpu) 0)
-goto cleanup;
-
-} else if (nvcpus dom-def-vcpus) {
-/* VCPU amount has grown, populate info for the new vcpus */
-for (i = dom-def-vcpus; i nvcpus; ++i)
-if (testDomainUpdateVCPU(dom, i, cpumaplen, maxcpu) 0)
-goto cleanup;
-}
-
-dom-def-vcpus = nvcpus;
-ret = 0;
- cleanup:
-return ret;
-}
static void
testDomainShutdownState(virDomainPtr domain,
@@ -695,9 +574,6 @@ testDomainStartState(testConnPtr
[libvirt] [PATCH] remove redundant condition
If the address type is SPAPRVIO, it will match the != NONE condition. --- src/qemu/qemu_command.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 3886b4f..078ecf7 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -2423,8 +2423,6 @@ qemuAssignDevicePCISlots(virDomainDefPtr def, def-controllers[i]-idx == 0) continue; -if (def-controllers[i]-info.type == VIR_DOMAIN_DEVICE_ADDRESS_TYPE_SPAPRVIO) -continue; if (def-controllers[i]-info.type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE) continue; -- 2.3.6 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] qemu: check hostdev address type
For USB and SCSI hostdevs, we passed the invalid address to QEMU.
Report an error earlier.
PCI hostdevs check the address type when parsing the XML.
https://bugzilla.redhat.com/show_bug.cgi?id=1225339
---
src/qemu/qemu_command.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 3886b4f..a4853ab 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -10572,7 +10572,12 @@ qemuBuildCommandLine(virConnectPtr conn,
/* USB */
if (hostdev-mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS
hostdev-source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_USB)
{
-
+if (hostdev-info-type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE
+hostdev-info-type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_USB) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(USB host devices must use 'usb' address
type));
+goto error;
+}
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE)) {
virCommandAddArg(cmd, -device);
if (!(devstr = qemuBuildUSBHostdevDevStr(def, hostdev,
qemuCaps)))
@@ -10644,6 +10649,12 @@ qemuBuildCommandLine(virConnectPtr conn,
/* SCSI */
if (hostdev-mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS
hostdev-source.subsys.type ==
VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_SCSI) {
+if (hostdev-info-type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_NONE
+hostdev-info-type != VIR_DOMAIN_DEVICE_ADDRESS_TYPE_DRIVE) {
+virReportError(VIR_ERR_INTERNAL_ERROR, %s,
+ _(SCSI host devices must use 'drive' address
type));
+goto error;
+}
if (virQEMUCapsGet(qemuCaps, QEMU_CAPS_DRIVE)
virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE)
virQEMUCapsGet(qemuCaps, QEMU_CAPS_DEVICE_SCSI_GENERIC)) {
--
2.3.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] daemon: Don't just include admin RPC
So, it's a little paradox that we use the file twice. Firstly to build libvirt-admin.la (a client side of the Admin API), then once again to build the server side. Well, the problem is, this does not play nicely with the distclean since the file is generated. So while it's removed in the src/ the distclean running in daemon/ will not find the file and fail. The file is needed because it contains the RPC wrappers. So let's leave the client code as is and from the daemon/ just link the client library. The linker will find desired symbols and use them. Signed-off-by: Michal Privoznik mpriv...@redhat.com --- daemon/Makefile.am | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/daemon/Makefile.am b/daemon/Makefile.am index b9c089d..d3fc029 100644 --- a/daemon/Makefile.am +++ b/daemon/Makefile.am @@ -128,8 +128,7 @@ libvirtd_conf_la_LIBADD = $(LIBXML_LIBS) noinst_LTLIBRARIES += libvirtd_admin.la libvirtd_admin_la_SOURCES = \ - admin_server.c admin_server.h \ - ../src/admin/admin_protocol.c + admin_server.c admin_server.h libvirtd_admin_la_CFLAGS = \ $(AM_CFLAGS)\ @@ -145,6 +144,9 @@ libvirtd_admin_la_LDFLAGS = \ $(COVERAGE_LDFLAGS) \ $(NO_INDIRECT_LDFLAGS) +libvirtd_admin_la_LIBADD = \ + ../src/libvirt-admin.la + man8_MANS = libvirtd.8 sbin_PROGRAMS = libvirtd -- 2.3.6 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] tests: Sort EXTRA_DIST in the Makefile
We tend to keep the folders in the EXTRA_DIST sorted alphabetically. However, we've failed sometimes and the list is not ordered anymore. Reorder it back. Signed-off-by: Michal Privoznik mpriv...@redhat.com --- tests/Makefile.am | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/tests/Makefile.am b/tests/Makefile.am index a1cca5c..8e3ab91 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -72,6 +72,7 @@ LDADDS = \ ../src/libvirt.la EXTRA_DIST = \ + .valgrind.supp \ bhyvexml2argvdata \ bhyvexml2xmloutdata \ capabilityschemadata \ @@ -93,12 +94,12 @@ EXTRA_DIST =\ lxcxml2xmldata \ lxcxml2xmloutdata \ networkschematest \ + networkxml2confdata \ + networkxml2firewalldata \ networkxml2xmlin \ networkxml2xmlout \ - networkxml2confdata \ networkxml2xmlupdatein \ networkxml2xmlupdateout \ - networkxml2firewalldata \ nodedevschemadata \ nodedevschematest \ nodeinfodata \ @@ -116,41 +117,40 @@ EXTRA_DIST = \ qemuxml2argvdata \ qemuxml2xmloutdata \ qemuxmlnsdata \ + schematestutils.sh \ secretxml2xmlin \ securityselinuxhelperdata \ securityselinuxlabeldata \ - schematestutils.sh \ sexpr2xmldata \ storagepoolschemadata \ storagepoolschematest \ storagepoolxml2xmlin \ storagepoolxml2xmlout \ - storagevolxml2argvdata \ storagevolschemadata \ storagevolschematest \ + storagevolxml2argvdata \ storagevolxml2xmlin \ storagevolxml2xmlout \ sysinfodata \ test-lib.sh \ - vircaps2xmldata \ vboxsnapshotxmldata \ - virsh-uriprecedence \ + vircaps2xmldata \ vircgroupdata \ virfiledata \ + virmock.h virnetdaemondata \ virnetdevtestdata \ virpcitestdata \ virscsidata \ + virsh-uriprecedence \ virusbtestdata \ + vmwareverdata \ vmx2xmldata \ xencapsdata \ - xmconfigdata \ xlconfigdata \ + xmconfigdata \ xml2sexprdata \ xml2vmxdata \ - vmwareverdata \ - .valgrind.supp \ - virmock.h test_helpers = commandhelper ssh test_conf test_programs = virshtest sockettest \ -- 2.3.6 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Qemu-devel] incorrect memory size inside vm
On Wed, Jun 17, 2015 at 6:33 PM, Vasiliy Tolstov v.tols...@selfip.ru wrote: 2015-06-17 17:09 GMT+03:00 Andrey Korolyov and...@xdel.ru: The rest of visible memory is eaten by reserved kernel areas, for us this was a main reason to switch to a hotplug a couple of years ago. You would not be able to scale a VM by an order of magnitude with regular balloon mechanism without mentioned impact, unfortunately. Igor Mammedov posted hotplug-related patches for 2.6.32 a while ago, though RHEL6 never adopted them by some reason. Hmm.. Thanks for info, from what version of kernel memory hotplug works? -- Vasiliy Tolstov, e-mail: v.tols...@selfip.ru Currently QEMU memory hotplug should work with 3.8 and onwards. Mentioned patches are an adaptation for an older frankenkernel of 3.8` functionality. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
