[libvirt] [PATCH v2 0/3] Check for <memoryBacking/>
by Michal Privoznik
Technically this is v2 of:
https://www.redhat.com/archives/libvir-list/2017-May/msg00626.html
diff to v1:
- Patches split and reworked as suggested by Peter in the review
Michal Privoznik (3):
virDomainDefCheckABIStabilityFlags: move memtune checks into a
separate function
virDomainXMLOption: Introduce virDomainABIStabilityDomain
virQEMUDriverDomainABIStability: Check for memoryBacking
src/conf/domain_conf.c | 93 ++++++++++++++++++++++++++++++--------------
src/conf/domain_conf.h | 16 +++++++-
src/conf/snapshot_conf.c | 5 ++-
src/conf/snapshot_conf.h | 3 +-
src/libvirt_private.syms | 6 +++
src/libxl/libxl_conf.c | 2 +-
src/libxl/libxl_domain.c | 4 +-
src/lxc/lxc_conf.c | 3 +-
src/openvz/openvz_driver.c | 2 +-
src/phyp/phyp_driver.c | 2 +-
src/qemu/qemu_capabilities.c | 2 +-
src/qemu/qemu_conf.c | 3 +-
src/qemu/qemu_domain.c | 41 +++++++++++++++++++
src/qemu/qemu_domain.h | 1 +
src/qemu/qemu_driver.c | 7 ++--
src/test/test_driver.c | 8 ++--
src/uml/uml_driver.c | 2 +-
src/vbox/vbox_common.c | 2 +-
src/vmware/vmware_driver.c | 2 +-
src/vmx/vmx.c | 2 +-
src/xen/xen_driver.c | 2 +-
src/xenapi/xenapi_driver.c | 2 +-
tests/qemuargv2xmltest.c | 2 +-
tests/qemuxml2argvtest.c | 2 +-
tests/sexpr2xmltest.c | 2 +-
tests/testutils.c | 4 +-
tests/vmx2xmltest.c | 2 +-
tests/xlconfigtest.c | 2 +-
tests/xmconfigtest.c | 2 +-
tests/xml2sexprtest.c | 2 +-
tests/xml2vmxtest.c | 2 +-
31 files changed, 167 insertions(+), 63 deletions(-)
--
2.13.0
7 years, 6 months
[libvirt] Remotable Libvirt
by Peter Volpe
Hi Everyone,
We are working towards building on the virtualization management
functionality in cockpit (http://cockpit-project.org/) and wanted to get
some feedback on the best way to integrate with libvirt.
As a quick overview, cockpit aims to talk to existing remotable system
APIs. Usually these API’s take the form of dbus, REST or executable
commands. The majority of cockpit is implemented in javascript. There is
no cockpit backend that knows how to change a hostname for example. The
cockpit backend knows how to handle a dbus payload. The javascript
running in the users browser knows how to use the systemd dbus API at
org.freedesktop.hostname1 to manage the system hostname.
Right now some of the basics have been implemented by spawning commands
on the system. This isn't ideal because it involves parsing / screen
scraping output and doesn't support receiving events so we have to poll
(ei run the command again) to keep the UI up to date.
As far as I know libvirt doesn't currently have a remoteable API. It
does have a daemon that communicates with clients via a XDR RPC.
(https://libvirt.org/internals/rpc.html) However from what I'm hearing
the RPC is considered an internal implementation and shouldn't be used
by external applications. Is that still the case? Is there any chance of
getting talking the daemon directly using the XDR standard for a subset
of methods blessed as part of the externally supported API?
An alternative is to implement a standards based remotable API, using
something like dbus or REST, that can be used by external applications.
I imagine that this would be at a bit of a higher level than the current
RPC and contain at least some of the logic around the actions it
performs rather than being a direct passthrough to the daemon.
Of course that is a pretty big undertaking and would, in my opinion,
only be worth it if there is broader interest in the community and use
cases beyond what cockpit would like to.
7 years, 6 months
[libvirt] RFE: virsh list improvement (--description and --details)
by Przemysław Sztoch
Hello,
1. Please add —description parameter to virsh list command. It should be similar to —title.
It will be very helpful for administrators who like to leave the order and documentation after their work.
2. Please add new columns to virsh list (for —details):
a) CPUs
b) MaxMem
c) Flags: p-persistent, t-transient, a-autostart, m-managed save, s-with snapshot(s)
and total sum for column vCPUs and Mem.
In my opinion it is very popular use case. It will help you control vCPU and memory overcommiting in very simple and fast way.
Put flags on list will prevents many additional commands from being executed. You will get all important information in one place.
3. Please add —domtime parameter to virsh list command. It should show column with domain’s system time similar to virsh domtime domname --pretty.
It will be very helpful for fast guest-agent checking for every domain.
4. Please add column Parent and Metadata to virsh snapshot-list.
—
Przemyslaw Sztoch
7 years, 6 months
[libvirt] [PATCH 0/8] Multiple cleanups within interfaceobj and interface driver
by John Ferlan
Sensing a theme lately yet?
More adjustments in preparation for having virobject code handle the bulk
of the object management code.
Far less in this series than the other two... The Clone code was a bit
unique and required more of a rewrite than a refigure since now we have
two allocated lists rather than two static lists.
John Ferlan (8):
interface: Consistently use 'obj' for a virInterfaceObjPtr
interface: Remove some unnecessary goto's for Interface tests
interface: Use virInterfaceDefPtr rather than deref from
virInterfaceObjPtr
interface: Make _virInterfaceObj struct private
interface: Make _virInterfaceObjList struct private
interface: Rename some virInterfaceObj* API's
interface: Clean up virInterfaceObjListFindByMACString
interface: Introduce virInterfaceObjNew
src/conf/virinterfaceobj.c | 232 +++++++++++++++++++++++++++++----------------
src/conf/virinterfaceobj.h | 65 ++++++-------
src/libvirt_private.syms | 15 +--
src/test/test_driver.c | 143 ++++++++++++++--------------
4 files changed, 262 insertions(+), 193 deletions(-)
--
2.9.3
7 years, 6 months
Re: [libvirt] [virt-tools-list] Problem with firewalls on Arch Linux
by Cole Robinson
On 05/25/2017 06:08 AM, Derek Richline wrote:
> Hi all:
>
> I noticed that Virt Manager will not start the network "default" unless
> it detects a running firewalld. Arch Linux only ships with iptables by
> default. Can Virt-Manager be patched to not check as aggressively for a
> firewall (or just issue a warning)?
>
virt-manager doesn't have any specific firewalld checking so this is likely
coming from libvirt. I don't know anything about arch packaging, but if the
libvirt package doesn't pull in firewalld then maybe libvirt should be built
--without-firewalld
What libvirt version is this? And what's the exact error message you are seeing?
- Cole
7 years, 6 months
[libvirt] [PATCH] qemu: Fix memory leak in qemuDomainUpdateMemoryDeviceInfo
by Yi Wang
The @meminfo allocated in qemuMonitorGetMemoryDeviceInfo may be lost when
exit monitor failed. Luckily we can free it according to rc.
Signed-off-by: Yi Wang <wang.yi59(a)zte.com.cn>
---
src/qemu/qemu_domain.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index c8dc748..c34ec5a 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -5767,8 +5767,11 @@ qemuDomainUpdateMemoryDeviceInfo(virQEMUDriverPtr driver,
rc = qemuMonitorGetMemoryDeviceInfo(priv->mon, &meminfo);
- if (qemuDomainObjExitMonitor(driver, vm) < 0)
+ if (qemuDomainObjExitMonitor(driver, vm) < 0) {
+ if (0 == rc)
+ virHashFree(meminfo);
return -1;
+ }
/* if qemu doesn't support the info request, just carry on */
if (rc == -2)
--
1.8.3.1
7 years, 6 months
[libvirt] [PATCH v2 RFC 0/4] qemu: replace nested job with interruptible async job state
by Nikolay Shirokovskiy
This is the next version of RFC [1] 'drop nested job concept'. Actually
it is quite different from the first. Patches that accomodate callers to
use functions to enter/exit monitor with without driver and asyncJob arguments
are moved out of this series. I guess this can be done as soon as this series
is upstream. Most of approach details are in the first patch.
Pros:
- better async job and concurrent regular job isolation
- more straightforward implementation
- more simple to use - no need to pass async job argument down the stack
- safer to use - no warnings to be fixed if function is started to be
used from asynchronous job context.
TODO:
- replace qemuDomainObjEnterMonitorAsync with qemuDomainObjEnterMonitor
- accomodate callers to qemuDomainObjExitMonitor became returning void
- remove passing driver and asyncJob down the stack
- reflect changes in THREADS.txt
[1] https://www.redhat.com/archives/libvir-list/2016-November/msg01357.html
Nikolay Shirokovskiy (4):
qemu: replace nested job with interruptible async job state
qemu: remove liveness check from qemuDomainObjExitMonitor
qemu: remove nesting job usage from qemuProcessStop
qemu: remove the rest of nested job parts
src/conf/domain_conf.c | 19 ----
src/conf/domain_conf.h | 1 -
src/libvirt_private.syms | 1 -
src/qemu/qemu_domain.c | 253 +++++++++++++++++++++++++++++-----------------
src/qemu/qemu_domain.h | 29 ++++--
src/qemu/qemu_driver.c | 2 +-
src/qemu/qemu_migration.c | 70 +++++++------
src/qemu/qemu_process.c | 31 ++----
8 files changed, 225 insertions(+), 181 deletions(-)
--
1.8.3.1
7 years, 6 months
[libvirt] [PATCH] qemu: Use correct variable in qemuDomainSetBlockIoTune
by Peter Krempa
'param' contains the correct element from 'params'.
If the group name would not be the first element libvirtd would crash.
Introduced in c53bd25b13.
---
src/qemu/qemu_driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index cd513ff9f..67f54282a 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -17443,7 +17443,7 @@ qemuDomainSetBlockIoTune(virDomainPtr dom,
/* NB: Cannot use macro since this is a value.s not a value.ul */
if (STREQ(param->field, VIR_DOMAIN_BLOCK_IOTUNE_GROUP_NAME)) {
- if (VIR_STRDUP(info.group_name, params->value.s) < 0)
+ if (VIR_STRDUP(info.group_name, param->value.s) < 0)
goto endjob;
set_fields |= QEMU_BLOCK_IOTUNE_SET_GROUP_NAME;
if (virTypedParamsAddString(&eventParams, &eventNparams,
--
2.12.2
7 years, 6 months
[libvirt] [PATCH v2] Regression: Report correct CPUs present on executing virsh nodecpumap
by Nitesh Konkar
On executing the virsh nodecpumap command, the number
of CPUs present was shown as (last cpu online id + 1). This
patch fixes the issue by reporting the current number of
CPUs present.
Signed-off-by: Nitesh Konkar <nitkon12(a)linux.vnet.ibm.com>
---
src/util/virhostcpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/util/virhostcpu.c b/src/util/virhostcpu.c
index aa9cfeac2..6d7e8b4f4 100644
--- a/src/util/virhostcpu.c
+++ b/src/util/virhostcpu.c
@@ -1093,7 +1093,7 @@ virHostCPUGetMap(unsigned char **cpumap,
if (online)
*online = virBitmapCountBits(cpus);
- ret = virBitmapSize(cpus);
+ ret = virHostCPUParseCountLinux();
cleanup:
if (ret < 0 && cpumap)
--
2.11.0
7 years, 6 months
Re: [libvirt] [PATCH v2] Regression: Report correct CPUs present on executing virsh nodecpumap
by Nitesh Konkar
Yes I did, limited to my knowledge.
On Thu, May 25, 2017 at 2:08 PM, Nitesh Konkar <
niteshkonkar.libvirt(a)gmail.com> wrote:
> Yes I did.
>
> On Thu, May 25, 2017 at 2:07 PM, Peter Krempa <pkrempa(a)redhat.com> wrote:
>
>> On Thu, May 25, 2017 at 14:04:16 +0530, Nitesh Konkar wrote:
>> > On executing the virsh nodecpumap command, the number
>> > of CPUs present was shown as (last cpu online id + 1). This
>> > patch fixes the issue by reporting the current number of
>> > CPUs present.
>> >
>> > Signed-off-by: Nitesh Konkar <nitkon12(a)linux.vnet.ibm.com>
>> > ---
>> > src/util/virhostcpu.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Did you test it? I did not.
>>
>
>
7 years, 6 months