[libvirt] [PATCH] Fix a mismatch attribute name
From libvirt.org we know this attribute named:
interface_mac MAC address of the network interface, not unique
Signed-off-by: Luyao Huang lhu...@redhat.com
---
src/access/viraccessdriverpolkit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/access/viraccessdriverpolkit.c
b/src/access/viraccessdriverpolkit.c
index 3136be7..0e07053 100644
--- a/src/access/viraccessdriverpolkit.c
+++ b/src/access/viraccessdriverpolkit.c
@@ -206,7 +206,7 @@ virAccessDriverPolkitCheckInterface(virAccessManagerPtr
manager,
const char *attrs[] = {
connect_driver, driverName,
interface_name, iface-name,
-interface_macaddr, iface-mac,
+interface_mac, iface-mac,
NULL,
};
--
1.8.3.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [Patch v6 0/5] Libvirt CPU enhancements for Power KVM
On 04.11.2014 18:19, Prerna Saxena wrote: This patch series is a collection of enhancements for PowerPC CPUs on PowerKVM. The v5 of this series has been acked. I have just rebased the patches on top of latest master and added a testcase. Series Summary: == Patch 1/5 : Introduce a new architecture 'ppc64le' for libvirt. Patch 2/5 : Add libvirt support for VMs running in 'compat' mode on Power KVM. Patch 3/5 : Improve PVR handling to fall back to cpu generation. Patch 4/5 : Add documentation describing compat mode usage for PowerPC guests. Patch 5/5 : Add a test case for compat mode. ACKed and pushed. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] virnuma: add notset NULL check in virNumaSetupMemoryPolicy
introduce by commit c63ef0452b, when nodeset is NULL, validation will pass in virNumaSetupMemoryPolicy, but virBitmapNextSetBit must ensure bitmap is not Null. there will cause a segmentation fault. this patch fixed it. Signed-off-by: Chen Fan chen.fan.f...@cn.fujitsu.com --- src/util/virnuma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/util/virnuma.c b/src/util/virnuma.c index 06520f7..b8d76f4 100644 --- a/src/util/virnuma.c +++ b/src/util/virnuma.c @@ -97,6 +97,9 @@ virNumaSetupMemoryPolicy(virDomainNumatuneMemMode mode, size_t i; int maxnode = 0; +if (!nodeset) +return 0; + if (!virNumaNodesetIsAvailable(nodeset)) return -1; -- 1.9.3 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix a mismatch attribute name
On 11/07/2014 09:24 AM, Luyao Huang wrote:
From libvirt.org we know this attribute named:
interface_mac MAC address of the network interface, not unique
Shouldn't we instead be fixing the docs to match the code? Changing the
code now may break existing implementations that have used the name in
the current code.
Signed-off-by: Luyao Huang lhu...@redhat.com
---
src/access/viraccessdriverpolkit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/access/viraccessdriverpolkit.c
b/src/access/viraccessdriverpolkit.c
index 3136be7..0e07053 100644
--- a/src/access/viraccessdriverpolkit.c
+++ b/src/access/viraccessdriverpolkit.c
@@ -206,7 +206,7 @@ virAccessDriverPolkitCheckInterface(virAccessManagerPtr
manager,
const char *attrs[] = {
connect_driver, driverName,
interface_name, iface-name,
-interface_macaddr, iface-mac,
+interface_mac, iface-mac,
NULL,
};
--
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] is there a notification when watchdog triggers?
On 11/06/2014 11:08 PM, Chris Friesen wrote: The libvirt.org docs say A virtual hardware watchdog device can be added to the guest via the watchdog elementCurrently libvirt does not support notification when the watchdog fires. This feature is planned for a future version of libvirt. Is that still accurate? Or does libvirt now support notifications? It looks outdated, as we have VIR_DOMAIN_EVENT_ID_WATCHDOG as the way to receive notification of a watchdog event in the guest: http://libvirt.org/html/libvirt-libvirt-domain.html#virDomainEventWatchdogAction http://libvirt.org/html/libvirt-libvirt-domain.html#virConnectDomainEventWatchdogCallback Which URL had the outdated information, so we can fix it? -- 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 00/15] Cleanup some curly braces
On 06.11.2014 17:38, Martin Kletzander wrote: There were unnecessary curly braces in few places (and the whole esx driver), so this series proposes fixing them. As this couldn't be done automatically, there is no syntax-check. We have to keep trying to eliminate that ;) Martin Kletzander (15): vbox: Remove useless condition branches Remove unneeded curly brackets around oneline code blocks in src/conf/ Remove unneeded curly brackets around oneline code blocks in src/esx/ Remove unneeded curly brackets around oneline code blocks in src/hyperv/ Remove unneeded curly brackets around oneline code blocks in src/node_device/ Remove unneeded curly brackets around oneline code blocks in src/qemu/ Remove unneeded curly brackets around oneline code blocks in src/util/ Remove unneeded curly brackets around oneline code blocks in src/vbox/ Remove unneeded curly brackets around oneline code blocks in src/vmx/ Remove unneeded curly brackets around oneline code blocks in src/[u-z]*/ Remove unneeded curly brackets around oneline code blocks in src/[st]*/ Remove unneeded curly brackets around oneline code blocks in src/[n-r]*/ Remove unneeded curly brackets around oneline code blocks in src/[a-m]*/ Remove unneeded curly brackets around oneline code blocks in tests/ Remove unneeded curly brackets around oneline code blocks daemon/libvirtd.c | 15 +- daemon/remote.c | 15 +- examples/object-events/event-test.c | 3 +- examples/openauth/openauth.c | 9 +- src/access/viraccessdriverstack.c | 3 +- src/bhyve/bhyve_driver.c | 3 +- src/conf/capabilities.c | 3 +- src/conf/device_conf.c| 6 +- src/conf/domain_conf.c| 203 +++- src/conf/interface_conf.c | 9 +- src/conf/netdev_vport_profile_conf.c | 12 +- src/conf/network_conf.c | 114 ++-- src/conf/node_device_conf.c | 27 +- src/conf/nwfilter_conf.c | 24 +- src/conf/object_event.c | 6 +- src/conf/storage_conf.c | 30 +- src/cpu/cpu_powerpc.c | 3 +- src/cpu/cpu_x86.c | 3 +- src/datatypes.c | 6 +- src/driver.c | 3 +- src/esx/esx_device_monitor.c | 3 +- src/esx/esx_driver.c | 838 ++ src/esx/esx_interface_driver.c| 36 +- src/esx/esx_network_driver.c | 132 ++--- src/esx/esx_nwfilter_driver.c | 3 +- src/esx/esx_secret_driver.c | 3 +- src/esx/esx_storage_backend_iscsi.c | 78 +-- src/esx/esx_storage_backend_vmfs.c| 204 +++- src/esx/esx_storage_driver.c | 81 +-- src/esx/esx_util.c| 51 +- src/esx/esx_vi.c | 606 +++-- src/esx/esx_vi_methods.c | 3 +- src/esx/esx_vi_types.c| 54 +- src/hyperv/hyperv_device_monitor.c| 3 +- src/hyperv/hyperv_driver.c| 132 ++--- src/hyperv/hyperv_interface_driver.c | 3 +- src/hyperv/hyperv_network_driver.c| 3 +- src/hyperv/hyperv_nwfilter_driver.c | 3 +- src/hyperv/hyperv_secret_driver.c | 3 +- src/hyperv/hyperv_storage_driver.c| 3 +- src/hyperv/hyperv_util.c | 6 +- src/hyperv/hyperv_wmi.c | 45 +- src/interface/interface_backend_udev.c| 15 +- src/libvirt-domain.c | 6 +- src/libvirt-lxc.c | 3 +- src/libvirt-nodedev.c | 3 +- src/libvirt-storage.c | 6 +- src/libxl/libxl_conf.c| 3 +- src/libxl/libxl_driver.c | 12 +- src/locking/lock_daemon.c | 9 +- src/locking/lock_driver_sanlock.c | 6 +- src/lxc/lxc_container.c | 12 +- src/lxc/lxc_driver.c | 12 +- src/lxc/lxc_process.c | 6 +- src/network/bridge_driver.c | 53 +- src/network/bridge_driver_linux.c | 9 +- src/network/leaseshelper.c| 3 +- src/node_device/node_device_driver.c | 33 +- src/node_device/node_device_hal.c | 6 +- src/node_device/node_device_udev.c| 222 +++- src/nodeinfo.c| 3 +- src/nwfilter/nwfilter_dhcpsnoop.c | 6 +- src/nwfilter/nwfilter_ebiptables_driver.c | 12 +- src/nwfilter/nwfilter_gentech_driver.c| 12 +- src/nwfilter/nwfilter_learnipaddr.c | 3 +- src/openvz/openvz_conf.c | 3 +-
Re: [libvirt] [PATCH] Transform VIR_ERROR into VIR_WARN in detect_scsi_host_caps
On 11/04/2014 03:15 PM, Cédric Bosdonnat wrote: If detect_scsi_host_caps reports errors but keeps libvirtd going on startup, the user is mislead by the error messages. Transforming them s/mislead/misled/ into warning still shows the problems, but indicates this is not fatal. --- po/POTFILES.in| 1 - src/node_device/node_device_linux_sysfs.c | 22 +++--- 2 files changed, 11 insertions(+), 12 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
[libvirt] [v2 PATCH] doc: Fix a mismatch attribute name
From virAccessDriverPolkitCheckInterface function, we know this attribute should named: interface_macaddr Signed-off-by: Luyao Huang lhu...@redhat.com --- docs/aclpolkit.html.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/aclpolkit.html.in b/docs/aclpolkit.html.in index 91b5296..e5a9b16 100644 --- a/docs/aclpolkit.html.in +++ b/docs/aclpolkit.html.in @@ -121,7 +121,7 @@ tdName of the network interface, unique to the local host/td /tr tr - tdinterface_mac/td + tdinterface_macaddr/td tdMAC address of the network interface, not unique/td /tr /tbody -- 1.8.3.1 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] qemu: don't setup cpuset.mems if memory mode in numatune is 'preferred'
On 2014/11/5 16:07, Martin Kletzander wrote:
[...]
diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c
index b5bdb36..8685d6f 100644
--- a/src/qemu/qemu_cgroup.c
+++ b/src/qemu/qemu_cgroup.c
@@ -618,6 +618,11 @@ qemuSetupCpusetMems(virDomainObjPtr vm,
if (!virCgroupHasController(priv-cgroup,
VIR_CGROUP_CONTROLLER_CPUSET))
return 0;
+if (virDomainNumatuneGetMode(vm-def-numatune, -1) !=
+VIR_DOMAIN_NUMATUNE_MEM_STRICT) {
+return 0;
+}
+
One question, is it problem only for 'preferred' or 'interleaved' as
well? Because if it's only problem for 'preferred', then the check is
wrong. If it's problem for 'interleaved' as well, then the commit
message is wrong.
'interleave' with a single node(such as nodeset='0') will cause the same
error.
But 'interleave' mode should not live with a single node. So maybe there's
another bugfix to check 'interleave' with single node.
Well, I'd be OK with just changing the commit message to mention that.
This fix is still a valid one and will fix both issues, won't it?
If configured with 'interleave' and multiple nodes(such as nodeset='0-1'),
VM can be started successfully. And cpuset.mems is set to the same nodeset.
So I'll revise my patch.
I'll send patches V2. Conclusion:
1/3 : add check for 'interleave' mode with single numa node
2/3 : fix this problem in qemu
3/3 : fix this problem in lxc
Is it OK?
Anyway, after either one is fixed, I can push this.
I tested this problem again and found that this error occurred with each
memory mode. It is broke by commit 411cea638f6ec8503b7142a31e58b1cd85dbeaba
which is produced by me.
qemu: move setting emulatorpin ahead of monitor showing up
I'm sorry for that.
That patch moved qemuSetupCgroupForEmulator before qemuSetupCgroupPostInit.
I have ideas to fix that.
1. Move qemuSetupCgroupPostInit ahead of monitor showing up, too.
Of course it's before qemuSetupCgroupForEmulator.
This action to fix the bug which is introduced by me.
(RFC)
2. Anyway the first problem is fixed, I have found the second problem which
is I wanted to fix originally. If memory mode is 'preferred' and with
one node (such as nodeset='0'), domain's memory is not in node 0
absolutely. Assumption that node 0 doesn't have enough memory, memory
can be allocated on node 1. Then if we set cpuset.mems to '0', it may
cause OOM.
The solution is checking memory mode in (lxc)qemuSetupCpusetMems as my
patch on Tuesday. Such as
+if (virDomainNumatuneGetMode(vm-def-numatune, -1) !=
+VIR_DOMAIN_NUMATUNE_MEM_PREFERRED) {
BTW:
3. After the first problem has been fixed, we can start domains with xml:
numatune
memory mode='interleave' nodeset='0'/
/numatune
Is a single node '0' valid for 'interleave' ? I take 'interleave' as
'at least two nodes'.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix a mismatch attribute name
On 11/07/2014 05:15 PM, Eric Blake wrote:
On 11/07/2014 09:24 AM, Luyao Huang wrote:
From libvirt.org we know this attribute named:
interface_mac MAC address of the network interface, not unique
Shouldn't we instead be fixing the docs to match the code? Changing the
code now may break existing implementations that have used the name in
the current code.
yes, i agree with you, i give a v2 patch, but i don't know how to change
the doc in http://libvirt.org.
https://www.redhat.com/archives/libvir-list/2014-November/msg00209.html
And this patch is for the bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1161358
Signed-off-by: Luyao Huang lhu...@redhat.com
---
src/access/viraccessdriverpolkit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/access/viraccessdriverpolkit.c
b/src/access/viraccessdriverpolkit.c
index 3136be7..0e07053 100644
--- a/src/access/viraccessdriverpolkit.c
+++ b/src/access/viraccessdriverpolkit.c
@@ -206,7 +206,7 @@ virAccessDriverPolkitCheckInterface(virAccessManagerPtr
manager,
const char *attrs[] = {
connect_driver, driverName,
interface_name, iface-name,
-interface_macaddr, iface-mac,
+interface_mac, iface-mac,
NULL,
};
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 00/15] Cleanup some curly braces
On 11/06/2014 05:38 PM, Martin Kletzander wrote: There were unnecessary curly braces in few places (and the whole esx driver), so this series proposes fixing them. As this couldn't be done automatically, there is no syntax-check. We have to keep trying to eliminate that ;) I'm a little bit worried that without a syntax check, this is just code churn and a conflict magnet that will make it harder to backport patches. I'm not entirely opposed to the idea, but I'm also thinking we should not be applying it without discussion. -- 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 01/15] vbox: Remove useless condition branches
On 11/06/2014 05:38 PM, Martin Kletzander wrote: These were probably left there after some code movement. Signed-off-by: Martin Kletzander mklet...@redhat.com --- src/vbox/vbox_common.c | 23 ++- 1 file changed, 6 insertions(+), 17 deletions(-) ACK to this one, regardless of the fate of the rest of the series. -- 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] Fix a mismatch attribute name
On 11/07/2014 10:37 AM, lhuang wrote: On 11/07/2014 05:15 PM, Eric Blake wrote: On 11/07/2014 09:24 AM, Luyao Huang wrote: From libvirt.org we know this attribute named: interface_macMAC address of the network interface, not unique Shouldn't we instead be fixing the docs to match the code? Changing the code now may break existing implementations that have used the name in the current code. yes, i agree with you, i give a v2 patch, but i don't know how to change the doc in http://libvirt.org. libvirt.org autogenerates from the latest libvirt.git, at least once an hour. https://www.redhat.com/archives/libvir-list/2014-November/msg00209.html So once that message is committed, the web page will auto-update. And this patch is for the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1161358 Then mention that in the commit message :) -- 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] [v2 PATCH] doc: Fix a mismatch attribute name
On 11/07/2014 10:35 AM, Luyao Huang wrote: From virAccessDriverPolkitCheckInterface function, we know this attribute should named: interface_macaddr Signed-off-by: Luyao Huang lhu...@redhat.com --- docs/aclpolkit.html.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ACK. I modified the commit message to point to the BZ (https://bugzilla.redhat.com/show_bug.cgi?id=1161358) and pushed. diff --git a/docs/aclpolkit.html.in b/docs/aclpolkit.html.in index 91b5296..e5a9b16 100644 --- a/docs/aclpolkit.html.in +++ b/docs/aclpolkit.html.in @@ -121,7 +121,7 @@ tdName of the network interface, unique to the local host/td /tr tr - tdinterface_mac/td + tdinterface_macaddr/td tdMAC address of the network interface, not unique/td /tr /tbody -- 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] [v2 PATCH] doc: Fix a mismatch attribute name
On 11/07/2014 10:47 AM, Eric Blake wrote: On 11/07/2014 10:35 AM, Luyao Huang wrote: From virAccessDriverPolkitCheckInterface function, we know this attribute should named: interface_macaddr Eww. 'git am' strips an initial commit line beginning with From , if it doesn't match an email address (this is because it special cases a leading 'From: ...' or 'From: ...' line as overriding commit authorship instead of using the email's sender as the author). I didn't realize that I lost a line of your commit message until after I had pushed my modifications. In the future, try to avoid using From as the first word of a commit message. Based on the could serve as an appropriate substitute phrase for this case. -- 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 00/15] Cleanup some curly braces
On Thu, Nov 06, 2014 at 05:38:25PM +0100, Martin Kletzander wrote: There were unnecessary curly braces in few places (and the whole esx driver), so this series proposes fixing them. As this couldn't be done automatically, there is no syntax-check. We have to keep trying to eliminate that ;) How did you go about identifying these places that needed fixing ? I'm assunming you didn't do manual code inspection across everything. While I like the intent, I share Eric's concern about doing this without a syntax-check rule to prevent us re-introducing the problem 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] [PATCHv2 0/2] Fix snapshot-revert and managedsave with host-passthrough CPU mode
Ján Tomko (2): Use UPDATE_CPU when saving domain status Ignore missing CPU model for HOST_PASSTHROUGH src/conf/cpu_conf.c| 4 +- src/conf/domain_conf.c | 1 + ...argv-cpu-host-passthrough-features-invalid.args | 22 + ...2argv-cpu-host-passthrough-features-invalid.xml | 55 ++ tests/qemuxml2argvtest.c | 1 + 5 files changed, 81 insertions(+), 2 deletions(-) create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-host-passthrough-features-invalid.args create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cpu-host-passthrough-features-invalid.xml -- 2.0.4 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] Fix a mismatch attribute name
On 11/07/2014 05:45 PM, Eric Blake wrote: On 11/07/2014 10:37 AM, lhuang wrote: On 11/07/2014 05:15 PM, Eric Blake wrote: On 11/07/2014 09:24 AM, Luyao Huang wrote: From libvirt.org we know this attribute named: interface_macMAC address of the network interface, not unique Shouldn't we instead be fixing the docs to match the code? Changing the code now may break existing implementations that have used the name in the current code. yes, i agree with you, i give a v2 patch, but i don't know how to change the doc in http://libvirt.org. libvirt.org autogenerates from the latest libvirt.git, at least once an hour. https://www.redhat.com/archives/libvir-list/2014-November/msg00209.html So once that message is committed, the web page will auto-update. Oh, I see, thanks And this patch is for the bug: https://bugzilla.redhat.com/show_bug.cgi?id=1161358 Then mention that in the commit message :) Okay and thanks for push the patch :) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCHv2 2/2] Ignore missing CPU model for HOST_PASSTHROUGH
Accept a list of features for HOST_PASSTHROUGH even without
a model specified, to catch domains started with older libvirtd.
(We already accept the list of features with a model specified,
even though they have no effect for HOST_PASSTHROUGH)
https://bugzilla.redhat.com/show_bug.cgi?id=1030793
https://bugzilla.redhat.com/show_bug.cgi?id=1151885
---
src/conf/cpu_conf.c| 4 +-
...argv-cpu-host-passthrough-features-invalid.args | 22 +
...2argv-cpu-host-passthrough-features-invalid.xml | 55 ++
tests/qemuxml2argvtest.c | 1 +
4 files changed, 80 insertions(+), 2 deletions(-)
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-cpu-host-passthrough-features-invalid.args
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-cpu-host-passthrough-features-invalid.xml
diff --git a/src/conf/cpu_conf.c b/src/conf/cpu_conf.c
index 1c74c66..02b9bfc 100644
--- a/src/conf/cpu_conf.c
+++ b/src/conf/cpu_conf.c
@@ -365,7 +365,7 @@ virCPUDefParseXML(xmlNodePtr node,
goto error;
if (n 0) {
-if (!def-model def-mode != VIR_CPU_MODE_HOST_MODEL) {
+if (!def-model def-mode == VIR_CPU_MODE_CUSTOM) {
virReportError(VIR_ERR_XML_ERROR, %s,
_(Non-empty feature list specified without
CPU model));
@@ -626,7 +626,7 @@ virCPUDefFormatBuf(virBufferPtr buf,
(def-mode == VIR_CPU_MODE_CUSTOM def-model)));
if (!def-model
-def-mode != VIR_CPU_MODE_HOST_MODEL
+def-mode == VIR_CPU_MODE_CUSTOM
def-nfeatures) {
virReportError(VIR_ERR_INTERNAL_ERROR, %s,
_(Non-empty feature list specified without CPU
model));
diff --git
a/tests/qemuxml2argvdata/qemuxml2argv-cpu-host-passthrough-features-invalid.args
b/tests/qemuxml2argvdata/qemuxml2argv-cpu-host-passthrough-features-invalid.args
new file mode 100644
index 000..18c1dce
--- /dev/null
+++
b/tests/qemuxml2argvdata/qemuxml2argv-cpu-host-passthrough-features-invalid.args
@@ -0,0 +1,22 @@
+LC_ALL=C \
+PATH=/bin \
+HOME=/home/test \
+USER=test \
+LOGNAME=test \
+QEMU_AUD\
+IO_DRV=none \
+/usr/bin/qemu \
+-S \
+-M pc \
+-cpu host \
+-m 214 \
+-smp 1 \
+-nographic \
+-monitor unix:/tmp/test-monitor,server,nowait \
+-no-acpi \
+-boot c \
+-usb \
+-hda /dev/HostVG/QEMUGuest1 \
+-net none \
+-serial none \
+-parallel none
diff --git
a/tests/qemuxml2argvdata/qemuxml2argv-cpu-host-passthrough-features-invalid.xml
b/tests/qemuxml2argvdata/qemuxml2argv-cpu-host-passthrough-features-invalid.xml
new file mode 100644
index 000..b5f5326
--- /dev/null
+++
b/tests/qemuxml2argvdata/qemuxml2argv-cpu-host-passthrough-features-invalid.xml
@@ -0,0 +1,55 @@
+domain type='kvm'
+ nameQEMUGuest1/name
+ uuidc7a5fdbd-edaf-9455-926a-d65c16db1809/uuid
+ titleA description of the test machine./title
+ description
+ A test of qemuapos;s minimal configuration.
+ This test also tests the description and title elements.
+ /description
+ memory unit='KiB'219100/memory
+ currentMemory unit='KiB'219100/currentMemory
+ vcpu placement='static' cpuset='1-4,8-20,525'1/vcpu
+ os
+type arch='i686' machine='pc'hvm/type
+boot dev='hd'/
+ /os
+ cpu mode='host-passthrough'
+feature policy='require' name='abm'/
+feature policy='require' name='pdpe1gb'/
+feature policy='require' name='rdrand'/
+feature policy='require' name='f16c'/
+feature policy='require' name='osxsave'/
+feature policy='require' name='pdcm'/
+feature policy='require' name='xtpr'/
+feature policy='require' name='tm2'/
+feature policy='require' name='est'/
+feature policy='require' name='smx'/
+feature policy='require' name='vmx'/
+feature policy='require' name='ds_cpl'/
+feature policy='require' name='monitor'/
+feature policy='require' name='dtes64'/
+feature policy='require' name='pbe'/
+feature policy='require' name='tm'/
+feature policy='require' name='ht'/
+feature policy='require' name='ss'/
+feature policy='require' name='acpi'/
+feature policy='require' name='ds'/
+feature policy='require' name='vme'/
+ /cpu
+ clock offset='utc'/
+ on_poweroffdestroy/on_poweroff
+ on_rebootrestart/on_reboot
+ on_crashdestroy/on_crash
+ devices
+emulator/usr/bin/qemu/emulator
+disk type='block' device='disk'
+ source dev='/dev/HostVG/QEMUGuest1'/
+ target dev='hda' bus='ide'/
+ address type='drive' controller='0' bus='0' target='0' unit='0'/
+/disk
+controller type='usb' index='0'/
+controller type='ide' index='0'/
+controller type='pci' index='0' model='pci-root'/
+memballoon model='virtio'/
+ /devices
+/domain
diff --git a/tests/qemuxml2argvtest.c b/tests/qemuxml2argvtest.c
index fe58a24..00a0cbf 100644
--- a/tests/qemuxml2argvtest.c
+++ b/tests/qemuxml2argvtest.c
@@ -1481,6 +1481,7 @@ mymain(void)
[libvirt] [PATCHv2 1/2] Use UPDATE_CPU when saving domain status
We only format cpu model for MODE_CUSTOM in domain status XML,
but we always format features if they are present.
This is a problem if we have a domain using MODE_HOST_PASSTHROUGH
that has been managedsaved, then restored, since it now has
a feature list but no model in /var/run/libvirt/qemu.
Use UPDATE_CPU even for the status XML to prevent libvirt
from losing track of the domain.
https://bugzilla.redhat.com/show_bug.cgi?id=1030793
https://bugzilla.redhat.com/show_bug.cgi?id=1151885
---
src/conf/domain_conf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 21309b0..acfb04b 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -19625,6 +19625,7 @@ virDomainSaveStatus(virDomainXMLOptionPtr xmlopt,
virDomainObjPtr obj)
{
unsigned int flags = (VIR_DOMAIN_XML_SECURE |
+ VIR_DOMAIN_XML_UPDATE_CPU |
VIR_DOMAIN_XML_INTERNAL_STATUS |
VIR_DOMAIN_XML_INTERNAL_ACTUAL_NET |
VIR_DOMAIN_XML_INTERNAL_PCI_ORIG_STATES |
--
2.0.4
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [v2 PATCH] doc: Fix a mismatch attribute name
On 11/07/2014 05:53 PM, Eric Blake wrote: On 11/07/2014 10:47 AM, Eric Blake wrote: On 11/07/2014 10:35 AM, Luyao Huang wrote: From virAccessDriverPolkitCheckInterface function, we know this attribute should named: interface_macaddr Eww. 'git am' strips an initial commit line beginning with From , if it doesn't match an email address (this is because it special cases a leading 'From: ...' or 'From: ...' line as overriding commit authorship instead of using the email's sender as the author). I didn't realize that I lost a line of your commit message until after I had pushed my modifications. In the future, try to avoid using From as the first word of a commit message. Based on the could serve as an appropriate substitute phrase for this case. So interesting :) i didn't notice this before.I will change my word next time, thanks your advice. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 02/15] Remove unneeded curly brackets around oneline code blocks in src/conf/
On 11/06/2014 05:38 PM, Martin Kletzander wrote:
As stated in our contributor guidelines, we don't want curly brackets
around oneline code block (with some exceptions).
Signed-off-by: Martin Kletzander mklet...@redhat.com
---
+++ b/src/conf/capabilities.c
@@ -219,9 +219,8 @@ virCapabilitiesDispose(void *object)
VIR_FREE(caps-host.migrateTrans[i]);
VIR_FREE(caps-host.migrateTrans);
-for (i = 0; i caps-host.nsecModels; i++) {
+for (i = 0; i caps-host.nsecModels; i++)
virCapabilitiesClearSecModel(caps-host.secModels[i]);
-}
Conversions like this make sense...
@@ -138,9 +138,9 @@ virDevicePCIAddressEqual(virDevicePCIAddress *addr1,
if (addr1-domain == addr2-domain
addr1-bus == addr2-bus
addr1-slot == addr2-slot
-addr1-function == addr2-function) {
+addr1-function == addr2-function)
return true;
-}
Conversions like this are a little harder to read (that is, any time the
'if' condition extends over multiple lines, but there is exactly four
space indentation of the condition, it's visually hard to see where the
multi-line condition ends and the loop body begins). The opening { is
hard to see either way, but seeing the closing } is my visual clue that
yes, the last line of this blob of code is not part of the 'if' but the
one-line body. I'm not opposed to your removal of {}, but wonder if we
should rethink our style to recommend keeping the {} if the 'if'
expression is multiline.
Besides, it is easier to write a syntax check that checks for one-line
'if' expressions (that's how I wrote my checks for mis-matched if{}else;
and if;else{}) than it is for multi-line if expressions. So
distinguishing between the two types may make it easier to write a
syntax check and enforce a consistent style.
@@ -3762,23 +3759,22 @@ virDomainDeviceInfoParseXML(xmlNodePtr node,
if (cur-type == XML_ELEMENT_NODE) {
if (alias == NULL
!(flags VIR_DOMAIN_XML_INACTIVE)
-xmlStrEqual(cur-name, BAD_CAST alias)) {
+xmlStrEqual(cur-name, BAD_CAST alias))
alias = cur;
This one is multi-line with no indentation to help...
-} else if (address == NULL
- xmlStrEqual(cur-name, BAD_CAST address)) {
+else if (address == NULL
+ xmlStrEqual(cur-name, BAD_CAST address))
address = cur;
...while this one has indentation help because of the 'else if'; see the
difference in spotting the one-line statement?
@@ -6879,9 +6870,8 @@ virDomainActualNetDefParseXML(xmlNodePtr node,
if (!(actual-virtPortProfile
= virNetDevVPortProfileParse(virtPortNode,
VIR_VPORT_XML_REQUIRE_ALL_ATTRIBUTES |
- VIR_VPORT_XML_REQUIRE_TYPE)))
{
+ VIR_VPORT_XML_REQUIRE_TYPE)))
goto error;
-}
And this is an example of a multi-line 'if' expression, but it is
indented (both because the '=' is split over lines, and because the last
part of the expression is a function call split over lines), so the
one-liner is easy to spot here.
But my earlier claim that one-liner 'if' expressions are easier to grep
for than multi-line 'if' may mean that a syntax check would not flag
this one as a place to remove the {}. Maybe it doesn't matter.
(Ideally, if we could figure out how to make GNU indent or some other
code prettifier enforce a style, we'd use that instead of syntax check
grep rules).
So, I'm welcome to other opinions...
--
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 02/15] Remove unneeded curly brackets around oneline code blocks in src/conf/
On Fri, Nov 07, 2014 at 11:09:11AM +0100, Eric Blake wrote:
On 11/06/2014 05:38 PM, Martin Kletzander wrote:
As stated in our contributor guidelines, we don't want curly brackets
around oneline code block (with some exceptions).
Signed-off-by: Martin Kletzander mklet...@redhat.com
---
+++ b/src/conf/capabilities.c
@@ -219,9 +219,8 @@ virCapabilitiesDispose(void *object)
VIR_FREE(caps-host.migrateTrans[i]);
VIR_FREE(caps-host.migrateTrans);
-for (i = 0; i caps-host.nsecModels; i++) {
+for (i = 0; i caps-host.nsecModels; i++)
virCapabilitiesClearSecModel(caps-host.secModels[i]);
-}
Conversions like this make sense...
@@ -138,9 +138,9 @@ virDevicePCIAddressEqual(virDevicePCIAddress *addr1,
if (addr1-domain == addr2-domain
addr1-bus == addr2-bus
addr1-slot == addr2-slot
-addr1-function == addr2-function) {
+addr1-function == addr2-function)
return true;
-}
Conversions like this are a little harder to read (that is, any time the
'if' condition extends over multiple lines, but there is exactly four
space indentation of the condition, it's visually hard to see where the
multi-line condition ends and the loop body begins). The opening { is
hard to see either way, but seeing the closing } is my visual clue that
yes, the last line of this blob of code is not part of the 'if' but the
one-line body. I'm not opposed to your removal of {}, but wonder if we
should rethink our style to recommend keeping the {} if the 'if'
expression is multiline.
Besides, it is easier to write a syntax check that checks for one-line
'if' expressions (that's how I wrote my checks for mis-matched if{}else;
and if;else{}) than it is for multi-line if expressions. So
distinguishing between the two types may make it easier to write a
syntax check and enforce a consistent style.
@@ -3762,23 +3759,22 @@ virDomainDeviceInfoParseXML(xmlNodePtr node,
if (cur-type == XML_ELEMENT_NODE) {
if (alias == NULL
!(flags VIR_DOMAIN_XML_INACTIVE)
-xmlStrEqual(cur-name, BAD_CAST alias)) {
+xmlStrEqual(cur-name, BAD_CAST alias))
alias = cur;
This one is multi-line with no indentation to help...
-} else if (address == NULL
- xmlStrEqual(cur-name, BAD_CAST address)) {
+else if (address == NULL
+ xmlStrEqual(cur-name, BAD_CAST address))
address = cur;
...while this one has indentation help because of the 'else if'; see the
difference in spotting the one-line statement?
@@ -6879,9 +6870,8 @@ virDomainActualNetDefParseXML(xmlNodePtr node,
if (!(actual-virtPortProfile
= virNetDevVPortProfileParse(virtPortNode,
VIR_VPORT_XML_REQUIRE_ALL_ATTRIBUTES |
-
VIR_VPORT_XML_REQUIRE_TYPE))) {
+
VIR_VPORT_XML_REQUIRE_TYPE)))
goto error;
-}
And this is an example of a multi-line 'if' expression, but it is
indented (both because the '=' is split over lines, and because the last
part of the expression is a function call split over lines), so the
one-liner is easy to spot here.
But my earlier claim that one-liner 'if' expressions are easier to grep
for than multi-line 'if' may mean that a syntax check would not flag
this one as a place to remove the {}. Maybe it doesn't matter.
(Ideally, if we could figure out how to make GNU indent or some other
code prettifier enforce a style, we'd use that instead of syntax check
grep rules).
Yeah, I'd really like to be able to run something like GNU indent over
the code and check input==output, but there were a couple of rules in
our coding style that indent didn't appear to support
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] [PATCH] nodeinfo: report error when failure in nodeSetMemoryParameters
nodeSetMemoryParameters() will call nodeSetMemoryParameterValue()
to set parameters. But it just filter the return code '-2' as
failure. Indeed we should report error when rc is negative.
https://bugzilla.redhat.com/show_bug.cgi?id=1161541
Signed-off-by: Jincheng Miao jm...@redhat.com
---
src/nodeinfo.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/nodeinfo.c b/src/nodeinfo.c
index 2e2fffa..3c22ebc 100644
--- a/src/nodeinfo.c
+++ b/src/nodeinfo.c
@@ -1374,8 +1374,7 @@ nodeSetMemoryParameters(virTypedParameterPtr params
ATTRIBUTE_UNUSED,
for (i = 0; i nparams; i++) {
rc = nodeSetMemoryParameterValue(params[i]);
-/* Out of memory */
-if (rc == -2)
+if (rc 0)
return -1;
}
--
1.7.1
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH v2] Memory : Allow specification of 'units' for numa nodes.
Reference :
===
v1: http://www.spinics.net/linux/fedora/libvir/msg105516.html
Changes since v1:
===
1) As suggested by Michal, a new function virCPUNumaCellMemoryParseXML has
been introduced for neat computation of NUMA memory.
2) Patches 2 3 of v1 have been merged together into this cumulative patch.
3) Corresponding documentation added.
From 2199d97b88cf9eab29788fb0e440c4b0a0bb23ec Mon Sep 17 00:00:00 2001
From: Prerna Saxena pre...@linux.vnet.ibm.com
Date: Mon, 3 Nov 2014 07:53:59 +0530
CPU numa topology implicitly allows memory specification in 'KiB'.
Enabling this to accept the 'unit' in which memory needs to be specified.
This now allows users to specify memory in units of choice, and
lists the same in 'KiB' -- just like other 'memory' elements in XML.
numa
cell cpus='0-3' memory='1024' unit='MiB' /
cell cpus='4-7' memory='1024' unit='MiB' /
/numa
Also augment test cases to correctly model NUMA memory specification.
This adds the tag 'unit=KiB' for memory attribute in NUMA cells.
Signed-off-by: Prerna Saxena pre...@linux.vnet.ibm.com
---
docs/formatdomain.html.in | 6 ++-
docs/schemas/domaincommon.rng | 5 ++
src/conf/cpu_conf.c| 62 --
.../qemuxml2argv-cpu-numa-disjoint.xml | 4 +-
.../qemuxml2argv-cpu-numa-memshared.xml| 4 +-
tests/qemuxml2argvdata/qemuxml2argv-cpu-numa1.xml | 4 +-
tests/qemuxml2argvdata/qemuxml2argv-cpu-numa2.xml | 4 +-
tests/qemuxml2argvdata/qemuxml2argv-cpu-numa3.xml | 4 +-
.../qemuxml2argv-hugepages-pages.xml | 8 +--
.../qemuxml2argv-hugepages-pages2.xml | 4 +-
.../qemuxml2argv-hugepages-pages3.xml | 4 +-
.../qemuxml2argv-hugepages-pages4.xml | 8 +--
.../qemuxml2argv-hugepages-shared.xml | 8 +--
.../qemuxml2argv-numatune-auto-prefer.xml | 2 +-
.../qemuxml2argv-numatune-memnode-no-memory.xml| 4 +-
.../qemuxml2argv-numatune-memnode.xml | 6 +--
.../qemuxml2argv-numatune-memnodes-problematic.xml | 4 +-
.../qemuxml2xmlout-cpu-numa1.xml | 4 +-
.../qemuxml2xmlout-cpu-numa2.xml | 4 +-
.../qemuxml2xmlout-numatune-auto-prefer.xml| 2 +-
.../qemuxml2xmlout-numatune-memnode.xml| 6 +--
21 files changed, 97 insertions(+), 60 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 0099ce7..24afc87 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1140,8 +1140,8 @@
lt;cpugt;
...
lt;numagt;
- lt;cell id='0' cpus='0-3' memory='512000'/gt;
- lt;cell id='1' cpus='4-7' memory='512000' memAccess='shared'/gt;
+ lt;cell id='0' cpus='0-3' memory='512000' unit='KiB'/gt;
+ lt;cell id='1' cpus='4-7' memory='512000' unit='KiB'
memAccess='shared'/gt;
lt;/numagt;
...
lt;/cpugt;
@@ -1152,6 +1152,8 @@
codecpus/code specifies the CPU or range of CPUs that are
part of the node. codememory/code specifies the node memory
in kibibytes (i.e. blocks of 1024 bytes).
+ span class=sinceSince 1.2.11/span one can specify an additional
+ codeunit/code attribute to describe the node memory unit.
span class=sinceSince 1.2.7/span all cells should
have codeid/code attribute in case referring to some cell is
necessary in the code, otherwise the cells are
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 20d81ae..44cabad 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -4144,6 +4144,11 @@
ref name=memoryKB/
/attribute
optional
+attribute name=unit
+ ref name=unit/
+/attribute
+ /optional
+ optional
attribute name=memAccess
choice
valueshared/value
diff --git a/src/conf/cpu_conf.c b/src/conf/cpu_conf.c
index 5475c07..a0a60c8 100644
--- a/src/conf/cpu_conf.c
+++ b/src/conf/cpu_conf.c
@@ -177,6 +177,48 @@ virCPUDefCopy(const virCPUDef *cpu)
return NULL;
}
+static int
+virCPUNumaCellMemoryParseXML(xmlNodePtr node,
+ xmlXPathContextPtr ctxt,
+ unsigned long long* cellMemory)
+{
+int ret = -1;
+xmlNodePtr oldnode = ctxt-node;
+unsigned long long bytes, max;
+char *unit = NULL;
+
+ctxt-node = node;
+
+/* 32 vs 64 bit will differ in value of upper memory bound.
+ * On 32-bit machines, our bound is 0x * KiB. On 64-bit
+ * machines, our bound is off_t (2^63).
+ */
+if (sizeof(unsigned long) sizeof(long long))
+max = 1024ull * ULONG_MAX;
+else
+max = LLONG_MAX;
+
+if (virXPathULongLong(string(./@memory), ctxt, bytes) 0) {
+virReportError(VIR_ERR_XML_DETAIL, %s,
+ _(unable to parse memory size attribute));
+goto cleanup;
+}
+
+unit =
Re: [libvirt] [PATCH] qemu: don't setup cpuset.mems if memory mode in numatune is 'preferred'
On Fri, Nov 07, 2014 at 05:36:43PM +0800, Wang Rui wrote:
On 2014/11/5 16:07, Martin Kletzander wrote:
[...]
diff --git a/src/qemu/qemu_cgroup.c b/src/qemu/qemu_cgroup.c
index b5bdb36..8685d6f 100644
--- a/src/qemu/qemu_cgroup.c
+++ b/src/qemu/qemu_cgroup.c
@@ -618,6 +618,11 @@ qemuSetupCpusetMems(virDomainObjPtr vm,
if (!virCgroupHasController(priv-cgroup, VIR_CGROUP_CONTROLLER_CPUSET))
return 0;
+if (virDomainNumatuneGetMode(vm-def-numatune, -1) !=
+VIR_DOMAIN_NUMATUNE_MEM_STRICT) {
+return 0;
+}
+
One question, is it problem only for 'preferred' or 'interleaved' as
well? Because if it's only problem for 'preferred', then the check is
wrong. If it's problem for 'interleaved' as well, then the commit
message is wrong.
'interleave' with a single node(such as nodeset='0') will cause the same error.
But 'interleave' mode should not live with a single node. So maybe there's
another bugfix to check 'interleave' with single node.
Well, I'd be OK with just changing the commit message to mention that.
This fix is still a valid one and will fix both issues, won't it?
If configured with 'interleave' and multiple nodes(such as nodeset='0-1'),
VM can be started successfully. And cpuset.mems is set to the same nodeset.
So I'll revise my patch.
I'll send patches V2. Conclusion:
1/3 : add check for 'interleave' mode with single numa node
2/3 : fix this problem in qemu
3/3 : fix this problem in lxc
Is it OK?
Anyway, after either one is fixed, I can push this.
I tested this problem again and found that this error occurred with each
memory mode. It is broke by commit 411cea638f6ec8503b7142a31e58b1cd85dbeaba
which is produced by me.
qemu: move setting emulatorpin ahead of monitor showing up
I'm sorry for that.
That patch moved qemuSetupCgroupForEmulator before qemuSetupCgroupPostInit.
I have ideas to fix that.
1. Move qemuSetupCgroupPostInit ahead of monitor showing up, too.
Of course it's before qemuSetupCgroupForEmulator.
This action to fix the bug which is introduced by me.
(RFC)
That cannot be done, IIRC, because we need monitor to get the
vCPU - thread mapping from it.
2. Anyway the first problem is fixed, I have found the second problem which
is I wanted to fix originally. If memory mode is 'preferred' and with
one node (such as nodeset='0'), domain's memory is not in node 0
absolutely. Assumption that node 0 doesn't have enough memory, memory
can be allocated on node 1. Then if we set cpuset.mems to '0', it may
cause OOM.
The solution is checking memory mode in (lxc)qemuSetupCpusetMems as my
patch on Tuesday. Such as
+if (virDomainNumatuneGetMode(vm-def-numatune, -1) !=
+VIR_DOMAIN_NUMATUNE_MEM_PREFERRED) {
Either this (as it makes sense to restrict qemu even for 'interleave'
or the previous check is fine too (just because that was what we did
before, I just rewrote it with few problems.
BTW:
3. After the first problem has been fixed, we can start domains with xml:
numatune
memory mode='interleave' nodeset='0'/
/numatune
Is a single node '0' valid for 'interleave' ? I take 'interleave' as
'at least two nodes'.
Well, interleave of 1 node is effectively 'strict', isn't it? What
errors do you get if you try that? (my kernel stopped accepting
numa=fake=2 as a cmdline parameter :( )
Anyway, I think the best way would be mimicking the old behaviour by
just adding your first proposed fix if (mode != STRICT) return 0,
just fit the fixed up comit message.
Martin
signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 01/15] vbox: Remove useless condition branches
On Fri, Nov 07, 2014 at 10:43:47AM +0100, Eric Blake wrote: On 11/06/2014 05:38 PM, Martin Kletzander wrote: These were probably left there after some code movement. Signed-off-by: Martin Kletzander mklet...@redhat.com --- src/vbox/vbox_common.c | 23 ++- 1 file changed, 6 insertions(+), 17 deletions(-) ACK to this one, regardless of the fate of the rest of the series. I pushed this one only, we'll see about the rest. Martin signature.asc Description: Digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v6 0/7] qemu: Introduce support for new the block_set_io_throttle parameters add in the version 1.7 of qemu.
On Wed, Oct 29, 2014 at 1:15 PM, Matthias Gatto matthias.ga...@outscale.com wrote: This series of patches add support for bps_max, bps_rd_max, bps_wr_max, bps_max, bps_rd_max, bps_wr_max, and iops_size in the functions qemuDomainSetBlockIoTune and qemuDomainGetBlockIoTune. The last patch add support for these parameters to the virsh blkdeviotune command. v2: -Spellfix v3: -Merge patch 1/9,2/9,5/9 together. -Change the capability detection.(patch 2/7 and 3/7). -Try to make the usage of QEMU_NB_BLOCK_IO_TUNE_PARAM_MAX more explicit(patch 3/7). v4: -Rebase on HEAD. -Update qemu_driver to comply with Pavel's patchs.(patch 3/6) -Remove the qemu_monitor_text modification.(remove old patch 5/7) v5: -Split patch 1/6 in two. -Add documentation for the new xml options (patch 2/7) -Change (void) to ATTRIBUTE_UNUSED (patch 4/7) -Capability detection of supportMaxOptions move before usage of supportMaxOptions (patch 4/7) v6: -Spellfix -Add comment (patch 4/7, 5/7) -Undo the modification of the supportMaxOptions made in the v5 because it was creating bugs(patch 4/5) The 2 first patches have been reviewed by Eric Blake and sould be merge soon The 3rd patch have been reviewed by Michal Privoznik and ack Matthias Gatto (7): qemu: Add define for the new throttle options qemu: Modify the structure _virDomainBlockIoTuneInfo. qemu: Add Qemu capability for bps_max and friends qemu: Add bps_max and friends qemu driver qemu: Add bps_max and friends QMP suport qemu: Add bps_max and friends to qemu command generation virsh: Add bps_max and friends to virsh docs/formatdomain.html.in| 25 docs/schemas/domaincommon.rng| 43 ++ include/libvirt/libvirt-domain.h | 110 src/conf/domain_conf.c | 109 +++- src/conf/domain_conf.h | 7 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 57 +++- src/qemu/qemu_driver.c | 187 ++- src/qemu/qemu_monitor.c | 10 +- src/qemu/qemu_monitor.h | 6 +- src/qemu/qemu_monitor_json.c | 66 -- src/qemu/qemu_monitor_json.h | 6 +- tests/qemucapabilitiesdata/caps_2.1.1-1.caps | 1 + tests/qemumonitorjsontest.c | 6 +- tools/virsh-domain.c | 119 + tools/virsh.pod | 10 ++ 17 files changed, 732 insertions(+), 33 deletions(-) -- 1.8.3.1 ping -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] How do I get the progress of a long operation
Dear Libvirt: How do I get the progress of a long operation (such as Snapshot take and recover )through libvirt API? Thankyou.-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] How do I get the progress of a long operation
On 11/07/2014 02:24 PM, windy wrote: Dear Libvirt: How do I get the progress of a long operation (such as Snapshot take and recover )through libvirt API? virsh exists as a sample of how to do this for several long-running APIs. Some APIs are (currently) blocking-only; for those, you have to have a second thread/process open a second connection to the hypervisor to track ongoing progress (see how 'virsh migrate --verbose' does this). Others are asynchronous by default, and require you to poll or wait for an event for the end of the operation; so a single thread can also query state in the middle of the operation (see how 'virsh blockpull --wait --verbose' works). And for some APIs, we just haven't yet implemented job reporting and status of those jobs (sadly; 'virsh vol-download' is an example of this); patches are welcome to help us improve these interfaces to use a more generic job handling mechanism that can let us run multiple jobs in parallel. -- 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] is there a notification when watchdog triggers?
On 11/07/2014 03:14 AM, Eric Blake wrote: On 11/06/2014 11:08 PM, Chris Friesen wrote: The libvirt.org docs say A virtual hardware watchdog device can be added to the guest via the watchdog elementCurrently libvirt does not support notification when the watchdog fires. This feature is planned for a future version of libvirt. Is that still accurate? Or does libvirt now support notifications? It looks outdated, as we have VIR_DOMAIN_EVENT_ID_WATCHDOG as the way to receive notification of a watchdog event in the guest: http://libvirt.org/html/libvirt-libvirt-domain.html#virDomainEventWatchdogAction http://libvirt.org/html/libvirt-libvirt-domain.html#virConnectDomainEventWatchdogCallback Which URL had the outdated information, so we can fix it? http://libvirt.org/formatdomain.html#elementsWatchdog It's also in the draft Fedora docs: http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/Virtualization_Deployment_and_Administration_Guide/index.html Chris -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] domain_conf: Use virDomainParseMemory more widely
As reviewing patches upstream it occurred to me, that we have two
functions doing nearly the same: virDomainParseMemory which
expects XML in the following format:
memory unit='MiB'1337/memory
The other function being virDomainHugepagesParseXML expecting the
following format:
someElement memory='1337' unit='MiB'/
It wouldn't matter to have two functions handle two different
scenarios like this if we could only not copy code that handles
32bit arches around. So this code merges the common parts into
one by inventing new @units_xpath argument to
virDomainParseMemory which allows overriding the default location
of @unit attribute in XML. With this change both scenarios above
can be parsed with virDomainParseMemory. Sweet. Of course,
everything is commented as it should be.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
src/conf/domain_conf.c | 137 +
1 file changed, 80 insertions(+), 57 deletions(-)
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index 21309b0..e097af7 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -6318,14 +6318,30 @@ virDomainDiskDefParseXML(virDomainXMLOptionPtr xmlopt,
goto cleanup;
}
-
-/* Parse a value located at XPATH within CTXT, and store the
- * result into val. If REQUIRED, then the value must exist;
- * otherwise, the value is optional. The value is in bytes.
- * Return 1 on success, 0 if the value was not present and
- * is not REQUIRED, -1 on failure after issuing error. */
+/**
+ * virDomainParseScaledValue:
+ * @bytes_xpath: XPath to memory amount
+ * @units_xpath: XPath to units attribute
+ * @ctxt: XPath context
+ * @val: scaled value is stored here
+ * @scale: default scale for @val
+ * @max: maximal @val allowed
+ * @required: is the value required?
+ *
+ * Parse a value located at @bytes_xpath within @ctxt, and store
+ * the result into @val. By default, if @units_xpath is NULL the
+ * unit attribute must be an attribute to @bytes_xpath.
+ * Otherwise, the unit attribute is looked for under specified
+ * path. If @required is set, then the value must exist;
+ * otherwise, the value is optional. The value is in bytes.
+ *
+ * Returns 1 on success,
+ * 0 if the value was not present and !@required,
+ * -1 on failure after issuing error.
+ */
static int
-virDomainParseScaledValue(const char *xpath,
+virDomainParseScaledValue(const char *bytes_xpath,
+ const char *units_xpath,
xmlXPathContextPtr ctxt,
unsigned long long *val,
unsigned long long scale,
@@ -6339,7 +6355,7 @@ virDomainParseScaledValue(const char *xpath,
unsigned long long bytes;
*val = 0;
-if (virAsprintf(xpath_full, string(%s), xpath) 0)
+if (virAsprintf(xpath_full, string(%s), bytes_xpath) 0)
goto cleanup;
bytes_str = virXPathString(xpath_full, ctxt);
@@ -6348,8 +6364,8 @@ virDomainParseScaledValue(const char *xpath,
ret = 0;
} else {
virReportError(VIR_ERR_XML_ERROR,
- _(missing element %s),
- xpath);
+ _(missing element or attribute '%s'),
+ bytes_xpath);
}
goto cleanup;
}
@@ -6357,12 +6373,15 @@ virDomainParseScaledValue(const char *xpath,
if (virStrToLong_ullp(bytes_str, NULL, 10, bytes) 0) {
virReportError(VIR_ERR_XML_ERROR,
- _(Invalid value '%s' for element '%s'),
- bytes_str, xpath);
+ _(Invalid value '%s' for element or attribute '%s'),
+ bytes_str, bytes_xpath);
goto cleanup;
}
-if (virAsprintf(xpath_full, string(%s/@unit), xpath) 0)
+if ((units_xpath
+ virAsprintf(xpath_full, string(%s), units_xpath) 0) ||
+(!units_xpath
+ virAsprintf(xpath_full, string(%s/@unit), bytes_xpath) 0))
goto cleanup;
unit = virXPathString(xpath_full, ctxt);
@@ -6379,17 +6398,35 @@ virDomainParseScaledValue(const char *xpath,
}
-/* Parse a memory element located at XPATH within CTXT, and store the
- * result into MEM, in blocks of 1024. If REQUIRED, then the value
- * must exist; otherwise, the value is optional. The value must not
- * exceed VIR_DOMAIN_MEMORY_PARAM_UNLIMITED once scaled; additionally,
- * if CAPPED is true, the value must fit within an unsigned long (only
- * matters on 32-bit platforms).
+/**
+ * virDomainParseMemory:
+ * @bytes_xpath: XPath to memory amount
+ * @units_xpath: XPath to units attribute
+ * @ctxt: XPath context
+ * @mem: scaled memory amount is stored here
+ * @required: whether value is required
+ * @capped: whether scaled value must fit within unsigned long
*
- * Return 0 on success, -1 on failure after issuing error. */
+ * Parse a memory element or attribute located at
Re: [libvirt] [PATCH 02/15] Remove unneeded curly brackets around oneline code blocks in src/conf/
On 11/07/2014 05:09 AM, Eric Blake wrote:
On 11/06/2014 05:38 PM, Martin Kletzander wrote:
@@ -138,9 +138,9 @@ virDevicePCIAddressEqual(virDevicePCIAddress *addr1,
if (addr1-domain == addr2-domain
addr1-bus == addr2-bus
addr1-slot == addr2-slot
-addr1-function == addr2-function) {
+addr1-function == addr2-function)
return true;
-}
Conversions like this are a little harder to read (that is, any time the
'if' condition extends over multiple lines, but there is exactly four
space indentation of the condition, it's visually hard to see where the
multi-line condition ends and the loop body begins). The opening { is
hard to see either way, but seeing the closing } is my visual clue that
yes, the last line of this blob of code is not part of the 'if' but the
one-line body. I'm not opposed to your removal of {}, but wonder if we
should rethink our style to recommend keeping the {} if the 'if'
expression is multiline.
I've always thought this, and used to do it that way until a few
reviewers complained. So I for one would welcome our new use braces if
condition is multiple lines overlords :-)
(I also agree that this is all an exercise in futility unless there is a
matching syntax-check rule to enforce it.)
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v2] Memory : Allow specification of 'units' for numa nodes.
On 07.11.2014 12:17, Prerna Saxena wrote:
Reference :
===
v1: http://www.spinics.net/linux/fedora/libvir/msg105516.html
Changes since v1:
===
1) As suggested by Michal, a new function virCPUNumaCellMemoryParseXML has
been introduced for neat computation of NUMA memory.
2) Patches 2 3 of v1 have been merged together into this cumulative patch.
3) Corresponding documentation added.
From 2199d97b88cf9eab29788fb0e440c4b0a0bb23ec Mon Sep 17 00:00:00 2001
From: Prerna Saxena pre...@linux.vnet.ibm.com
Date: Mon, 3 Nov 2014 07:53:59 +0530
CPU numa topology implicitly allows memory specification in 'KiB'.
Enabling this to accept the 'unit' in which memory needs to be specified.
This now allows users to specify memory in units of choice, and
lists the same in 'KiB' -- just like other 'memory' elements in XML.
numa
cell cpus='0-3' memory='1024' unit='MiB' /
cell cpus='4-7' memory='1024' unit='MiB' /
/numa
Also augment test cases to correctly model NUMA memory specification.
This adds the tag 'unit=KiB' for memory attribute in NUMA cells.
Signed-off-by: Prerna Saxena pre...@linux.vnet.ibm.com
---
docs/formatdomain.html.in | 6 ++-
docs/schemas/domaincommon.rng | 5 ++
src/conf/cpu_conf.c| 62 --
.../qemuxml2argv-cpu-numa-disjoint.xml | 4 +-
.../qemuxml2argv-cpu-numa-memshared.xml| 4 +-
tests/qemuxml2argvdata/qemuxml2argv-cpu-numa1.xml | 4 +-
tests/qemuxml2argvdata/qemuxml2argv-cpu-numa2.xml | 4 +-
tests/qemuxml2argvdata/qemuxml2argv-cpu-numa3.xml | 4 +-
.../qemuxml2argv-hugepages-pages.xml | 8 +--
.../qemuxml2argv-hugepages-pages2.xml | 4 +-
.../qemuxml2argv-hugepages-pages3.xml | 4 +-
.../qemuxml2argv-hugepages-pages4.xml | 8 +--
.../qemuxml2argv-hugepages-shared.xml | 8 +--
.../qemuxml2argv-numatune-auto-prefer.xml | 2 +-
.../qemuxml2argv-numatune-memnode-no-memory.xml| 4 +-
.../qemuxml2argv-numatune-memnode.xml | 6 +--
.../qemuxml2argv-numatune-memnodes-problematic.xml | 4 +-
.../qemuxml2xmlout-cpu-numa1.xml | 4 +-
.../qemuxml2xmlout-cpu-numa2.xml | 4 +-
.../qemuxml2xmlout-numatune-auto-prefer.xml| 2 +-
.../qemuxml2xmlout-numatune-memnode.xml| 6 +--
21 files changed, 97 insertions(+), 60 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in
index 0099ce7..24afc87 100644
--- a/docs/formatdomain.html.in
+++ b/docs/formatdomain.html.in
@@ -1140,8 +1140,8 @@
lt;cpugt;
...
lt;numagt;
- lt;cell id='0' cpus='0-3' memory='512000'/gt;
- lt;cell id='1' cpus='4-7' memory='512000' memAccess='shared'/gt;
+ lt;cell id='0' cpus='0-3' memory='512000' unit='KiB'/gt;
+ lt;cell id='1' cpus='4-7' memory='512000' unit='KiB'
memAccess='shared'/gt;
lt;/numagt;
...
lt;/cpugt;
@@ -1152,6 +1152,8 @@
codecpus/code specifies the CPU or range of CPUs that are
part of the node. codememory/code specifies the node memory
in kibibytes (i.e. blocks of 1024 bytes).
+ span class=sinceSince 1.2.11/span one can specify an additional
+ codeunit/code attribute to describe the node memory unit.
I'd make codeunit/code a link to that part of docs, which explains
what values are accepted and what scale they refer to.
span class=sinceSince 1.2.7/span all cells should
have codeid/code attribute in case referring to some cell is
necessary in the code, otherwise the cells are
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index 20d81ae..44cabad 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -4144,6 +4144,11 @@
ref name=memoryKB/
/attribute
optional
+attribute name=unit
+ ref name=unit/
+/attribute
+ /optional
+ optional
attribute name=memAccess
choice
valueshared/value
diff --git a/src/conf/cpu_conf.c b/src/conf/cpu_conf.c
index 5475c07..a0a60c8 100644
--- a/src/conf/cpu_conf.c
+++ b/src/conf/cpu_conf.c
@@ -177,6 +177,48 @@ virCPUDefCopy(const virCPUDef *cpu)
return NULL;
}
+static int
+virCPUNumaCellMemoryParseXML(xmlNodePtr node,
+ xmlXPathContextPtr ctxt,
+ unsigned long long* cellMemory)
+{
+int ret = -1;
+xmlNodePtr oldnode = ctxt-node;
+unsigned long long bytes, max;
+char *unit = NULL;
+
+ctxt-node = node;
+
+/* 32 vs 64 bit will differ in value of upper memory bound.
+ * On 32-bit machines, our bound is 0x * KiB. On 64-bit
+ * machines, our bound is off_t (2^63).
+ */
+if (sizeof(unsigned long) sizeof(long long))
+max = 1024ull * ULONG_MAX;
+else
+max = LLONG_MAX;
+
+
Re: [libvirt] [PATCH] Transform VIR_ERROR into VIR_WARN in detect_scsi_host_caps
On Fri, 2014-11-07 at 10:31 +0100, Eric Blake wrote: On 11/04/2014 03:15 PM, Cédric Bosdonnat wrote: If detect_scsi_host_caps reports errors but keeps libvirtd going on startup, the user is mislead by the error messages. Transforming them s/mislead/misled/ into warning still shows the problems, but indicates this is not fatal. --- po/POTFILES.in| 1 - src/node_device/node_device_linux_sysfs.c | 22 +++--- 2 files changed, 11 insertions(+), 12 deletions(-) ACK. Pushed with the grammar fix. Thanks -- Cedric -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] domain_conf: Use virDomainParseMemory more widely
On Fri, Nov 07, 2014 at 15:30:10 +0100, Michal Privoznik wrote: As reviewing patches upstream it occurred to me, that we have two functions doing nearly the same: virDomainParseMemory which expects XML in the following format: memory unit='MiB'1337/memory The other function being virDomainHugepagesParseXML expecting the following format: someElement memory='1337' unit='MiB'/ This should rather be someElement size=.../ to match what the code really does. It wouldn't matter to have two functions handle two different scenarios like this if we could only not copy code that handles 32bit arches around. So this code merges the common parts into one by inventing new @units_xpath argument to virDomainParseMemory which allows overriding the default location of @unit attribute in XML. With this change both scenarios above can be parsed with virDomainParseMemory. Sweet. Of course, everything is commented as it should be. Signed-off-by: Michal Privoznik mpriv...@redhat.com --- src/conf/domain_conf.c | 137 + 1 file changed, 80 insertions(+), 57 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 21309b0..e097af7 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -6318,14 +6318,30 @@ virDomainDiskDefParseXML(virDomainXMLOptionPtr xmlopt, goto cleanup; } - -/* Parse a value located at XPATH within CTXT, and store the - * result into val. If REQUIRED, then the value must exist; - * otherwise, the value is optional. The value is in bytes. - * Return 1 on success, 0 if the value was not present and - * is not REQUIRED, -1 on failure after issuing error. */ +/** + * virDomainParseScaledValue: + * @bytes_xpath: XPath to memory amount I think the bytes_xpath name is slightly misleading and plain xpath would be better since this is a general function and we may be parsing something completely different not to mention that the value may represent for example Mebibytes depending on what is parsed from @units_xpath. + * @units_xpath: XPath to units attribute + * @ctxt: XPath context + * @val: scaled value is stored here + * @scale: default scale for @val + * @max: maximal @val allowed + * @required: is the value required? + * + * Parse a value located at @bytes_xpath within @ctxt, and store + * the result into @val. By default, if @units_xpath is NULL the + * unit attribute must be an attribute to @bytes_xpath. + * Otherwise, the unit attribute is looked for under specified + * path. If @required is set, then the value must exist; + * otherwise, the value is optional. The value is in bytes. + * + * Returns 1 on success, + * 0 if the value was not present and !@required, + * -1 on failure after issuing error. + */ static int -virDomainParseScaledValue(const char *xpath, +virDomainParseScaledValue(const char *bytes_xpath, + const char *units_xpath, xmlXPathContextPtr ctxt, unsigned long long *val, unsigned long long scale, ... @@ -6379,17 +6398,35 @@ virDomainParseScaledValue(const char *xpath, } -/* Parse a memory element located at XPATH within CTXT, and store the - * result into MEM, in blocks of 1024. If REQUIRED, then the value - * must exist; otherwise, the value is optional. The value must not - * exceed VIR_DOMAIN_MEMORY_PARAM_UNLIMITED once scaled; additionally, - * if CAPPED is true, the value must fit within an unsigned long (only - * matters on 32-bit platforms). +/** + * virDomainParseMemory: + * @bytes_xpath: XPath to memory amount My comment about bytes_xpath above is applicable here as well. Although we at least know the value has to do something with bytes. + * @units_xpath: XPath to units attribute + * @ctxt: XPath context + * @mem: scaled memory amount is stored here + * @required: whether value is required + * @capped: whether scaled value must fit within unsigned long * - * Return 0 on success, -1 on failure after issuing error. */ + * Parse a memory element or attribute located at @bytes_xpath + * within @ctxt, and store the result into @mem, in blocks of + * 1024. By default, if @units_xpath is NULL the unit attribute + * must be an attribute to @bytes_xpath. Otherwise, the unit + * attribute is looked for under specified path. If @required is + * set, then the value must exist; otherwise, the value is + * optional. The value must not exceed + * VIR_DOMAIN_MEMORY_PARAM_UNLIMITED once scaled; additionally, + * if @capped is true, the value must fit within an unsigned long + * (only matters on 32-bit platforms). + * + * Return 0 on success, -1 on failure after issuing error. + */ static int -virDomainParseMemory(const char *xpath, xmlXPathContextPtr ctxt, - unsigned long long *mem, bool required, bool capped)
Re: [libvirt] [PATCH v6 4/7] qemu: Add bps_max and friends qemu driver
On 29.10.2014 13:16, Matthias Gatto wrote: Add support for bps_max and friends in the driver part. In the part checking if a qemu is running, check if the running binary support bps_max, if not print an error message, if yes add it to info variable Signed-off-by: Matthias Gatto matthias.ga...@outscale.com --- include/libvirt/libvirt-domain.h | 56 src/qemu/qemu_driver.c | 187 +-- src/qemu/qemu_monitor.c | 10 ++- src/qemu/qemu_monitor.h | 6 +- src/qemu/qemu_monitor_json.c | 11 ++- src/qemu/qemu_monitor_json.h | 6 +- tests/qemumonitorjsontest.c | 4 +- 7 files changed, 259 insertions(+), 21 deletions(-) diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h index 6146244..652512b 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -3251,6 +3251,62 @@ typedef void (*virConnectDomainEventDeviceRemovedCallback)(virConnectPtr conn, # define VIR_DOMAIN_TUNABLE_BLKDEV_WRITE_IOPS_SEC blkdeviotune.write_iops_sec /** + * VIR_DOMAIN_TUNABLE_BLKDEV_TOTAL_BYTES_SEC_MAX: + * + * Marco represents the total throughput limit in maximum bytes per second, + * as VIR_TYPED_PARAM_ULLONG. + */ +#define VIR_DOMAIN_TUNABLE_BLKDEV_TOTAL_BYTES_SEC_MAX blkdeviotune.total_bytes_sec_max Yet again, s/#define/# define/. + +/** + * VIR_DOMAIN_TUNABLE_BLKDEV_READ_BYTES_SEC_MAX: + * + * Marco represents the read throughput limit in maximum bytes per second, + * as VIR_TYPED_PARAM_ULLONG. + */ +#define VIR_DOMAIN_TUNABLE_BLKDEV_READ_BYTES_SEC_MAX blkdeviotune.read_bytes_sec_max + +/** + * VIR_DOMAIN_TUNABLE_BLKDEV_WRITE_BYTES_SEC_MAX: + * + * Macro represents the write throughput limit in maximum bytes per second, + * as VIR_TYPED_PARAM_ULLONG. + */ +#define VIR_DOMAIN_TUNABLE_BLKDEV_WRITE_BYTES_SEC_MAX blkdeviotune.write_bytes_sec_max + +/** + * VIR_DOMAIN_TUNABLE_BLKDEV_TOTAL_IOPS_SEC_MAX: + * + * Macro represents the total maximum I/O operations per second, + * as VIR_TYPED_PARAM_ULLONG. + */ +#define VIR_DOMAIN_TUNABLE_BLKDEV_TOTAL_IOPS_SEC_MAX blkdeviotune.total_iops_sec_max + +/** + * VIR_DOMAIN_TUNABLE_BLKDEV_READ_IOPS_SEC_MAX: + * + * Macro represents the read maximum I/O operations per second, + * as VIR_TYPED_PARAM_ULLONG. + */ +#define VIR_DOMAIN_TUNABLE_BLKDEV_READ_IOPS_SEC_MAX blkdeviotune.read_iops_sec_max + +/** + * VIR_DOMAIN_TUNABLE_BLKDEV_WRITE_IOPS_SEC_MAX: + * + * Macro represents the write maximum I/O operations per second, + * as VIR_TYPED_PARAM_ULLONG. + */ +#define VIR_DOMAIN_TUNABLE_BLKDEV_WRITE_IOPS_SEC_MAX blkdeviotune.write_iops_sec_max + +/** + * VIR_DOMAIN_TUNABLE_BLKDEV_SIZE_IOPS_SEC: + * + * Macro represents the size maximum I/O operations per second, + * as VIR_TYPED_PARAM_ULLONG. + */ +#define VIR_DOMAIN_TUNABLE_BLKDEV_SIZE_IOPS_SEC blkdeviotune.size_iops_sec + +/** * virConnectDomainEventTunableCallback: * @conn: connection object * @dom: domain on which the event occurred diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 5eccacc..54ba154 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -105,6 +105,7 @@ VIR_LOG_INIT(qemu.qemu_driver); #define QEMU_NB_MEM_PARAM 3 #define QEMU_NB_BLOCK_IO_TUNE_PARAM 6 +#define QEMU_NB_BLOCK_IO_TUNE_PARAM_MAX 13 #define QEMU_NB_NUMA_PARAM 2 @@ -16520,6 +16521,10 @@ qemuDomainSetBlockIoTune(virDomainPtr dom, int conf_idx = -1; bool set_bytes = false; bool set_iops = false; +bool set_bytes_max = false; +bool set_iops_max = false; +bool set_size_iops = false; +bool supportMaxOptions = true; virQEMUDriverConfigPtr cfg = NULL; virCapsPtr caps = NULL; virObjectEventPtr event = NULL; @@ -16542,6 +16547,20 @@ qemuDomainSetBlockIoTune(virDomainPtr dom, VIR_TYPED_PARAM_ULLONG, VIR_DOMAIN_BLOCK_IOTUNE_WRITE_IOPS_SEC, VIR_TYPED_PARAM_ULLONG, + VIR_DOMAIN_BLOCK_IOTUNE_TOTAL_BYTES_SEC_MAX, + VIR_TYPED_PARAM_ULLONG, + VIR_DOMAIN_BLOCK_IOTUNE_READ_BYTES_SEC_MAX, + VIR_TYPED_PARAM_ULLONG, + VIR_DOMAIN_BLOCK_IOTUNE_WRITE_BYTES_SEC_MAX, + VIR_TYPED_PARAM_ULLONG, + VIR_DOMAIN_BLOCK_IOTUNE_TOTAL_IOPS_SEC_MAX, + VIR_TYPED_PARAM_ULLONG, + VIR_DOMAIN_BLOCK_IOTUNE_READ_IOPS_SEC_MAX, + VIR_TYPED_PARAM_ULLONG, + VIR_DOMAIN_BLOCK_IOTUNE_WRITE_IOPS_SEC_MAX, + VIR_TYPED_PARAM_ULLONG, + VIR_DOMAIN_BLOCK_IOTUNE_SIZE_IOPS_SEC, + VIR_TYPED_PARAM_ULLONG, NULL) 0)
Re: [libvirt] [PATCH v6 0/7] qemu: Introduce support for new the block_set_io_throttle parameters add in the version 1.7 of qemu.
On 29.10.2014 13:15, Matthias Gatto wrote: This series of patches add support for bps_max, bps_rd_max, bps_wr_max, bps_max, bps_rd_max, bps_wr_max, and iops_size in the functions qemuDomainSetBlockIoTune and qemuDomainGetBlockIoTune. The last patch add support for these parameters to the virsh blkdeviotune command. v2: -Spellfix v3: -Merge patch 1/9,2/9,5/9 together. -Change the capability detection.(patch 2/7 and 3/7). -Try to make the usage of QEMU_NB_BLOCK_IO_TUNE_PARAM_MAX more explicit(patch 3/7). v4: -Rebase on HEAD. -Update qemu_driver to comply with Pavel's patchs.(patch 3/6) -Remove the qemu_monitor_text modification.(remove old patch 5/7) v5: -Split patch 1/6 in two. -Add documentation for the new xml options (patch 2/7) -Change (void) to ATTRIBUTE_UNUSED (patch 4/7) -Capability detection of supportMaxOptions move before usage of supportMaxOptions (patch 4/7) v6: -Spellfix -Add comment (patch 4/7, 5/7) -Undo the modification of the supportMaxOptions made in the v5 because it was creating bugs(patch 4/5) The 2 first patches have been reviewed by Eric Blake and sould be merge soon The 3rd patch have been reviewed by Michal Privoznik and ack Matthias Gatto (7): qemu: Add define for the new throttle options qemu: Modify the structure _virDomainBlockIoTuneInfo. qemu: Add Qemu capability for bps_max and friends qemu: Add bps_max and friends qemu driver qemu: Add bps_max and friends QMP suport qemu: Add bps_max and friends to qemu command generation virsh: Add bps_max and friends to virsh docs/formatdomain.html.in| 25 docs/schemas/domaincommon.rng| 43 ++ include/libvirt/libvirt-domain.h | 110 src/conf/domain_conf.c | 109 +++- src/conf/domain_conf.h | 7 + src/qemu/qemu_capabilities.c | 2 + src/qemu/qemu_capabilities.h | 1 + src/qemu/qemu_command.c | 57 +++- src/qemu/qemu_driver.c | 187 ++- src/qemu/qemu_monitor.c | 10 +- src/qemu/qemu_monitor.h | 6 +- src/qemu/qemu_monitor_json.c | 66 -- src/qemu/qemu_monitor_json.h | 6 +- tests/qemucapabilitiesdata/caps_2.1.1-1.caps | 1 + tests/qemumonitorjsontest.c | 6 +- tools/virsh-domain.c | 119 + tools/virsh.pod | 10 ++ 17 files changed, 732 insertions(+), 33 deletions(-) So, I've reviewed the patches. They seem okay except for a few minor things I've found. I don't want to force you to send another version, so can you send just a follow-up patch? Well, 1/7 and 6/7 is easily fixable so I'll do that myself. However, 4/7 requires a bit more of work. So I'm okay with you sending follow-up patch just for that one. Partial ACK for now. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v6 1/7] qemu: Add define for the new throttle options
On 29.10.2014 13:15, Matthias Gatto wrote: Add defines for the new options total_bytes_sec_max, write_bytes_sec_max, read_bytes_sec_max, total_iops_sec_max, write_iops_sec_max, read_iops_sec_max, size_iops_sec. Signed-off-by: Matthias Gatto matthias.ga...@outscale.com --- include/libvirt/libvirt-domain.h | 54 1 file changed, 54 insertions(+) diff --git a/include/libvirt/libvirt-domain.h b/include/libvirt/libvirt-domain.h index b28d37d..6146244 100644 --- a/include/libvirt/libvirt-domain.h +++ b/include/libvirt/libvirt-domain.h @@ -1965,6 +1965,60 @@ int virDomainBlockCommit(virDomainPtr dom, const char *disk, const char *base, */ # define VIR_DOMAIN_BLOCK_IOTUNE_WRITE_IOPS_SEC write_iops_sec +/** + * VIR_DOMAIN_BLOCK_IOTUNE_TOTAL_BYTES_SEC_MAX: + * + * Macro for the BlockIoTune tunable weight: it represents the maximum total + * bytes per second permitted through a block device, as a ullong. + */ +#define VIR_DOMAIN_BLOCK_IOTUNE_TOTAL_BYTES_SEC_MAX total_bytes_sec_max See the context line above? There should be a space between sharp and 'define'. Even 'syntax-check' warns about it (but I guess you don't have cppi installed, do you?). + +/** + * VIR_DOMAIN_BLOCK_IOTUNE_READ_BYTES_SEC_MAX: + * + * Macro for the BlockIoTune tunable weight: it represents the maximum read + * bytes per second permitted through a block device, as a ullong. + */ +#define VIR_DOMAIN_BLOCK_IOTUNE_READ_BYTES_SEC_MAX read_bytes_sec_max + +/** + * VIR_DOMAIN_BLOCK_IOTUNE_WRITE_BYTES_SEC_MAX: + * + * Macro for the BlockIoTune tunable weight: it represents the maximum write + * bytes per second permitted through a block device, as a ullong. + */ +#define VIR_DOMAIN_BLOCK_IOTUNE_WRITE_BYTES_SEC_MAX write_bytes_sec_max + +/** + * VIR_DOMAIN_BLOCK_IOTUNE_TOTAL_IOPS_SEC_MAX: + * + * Macro for the BlockIoTune tunable weight: it represents the maximum + * I/O operations per second permitted through a block device, as a ullong. + */ +#define VIR_DOMAIN_BLOCK_IOTUNE_TOTAL_IOPS_SEC_MAX total_iops_sec_max + +/** + * VIR_DOMAIN_BLOCK_IOTUNE_READ_IOPS_SEC_MAX: + * + * Macro for the BlockIoTune tunable weight: it represents the maximum read + * I/O operations per second permitted through a block device, as a ullong. + */ +#define VIR_DOMAIN_BLOCK_IOTUNE_READ_IOPS_SEC_MAX read_iops_sec_max + +/** + * VIR_DOMAIN_BLOCK_IOTUNE_WRITE_IOPS_SEC_MAX: + * Macro for the BlockIoTune tunable weight: it represents the maximum write + * I/O operations per second permitted through a block device, as a ullong. + */ +#define VIR_DOMAIN_BLOCK_IOTUNE_WRITE_IOPS_SEC_MAX write_iops_sec_max + +/** + * VIR_DOMAIN_BLOCK_IOTUNE_SIZE_IOPS_SEC: + * Macro for the BlockIoTune tunable weight: it represents the size + * I/O operations per second permitted through a block device, as a ullong. + */ +#define VIR_DOMAIN_BLOCK_IOTUNE_SIZE_IOPS_SEC size_iops_sec + int virDomainSetBlockIoTune(virDomainPtr dom, const char *disk, Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH v6 6/7] qemu: Add bps_max and friends to qemu command generation
On 29.10.2014 13:16, Matthias Gatto wrote:
Check the arability of the options with the current qemu binary,
add them in the varable opt if yes, print a message if not.
Signed-off-by: Matthias Gatto matthias.ga...@outscale.com
---
src/qemu/qemu_command.c | 57 -
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index 2e5af4f..b3dc919 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -3669,12 +3669,32 @@ qemuBuildDriveStr(virConnectPtr conn,
goto error;
}
+/* block I/O throttling 1.7 */
+if ((disk-blkdeviotune.total_bytes_sec_max ||
+ disk-blkdeviotune.read_bytes_sec_max ||
+ disk-blkdeviotune.write_bytes_sec_max ||
+ disk-blkdeviotune.total_iops_sec_max ||
+ disk-blkdeviotune.read_iops_sec_max ||
+ disk-blkdeviotune.write_iops_sec_max)
+!virQEMUCapsGet(qemuCaps, QEMU_CAPS_DRIVE_IOTUNE_MAX)) {
+virReportError(VIR_ERR_CONFIG_UNSUPPORTED, %s,
+ _(there is some block I/O throttling paramater that are not
supported with this
+ QEMU binary(need QEMU 1.7 or superior)));
+goto error;
This is rather a long line. Can you split it better, so that it has max
~80 characters?
+}
+
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 02/15] Remove unneeded curly brackets around oneline code blocks in src/conf/
On Fri, Nov 07, 2014 at 09:58:11AM -0500, Laine Stump wrote:
On 11/07/2014 05:09 AM, Eric Blake wrote:
On 11/06/2014 05:38 PM, Martin Kletzander wrote:
@@ -138,9 +138,9 @@ virDevicePCIAddressEqual(virDevicePCIAddress *addr1,
if (addr1-domain == addr2-domain
addr1-bus == addr2-bus
addr1-slot == addr2-slot
-addr1-function == addr2-function) {
+addr1-function == addr2-function)
return true;
-}
Conversions like this are a little harder to read (that is, any time the
'if' condition extends over multiple lines, but there is exactly four
space indentation of the condition, it's visually hard to see where the
multi-line condition ends and the loop body begins). The opening { is
hard to see either way, but seeing the closing } is my visual clue that
yes, the last line of this blob of code is not part of the 'if' but the
one-line body. I'm not opposed to your removal of {}, but wonder if we
should rethink our style to recommend keeping the {} if the 'if'
expression is multiline.
I've always thought this, and used to do it that way until a few
reviewers complained. So I for one would welcome our new use braces if
condition is multiple lines overlords :-)
(I also agree that this is all an exercise in futility unless there is a
matching syntax-check rule to enforce it.)
Well, I used to place opening curly brackets on their own new lines as
we do with functions (pre-libvirt) and this is something I had to get
used to.
Anyway, I'd be more than OK with changing contributor guidelines and
saying that we require curly brackets if either a) the body or b) the
condition itself spans over multiple lines. syntax-check for that is
*way* easier ;)
Martin
signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 02/15] Remove unneeded curly brackets around oneline code blocks in src/conf/
On Fri, Nov 07, 2014 at 11:11:27AM +0100, Daniel P. Berrange wrote:
On Fri, Nov 07, 2014 at 11:09:11AM +0100, Eric Blake wrote:
On 11/06/2014 05:38 PM, Martin Kletzander wrote:
As stated in our contributor guidelines, we don't want curly brackets
around oneline code block (with some exceptions).
Signed-off-by: Martin Kletzander mklet...@redhat.com
---
+++ b/src/conf/capabilities.c
@@ -219,9 +219,8 @@ virCapabilitiesDispose(void *object)
VIR_FREE(caps-host.migrateTrans[i]);
VIR_FREE(caps-host.migrateTrans);
-for (i = 0; i caps-host.nsecModels; i++) {
+for (i = 0; i caps-host.nsecModels; i++)
virCapabilitiesClearSecModel(caps-host.secModels[i]);
-}
Conversions like this make sense...
@@ -138,9 +138,9 @@ virDevicePCIAddressEqual(virDevicePCIAddress *addr1,
if (addr1-domain == addr2-domain
addr1-bus == addr2-bus
addr1-slot == addr2-slot
-addr1-function == addr2-function) {
+addr1-function == addr2-function)
return true;
-}
Conversions like this are a little harder to read (that is, any time the
'if' condition extends over multiple lines, but there is exactly four
space indentation of the condition, it's visually hard to see where the
multi-line condition ends and the loop body begins). The opening { is
hard to see either way, but seeing the closing } is my visual clue that
yes, the last line of this blob of code is not part of the 'if' but the
one-line body. I'm not opposed to your removal of {}, but wonder if we
should rethink our style to recommend keeping the {} if the 'if'
expression is multiline.
Besides, it is easier to write a syntax check that checks for one-line
'if' expressions (that's how I wrote my checks for mis-matched if{}else;
and if;else{}) than it is for multi-line if expressions. So
distinguishing between the two types may make it easier to write a
syntax check and enforce a consistent style.
@@ -3762,23 +3759,22 @@ virDomainDeviceInfoParseXML(xmlNodePtr node,
if (cur-type == XML_ELEMENT_NODE) {
if (alias == NULL
!(flags VIR_DOMAIN_XML_INACTIVE)
-xmlStrEqual(cur-name, BAD_CAST alias)) {
+xmlStrEqual(cur-name, BAD_CAST alias))
alias = cur;
This one is multi-line with no indentation to help...
-} else if (address == NULL
- xmlStrEqual(cur-name, BAD_CAST address)) {
+else if (address == NULL
+ xmlStrEqual(cur-name, BAD_CAST address))
address = cur;
...while this one has indentation help because of the 'else if'; see the
difference in spotting the one-line statement?
@@ -6879,9 +6870,8 @@ virDomainActualNetDefParseXML(xmlNodePtr node,
if (!(actual-virtPortProfile
= virNetDevVPortProfileParse(virtPortNode,
VIR_VPORT_XML_REQUIRE_ALL_ATTRIBUTES |
- VIR_VPORT_XML_REQUIRE_TYPE)))
{
+ VIR_VPORT_XML_REQUIRE_TYPE)))
goto error;
-}
And this is an example of a multi-line 'if' expression, but it is
indented (both because the '=' is split over lines, and because the last
part of the expression is a function call split over lines), so the
one-liner is easy to spot here.
But my earlier claim that one-liner 'if' expressions are easier to grep
for than multi-line 'if' may mean that a syntax check would not flag
this one as a place to remove the {}. Maybe it doesn't matter.
(Ideally, if we could figure out how to make GNU indent or some other
code prettifier enforce a style, we'd use that instead of syntax check
grep rules).
Yeah, I'd really like to be able to run something like GNU indent over
the code and check input==output, but there were a couple of rules in
our coding style that indent didn't appear to support
I tried playing with the indent tool many times but I've never got to
any better situation than where we were at the time I started hacking
on libvirt. Maybe if we can adjust our rules to match whatever indent
supports, although I don't remember what the particular problems were.
Martin
signature.asc
Description: Digital signature
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH] domain_conf: Use virDomainParseMemory more widely
On 11/07/2014 03:30 PM, Michal Privoznik wrote: As reviewing patches upstream it occurred to me, that we have two functions doing nearly the same: virDomainParseMemory which expects XML in the following format: memory unit='MiB'1337/memory The other function being virDomainHugepagesParseXML expecting the following format: someElement memory='1337' unit='MiB'/ It wouldn't matter to have two functions handle two different scenarios like this if we could only not copy code that handles 32bit arches around. So this code merges the common parts into one by inventing new @units_xpath argument to virDomainParseMemory which allows overriding the default location of @unit attribute in XML. With this change both scenarios above can be parsed with virDomainParseMemory. Sweet. Of course, everything is commented as it should be. There's no need to commend yourself for your comments in the commit message :) See below for a few nit picks. Signed-off-by: Michal Privoznik mpriv...@redhat.com --- src/conf/domain_conf.c | 137 + 1 file changed, 80 insertions(+), 57 deletions(-) diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c index 21309b0..e097af7 100644 --- a/src/conf/domain_conf.c +++ b/src/conf/domain_conf.c @@ -6318,14 +6318,30 @@ virDomainDiskDefParseXML(virDomainXMLOptionPtr xmlopt, goto cleanup; } - -/* Parse a value located at XPATH within CTXT, and store the - * result into val. If REQUIRED, then the value must exist; - * otherwise, the value is optional. The value is in bytes. - * Return 1 on success, 0 if the value was not present and - * is not REQUIRED, -1 on failure after issuing error. */ +/** + * virDomainParseScaledValue: + * @bytes_xpath: XPath to memory amount + * @units_xpath: XPath to units attribute + * @ctxt: XPath context + * @val: scaled value is stored here + * @scale: default scale for @val + * @max: maximal @val allowed + * @required: is the value required? + * + * Parse a value located at @bytes_xpath within @ctxt, and store + * the result into @val. By default, if @units_xpath is NULL the + * unit attribute must be an attribute to @bytes_xpath. The attribute doesn't have to be present. It would also be nice to mention the scaling: The value is scaled by units located at @units_xpath (or the 'unit' attribute under @bytes_xpath if @units_xpath is NULL). If units are not present, the default @scale is used. + * Otherwise, the unit attribute is looked for under specified + * path. This sentence seems redundant. If @required is set, then the value must exist; + * otherwise, the value is optional. The value is in bytes. To distinguish it from the input value (although their existences are linked together): The resulting value is in bytes. Jan signature.asc Description: OpenPGP digital signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [PATCH] phyp: Fix NULL dereference in phypConnectOpen
Coverity found out that commit cd490086 caused a possible NULL pointer
dereference. This is due to the fact, that phyp_driver might be
NULL (if VIR_ALLOC() fails), but connection_data, which kept the socket
before the mentioned commit, could not be NULL.
Signed-off-by: Martin Kletzander mklet...@redhat.com
---
src/phyp/phyp_driver.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/phyp/phyp_driver.c b/src/phyp/phyp_driver.c
index 7c8bc5c..0d3ad53 100644
--- a/src/phyp/phyp_driver.c
+++ b/src/phyp/phyp_driver.c
@@ -1222,6 +1222,7 @@ phypConnectOpen(virConnectPtr conn,
if (phyp_driver != NULL) {
virObjectUnref(phyp_driver-caps);
virObjectUnref(phyp_driver-xmlopt);
+VIR_FORCE_CLOSE(phyp_driver-sock);
VIR_FREE(phyp_driver);
}
@@ -1232,8 +1233,6 @@ phypConnectOpen(virConnectPtr conn,
libssh2_session_free(session);
}
-VIR_FORCE_CLOSE(phyp_driver-sock);
-
return VIR_DRV_OPEN_ERROR;
}
--
2.1.3
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 0/2] Resolve fc_host startup config issues
Don't bother reviewing this series - there's another related bug for which I need to make some adjustments to 2/2 - so I'll just with that fix as 3/3. John On 11/06/2014 03:57 PM, John Ferlan wrote: Fix a couple of bugs related to attempting to start an fc_host with incorrect 'parent' attributes. One consideration is a parent that is not capable to support the vport operations and the other is providing the incorrect scsi_host# for the parent from the nodedev-create used to generate the wwnn,wwpn Updated the documentation in order to add some more cautions I've find during my investigation and make it clearer what must be provided. John Ferlan (2): storage: Check for valid fc_host parent at startup storage: Ensure fc_host parent matches wwnn/wwpn docs/formatstorage.html.in | 15 - src/storage/storage_backend_scsi.c | 115 ++--- 2 files changed, 119 insertions(+), 11 deletions(-) -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
