[libvirt] [PATCH] qemu: caps: Use unique key for domCaps caching
by Cole Robinson
When searching qemuCaps->domCapsCache for existing domCaps data,
we check for a matching pair of arch+virttype+machine+emulator. However
for the hash table key we only use the machine string. So if the
cache already contains:
x86_64 + kvm + pc + /usr/bin/qemu-kvm
But a new VM is defined with
x86_64 + qemu + pc + /usr/bin/qemu-kvm
We correctly fail to find matching cached domCaps, but then attempt
to use a colliding key with virHashAddEntry
Fix this by building a hash key from the 4 values, not just machine
Signed-off-by: Cole Robinson <crobinso(a)redhat.com>
---
qemu_domain.c validation should be affected, but it is covered up
by another bug, fixed here:
https://www.redhat.com/archives/libvir-list/2019-October/msg00708.html
src/qemu/qemu_conf.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/src/qemu/qemu_conf.c b/src/qemu/qemu_conf.c
index 08cd784054..64ac8cbdd3 100644
--- a/src/qemu/qemu_conf.c
+++ b/src/qemu/qemu_conf.c
@@ -1396,6 +1396,8 @@ virQEMUDriverGetDomainCapabilities(virQEMUDriverPtr driver,
domCaps = virHashSearch(domCapsCache,
virQEMUDriverSearchDomcaps, &data, NULL);
if (!domCaps) {
+ VIR_AUTOFREE(char *) key = NULL;
+
/* hash miss, build new domcaps */
if (!(domCaps = virDomainCapsNew(data.path, data.machine,
data.arch, data.virttype)))
@@ -1406,7 +1408,14 @@ virQEMUDriverGetDomainCapabilities(virQEMUDriverPtr driver,
cfg->firmwares, cfg->nfirmwares) < 0)
return NULL;
- if (virHashAddEntry(domCapsCache, machine, domCaps) < 0)
+ if (virAsprintf(&key, "%d:%d:%s:%s",
+ data.arch,
+ data.virttype,
+ NULLSTR(data.machine),
+ NULLSTR(data.path)) < 0)
+ return NULL;
+
+ if (virHashAddEntry(domCapsCache, key, domCaps) < 0)
return NULL;
}
--
2.23.0
5 years, 6 months
[libvirt] [Call for Presentations] FOSDEM 2020 Virtualization & IaaS Devroom
by Kashyap Chamarthy
The FOSDEM open source developer conference is taking place in
Brussels, Belgium on February 1st & 2nd, 2020. The call for
virtualization presentations has been posted[1]. Reposting the text
here (formatted for readability):
-----------------------------------------------------------------------
We are excited to announce that the call for proposals is now open for
the Virtualization & IaaS devroom at the upcoming FOSDEM 2020, to be
hosted on February 1st 2020.
The year 2020 will mark FOSDEM’s 20th anniversary as one of the
longest-running free and open source software developer events,
attracting thousands of developers and users from all over the world.
FOSDEM will be held once again in Brussels, Belgium, on February 1st &
2nd, 2020.
This devroom is a collaborative effort, and is organized by dedicated
folks from projects such as OpenStack, Xen Project, oVirt, QEMU, KVM,
libvirt, Foreman, and virtualization-related projects. We would like to
invite all those who are involved in these fields to submit your
proposals by December 1st, 2019.
Important Dates
---------------
- Submission deadline: 1 December 2019
- Acceptance notifications: 10 December 2019
- Final schedule announcement: 15th December 2019
- Devroom is only on one day: 1st February 2020
About the Devroom
-----------------
The Virtualization & IaaS devroom will feature session topics such as open
source hypervisors and virtual machine managers such as Xen Project,
KVM, QEMU, bhyve, and VirtualBox, and Infrastructure-as-a-Service
projects such as KubeVirt, Apache CloudStack, OpenStack, oVirt, QEMU and
OpenNebula.
This devroom will host presentations that focus on topics of shared
interest, such as KVM; QEMU; libvirt; shared storage; virtualized
networking; cloud security; clustering and high availability;
interfacing with multiple hypervisors; hyperconverged deployments; and
scaling across hundreds or thousands of servers.
Presentations in this devroom will be aimed at developers working on
these platforms who are looking to collaborate and improve shared
infrastructure or solve common problems. We seek topics that encourage
dialog between projects and continued work post-FOSDEM.
Submit Your Proposal
--------------------
All submissions must be made via the Pentabarf event planning site[1]. If
you have not used Pentabarf before, you will need to create an account. If
you submitted proposals for FOSDEM in previous years, you can use your
existing account.
After creating the account, select Create Event to start the submission
process. Make sure to select Virtualization and IaaS devroom from the Track
list. Please fill out all the required fields, and provide a meaningful
abstract and description of your proposed session.
Submission Guidelines
---------------------
We expect more proposals than we can possibly accept, so it is vitally
important that you submit your proposal on or before the deadline. Late
submissions are unlikely to be considered.
All presentation slots are 30 minutes, with 20 minutes planned for
presentations, and 10 minutes for Q&A.
All presentations will be recorded and made available under Creative
Commons licenses. In the Submission notes field, please indicate that you
agree that your presentation will be licensed under the CC-By-SA-4.0 or
CC-By-4.0 license and that you agree to have your presentation recorded.
For example:
"If my presentation is accepted for FOSDEM, I hereby agree to license all
recordings, slides, and other associated materials under the Creative
Commons Attribution Share-Alike 4.0 International License. Sincerely,
<NAME>."
In the Submission notes field, please also confirm that if your talk is
accepted, you will be able to attend FOSDEM and deliver your presentation.
We will not consider proposals from prospective speakers who are unsure
whether they will be able to secure funds for travel and lodging to attend
FOSDEM. (Sadly, we are not able to offer travel funding for prospective
speakers.)
Speaker Mentoring Program
-------------------------
As a part of the rising efforts to grow our communities and encourage a
diverse and inclusive conference ecosystem, we're happy to announce that
we'll be offering mentoring for new speakers. Our mentors can help you
with tasks such as reviewing your abstract, reviewing your presentation
outline or slides, or practicing your talk with you.
You may apply to the mentoring program as a newcomer speaker if you:
Never presented before or
Presented only lightning talks or
Presented full-length talks at small meetups (<50 ppl)
Mentored presentations will have 25-minute slots, where 20 minutes will
include the presentation and 5 minutes will be reserved for questions.
The number of newcomer session slots is limited, so we will probably not be
able to accept all applications.
You must submit your talk and abstract to apply for the mentoring program,
our mentors are volunteering their time and will happily provide feedback
but won't write your presentation for you!
If you are experiencing problems with Pentabarf, the proposal submission
interface, or have other questions, you can email our devroom mailing
list[2] and we will try to help you.
How to Apply
------------
In addition to agreeing to video recording and confirming that you can
attend FOSDEM in case your session is accepted, please write "speaker
mentoring program application" in the "Submission notes" field, and list
any prior speaking experience or other relevant information for your
application.
Code of Conduct
---------------
Following the release of the updated code of conduct for FOSDEM, we'd
like to remind all speakers and attendees that all of the presentations
and discussions in our devroom are held under the guidelines set in the
CoC and we expect attendees, speakers, and volunteers to follow the CoC
at all times.
If you submit a proposal and it is accepted, you will be required to
confirm that you accept the FOSDEM CoC. If you have any questions about
the CoC or wish to have one of the devroom organizers review your
presentation slides or any other content for CoC compliance, please
email us and we will do our best to assist you.
Call for Volunteers
-------------------
We are also looking for volunteers to help run the devroom. We need
assistance watching time for the speakers, and helping with video for
the devroom. Please contact devroom mailing list [2] for more
information.
Questions?
----------
If you have any questions about this devroom, please send your questions
to our devroom mailing list. You can also subscribe to the list to
receive updates about important dates, session announcements, and to
connect with other attendees.
See you all at FOSDEM!
-----------------------------------------------------------------------
[1] https://lists.fosdem.org/pipermail/fosdem/2019q4/002889.html
--
/kashyap
5 years, 6 months
[libvirt] [RFC] Accepting PRs/MRs for libvirt on GitHub/GitLab
by Andrea Bolognani
As we look to make the libvirt project easier to contribute to, one
fact that certainly comes to mind is that we only accept patches via
the mailing list. While the core developers are comfortable with the
email-based workflow and swear by it, many perspective contributors
are used to the PR/MR workflow common to many Open Source projects
these days, and similarly swear by it.
If we look at the PRs submitted on GitHub against the libvirt mirror
repository[1], there's just three of them per year on average, which
is arguably not a lot; however, it should be noted that each
repository also carries a fairly loud "PULL REQUESTS ARE IGNORED"
message right at the top, and it's not unlikely that a number of
perspective contributors simply lost interest after seeing it.
As a way to make contributions easier without forcing core developers
to give up their current workflow or making the project dependent on
a third-party provider, I suggest we adopt a hybrid approach.
First of all, we'd remove the ominous message from GitHub mirror
repositories (interestingly, the same is not present on GitLab).
Then, we'd starting accepting PRs/MRs. The way we'd handle them is
that, when one comes in, one among the handful of core developers who
volunteered to do so would review the patches on the respective
platform, working with the submitter to get it into shape just like
they would do on the mailing list; once the series is finally ready
to be merged, the core developer would update the PR/MR as necessary,
for example picking up R-bs or fixing the kind of trivial issues that
usually don't warrant a repost, and then push to master as usual.
More in detail: GitHub and GitLab have a feature that allows project
members to update PRs/MRs: basically the way it works is that, if the
PR/MR was created by the user 'foo' from their branch 'bar', the
libvirt developer is allowed to (force-)push to the foo/libvirt/bar
branch, and doing so updates the corresponding PR/MR; after that, if
the updated branch is locally merged into master and master is pushed
to the libvirt.org repo, once it gets mirrored GitHub/GitLab will
recognize that the commit IDs match and automatically mark the PR/MR
as merged. I have tested this behavior on both platforms (minus the
mirroring part) with Martin's help.
One last important bit. In the spirit of not requiring core
developers to alter their workflow, the developer who reviewed the
patches on GitHub/GitLab will also be responsible to format them to
the mailing list after merging them: this way, even those who don't
have a GitHub/GitLab account will get a chance to take notice of the
code changes and weigh in. Unlike what we're used to, this feedback
will come after the fact, but assuming that issues are spotted only
at that point we can either push the relevant fixes as follow-up
commits or even revert the series outright, so I don't feel like it
would be a massive problem overall.
Thoughts?
[1] https://github.com/libvirt/libvirt/pulls?q=is:pr+is:closed
--
Andrea Bolognani / Red Hat / Virtualization
5 years, 6 months
[libvirt] [PATCH 0/2] gitdm: Update configuration
by Andrea Bolognani
Andrea Bolognani (2):
gitdm: Fix sorting
gitdm: Add missing entries
docs/gitdm/companies/others | 4 +++-
docs/gitdm/groups/unaffiliated | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
--
2.21.0
5 years, 6 months
[libvirt] [PATCH v1] qemu_driver: improve comparison/baseline error reporting
by Collin Walling
Providing an erroneous CPU definition in the XML file provided to the
hypervisor-cpu-compare/baseline command will result in a verbose
internal error. Let's add some sanity checking before executing the QMP
commands to provide a cleaner message if something is wrong with the
CPU model or features.
An internal error will still appear for other messages originating from
QEMU e.g. if a newer feature is not available for an older CPU model.
Signed-off-by: Collin Walling <walling(a)linux.ibm.com>
---
src/qemu/qemu_driver.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 57 insertions(+)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 2e422b5..a4f916b 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -13645,6 +13645,52 @@ qemuConnectCompareCPU(virConnectPtr conn,
}
+static int
+qemuConnectCheckCPUModel(qemuMonitorPtr mon,
+ virCPUDefPtr cpu)
+{
+ qemuMonitorCPUModelInfoPtr modelInfo = NULL;
+ qemuMonitorCPUModelExpansionType type;
+ size_t i, j;
+ int ret = -1;
+
+ /* Collect CPU model name and features known by QEMU */
+ type = QEMU_MONITOR_CPU_MODEL_EXPANSION_FULL;
+ if (qemuMonitorGetCPUModelExpansion(mon, type, cpu, true,
+ false, &modelInfo) < 0)
+ goto cleanup;
+
+ /* Sanity check CPU model */
+ if (!modelInfo) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("Unknown CPU model: %s"), cpu->model);
+ goto cleanup;
+ }
+
+ /* Sanity check CPU features */
+ for (i = 0; i < cpu->nfeatures; i++) {
+ const char *feat = cpu->features[i].name;
+
+ for (j = 0; j < modelInfo->nprops; j++) {
+ const char *prop = modelInfo->props[j].name;
+ if (STREQ(feat, prop))
+ break;
+ }
+
+ if (j == modelInfo->nprops) {
+ virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
+ _("Unknown CPU feature: %s"), feat);
+ goto cleanup;
+ }
+ }
+ ret = 0;
+
+ cleanup:
+ qemuMonitorCPUModelInfoFree(modelInfo);
+ return ret;
+}
+
+
static virCPUCompareResult
qemuConnectCPUModelComparison(virQEMUCapsPtr qemuCaps,
const char *libDir,
@@ -13665,6 +13711,11 @@ qemuConnectCPUModelComparison(virQEMUCapsPtr qemuCaps,
if (qemuProcessQMPStart(proc) < 0)
goto cleanup;
+ if (qemuConnectCheckCPUModel(proc->mon, cpu_a) < 0 ||
+ qemuConnectCheckCPUModel(proc->mon, cpu_b) < 0) {
+ goto cleanup;
+ }
+
if (qemuMonitorGetCPUModelComparison(proc->mon, cpu_a, cpu_b, &result) < 0)
goto cleanup;
@@ -13863,6 +13914,9 @@ qemuConnectCPUModelBaseline(virQEMUCapsPtr qemuCaps,
if (qemuProcessQMPStart(proc) < 0)
goto cleanup;
+ if (qemuConnectCheckCPUModel(proc->mon, cpus[0]) < 0)
+ goto cleanup;
+
if (VIR_ALLOC(baseline) < 0)
goto cleanup;
@@ -13870,6 +13924,9 @@ qemuConnectCPUModelBaseline(virQEMUCapsPtr qemuCaps,
goto cleanup;
for (i = 1; i < ncpus; i++) {
+ if (qemuConnectCheckCPUModel(proc->mon, cpus[i]) < 0)
+ goto cleanup;
+
if (qemuMonitorGetCPUModelBaseline(proc->mon, baseline,
cpus[i], &result) < 0)
goto cleanup;
--
2.7.4
5 years, 6 months
[libvirt] [PATCH 1/1] qemu_hotplug: use VIR_AUTOUNREF() with virConnectPtr
by Daniel Henrique Barboza
Signed-off-by: Daniel Henrique Barboza <danielhb413(a)gmail.com>
---
Checked other pointer types that can be autounref as well,
just found these instances.
src/qemu/qemu_hotplug.c | 22 ++++++++--------------
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index e9285f0964..4cab132901 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -1154,7 +1154,7 @@ qemuDomainAttachNetDevice(virQEMUDriverPtr driver,
bool charDevPlugged = false;
bool netdevPlugged = false;
VIR_AUTOFREE(char *) netdev_name = NULL;
- virConnectPtr conn = NULL;
+ VIR_AUTOUNREF(virConnectPtr) conn = NULL;
virErrorPtr save_err = NULL;
/* preallocate new slot for device */
@@ -1497,7 +1497,6 @@ qemuDomainAttachNetDevice(virQEMUDriverPtr driver,
}
VIR_FREE(vhostfd);
VIR_FREE(vhostfdName);
- virObjectUnref(conn);
virDomainCCWAddressSetFree(ccwaddrs);
VIR_FORCE_CLOSE(slirpfd);
@@ -3475,7 +3474,7 @@ qemuDomainChangeNet(virQEMUDriverPtr driver,
bool needVlanUpdate = false;
int ret = -1;
int changeidx = -1;
- virConnectPtr conn = NULL;
+ VIR_AUTOUNREF(virConnectPtr) conn = NULL;
virErrorPtr save_err = NULL;
if ((changeidx = virDomainNetFindIdx(vm->def, newdev)) < 0)
@@ -3919,7 +3918,6 @@ qemuDomainChangeNet(virQEMUDriverPtr driver,
*/
if (newdev && newdev->type == VIR_DOMAIN_NET_TYPE_NETWORK && conn)
virDomainNetReleaseActualDevice(conn, vm->def, newdev);
- virObjectUnref(conn);
virErrorRestore(&save_err);
return ret;
@@ -4535,13 +4533,11 @@ qemuDomainRemoveHostDevice(virQEMUDriverPtr driver,
if (net) {
if (net->type == VIR_DOMAIN_NET_TYPE_NETWORK) {
- virConnectPtr conn = virGetConnectNetwork();
- if (conn) {
+ VIR_AUTOUNREF(virConnectPtr) conn = virGetConnectNetwork();
+ if (conn)
virDomainNetReleaseActualDevice(conn, vm->def, net);
- virObjectUnref(conn);
- } else {
+ else
VIR_WARN("Unable to release network device '%s'", NULLSTR(net->ifname));
- }
}
virDomainNetDefFree(net);
}
@@ -4641,13 +4637,11 @@ qemuDomainRemoveNetDevice(virQEMUDriverPtr driver,
qemuDomainNetDeviceVportRemove(net);
if (net->type == VIR_DOMAIN_NET_TYPE_NETWORK) {
- virConnectPtr conn = virGetConnectNetwork();
- if (conn) {
+ VIR_AUTOUNREF(virConnectPtr) conn = virGetConnectNetwork();
+ if (conn)
virDomainNetReleaseActualDevice(conn, vm->def, net);
- virObjectUnref(conn);
- } else {
+ else
VIR_WARN("Unable to release network device '%s'", NULLSTR(net->ifname));
- }
}
virDomainNetDefFree(net);
return 0;
--
2.21.0
5 years, 6 months
[libvirt] [PATCH 00/30] storagefile, security: qcow2 data_file support
by Cole Robinson
This series is the first steps to teaching libvirt about qcow2
data_file support, aka external data files or qcow2 external metadata.
A bit about the feature: it was added in qemu 4.0. It essentially
creates a two part image file: a qcow2 layer that just tracks the
image metadata, and a separate data file which is stores the VM
disk contents. AFAICT the driving use case is to keep a fully coherent
raw disk image on disk, and only use qcow2 as an intermediate metadata
layer when necessary, for things like incremental backup support.
The original qemu patch posting is here:
https://lists.gnu.org/archive/html/qemu-devel/2019-02/msg07496.html
For testing, you can create a new qcow2+raw data_file image from an
existing image, like:
qemu-img convert -O qcow2 \
-o data_file=NEW.raw,data_file_raw=yes
EXISTING.raw NEW.qcow2
The goal of this series is to teach libvirt enough about this case
so that we can correctly relabel the data_file on VM startup/shutdown.
The main functional changes are
* Teach storagefile how to parse out data_file from the qcow2 header
* Store the raw string as virStorageSource->externalDataStoreRaw
* Track that as its out virStorageSource in externalDataStore
* dac/selinux relabel externalDataStore as needed
>From libvirt's perspective, externalDataStore is conceptually pretty
close to a backingStore, but the main difference is its read/write
permissions should match its parent image, rather than being readonly
like backingStore.
This series has only been tested on top of the -blockdev enablement
series, but I don't think it actually interacts with that work at
the moment.
Future work:
* Exposing this in the runtime XML. We need to figure out an XML
schema. It will reuse virStorageSource obviously, but the main
thing to figure out is probably 1) what the top element name
should be ('dataFile' maybe?), 2) where it sits in the XML
hierarchy (under <disk> or under <source> I guess)
* Exposing this on the qemu -blockdev command line. Similar to how
in the blockdev world we are explicitly putting the disk backing
chain on the command line, we can do that for data_file too. Then
like persistent <backingStore> XML the user will have the power
to overwrite the data_file location for an individual VM run.
* Figure out how we expect ovirt/rhev to be using this at runtime.
Possibly taking a running VM using a raw image, doing blockdev-*
magic to pivot it to qcow2+raw data_file, so it can initiate
incremental backup on top of a previously raw only VM?
Known issues:
* In the qemu driver, the qcow2 image metadata is only parsed
in -blockdev world if no <backingStore> is specified in the
persistent XML. So basically if there's a <backingStore> listed,
we never parse the qcow2 header and detect the presence of
data_file. Fixable I'm sure but I didn't look into it much yet.
Most of this is cleanups and refactorings to simplify the actual
functional changes.
Cole Robinson (30):
storagefile: Make GetMetadataInternal static
storagefile: qcow1: Check for BACKING_STORE_OK
storagefile: qcow1: Fix check for empty backing file
storagefile: qcow1: Let qcowXGetBackingStore fill in format
storagefile: Check version to determine if qcow2 or not
storagefile: Drop now unused isQCow2 argument
storagefile: Use qcowXGetBackingStore directly
storagefile: Push 'start' into qcow2GetBackingStoreFormat
storagefile: Push extension_end calc to qcow2GetBackingStoreFormat
storagefile: Rename qcow2GetBackingStoreFormat
storagefile: Rename qcow2GetExtensions 'format' argument
storagefile: Fix backing format \0 check
storagefile: Add externalDataStoreRaw member
storagefile: Parse qcow2 external data file
storagefile: Fill in meta->externalDataStoreRaw
storagefile: Don't access backingStoreRaw directly in
FromBackingRelative
storagefile: Split out virStorageSourceNewFromChild
storagefile: Add externalDataStore member
storagefile: Fill in meta->externalDataStore
security: dac: Drop !parent handling in SetImageLabelInternal
security: dac: Add is_toplevel to SetImageLabelInternal
security: dac: Restore image label for externalDataStore
security: dac: break out SetImageLabelRelative
security: dac: Label externalDataStore
security: selinux: Simplify SetImageLabelInternal
security: selinux: Drop !parent handling in SetImageLabelInternal
security: selinux: Add is_toplevel to SetImageLabelInternal
security: selinux: Restore image label for externalDataStore
security: selinux: break out SetImageLabelRelative
security: selinux: Label externalDataStore
src/libvirt_private.syms | 1 -
src/security/security_dac.c | 63 +++++--
src/security/security_selinux.c | 97 +++++++----
src/util/virstoragefile.c | 281 ++++++++++++++++++++------------
src/util/virstoragefile.h | 11 +-
5 files changed, 290 insertions(+), 163 deletions(-)
--
2.23.0
5 years, 6 months
[libvirt] [PATCH 0/2] Fix build with musl libc
by casantos＠redhat.com
From: Carlos Santos <casantos(a)redhat.com>
- Do not use 'stderr' as a field name, since it's a preprocessor macro
in stdio.h.
- Include paths.h for _PATH_MOUNTED, if it's not defined in mntent.h.
Found while porting libvirt to Buildroot (https://buildroot.org/).
Carlos Santos (2):
qemu: fix build with musl libc
storage: fix build with musl libc
src/qemu/qemu_process.c | 8 ++++----
src/qemu/qemu_process.h | 2 +-
src/storage/storage_backend_fs.c | 3 +++
src/storage/storage_backend_vstorage.c | 3 +++
4 files changed, 11 insertions(+), 5 deletions(-)
--
2.18.1
5 years, 6 months
[libvirt] [PATCH 0/3] docs: hacking: document removed macro replacements (glib chronicles)
by Ján Tomko
Make the GLib section more readable.
Ján Tomko (3):
docs: hacking: separate section about already deleted macros
docs: hacking: use <code> for functions/names
docs: hacking: add a conversion table for removed libvirt macros
docs/hacking.html.in | 71 +++++++++++++++++++++++++++++---------------
1 file changed, 47 insertions(+), 24 deletions(-)
--
2.21.0
5 years, 6 months
