Re: [libvirt] [PATCH] qemucaps2xmltest: fix test to successfully run without kvm support
Hi, On Wed, Mar 25, 2015 at 03:24:53PM +0100, Guido Günther wrote: Hi, On Wed, Mar 25, 2015 at 12:29:41PM +0100, Pavel Hrdina wrote: On Wed, Mar 25, 2015 at 12:12:20PM +0100, Ján Tomko wrote: On Wed, Mar 25, 2015 at 10:50:52AM +0100, Pavel Hrdina wrote: Function virQEMUCapsInitGuestFromBinary detect kvm support by testing whether /dev/kvm exists or whether we pass path to kvmbin. Provide the path we are testing via kvmbin for testing purpose instead of detecting presence of /dev/kvm to successfully run the tests on all hosts. Signed-off-by: Pavel Hrdina phrd...@redhat.com --- tests/qemucaps2xmltest.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) ACK Jan Thanks, pushed now. According to Testbuild: http://honk.sigxcpu.org:8001/job/libvirt-check/3300/consoleFull SourceBuild http://honk.sigxcpu.org:8001/job/libvirt-build/3730/ this broke on Debian Wheezy like: TEST: qemucaps2xmltest 1) all_1.6.0-1 ... Offset 280 Expect [ domain type='kvm' emulator/usr/bin/qemu-system-i386/emulator /domain ] Actual [] ... FAILED 2) nodisksnapshot_1.6.0-1... Offset 280 Expect [ domain type='kvm' emulator/usr/bin/qemu-system-i386/emulator /domain ] Actual [] ... FAILED FAIL: qemucaps2xmltest I didn't get a chance to look into this in any detail yet. Any idea what went wrong? Just for the record: this got fixed by eb05cb0d5c4ab013622a3695bcd60b72eeaa7dfe with logs at http://honk.sigxcpu.org:8001/job/libvirt-check/3324/ Cheers, -- Guido -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virDomainShutdown*: Describe blocking behaviour
On 30.03.2015 22:38, Eric Blake wrote: On 03/30/2015 06:07 AM, Michal Privoznik wrote: The description to both virDomainShutdown() and virDomainShutdownFlags() is quite misleading when it comes to blocking behaviour of these two APIs. Firstly, we support many shutdown methods, from signalizing an ACPI event, through sending a signal to guest agent assisted shutdown. Some of these methods make the API return immediately, while others block the API until domain is actually shut of. And since virDomainShutdown() is s/of/off/ equivalent to calling virDomainShutdownFlags(0), it's up to each driver which methods to try. So the bare virDomainShutdown() may block or may return immediately at the same time. I know, it's confusing, but at least let users know. Signed-off-by: Michal Privoznik mpriv...@redhat.com --- src/libvirt-domain.c | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) I don't think this is the right approach. It is okay to block for a small finite amount of time, but if the guest agent really is something that can hang, we should fix that code to return without waiting for the agent response. The problem is, we can tell if the shutdown qemu-ga command succeeded only when we see the SHUTDOWN event on the domain monitor. The other option is to treat it like we're treating ACPI mode of the API: just send the request and report if the sending succeeded. Don't wait until domain actually shuts down. I can provide a patch. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH V2] libxl: fix dom0 balloon logic
On Tue, Mar 24, 2015 at 02:43:42PM -0600, Jim Fehlig wrote:
Recent testing on large memory systems revealed a bug in the Xen xl
tool's freemem() function. When autoballooning is enabled, freemem()
is used to ensure enough memory is available to start a domain,
ballooning dom0 if necessary. When ballooning large amounts of memory
from dom0, freemem() would exceed its self-imposed wait time and
return an error. Meanwhile, dom0 continued to balloon. Starting the
domain later, after sufficient memory was ballooned from dom0, would
succeed. The libvirt implementation in libxlDomainFreeMem() suffers
the same bug since it is modeled after freemem().
In the end, the best place to fix the bug on the Xen side was to
slightly change the behavior of libxl_wait_for_memory_target().
Instead of failing after caller-provided wait_sec, the function now
blocks as long as dom0 memory ballooning is progressing. It will return
failure only when more memory is needed to reach the target and wait_sec
have expired with no progress being made. See xen.git commit fd3aa246.
There was a dicussion on how this would affect other libxl apps like
libvirt
http://lists.xen.org/archives/html/xen-devel/2015-03/msg00739.html
If libvirt containing this patch was build against a Xen containing
the old libxl_wait_for_memory_target() behavior, libxlDomainFreeMem()
will fail after 30 sec and domain creation will be terminated.
Without this patch and with old libxl_wait_for_memory_target() behavior,
libxlDomainFreeMem() does not succeed after 30 sec, but returns success
anyway. Domain creation continues resulting in all sorts of fun stuff
like cpu soft lockups in the guest OS. It was decided to properly fix
libxl_wait_for_memory_target(), and if anything improve the default
behavior of apps using the freemem reference impl in xl.
xl was patched to accommodate the change in libxl_wait_for_memory_target()
with xen.git commit 883b30a0. This patch does the same in the libxl
driver. While at it, I changed the logic to essentially match
freemem() in $xensrc/tools/libxl/xl_cmdimpl.c. It was a bit cleaner
IMO and will make it easier to spot future, potentially interesting
divergences.
Signed-off-by: Jim Fehlig jfeh...@suse.com
---
V2: Actually use libxl_wait_for_memory_target(), instead of
libxl_wait_for_free_memory()
src/libxl/libxl_domain.c | 55 +++-
1 file changed, 26 insertions(+), 29 deletions(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 407a9bd..a1739aa 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -1121,38 +1121,39 @@ libxlDomainFreeMem(libxlDomainObjPrivatePtr priv,
libxl_domain_config *d_config)
{
uint32_t needed_mem;
uint32_t free_mem;
-size_t i;
-int ret = -1;
+int ret;
This variable is unnecessary and confusing since you don't return it.
And without this, you can make ...
int tries = 3;
int wait_secs = 10;
-if ((ret = libxl_domain_need_memory(priv-ctx, d_config-b_info,
-needed_mem)) = 0) {
-for (i = 0; i tries; ++i) {
-if ((ret = libxl_get_free_memory(priv-ctx, free_mem)) 0)
-break;
+ret = libxl_domain_need_memory(priv-ctx, d_config-b_info, needed_mem);
+if (ret 0)
+goto error;
... these conditions smaller, e.g.:
if (libxl_domain_need_memory(priv-ctx, d_config-b_info, needed_mem) 0)
goto error;
Do you need this for the release? (sorry for noticing that late)
pgpAQl_U8Jp3K.pgp
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] hostdev: Fix index error in loop after remove an element
On Thu, Mar 26, 2015 at 10:23:46PM +0800, Huanle Han wrote:
'virPCIDeviceList' is actually an array. Removing one element makes the
rest of the element move.
Use while loop, increase index only when not virPCIDeviceListDel(pcidevs, dev)
Signed-off-by: Huanle Han hanxue...@gmail.com
---
src/util/virhostdev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/util/virhostdev.c b/src/util/virhostdev.c
index 23365a3..83f567d 100644
--- a/src/util/virhostdev.c
+++ b/src/util/virhostdev.c
@@ -785,7 +785,8 @@ virHostdevReAttachPCIDevices(virHostdevManagerPtr
hostdev_mgr,
* them and reset all the devices before re-attach.
* Attach mac and port profile parameters to devices
*/
-for (i = 0; i virPCIDeviceListCount(pcidevs); i++) {
+i = 0;
+while (i virPCIDeviceListCount(pcidevs)) {
virPCIDevicePtr dev = virPCIDeviceListGet(pcidevs, i);
virPCIDevicePtr activeDev = NULL;
@@ -806,6 +807,7 @@ virHostdevReAttachPCIDevices(virHostdevManagerPtr
hostdev_mgr,
}
virPCIDeviceListDel(hostdev_mgr-activePCIHostdevs, dev);
+i++;
'i--;' before that 'continue;' that's not in the index would be
shorter, but I guess this is more readable. Or maybe:
for (i = virPCIDeviceListCount(pcidevs); i 0; i--) {
size_t dev_index = i - 1;
would just deal with this.
Anyway, this works just as it is, ACK if you don't want to change it.
}
/* At this point, any device that had been used by the guest is in
--
1.9.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
pgpCAeqrCTBlJ.pgp
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/3] iscsi: Check for presence of error before creating new one
On Mon, Mar 30, 2015 at 07:16:32PM -0400, John Ferlan wrote:
If virStorageBackendSCSIFindLUs fails, but the failure has an error
message - the iscsi code didn't honor that creating it's own wonderful
message such as error: Failed to find LUs on host 60: ... - not overly
helpful. Since a few of the called paths generate a message, check for
that before using that generic one.
Both of the paths returning -1 generate an error:
* return -1 after opendir failed
* retval = virDirRead
Signed-off-by: John Ferlan jfer...@redhat.com
---
src/storage/storage_backend_iscsi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/storage/storage_backend_iscsi.c
b/src/storage/storage_backend_iscsi.c
index 079c767..1dac238 100644
--- a/src/storage/storage_backend_iscsi.c
+++ b/src/storage/storage_backend_iscsi.c
@@ -147,8 +147,9 @@ virStorageBackendISCSIFindLUs(virStoragePoolObjPtr pool,
}
if (virStorageBackendSCSIFindLUs(pool, host) 0) {
-virReportSystemError(errno,
- _(Failed to find LUs on host %u), host);
+if (virGetLastError() == NULL)
This condition is never true. And it should only be used if
we can't fix the function to consistently set an error in all
cases.
Jan
+virReportSystemError(errno,
+ _(Failed to find LUs on host %u), host);
retval = -1;
}
signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 2/2] hostdev: fix net config restore error
On Thu, Mar 26, 2015 at 10:23:47PM +0800, Huanle Han wrote:
Fix for such a case:
1. Domain A and B xml contain the same SRIOV net hostdev(interface
type='hostdev' / with same pci address).
2. virsh start A (Successfully, and configure the SRIOV net with
custom mac)
3. virsh start B (Fail because of the hostdev used by domain A or other
reason.)
In step 3, 'virHostdevNetConfigRestore' is called for the hostdev
which is still used by domain A. It makes the mac/vlan of the SRIOV net
change.
Makes perfect sense, thanks for finding that out.
Code Change in this fix:
1. As the pci used by other domain have been removed from
'pcidevs' in previous loop, we only restore the nic config for
the hostdev still in 'pcidevs'(used by this domain)
2. wrap a function 'virHostdevIsPCINetDevice', which detect whether the
hostdev is a pci net device or not.
3. update the comments to make it more clear
Signed-off-by: Huanle Han hanxue...@gmail.com
---
src/util/virhostdev.c | 52 ---
1 file changed, 37 insertions(+), 15 deletions(-)
diff --git a/src/util/virhostdev.c b/src/util/virhostdev.c
index 83f567d..b04bae2 100644
--- a/src/util/virhostdev.c
+++ b/src/util/virhostdev.c
@@ -350,6 +350,14 @@ virHostdevNetDevice(virDomainHostdevDefPtr hostdev, char
**linkdev,
return ret;
}
+static int
+virHostdevIsPCINetDevice(virDomainHostdevDefPtr hostdev)
+{
+return hostdev-mode == VIR_DOMAIN_HOSTDEV_MODE_SUBSYS
+hostdev-source.subsys.type == VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI
+hostdev-parent.type == VIR_DOMAIN_DEVICE_NET
+hostdev-parent.data.net;
+}
static int
virHostdevNetConfigVirtPortProfile(const char *linkdev, int vf,
@@ -481,10 +489,7 @@ virHostdevNetConfigRestore(virDomainHostdevDefPtr hostdev,
/* This is only needed for PCI devices that have been defined
* using interface type='hostdev'. For all others, it is a NOP.
*/
-if (hostdev-mode != VIR_DOMAIN_HOSTDEV_MODE_SUBSYS ||
-hostdev-source.subsys.type != VIR_DOMAIN_HOSTDEV_SUBSYS_TYPE_PCI ||
-hostdev-parent.type != VIR_DOMAIN_DEVICE_NET ||
-!hostdev-parent.data.net)
+if (!virHostdevIsPCINetDevice(hostdev))
return 0;
isvf = virHostdevIsVirtualFunction(hostdev);
@@ -781,19 +786,20 @@ virHostdevReAttachPCIDevices(virHostdevManagerPtr
hostdev_mgr,
goto cleanup;
}
-/* Again 4 loops; mark all devices as inactive before reset
+/* Here are 4 loops; mark all devices as inactive before reset
* them and reset all the devices before re-attach.
* Attach mac and port profile parameters to devices
*/
+
+/* Loop 1: delete the copy of the dev from pcidevs if it's used by
+ * other domain. Or delete it from activePCIHostDevs if it had
+ * been used by this domain.
+ */
i = 0;
while (i virPCIDeviceListCount(pcidevs)) {
virPCIDevicePtr dev = virPCIDeviceListGet(pcidevs, i);
virPCIDevicePtr activeDev = NULL;
-/* delete the copy of the dev from pcidevs if it's used by
- * other domain. Or delete it from activePCIHostDevs if it had
- * been used by this domain.
- */
activeDev = virPCIDeviceListFind(hostdev_mgr-activePCIHostdevs, dev);
if (activeDev) {
const char *usedby_drvname;
@@ -814,14 +820,27 @@ virHostdevReAttachPCIDevices(virHostdevManagerPtr
hostdev_mgr,
* pcidevs, but has been removed from activePCIHostdevs.
*/
-/*
- * For SRIOV net host devices, unset mac and port profile before
- * reset and reattach device
+/* Loop 2: before reset and reattach device,
+ * unset mac and port profile for SRIOV net host devices used by this
domain
*/
The comments were formatted as a sentence, it would be nice to keep it
that way.
-for (i = 0; i nhostdevs; i++)
-virHostdevNetConfigRestore(hostdevs[i], hostdev_mgr-stateDir,
- oldStateDir);
+for (i = 0; i nhostdevs; i++) {
+virDomainHostdevDefPtr hostdev = hostdevs[i];
+if (virHostdevIsPCINetDevice(hostdev)) {
+virDomainHostdevSubsysPCIPtr pcisrc =
hostdev-source.subsys.u.pci;
+virPCIDevicePtr dev = NULL;
+dev = virPCIDeviceNew(pcisrc-addr.domain, pcisrc-addr.bus,
+ pcisrc-addr.slot, pcisrc-addr.function);
+
The daemon will crash if this function returns NULL. There should be
check for that, but it shouldn't be fatal, so we can clean up as much
as possible (see Loop 3 for example on how to handle that).
+if (virPCIDeviceListFind(pcidevs, dev)) {
+virHostdevNetConfigRestore(hostdev, hostdev_mgr-stateDir,
+ oldStateDir);
+}
+virPCIDeviceFree(dev);
+}
+}
+
+/* Loop 3: reset pci device used by this domain */
for (i = 0; i virPCIDeviceListCount(pcidevs); i++) {
virPCIDevicePtr dev
Re: [libvirt] [PATCH 1/2] tests: nodeinfo: Test F21 aarch64 on APM mustang
On Sat, Mar 28, 2015 at 02:31:30PM -0400, Cole Robinson wrote: -- 8 -- ACK to both. Jan signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 0/3] A few NUMA fixes
diff to v1: -reworked to follow Jan's review. Hopefully. Michal Privoznik (3): vircgroup: Introduce virCgroupControllerAvailable qemuProcessHook: Call virNuma*() iff needed virLXCControllerSetupResourceLimits: Call virNuma*() iff needed src/libvirt_private.syms | 1 + src/lxc/lxc_controller.c | 22 -- src/qemu/qemu_process.c | 21 + src/util/vircgroup.c | 19 +++ src/util/vircgroup.h | 1 + tests/vircgrouptest.c| 31 +++ 6 files changed, 85 insertions(+), 10 deletions(-) -- 2.0.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 3/3] virLXCControllerSetupResourceLimits: Call virNuma*() iff needed
Like we are doing in qemu driver
($COMMIT_HASH_TO_BE_FILLED_DURING_PUSHING), lets call
virNumaSetupMemoryPolicy() only if really needed. Problem is, if
we numa_set_membind() child, there's no way to change it from the
daemon afterwards. So any later attempts to change the pinning
will fail. But in very weird way - CGroups will be set, but due
to membind child will not allocate memory from any other node.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
src/lxc/lxc_controller.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/src/lxc/lxc_controller.c b/src/lxc/lxc_controller.c
index 8545f29..4b340ab 100644
--- a/src/lxc/lxc_controller.c
+++ b/src/lxc/lxc_controller.c
@@ -742,14 +742,24 @@ static int
virLXCControllerSetupResourceLimits(virLXCControllerPtr ctrl)
virBitmapPtr nodeset = NULL;
virDomainNumatuneMemMode mode;
-VIR_DEBUG(Setting up process resource limits);
-
-if (virLXCControllerGetNumadAdvice(ctrl, auto_nodeset) 0)
-goto cleanup;
-
-nodeset = virDomainNumatuneGetNodeset(ctrl-def-numa, auto_nodeset, -1);
mode = virDomainNumatuneGetMode(ctrl-def-numa, -1);
+if (mode == VIR_DOMAIN_NUMATUNE_MEM_STRICT
+virCgroupControllerAvailable(VIR_CGROUP_CONTROLLER_CPUSET)) {
+/* Use virNuma* API iff necessary. Once set and child is exec()-ed,
+ * there's no way for us to change it. Rely on cgroups (if available
+ * and enabled in the config) rather then virNuma*. */
+VIR_DEBUG(Postponing setting up resource limits to CGroup set up
phase);
+return virLXCControllerSetupCpuAffinity(ctrl);
+}
+
+VIR_DEBUG(Setting up process resource limits);
+
+if (virLXCControllerGetNumadAdvice(ctrl, auto_nodeset) 0)
+goto cleanup;
+
+nodeset = virDomainNumatuneGetNodeset(ctrl-def-numa, auto_nodeset, -1);
+
if (virNumaSetupMemoryPolicy(mode, nodeset) 0)
goto cleanup;
--
2.0.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 2/3] qemuProcessHook: Call virNuma*() iff needed
https://bugzilla.redhat.com/show_bug.cgi?id=1198645
Once upon a time, there was a little domain. And the domain was pinned
onto a NUMA node and hasn't fully allocated its memory:
memory unit='KiB'2355200/memory
currentMemory unit='KiB'1048576/currentMemory
numatune
memory mode='strict' nodeset='0'/
/numatune
Oh little me, said the domain, what will I do with so little memory.
If I only had a few megabytes more. But the old admin noticed the
whimpering, barely audible to untrained human ear. And good admin he
was, he gave the domain yet more memory. But the old NUMA topology
witch forbade to allocate more memory on the node zero. So he
decided to allocate it on a different node:
virsh # numatune little_domain --nodeset 0-1
virsh # setmem little_domain 2355200
The little domain was happy. For a while. Until bad, sharp teeth
shaped creature came. Every process in the system was afraid of him.
The OOM Killer they called him. Oh no, he's after the little domain.
There's no escape.
Do you kids know why? Because when the little domain was born, her
father, Libvirt, called numa_set_membind(). So even if the admin
allowed her to allocate memory from other nodes in the cgroups, the
membind() forbid it.
So what's the lesson? Libvirt should rely on cgroups, whenever
possible and use numa_set_membind() as the last ditch effort.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
src/qemu/qemu_process.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index 2d86eb8..6c955c3 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -3166,6 +3166,7 @@ static int qemuProcessHook(void *data)
int fd;
virBitmapPtr nodeset = NULL;
virDomainNumatuneMemMode mode;
+bool doNuma = true;
/* This method cannot use any mutexes, which are not
* protected across fork()
@@ -3197,11 +3198,23 @@ static int qemuProcessHook(void *data)
goto cleanup;
mode = virDomainNumatuneGetMode(h-vm-def-numa, -1);
-nodeset = virDomainNumatuneGetNodeset(h-vm-def-numa,
- priv-autoNodeset, -1);
-if (virNumaSetupMemoryPolicy(mode, nodeset) 0)
-goto cleanup;
+if (mode == VIR_DOMAIN_NUMATUNE_MEM_STRICT
+h-cfg-cgroupControllers (1 VIR_CGROUP_CONTROLLER_CPUSET)
+virCgroupControllerAvailable(VIR_CGROUP_CONTROLLER_CPUSET)) {
+/* Use virNuma* API iff necessary. Once set and child is exec()-ed,
+ * there's no way for us to change it. Rely on cgroups (if available
+ * and enabled in the config) rather then virNuma*. */
+doNuma = false;
+}
+
+if (doNuma) {
+nodeset = virDomainNumatuneGetNodeset(h-vm-def-numa,
+ priv-autoNodeset, -1);
+
+if (virNumaSetupMemoryPolicy(mode, nodeset) 0)
+goto cleanup;
+}
ret = 0;
--
2.0.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2 1/3] vircgroup: Introduce virCgroupControllerAvailable
This new internal API checks if given CGroup controller is
available. It is going to be needed later when we need to make a
decision whether pin domain memory onto NUMA nodes using cpuset
CGroup controller or using numa_set_membind().
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
src/libvirt_private.syms | 1 +
src/util/vircgroup.c | 19 +++
src/util/vircgroup.h | 1 +
tests/vircgrouptest.c| 31 +++
4 files changed, 52 insertions(+)
diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
index 5716ece..136036b 100644
--- a/src/libvirt_private.syms
+++ b/src/libvirt_private.syms
@@ -1129,6 +1129,7 @@ virCgroupAllowDevice;
virCgroupAllowDeviceMajor;
virCgroupAllowDevicePath;
virCgroupAvailable;
+virCgroupControllerAvailable;
virCgroupControllerTypeFromString;
virCgroupControllerTypeToString;
virCgroupDenyAllDevices;
diff --git a/src/util/vircgroup.c b/src/util/vircgroup.c
index d42f433..00c0bab 100644
--- a/src/util/vircgroup.c
+++ b/src/util/vircgroup.c
@@ -4011,6 +4011,20 @@ virCgroupHasEmptyTasks(virCgroupPtr cgroup, int
controller)
return ret;
}
+bool
+virCgroupControllerAvailable(int controller)
+{
+virCgroupPtr cgroup;
+bool ret = false;
+
+if (virCgroupNewSelf(cgroup) 0)
+return ret;
+
+ret = virCgroupHasController(cgroup, controller);
+virCgroupFree(cgroup);
+return ret;
+}
+
#else /* !VIR_CGROUP_SUPPORTED */
bool
@@ -4781,4 +4795,9 @@ virCgroupHasEmptyTasks(virCgroupPtr cgroup
ATTRIBUTE_UNUSED,
return -1;
}
+bool
+virCgroupControllerAvailable(int controller ATTRIBUTE_UNUSED)
+{
+return false;
+}
#endif /* !VIR_CGROUP_SUPPORTED */
diff --git a/src/util/vircgroup.h b/src/util/vircgroup.h
index eee15ca..5d6356d 100644
--- a/src/util/vircgroup.h
+++ b/src/util/vircgroup.h
@@ -282,4 +282,5 @@ int virCgroupSetOwner(virCgroupPtr cgroup,
int virCgroupHasEmptyTasks(virCgroupPtr cgroup, int controller);
+bool virCgroupControllerAvailable(int controller);
#endif /* __VIR_CGROUP_H__ */
diff --git a/tests/vircgrouptest.c b/tests/vircgrouptest.c
index bbf28d1..2b30258 100644
--- a/tests/vircgrouptest.c
+++ b/tests/vircgrouptest.c
@@ -586,6 +586,34 @@ static int testCgroupAvailable(const void *args)
return 0;
}
+static int testCgroupControllerAvailable(const void *args ATTRIBUTE_UNUSED)
+{
+int ret = 0;
+
+# define CHECK_CONTROLLER(c, present) \
+if ((present !virCgroupControllerAvailable(c)) ||\
+(!present virCgroupControllerAvailable(c))) {\
+fprintf(stderr, present ? \
+Expected controller %s not available\n : \
+Unexpected controller %s available\n, #c);\
+ret = -1; \
+}
+
+CHECK_CONTROLLER(VIR_CGROUP_CONTROLLER_CPU, true)
+CHECK_CONTROLLER(VIR_CGROUP_CONTROLLER_CPUACCT, true)
+CHECK_CONTROLLER(VIR_CGROUP_CONTROLLER_CPUSET, true)
+CHECK_CONTROLLER(VIR_CGROUP_CONTROLLER_MEMORY, true)
+CHECK_CONTROLLER(VIR_CGROUP_CONTROLLER_DEVICES, false)
+CHECK_CONTROLLER(VIR_CGROUP_CONTROLLER_FREEZER, true)
+CHECK_CONTROLLER(VIR_CGROUP_CONTROLLER_BLKIO, true)
+CHECK_CONTROLLER(VIR_CGROUP_CONTROLLER_NET_CLS, false)
+CHECK_CONTROLLER(VIR_CGROUP_CONTROLLER_PERF_EVENT, false)
+CHECK_CONTROLLER(VIR_CGROUP_CONTROLLER_SYSTEMD, true)
+
+# undef CHECK_CONTROLLER
+return ret;
+}
+
static int testCgroupGetPercpuStats(const void *args ATTRIBUTE_UNUSED)
{
virCgroupPtr cgroup = NULL;
@@ -886,6 +914,9 @@ mymain(void)
if (virtTestRun(Cgroup available, testCgroupAvailable, (void*)0x1) 0)
ret = -1;
+if (virtTestRun(Cgroup controller available,
testCgroupControllerAvailable, NULL) 0)
+ret = -1;
+
if (virtTestRun(virCgroupGetBlkioIoServiced works,
testCgroupGetBlkioIoServiced, NULL) 0)
ret = -1;
--
2.0.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] connect: ssh: Shall we remove the dependency of netcat ?
On Tue, Mar 31, 2015 at 09:02:23 +0800, zhang bo wrote: On 2015/3/28 0:25, Peter Krempa wrote: On Fri, Mar 27, 2015 at 10:54:26 +0800, zhang bo wrote: Too powerful? That is a ridiculous statement that probably originates from some kind of misunderstanding when creating a security policy or stuff like that. If a policy bans nc as powerful then it's missing on a lot of other options how to create listening or outgoing connections on arbitrary sockets. The only insecure part is that it does not use encryption, but that's a widely known fact about nc. Sorry for replying so late:) I tried to confirm the security fact the other days, unfortunately no clear answer gotten. What I meant was that the *network monitoring tools*, such as 'nc' and 'tcpdump', they are considered as dangerous for network security. They are prohibited in our company and some other organizations. I'm not quite sure whether the result that they're prohibited are directly related to their capability of monitoring network. But they actually got prohibited anyway. That sounds like a security-by-obscurity policy. I don't think that banning such tools might have any benefit for security. Anyways I'm planing on adding the native client. In such case, companies having such ridiculous security rules may opt to uninstall netcat and rely solely on libvirt's internal client (once it's implemented). Such policy will then basically mandate a minimal version of libvirt that will support the new client as older clients will still want to use NC. Peter signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/3] scsi: Check for invalid target.path after processLU failure
On Mon, Mar 30, 2015 at 07:16:34PM -0400, John Ferlan wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1171933
After processing all the LU's and find no real LU's - check if perhaps
the cause of that was a poorly formed 'target.path'. The expection is
generally that the path is /dev/disk/by-path or at least something in /dev.
Although it's not impossible for the user to provide something. If they
do provide something it should be valid or we should just cause a failure
to start the pool with an appropriate message.
Signed-off-by: John Ferlan jfer...@redhat.com
---
src/storage/storage_backend_scsi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/storage/storage_backend_scsi.c
b/src/storage/storage_backend_scsi.c
index 2f1f5ed..c3a1892 100644
--- a/src/storage/storage_backend_scsi.c
+++ b/src/storage/storage_backend_scsi.c
@@ -467,6 +467,15 @@
virStorageBackendSCSIFindLUsInternal(virStoragePoolObjPtr pool,
if (!*found)
VIR_DEBUG(No LU found for pool %s, pool-def-name);
+if (!*found !virFileExists(pool-def-target.path)
+!STRPREFIX(pool-def-target.path, /dev)) {
Checking for *found here seems pointless. After the logic change in the
previous patch, it is implied by either of the following conditions:
a) If the target path does not start with /dev, *found will be false:
virStorageBackendStablePath will short-circuit, just strduping
the volume path, and virStorageBackendSCSINewLun will return -1
in that case.
b) If the target path does not exist, it will either be rejected by the
above code path, or by the failed opendir in
virStorageBackendStablePath.
If all you want to do is forbid to start an {,i}SCSI pool that does not
start with /dev, we can do that much earlier in {,I}SCSIStartPool.
To catch wrong paths in /dev, I think the proper way is to stop ignoring
the return value of processLU and make it return -1 on fatal errors
(OOM, pool target path does not exist, etc.) and -2 on errors that won't
necessarily stop us from finding other volumes.
Jan
signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/3] iscsi: Check for presence of error before creating new one
On 03/31/2015 07:03 AM, Ján Tomko wrote:
On Mon, Mar 30, 2015 at 07:16:32PM -0400, John Ferlan wrote:
If virStorageBackendSCSIFindLUs fails, but the failure has an error
message - the iscsi code didn't honor that creating it's own wonderful
message such as error: Failed to find LUs on host 60: ... - not overly
helpful. Since a few of the called paths generate a message, check for
that before using that generic one.
Both of the paths returning -1 generate an error:
* return -1 after opendir failed
* retval = virDirRead
Signed-off-by: John Ferlan jfer...@redhat.com
---
src/storage/storage_backend_iscsi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/storage/storage_backend_iscsi.c
b/src/storage/storage_backend_iscsi.c
index 079c767..1dac238 100644
--- a/src/storage/storage_backend_iscsi.c
+++ b/src/storage/storage_backend_iscsi.c
@@ -147,8 +147,9 @@ virStorageBackendISCSIFindLUs(virStoragePoolObjPtr pool,
}
if (virStorageBackendSCSIFindLUs(pool, host) 0) {
-virReportSystemError(errno,
- _(Failed to find LUs on host %u), host);
+if (virGetLastError() == NULL)
This condition is never true. And it should only be used if
we can't fix the function to consistently set an error in all
cases.
Fair enough - just being overly cautious or un-optimistic I suppose
John
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 3/3] qemu: blockjob: Synchronously update backing chain in XML on ABORT/PIVOT
On Mon, Mar 30, 2015 at 14:51:08 -0600, Eric Blake wrote:
On 03/30/2015 03:26 AM, Peter Krempa wrote:
When the synchronous pivot option is selected, libvirt would not update
the backing chain until the job was exitted. Some applications then
s/exitted/exited/
received invalid data as their job serialized first.
This patch removes polling to wait for the ABORT/PIVOT job completion
and replaces it with a condition. If a synchronous operation is
requested the update of the XML is executed in the job of the caller of
the synchronous request. Otherwise the monitor event callback uses a
separate worker to update the backing chain with a new job.
This is a regression since 1a92c719101e5bfa6fe2b78006ad04c7f075ea28
unreleased, and therefore worth fixing during freeze.
When the ABORT job is finished synchronously you get the following call
stack:
#0 qemuBlockJobEventProcess
#1 qemuDomainBlockJobImpl
#2 qemuDomainBlockJobAbort
#3 virDomainBlockJobAbort
While previously or while using the _ASYNC flag you'd get:
#0 qemuBlockJobEventProcess
#1 processBlockJobEvent
#2 qemuProcessEventHandler
#3 virThreadPoolWorker
---
src/conf/domain_conf.c | 16 +++-
src/conf/domain_conf.h | 6 ++
src/qemu/qemu_driver.c | 45 +++--
src/qemu/qemu_process.c | 38 +-
4 files changed, 65 insertions(+), 40 deletions(-)
@@ -16389,37 +16395,24 @@ qemuDomainBlockJobImpl(virDomainObjPtr vm,
status);
event2 = virDomainEventBlockJob2NewFromObj(vm, disk-dst, type,
status);
-} else if (!(flags VIR_DOMAIN_BLOCK_JOB_ABORT_ASYNC)) {
+} else if (disk-blockJobSync) {
/* XXX If the event reports failure, we should reflect
* that back into the return status of this API call. */
Isn't this comment stale now? That is, since you are waiting for the
event to free the condition, and we are listening for both success and
failure events, we can now tell if the event reports failure.
No it is not. The code currently does not change the return value
depending on the success state of the operation. I wanted not to change
semantics in this case.
I'm going to follow up to this series with a series that refactors
qemuDomainBlockJobImpl by splitting it into seprate functions instead of
that spaghetti monster of function it is now.
In that change I'll then try to fix the semantics.
Otherwise, looks correct to me. I hate that it is so close to the
release deadline, but I hate regressions more (which is why we have
freezes). I'd feel better if you got a second review, if you can
wrangle one up in time, but here's my:
ACK.
Thanks.
Peter
signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virDomainShutdown*: Describe blocking behaviour
On 03/31/2015 01:37 AM, Michal Privoznik wrote: I don't think this is the right approach. It is okay to block for a small finite amount of time, but if the guest agent really is something that can hang, we should fix that code to return without waiting for the agent response. The problem is, we can tell if the shutdown qemu-ga command succeeded only when we see the SHUTDOWN event on the domain monitor. But we don't NEED to know if it succeeded - per our docs, we only issue the request (or fail outright because the request cannot be delivered because the agent is non-responsive). The other option is to treat it like we're treating ACPI mode of the API: just send the request and report if the sending succeeded. Don't wait until domain actually shuts down. I can provide a patch. Yes, that would be more in line with the docs. -- 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] [PATCH v4 0/9] qemu: Add quorum support to libvirt
On Tue, Mar 17, 2015 at 8:25 PM, Matthias Gatto matthias.ga...@outscale.com wrote: The purpose of these patches is to introduce quorum for libvirt I've try to follow this proposal: http://www.redhat.com/archives/libvir-list/2014-May/msg00533.html This feature ask for 6 task: 1) Allow a _virStorageSource to contain more than one backing store. Because all the actual libvirt code use the backingStore field as a pointer and we needs want to change that, I've decide to encapsulate the backingStore field to simplifie the array manipulation. 2) Add the missing field a quorum need in _virStorageSource and the VIR_STORAGE_TYPE_QUORUM and VIR_STORAGE_FILE_QUORUM in their respectives enums. 3) Parse and format the xml Because a quorum allows to have more than one backing store at the same level we need to change virDomainDiskDefFormat and virDomainDiskDefParseXML to call virDomainDiskBackingStoreFormat and virDomainDiskBackingStoreParse in a loop. virDomainDiskBackingStoreFormat and virDomainDiskBackingStoreParse can call themself recursively in a loop because a quorum can contain another quorum 4) Add nodename We need to add nodename support in _virStorageSource because qemu use them for their child. 5) Build qemu string As for the xml, we have to call the function which create quorum recursively. But this task have the problem explained here: http://www.redhat.com/archives/libvir-list/2014-October/msg00529.html The _virStorageSource missing some informations that can be passed to a child, and therefore this version of quorum is incomplet. 6) Allow to hotplug/change a disk in a quorum This part is not present in these patches because for this task we have to use blockdev-add, and currently libvirt use device_add for hotpluging that doesn't allow to hotplug quorum childs. There is 3 way to handle this problem: 1) create a virDomainBlockDevAdd function in libvirt witch call blockdev-add. 2) use blockdev-add instead of device_add in qemuMonitorJSONAddDevice 3) write a hack which uses blockdev-add when only attaching quorum (but i'm pretty sure this solution is not the good one) V2: -Rebase on master -Add Documentation V3: -Transforme the backingStore field in virStorageSource into an array of pointer instead of a pointer -Modify virStorageSourceSetBackingStore to allow it to expand the backingStore size. V4: -Rebase on master Matthias Gatto (9): virstoragefile: Add virStorageSourceGetBackingStore virstoragefile: Always use virStorageSourceGetBackingStore to get backing store virstoragefile: Add virStorageSourceSetBackingStore virstoragefile: Always use virStorageSourceSetBackingStore to set backing store virstoragefile: change backingStore to backingStores. virstoragefile: Add quorum in virstoragefile domain_conf: Read and Write quorum config qemu: Add quorum support in qemuBuildDriveDevStr virstoragefile: Add node-name docs/formatdomain.html.in | 27 - docs/schemas/domaincommon.rng | 95 +++-- docs/schemas/storagecommon.rng| 1 + docs/schemas/storagevol.rng | 1 + src/conf/domain_conf.c| 195 ++ src/conf/storage_conf.c | 22 ++-- src/libvirt_private.syms | 2 + src/qemu/qemu_cgroup.c| 4 +- src/qemu/qemu_command.c | 114 src/qemu/qemu_domain.c| 2 +- src/qemu/qemu_driver.c| 30 +++--- src/qemu/qemu_migration.c | 1 + src/security/security_dac.c | 2 +- src/security/security_selinux.c | 4 +- src/security/virt-aa-helper.c | 2 +- src/storage/storage_backend.c | 35 +++--- src/storage/storage_backend_fs.c | 37 --- src/storage/storage_backend_gluster.c | 10 +- src/storage/storage_backend_logical.c | 15 ++- src/storage/storage_driver.c | 2 +- src/util/virstoragefile.c | 116 +--- src/util/virstoragefile.h | 13 ++- tests/virstoragetest.c| 18 ++-- 23 files changed, 573 insertions(+), 175 deletions(-) -- 1.8.3.1 ping -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [RFC] How to build libvirt package with git commit info from libvirt.git
Hello there, Currently I am searching a way to build a libvirt package from latest libvirt.git with package name including git commit info. Like # cd libvirt git describe v1.2.14-rc1-16-g0c4474d then I want to build a libvirt package with name like libvirt-1.2.14-1.el7.v1.2.14-rc1-16-g0c4474d.x86_64 The context why I need this is there are some hosts running scripts for auto QE-consumption testing while there is no job running sometimes.( we won't get a internal release version everyday, it is not necessary also). We can make use of these resource to do some auto testing daily so that we may be able to find the regression problems earlier. So, a package with commit info is required for comparative testing. After talk with eblake I got a way as below: after 'make rpm' , I will get libvirt.spec, then I can tweak libvirt.spec add a line %define extra_release .git_commit_num at the top of libvirt.spec then use the tweaked libvirt.spec to build the package I want to get I wonder anybody have a better method to achieve this ? Thanks -- Regards shyu -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] Add vmport feature
The QEMU machine vmport option allows to set the VMWare IO port
emulation. This emulation is useful for absolute pointer input when the
guest has vmware input drivers, and is enabled by default for kvm.
However it is unnecessary for Spice-enabled VM, since the agent already
handles absolute pointer and multi-monitors. Furthermore, it prevents
Spice from switching to relative input since the regular ps/2 pointer
driver is replaced by the vmware driver. It is thus advised to disable
vmport when using a Spice VM. This will permit the Spice client to
switch from absolute to relative pointer, as it may be required for
certain games or applications.
---
docs/formatdomain.html.in | 6 +
docs/schemas/domaincommon.rng | 9 +++
src/conf/domain_conf.c | 5 +++-
src/conf/domain_conf.h | 1 +
src/qemu/qemu_capabilities.c | 6 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c| 14 +++
.../qemuxml2argv-machine-vmport-opt.args | 6 +
.../qemuxml2argv-machine-vmport-opt.xml| 28 ++
tests/qemuxml2argvtest.c | 2 ++
10 files changed, 77 insertions(+), 1 deletion(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-vmport-opt.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-machine-vmport-opt.xml
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 1b496c3..faa22ec 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1500,6 +1500,12 @@
performance monitoring unit for the guest.
span class=sinceSince 1.2.12/span
/dd
+ dtcodevmport/code/dt
+ ddDepending on the codestate/code attribute (values
codeon/code,
+codeoff/code, default codeon/code) enable or disable the
+the emulation of VMWare IO port, for vmmouse etc.
+span class=sinceSince 1.2.14/span
+ /dd
/dl
h3a name=elementsTimeTime keeping/a/h3
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 03fd541..b8e06b3 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -4149,6 +4149,15 @@
optional
ref name=pmu/
/optional
+ optional
+element name=vmport
+ optional
+attribute name=state
+ ref name=virOnOff/
+/attribute
+ /optional
+/element
+ /optional
/interleave
/element
/optional
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index cd6ee22..b92c634 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -139,7 +139,8 @@ VIR_ENUM_IMPL(virDomainFeature, VIR_DOMAIN_FEATURE_LAST,
kvm,
pvspinlock,
capabilities,
- pmu)
+ pmu,
+ vmport)
VIR_ENUM_IMPL(virDomainCapabilitiesPolicy, VIR_DOMAIN_CAPABILITIES_POLICY_LAST,
default,
@@ -14223,6 +14224,7 @@ virDomainDefParseXML(xmlDocPtr xml,
case VIR_DOMAIN_FEATURE_PMU:
case VIR_DOMAIN_FEATURE_PVSPINLOCK:
+case VIR_DOMAIN_FEATURE_VMPORT:
node = ctxt-node;
ctxt-node = nodes[i];
if ((tmp = virXPathString(string(./@state), ctxt))) {
@@ -20858,6 +20860,7 @@ virDomainDefFormatInternal(virDomainDefPtr def,
case VIR_DOMAIN_FEATURE_PMU:
case VIR_DOMAIN_FEATURE_PVSPINLOCK:
+case VIR_DOMAIN_FEATURE_VMPORT:
switch ((virTristateSwitch) def-features[i]) {
case VIR_TRISTATE_SWITCH_LAST:
case VIR_TRISTATE_SWITCH_ABSENT:
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index 84e880a..b29767e 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -1634,6 +1634,7 @@ typedef enum {
VIR_DOMAIN_FEATURE_PVSPINLOCK,
VIR_DOMAIN_FEATURE_CAPABILITIES,
VIR_DOMAIN_FEATURE_PMU,
+VIR_DOMAIN_FEATURE_VMPORT,
VIR_DOMAIN_FEATURE_LAST
} virDomainFeature;
diff --git a/src/qemu/qemu_capabilities.c b/src/qemu/qemu_capabilities.c
index ce6767c..8782613 100644
--- a/src/qemu/qemu_capabilities.c
+++ b/src/qemu/qemu_capabilities.c
@@ -279,6 +279,8 @@ VIR_ENUM_IMPL(virQEMUCaps, QEMU_CAPS_LAST,
qxl.vgamem_mb,
qxl-vga.vgamem_mb,
pc-dimm,
+
+ machine-vmport-opt, /* 185 */
);
@@ -3239,6 +3241,10 @@ virQEMUCapsInitQMPMonitor(virQEMUCapsPtr qemuCaps,
if (qemuCaps-version = 1003000)
virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACHINE_USB_OPT);
+/* vmport option is supported v2.2.0 onwards */
+if (qemuCaps-version = 2002000)
+virQEMUCapsSet(qemuCaps, QEMU_CAPS_MACHINE_VMPORT_OPT);
+
/* WebSockets were introduced between
[libvirt] Lispvirt: porting Libvirt API for Common Lisp
Hi everyone! I'm developing a Libvirt bindings for Common Lisp. The project is called Lispvirt. I created this project because I was doing a project in Lisp to manage Virtual Machines. So, I needed to implement some code using C and set up Lisp to access those methods in C. This project was becoming a mess. The better scenario is using only Lisp. That's why I started to develop this bindings for Lisp. Now, I'm only using Lisp for it. For a while, I'm hosting this project on GitHub: https://github.com/jcfaracco/lispvirt But I'm planning to move it to common-lisp.net. There is still many things to do (callbacks, structures, some project decisions and planings, documentation, etc). Any contribution or suggestions would be helpful. The most important things to do now are test, test and test. Just sharing if someone is interested to help us. Thanks! *--* *Julio Cesar Faracco* -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] virsh: add check for exclusive options for domstats command
On Tue, Mar 31, 2015 at 15:34:10 +0200, Pavel Hrdina wrote: Option --domain cannot be combined with options --list-*. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1143837 Signed-off-by: Pavel Hrdina phrd...@redhat.com --- tools/virsh-domain-monitor.c | 9 + 1 file changed, 9 insertions(+) diff --git a/tools/virsh-domain-monitor.c b/tools/virsh-domain-monitor.c index 6951db2..e683a6d 100644 --- a/tools/virsh-domain-monitor.c +++ b/tools/virsh-domain-monitor.c @@ -2110,6 +2110,15 @@ cmdDomstats(vshControl *ctl, const vshCmd *cmd) const vshCmdOpt *opt = NULL; bool ret = false; +VSH_EXCLUSIVE_OPTIONS(domain, list-active); +VSH_EXCLUSIVE_OPTIONS(domain, list-inactive); +VSH_EXCLUSIVE_OPTIONS(domain, list-persistent); +VSH_EXCLUSIVE_OPTIONS(domain, list-transient); +VSH_EXCLUSIVE_OPTIONS(domain, list-running); +VSH_EXCLUSIVE_OPTIONS(domain, list-paused); +VSH_EXCLUSIVE_OPTIONS(domain, list-shutoff); +VSH_EXCLUSIVE_OPTIONS(domain, list-other); + if (vshCommandOptBool(cmd, state)) stats |= VIR_DOMAIN_STATS_STATE; NACK, it was a deliberate design decision to allow users provide filters along with domain lists with the intention that we might want to filter the list provided by users. It was never implemented though. Peter signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/8] Fix cgroups regresion when default cpuset is specified
On Fri, Mar 27, 2015 at 02:12:04PM +0100, Peter Krempa wrote: Since commit a39f69d2b libvirt would fail to start a VM if the default cpu set was specified and individual vcpus were pinned to cpus outside of that cpuset. Peter Krempa (8): qemu: cgroup: Store auto cpuset instead of re-creating it on demand qemu: cgroup: Refactor setup for IOThread cgroups qemu: cgroup: Properly set up vcpu pinning qemu: cgroup: Use priv-autoCpuset instead of using qemuPrepareCpumap() qemu: cgroup: Rename qemuSetupCgroupEmulatorPin to qemuSetupCgroupCpusetCpus qemu: cgroup: Kill qemuSetupCgroupIOThreadsPin() qemu: cgroup: Kill qemuSetupCgroupVcpuPin() qemu: Copy bitmap in a sane way src/qemu/qemu_cgroup.c | 150 +++- src/qemu/qemu_cgroup.h | 13 + src/qemu/qemu_domain.c | 1 + src/qemu/qemu_domain.h | 3 + src/qemu/qemu_driver.c | 21 +++ src/qemu/qemu_process.c | 93 +- src/qemu/qemu_process.h | 2 - 7 files changed, 85 insertions(+), 198 deletions(-) ACK series. Nice cleanup, that will show the NUMA topology witch! [1] Jan [1] https://www.redhat.com/archives/libvir-list/2015-March/msg01581.html signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] tests: nodeinfo: Test F21 aarch64 on APM mustang
On 03/31/2015 04:19 PM, Eric Blake wrote: On 03/31/2015 09:19 AM, Cole Robinson wrote: On 03/31/2015 06:06 AM, Ján Tomko wrote: On Sat, Mar 28, 2015 at 02:31:30PM -0400, Cole Robinson wrote: -- 8 -- ACK to both. Jan Thanks, but trying to push I'm getting errors: remote: tests/nodeinfodata/linux-f21-mustang/cpu/cpu0/uevent:1: new blank line at EOF. I'll push on your behalf (I know the magic secrets for temporarily relaxing the libvirt.org commit checks in cases like this. Supposedly, it was at one point possible for anyone to make those changes on a one-push basis by creating a special tag for the commit, but without actually reading the hooks on libvirt.org, and in light of no documentation for such a hack, I think that the only people that can do it right now are those with libvirt.org shell login; it would be nice to get to a point where anyone with push rights could do it even without shell rights, but it happens so seldom that no one is ever motivated to tackle that project) And now that I actually run syntax-check (sorry), seeing an additional error: tests/nodeinfodata/linux-f21-mustang/cpu/offline:1: tests/nodeinfodata/linux-rhelsa-3.19.0-mustang/cpu/offline:1: maint.mk: Prohibited empty first line cfg.mk:956: recipe for target 'sc_prohibit_empty_first_line' failed make: *** [sc_prohibit_empty_first_line] Error 1 And the fix for this is: diff --git i/cfg.mk w/cfg.mk index 661..79c5d48 100644 --- i/cfg.mk +++ w/cfg.mk @@ -1185,7 +1185,7 @@ exclude_file_name_regexp--sc_prohibit_mixed_case_abbreviations = \ ^src/(vbox/vbox_CAPI.*.h|esx/esx_vi.(c|h)|esx/esx_storage_backend_iscsi.c)$$ exclude_file_name_regexp--sc_prohibit_empty_first_line = \ - ^(README|daemon/THREADS\.txt|src/esx/README|docs/library.xen|tests/vmwareverdata/fusion-5.0.3.txt|tests/nodeinfodata/linux-raspberrypi/cpu/offline)$$ + ^(README|daemon/THREADS\.txt|src/esx/README|docs/library.xen|tests/(vmware|nodeinfo)data/*)$$ exclude_file_name_regexp--sc_prohibit_useless_translation = \ ^tests/virpolkittest.c I attached the unaltered patches if anyone wants to figure out the tweaks to make these bits pass, I can't look at this at the moment. I'll push shortly. Thanks a lot Eric! - Cole -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 1/2] tests: nodeinfo: Test F21 aarch64 on APM mustang
On 03/31/2015 09:19 AM, Cole Robinson wrote: On 03/31/2015 06:06 AM, Ján Tomko wrote: On Sat, Mar 28, 2015 at 02:31:30PM -0400, Cole Robinson wrote: -- 8 -- ACK to both. Jan Thanks, but trying to push I'm getting errors: remote: tests/nodeinfodata/linux-f21-mustang/cpu/cpu0/uevent:1: new blank line at EOF. I'll push on your behalf (I know the magic secrets for temporarily relaxing the libvirt.org commit checks in cases like this. Supposedly, it was at one point possible for anyone to make those changes on a one-push basis by creating a special tag for the commit, but without actually reading the hooks on libvirt.org, and in light of no documentation for such a hack, I think that the only people that can do it right now are those with libvirt.org shell login; it would be nice to get to a point where anyone with push rights could do it even without shell rights, but it happens so seldom that no one is ever motivated to tackle that project) And now that I actually run syntax-check (sorry), seeing an additional error: tests/nodeinfodata/linux-f21-mustang/cpu/offline:1: tests/nodeinfodata/linux-rhelsa-3.19.0-mustang/cpu/offline:1: maint.mk: Prohibited empty first line cfg.mk:956: recipe for target 'sc_prohibit_empty_first_line' failed make: *** [sc_prohibit_empty_first_line] Error 1 And the fix for this is: diff --git i/cfg.mk w/cfg.mk index 661..79c5d48 100644 --- i/cfg.mk +++ w/cfg.mk @@ -1185,7 +1185,7 @@ exclude_file_name_regexp--sc_prohibit_mixed_case_abbreviations = \ ^src/(vbox/vbox_CAPI.*.h|esx/esx_vi.(c|h)|esx/esx_storage_backend_iscsi.c)$$ exclude_file_name_regexp--sc_prohibit_empty_first_line = \ - ^(README|daemon/THREADS\.txt|src/esx/README|docs/library.xen|tests/vmwareverdata/fusion-5.0.3.txt|tests/nodeinfodata/linux-raspberrypi/cpu/offline)$$ + ^(README|daemon/THREADS\.txt|src/esx/README|docs/library.xen|tests/(vmware|nodeinfo)data/*)$$ exclude_file_name_regexp--sc_prohibit_useless_translation = \ ^tests/virpolkittest.c I attached the unaltered patches if anyone wants to figure out the tweaks to make these bits pass, I can't look at this at the moment. I'll push shortly. -- 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] [PATCH V2] libxl: fix dom0 balloon logic
Martin Kletzander wrote:
On Tue, Mar 24, 2015 at 02:43:42PM -0600, Jim Fehlig wrote:
Recent testing on large memory systems revealed a bug in the Xen xl
tool's freemem() function. When autoballooning is enabled, freemem()
is used to ensure enough memory is available to start a domain,
ballooning dom0 if necessary. When ballooning large amounts of memory
from dom0, freemem() would exceed its self-imposed wait time and
return an error. Meanwhile, dom0 continued to balloon. Starting the
domain later, after sufficient memory was ballooned from dom0, would
succeed. The libvirt implementation in libxlDomainFreeMem() suffers
the same bug since it is modeled after freemem().
In the end, the best place to fix the bug on the Xen side was to
slightly change the behavior of libxl_wait_for_memory_target().
Instead of failing after caller-provided wait_sec, the function now
blocks as long as dom0 memory ballooning is progressing. It will return
failure only when more memory is needed to reach the target and wait_sec
have expired with no progress being made. See xen.git commit fd3aa246.
There was a dicussion on how this would affect other libxl apps like
libvirt
http://lists.xen.org/archives/html/xen-devel/2015-03/msg00739.html
If libvirt containing this patch was build against a Xen containing
the old libxl_wait_for_memory_target() behavior, libxlDomainFreeMem()
will fail after 30 sec and domain creation will be terminated.
Without this patch and with old libxl_wait_for_memory_target() behavior,
libxlDomainFreeMem() does not succeed after 30 sec, but returns success
anyway. Domain creation continues resulting in all sorts of fun stuff
like cpu soft lockups in the guest OS. It was decided to properly fix
libxl_wait_for_memory_target(), and if anything improve the default
behavior of apps using the freemem reference impl in xl.
xl was patched to accommodate the change in
libxl_wait_for_memory_target()
with xen.git commit 883b30a0. This patch does the same in the libxl
driver. While at it, I changed the logic to essentially match
freemem() in $xensrc/tools/libxl/xl_cmdimpl.c. It was a bit cleaner
IMO and will make it easier to spot future, potentially interesting
divergences.
Signed-off-by: Jim Fehlig jfeh...@suse.com
---
V2: Actually use libxl_wait_for_memory_target(), instead of
libxl_wait_for_free_memory()
src/libxl/libxl_domain.c | 55
+++-
1 file changed, 26 insertions(+), 29 deletions(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 407a9bd..a1739aa 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -1121,38 +1121,39 @@ libxlDomainFreeMem(libxlDomainObjPrivatePtr
priv, libxl_domain_config *d_config)
{
uint32_t needed_mem;
uint32_t free_mem;
-size_t i;
-int ret = -1;
+int ret;
This variable is unnecessary and confusing since you don't return it.
And without this, you can make ...
int tries = 3;
int wait_secs = 10;
-if ((ret = libxl_domain_need_memory(priv-ctx, d_config-b_info,
-needed_mem)) = 0) {
-for (i = 0; i tries; ++i) {
-if ((ret = libxl_get_free_memory(priv-ctx, free_mem))
0)
-break;
+ret = libxl_domain_need_memory(priv-ctx, d_config-b_info,
needed_mem);
+if (ret 0)
+goto error;
... these conditions smaller, e.g.:
if (libxl_domain_need_memory(priv-ctx, d_config-b_info,
needed_mem) 0)
goto error;
Yeah, too much copy and paste. I'll fix this up and send a V3.
Do you need this for the release? (sorry for noticing that late)
No, this can wait. From a Xen perspective, more useful work for the
release would have been this series
https://www.redhat.com/archives/libvir-list/2015-March/msg01337.html
But I think it is a bit too late now :-(.
Regards,
Jim
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH V2] libxl: fix dom0 balloon logic
On Tue, Mar 31, 2015 at 08:16:09AM -0600, Jim Fehlig wrote:
Martin Kletzander wrote:
On Tue, Mar 24, 2015 at 02:43:42PM -0600, Jim Fehlig wrote:
Recent testing on large memory systems revealed a bug in the Xen xl
tool's freemem() function. When autoballooning is enabled, freemem()
is used to ensure enough memory is available to start a domain,
ballooning dom0 if necessary. When ballooning large amounts of memory
from dom0, freemem() would exceed its self-imposed wait time and
return an error. Meanwhile, dom0 continued to balloon. Starting the
domain later, after sufficient memory was ballooned from dom0, would
succeed. The libvirt implementation in libxlDomainFreeMem() suffers
the same bug since it is modeled after freemem().
In the end, the best place to fix the bug on the Xen side was to
slightly change the behavior of libxl_wait_for_memory_target().
Instead of failing after caller-provided wait_sec, the function now
blocks as long as dom0 memory ballooning is progressing. It will return
failure only when more memory is needed to reach the target and wait_sec
have expired with no progress being made. See xen.git commit fd3aa246.
There was a dicussion on how this would affect other libxl apps like
libvirt
http://lists.xen.org/archives/html/xen-devel/2015-03/msg00739.html
If libvirt containing this patch was build against a Xen containing
the old libxl_wait_for_memory_target() behavior, libxlDomainFreeMem()
will fail after 30 sec and domain creation will be terminated.
Without this patch and with old libxl_wait_for_memory_target() behavior,
libxlDomainFreeMem() does not succeed after 30 sec, but returns success
anyway. Domain creation continues resulting in all sorts of fun stuff
like cpu soft lockups in the guest OS. It was decided to properly fix
libxl_wait_for_memory_target(), and if anything improve the default
behavior of apps using the freemem reference impl in xl.
xl was patched to accommodate the change in
libxl_wait_for_memory_target()
with xen.git commit 883b30a0. This patch does the same in the libxl
driver. While at it, I changed the logic to essentially match
freemem() in $xensrc/tools/libxl/xl_cmdimpl.c. It was a bit cleaner
IMO and will make it easier to spot future, potentially interesting
divergences.
Signed-off-by: Jim Fehlig jfeh...@suse.com
---
V2: Actually use libxl_wait_for_memory_target(), instead of
libxl_wait_for_free_memory()
src/libxl/libxl_domain.c | 55
+++-
1 file changed, 26 insertions(+), 29 deletions(-)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index 407a9bd..a1739aa 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -1121,38 +1121,39 @@ libxlDomainFreeMem(libxlDomainObjPrivatePtr
priv, libxl_domain_config *d_config)
{
uint32_t needed_mem;
uint32_t free_mem;
-size_t i;
-int ret = -1;
+int ret;
This variable is unnecessary and confusing since you don't return it.
And without this, you can make ...
int tries = 3;
int wait_secs = 10;
-if ((ret = libxl_domain_need_memory(priv-ctx, d_config-b_info,
-needed_mem)) = 0) {
-for (i = 0; i tries; ++i) {
-if ((ret = libxl_get_free_memory(priv-ctx, free_mem))
0)
-break;
+ret = libxl_domain_need_memory(priv-ctx, d_config-b_info,
needed_mem);
+if (ret 0)
+goto error;
... these conditions smaller, e.g.:
if (libxl_domain_need_memory(priv-ctx, d_config-b_info,
needed_mem) 0)
goto error;
Yeah, too much copy and paste. I'll fix this up and send a V3.
Do you need this for the release? (sorry for noticing that late)
No, this can wait. From a Xen perspective, more useful work for the
release would have been this series
https://www.redhat.com/archives/libvir-list/2015-March/msg01337.html
But I think it is a bit too late now :-(.
I missed that, sorry. I'll have a look at it tomorrow. Not being
that Xen-knowledgeable, I probably haven't felt that confident
reviewing that.
Regards,
Jim
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
pgp_34bWKZnxE.pgp
Description: PGP signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] virsh: add check for exclusive options for domstats command
Option --domain cannot be combined with options --list-*. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1143837 Signed-off-by: Pavel Hrdina phrd...@redhat.com --- tools/virsh-domain-monitor.c | 9 + 1 file changed, 9 insertions(+) diff --git a/tools/virsh-domain-monitor.c b/tools/virsh-domain-monitor.c index 6951db2..e683a6d 100644 --- a/tools/virsh-domain-monitor.c +++ b/tools/virsh-domain-monitor.c @@ -2110,6 +2110,15 @@ cmdDomstats(vshControl *ctl, const vshCmd *cmd) const vshCmdOpt *opt = NULL; bool ret = false; +VSH_EXCLUSIVE_OPTIONS(domain, list-active); +VSH_EXCLUSIVE_OPTIONS(domain, list-inactive); +VSH_EXCLUSIVE_OPTIONS(domain, list-persistent); +VSH_EXCLUSIVE_OPTIONS(domain, list-transient); +VSH_EXCLUSIVE_OPTIONS(domain, list-running); +VSH_EXCLUSIVE_OPTIONS(domain, list-paused); +VSH_EXCLUSIVE_OPTIONS(domain, list-shutoff); +VSH_EXCLUSIVE_OPTIONS(domain, list-other); + if (vshCommandOptBool(cmd, state)) stats |= VIR_DOMAIN_STATS_STATE; -- 2.0.5 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Add vmport feature
Hi On Wed, Apr 1, 2015 at 2:45 AM, Marc-André Lureau marcandre.lur...@gmail.com wrote: +span class=sinceSince 1.2.14/span I guess this will have to wait 1.2.15 -- Marc-André Lureau -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
