[libvirt] [PATCH 0/3] More adjustments for recent storage probe logic
by John Ferlan
Adjustments based on recent activity...
The !writelabel path of patch 3 is probably a moot point since patches
to check at FS and Logical startup for a valid data on the device(s)
were reverted.
John Ferlan (3):
storage: Alter logic when both BLKID and PARTED unavailable
storage: Clean up return value checking
storage: Alter error message in probe/empty checks
src/storage/storage_backend.c | 44 ++++++++++++++++++++++++-------------------
1 file changed, 25 insertions(+), 19 deletions(-)
--
2.7.4
8 years, 2 months
[libvirt] [PATCH] qemu-capabilities: Fix query-cpu-model-expansion on s390 with older kernel
by Collin L. Walling
When running on s390 with a kernel that does not support cpu model checking and
with a Qemu new enough to support query-cpu-model-expansion, the gathering of qemu
capabilities will fail. Qemu responds to the query-cpu-model-expansion qmp
command with an error because the needed kernel ioct does not exist. When this
happens a guest cannot even be defined due to missing qemu capabilities data.
This patch fixes the problem by silently ignoring generic errors stemming from
calls to query-cpu-model-expansion.
Reported-by: Farhan Ali <alifm(a)linux.vnet.ibm.com>
Signed-off-by: Collin L. Walling <walling(a)linux.vnet.ibm.com>
Signed-off-by: Jason J. Herne <jjherne(a)linux.vnet.ibm.com>
---
src/qemu/qemu_monitor_json.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/src/qemu/qemu_monitor_json.c b/src/qemu/qemu_monitor_json.c
index e767437..1662749 100644
--- a/src/qemu/qemu_monitor_json.c
+++ b/src/qemu/qemu_monitor_json.c
@@ -5041,6 +5041,15 @@ qemuMonitorJSONGetCPUModelExpansion(qemuMonitorPtr mon,
if (qemuMonitorJSONCommand(mon, cmd, &reply) < 0)
goto cleanup;
+ /* Some QEMU architectures have the query-cpu-model-expansion
+ * command, but return 'GenericError' instead of simply omitting
+ * the command entirely.
+ */
+ if (qemuMonitorJSONHasError(reply, "GenericError")) {
+ ret = 0;
+ goto cleanup;
+ }
+
if (qemuMonitorJSONCheckError(cmd, reply) < 0)
goto cleanup;
--
2.7.4
8 years, 2 months
[libvirt] [PATCH v2 0/2] Fabric name must not be required for fc_host capability
by Boris Fiuczynski
fabric_name is one of many fc_host attributes in Linux that is optional
and left to the low-level driver to decide if it is implemented.
---
Changes since v1:
- split of minor correction in documenting comment
- added news entry...
- added new virReadFCHostOption method
- added check for file existence when optional is set
- rearranged fchost tests to fit the numbering
---
Boris Fiuczynski (2):
nodedev: Fabric name must not be required for fc_host capability
util: Minor correction in documenting comment
docs/formatnode.html.in | 2 +-
docs/news.xml | 12 +++++++++
docs/schemas/nodedev.rng | 8 +++---
src/libvirt_private.syms | 1 +
src/node_device/node_device_linux_sysfs.c | 6 ++---
src/util/virutil.c | 25 +++++++++++++++++-
src/util/virutil.h | 5 ++++
tests/fchostdata/fc_host/host6/node_name | 1 +
tests/fchostdata/fc_host/host6/port_name | 1 +
tests/fchostdata/fc_host/host6/port_state | 1 +
tests/fchosttest.c | 44 ++++++++++++++++++++++++++++---
11 files changed, 95 insertions(+), 11 deletions(-)
create mode 100644 tests/fchostdata/fc_host/host6/node_name
create mode 100644 tests/fchostdata/fc_host/host6/port_name
create mode 100644 tests/fchostdata/fc_host/host6/port_state
--
2.5.5
8 years, 2 months
[libvirt] [PATCH] docs: Fix libvirt_guest nss module name
by Michal Privoznik
In the documentation we are mixing libvirt-guest and
libvirt_guest module name. The correct name is the latter.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
Pushed as trivial.
docs/news.xml | 4 ++--
docs/nss.html.in | 12 ++++++------
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/docs/news.xml b/docs/news.xml
index 8a876e998..50c3b3ea2 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -29,10 +29,10 @@
</change>
<change>
<summary>
- nss: Introduce <code>libvirt-guest</code>
+ nss: Introduce <code>libvirt_guest</code>
</summary>
<description>
- New <code>libvirt-guest</code> nss module that translates libvirt
+ New <code>libvirt_guest</code> nss module that translates libvirt
guest names into IP addresses.
</description>
</change>
diff --git a/docs/nss.html.in b/docs/nss.html.in
index e07f9b774..2a5a46cd1 100644
--- a/docs/nss.html.in
+++ b/docs/nss.html.in
@@ -72,34 +72,34 @@ hosts: files libvirt dns
records. Therefore this is dependent on hostname provided by guests. Thing
is, not all the guests out there provide one in DHCP transactions, or not
every sysadmin out there believes all the guests. Hence libvirt implements
- second method in <code>libvirt-guest</code> module which does libvirt guest
+ second method in <code>libvirt_guest</code> module which does libvirt guest
name to IP address translation (regardless of hostname set in the guest).
</p>
<p>
To enable either of the modules put their name into the
<code>nsswitch.conf</code> file. For instance, to enable
- <code>libvirt-guest</code> module:
+ <code>libvirt_guest</code> module:
</p>
<pre>
$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf:
-hosts: files libvirt-guest dns
+hosts: files libvirt_guest dns
# ...
</pre>
<p>Or users can enable both at the same time:</p>
<pre>
$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf:
-hosts: files libvirt libvirt-guest dns
+hosts: files libvirt libvirt_guest dns
# ...
</pre>
<p>
This configuration will mean that if hostname is not found by the
<code>libvirt</code> module (e.g. because a guest did not sent hostname
- during DHCP transaction), the <code>libvirt-guest</code> module is
+ during DHCP transaction), the <code>libvirt_guest</code> module is
consulted (and if the hostname matches libvirt guest name it will be
resolved).
</p>
@@ -181,7 +181,7 @@ virsh domifaddr --source lease $domain
<p>
If there's no record for either of the aforementioned commands, it's
very likely that NSS module won't find anything and vice versa.
- As of <code>v3.0.0</code> libvirt provides <code>libvirt-guest</code> NSS
+ As of <code>v3.0.0</code> libvirt provides <code>libvirt_guest</code> NSS
module that doesn't have this limitation. However, the statement is still
true for the <code>libvirt</code> NSS module.
</p>
--
2.11.0
8 years, 2 months
[libvirt] [PATCH v2 00/10] Introduce new libvirt-guest NSS module
by Michal Privoznik
v2 of:
https://www.redhat.com/archives/libvir-list/2016-November/msg01456.html
diff to v1:
- New module is created instead of putting everything into already existing one
- Few hints from review of v1 were worked in
Michal Privoznik (10):
network: Don't unlock non-locked network driver
nssmock: Prefer free() over VIR_FREE()
virstring: Introduce virStringListAdd
virstring: Introduce virStringListRemove
util: Introduce virFileRewriteStr
util: Introduce virMACMap module
network: Track MAC address map
nss: Use macro to generate public API names
nss: Move address appending code into a separate function
nss: Introduce libvirt-guest module
cfg.mk | 2 +-
docs/news.html.in | 4 +
docs/nss.html.in | 58 ++++-
po/POTFILES.in | 1 +
src/Makefile.am | 9 +
src/conf/network_conf.h | 4 +
src/conf/virsecretobj.c | 20 +-
src/libvirt_private.syms | 12 ++
src/network/bridge_driver.c | 95 ++++++++-
src/network/leaseshelper.c | 14 +-
src/util/virfile.c | 24 ++-
src/util/virfile.h | 7 +-
src/util/virmacmap.c | 399 +++++++++++++++++++++++++++++++++++
src/util/virmacmap.h | 48 +++++
src/util/virstring.c | 84 ++++++++
src/util/virstring.h | 6 +
src/util/virxml.c | 4 +-
tests/Makefile.am | 36 +++-
tests/nssdata/virbr0.macs | 23 ++
tests/nssdata/virbr0.status | 5 +
tests/nssdata/virbr1.macs | 21 ++
tests/nssdata/virbr1.status | 5 +
tests/nsslinktest.c | 2 +-
tests/nssmock.c | 25 ++-
tests/nsstest.c | 17 +-
tests/virmacmapmock.c | 29 +++
tests/virmacmaptest.c | 232 ++++++++++++++++++++
tests/virmacmaptestdata/complex.json | 45 ++++
tests/virmacmaptestdata/empty.json | 3 +
tests/virmacmaptestdata/simple.json | 8 +
tests/virmacmaptestdata/simple2.json | 16 ++
tests/virstringtest.c | 98 +++++++++
tools/Makefile.am | 46 +++-
tools/nss/libvirt_guest_nss.syms | 12 ++
tools/nss/libvirt_nss.c | 216 +++++++++++++------
tools/nss/libvirt_nss.h | 30 +--
36 files changed, 1531 insertions(+), 129 deletions(-)
create mode 100644 src/util/virmacmap.c
create mode 100644 src/util/virmacmap.h
create mode 100644 tests/nssdata/virbr0.macs
create mode 100644 tests/nssdata/virbr1.macs
create mode 100644 tests/virmacmapmock.c
create mode 100644 tests/virmacmaptest.c
create mode 100644 tests/virmacmaptestdata/complex.json
create mode 100644 tests/virmacmaptestdata/empty.json
create mode 100644 tests/virmacmaptestdata/simple.json
create mode 100644 tests/virmacmaptestdata/simple2.json
create mode 100644 tools/nss/libvirt_guest_nss.syms
--
2.11.0
8 years, 2 months
[libvirt] [PATCH 0/4] Doc update changes for my recent commits
by John Ferlan
These are all trivial and will push in a bit - I was essentially waiting
for the news.html.in or news.xml to shake out before adjusting.
John Ferlan (4):
docs: Document the new vHBA/NPIV params for storage
docs: Add NPIV/vHBA change description to news.xml
docs: Add file system pool overwrite change description to news.xml
docs: Add logical storage pool overwrite change description to
news.xml
docs/formatstorage.html.in | 17 +++++++++++++++++
docs/news.xml | 34 ++++++++++++++++++++++++++++++++++
2 files changed, 51 insertions(+)
--
2.7.4
8 years, 2 months
[libvirt] [PATCH 0/3] For 3.0: storage: fix regressions in storage driver
by Peter Krempa
Few recent patches broke stuff. Revert/fix them.
Peter Krempa (3):
Revert "storage: For FS pool check for properly formatted target
volume"
Revert "storage: Validate the device formats at logical startup"
storage: logical: Fix flawed logic with (NO)_OVERWRITE flags.
src/storage/storage_backend_fs.c | 13 ++-----------
src/storage/storage_backend_logical.c | 15 +--------------
2 files changed, 3 insertions(+), 25 deletions(-)
--
2.11.0
8 years, 2 months
Re: [libvirt] Query regarding sharing of vcpu's (cpu alloc ratio 1.0) between VM's
by Martin Kletzander
[It's a good thing to keep the list Cc'd, someone else might have better answer]
On Thu, Jan 12, 2017 at 10:33:23AM -0600, BharaniKumar Gedela wrote:
>Hi Martin,
>
>To be more clear on the requirement, I have a kind of VM which needs 2
>vcpu's. One of the vcpu is dedicated for a specific process in the VM and
>the other vcpu can be shared by other VM's of the same kind.
>To be more clear, each VM is having 2 processes, one cpu intensive which
>got a dedicated vcpu alloted and the other process is a lightweight process
>which needs less amount of cpu so it can be shared with the other Vm's
>light weight processes.
>Example:
>There are 10 VM's of same type which need 2 vcpu's each (1 dedicated and 1
>shared):
>VM#: vcpu1, vcpu2
>VM1: 1, 11
>VM2: 2, 11
>VM3: 3, 11
>VM4: 4, 11
>VM5: 5, 11
>VM6: 6, 11
>VM7:7, 11
>VM8: 8, 11
>VM: 9, 11
>VM:10, 11
>
OK, so this is easy to do in libvirt. You just use <vcpupin/>
>IS there a way openstack nova-scheduler can provision the same (does this
>need libvirt changes if we want to provision via nova-scheduler)?or it can
>only be done via boot via xml (manually via templates in virsh)?
>
However, I don't know about openstack. But definitely there's no change
needed in libvirt. There might be some people from openstack on this
list, but it's mainly libvirt-related
>Regards,
>Bharani..
>
>On Thu, Jan 12, 2017 at 2:26 AM, Martin Kletzander <mkletzan(a)redhat.com>
>wrote:
>
>> On Wed, Jan 11, 2017 at 11:13:52AM -0600, BharaniKumar Gedela wrote:
>>
>>> HI,
>>>
>>> I have a Q about sharing a vcpu across Vm's (cpu alloc ratio 1.0 and HT
>>> not
>>> enabled)?
>>>
>>> I have a Use case where a VM needs vcpu's and one of the vcpu is dedicated
>>> to the VM for some traffic processing. We want the other vcpu which is
>>> used
>>> for control processing and can be shared with a similar VM's control
>>> processing.
>>> Is this possible and support in openstack/libvirt/KVM?
>>>
>>>
>> I can't wrap my head around it, but do you mean something like this:
>>
>> | pCPUs | 0 | 1 | 2 | 3 |
>> |---------------+---+---+---+---|
>> | VM #0's vCPUs | 0 | 1 | 2 | |
>> | VM #1's vCPUs | | 0 | 1 | |
>>
>> where VM #0 uses pCPU 0 exclusively and both VMs share pCPUs 1 and 2?
>>
>> You can do that using vcpupin [1]. Do you want them to share the pCPUs
>> fairly? You could theoretically utilize shares/period/quota for that,
>> making sure that the rest of the system is set up properly as well.
>>
>> If so could you please advice how to test it?
>>>
>>>
>>
>> [1] https://libvirt.org/formatdomain.html#elementsCPUTuning
>>
>> Regards,
>>> Bharani..
>>>
>>
>> --
>>> libvir-list mailing list
>>> libvir-list(a)redhat.com
>>> https://www.redhat.com/mailman/listinfo/libvir-list
>>>
>>
8 years, 2 months
[libvirt] [PATCH] libxl: always enable pae for x86_64 HVM
by Jim Fehlig
For HVM domains, pae is only set in libxl_domain_build_info when
explicitly specified in the hypervisor <features> config. This is
fine for i686 machines, but is incorrect behavior for x86_64 machines
where pae must always be enabled. See the following discussion for
additional details
https://www.redhat.com/archives/libvir-list/2017-January/msg00254.html
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
src/libxl/libxl_domain.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index fbe7ee5..a5314b0 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -410,6 +410,12 @@ libxlDomainDefPostParse(virDomainDefPtr def,
if (xenDomainDefAddImplicitInputDevice(def) < 0)
return -1;
+ /* For x86_64 HVM, always enable pae */
+ if (def->os.type == VIR_DOMAIN_OSTYPE_HVM &&
+ def->os.arch == VIR_ARCH_X86_64) {
+ def->features[VIR_DOMAIN_FEATURE_PAE] = VIR_TRISTATE_SWITCH_ON;
+ }
+
return 0;
}
--
2.9.2
8 years, 2 months
[libvirt] (no subject)
by 乔立勇(Eli Qiao)
hi all
Thanks all for the comment for previous RFC version, I summary all input
here also with Opens which I am not sure, can you please review again?
#Propose Changes
## Expose cache information into capabilities
Extend capabilities to expose all level cache resource information and
should tell the topology of caches also tell which kinds of resources can
be tuned/allocation
There information comes from
/sys/devices/system/cpu/cpu0/cache/index${level}/size
also /sys/fs/resctrl/ (this is CAT sys interface in linux kernel)
virsh capabilities
<cache>
<bank id='0, 'type="l3" size="56320" units="KiB" cpus="0,1,2,6,7,8"/>
<--------------------- level 3 cache is per socket, so group them by
socket id
<control unit="KiB" min="2816"/>
<bank id='1', type="l3" size="56320" units="KiB"
cpus="3,4,5,9,10,11"/>
<bank id='2' type="l2" size="256" units="KiB" cpus="0"/>
<bank id='3' type="l2" size="256" units="KiB" cpus="1"/>
<bank id='4' type="l2" size="256" units="KiB" cpus="2"/>
<bank id='5' type="l2" size="256" units="KiB" cpus="3"/>
<bank id='6' type="l2" size="256" units="KiB" cpus="4"/>
...
<cache>
Opens
1. how about add socket id to bank for bank type = l3 ?
2. do we really want to expose l2/l3 cache for now , they are per core
resource and linux kernel don't support l2 yet (depend no hardware)?
3. if enable CDP in resctrl, for bank type=l3 , it will be split to
l3data l3code, should expose this ability.
<bank type="l3" size="56320" units="KiB" cpus="0,1,2,6,7,8"/>
<--------------------- level 3 cache is per socket, so group them by
socket id
<control unit="KiB" min="2816" cdp="enabled"/>
## Provide a new API to get the avail cache on each bank, such as the
output are:
id=0
type=l3
avail=56320
total = ?? <--------- do we need this?
id=1
type=l3
avail=56320
id=3
type=l2
avail=256
Opens:
· Don't expose the avail cache information if the host can not do
the allocation of that type cache(eg, for l2 currently) ?
· We can not make all of the cache , the reservation amount is the
min_cbm_len (=1) * min_unit .
· do we need to expose total?
## enable CAT for a domain
1 Domain XML changes
<cputune>
<cache id="1" host_id="0" type="l3" size="5632" unit="KiB"/>
<cache id="2" host_id="1" type="l3" size="5632" unit="KiB"/>
<cpu_cache vcpus="0-3" id="1"/>
<cpu_cache vcpus="4-7" id="2"/>
<iothread_cache iothreads="0-1" id="1"/>
<emulator_cache id="2"/>
</cputune>
2. Extend cputune command ?
Opens:
1. Do we accept to extend existed API ? or using new API/virsh?
2. How to calculate cache size -> CBM bit?
eg:
5632/ 2816 = 2 bits
5733/ 2816 = 2 bits or 3 bits?
## Restriction for using cache tune on multiple sockets' host.
The l3 cache is per socket resource, kernel need to know about what's
affinity looks like, so for a VM which running on a multiple socket's host,
it should have NUMA setting or vcpuset pin setting. Or cache tune will fail.
[1] kernel support https://git.kernel.org/cgit/linux/kernel/git/tip/
tip.git/tree/arch/x86/kernel/cpu/intel_rdt.c?h=x86/cache
[2] libvirt PoC(not finished yet) https://github.com/taget/
libvirt/commits/cat_new
--
Best regards
- Eli
天涯无处不重逢
a leaf duckweed belongs to the sea , where not to meet in life
8 years, 2 months
