October 2017 - Devel - libvirt List Archives

[libvirt] [PATCH 0/6] qemu: hotplug: Kill duplicated code in disk hotplug (blockdev-add saga)
by Peter Krempa 19 Oct '17

19 Oct '17

A lot of code was copypasted into the three disk attaching functions which are (almost) identical (one was forgotten), without refactoring it first. Let's reduce two copies of the ugly code. BTW this adds support for disk encryption and storage source authentication for USB disks. Peter Krempa (6): qemu: address: Remove dead code when un-reserving PCI address qemu: hotplug: Remove wrong check for empty disks qemu: hotplug: Use disk target in debug/warning messages where appropriate qemu: hotplug: extract disk hotplug worker code qemu: hotplug: Reuse qemuDomainAttachDiskGeneric in qemuDomainAttachSCSIDisk qemu: hotplug: Reuse qemuDomainAttachDiskGeneric in qemuDomainAttachUSBMassStorageDevice src/conf/domain_addr.c | 3 +- src/conf/domain_addr.h | 4 +- src/qemu/qemu_domain_address.c | 7 +- src/qemu/qemu_hotplug.c | 273 ++++++++--------------------------------- 4 files changed, 53 insertions(+), 234 deletions(-) -- 2.14.1

2 7

[libvirt] [PATCH 00/12] qemu: input device hotplug
by Ján Tomko 19 Oct '17

19 Oct '17

https://bugzilla.redhat.com/show_bug.cgi?id=1379603 Ján Tomko (12): conf: audit passthrough input devices at domain startup qemuDomainAttachControllerDevice: remove dead code qemuDomainAttachRNGDevice: do not access source.file randomly Move qemuCheckCCWS390AddressSupport to qemu_domain Split out qemuDomainEnsureVirtioAddress Use qemuDomainEnsureVirtioAddress where possible qemu: allow coldplugging input devices qemu: allow cold unplugging of input devices split out qemuAssignDeviceInputAlias Introduce qemuBuildInputDevStr qemu: implement input device hotplug qemu: implement input device hotunplug src/conf/domain_audit.c | 44 ++++++++ src/conf/domain_audit.h | 5 + src/conf/domain_conf.c | 37 +++++++ src/conf/domain_conf.h | 3 + src/libvirt_private.syms | 3 + src/qemu/qemu_alias.c | 24 ++++- src/qemu/qemu_alias.h | 3 + src/qemu/qemu_command.c | 82 +++++--------- src/qemu/qemu_command.h | 12 ++- src/qemu/qemu_domain.c | 40 +++++++ src/qemu/qemu_domain.h | 5 + src/qemu/qemu_domain_address.c | 45 ++++++++ src/qemu/qemu_domain_address.h | 4 + src/qemu/qemu_driver.c | 25 ++++- src/qemu/qemu_hotplug.c | 239 +++++++++++++++++++++++++++-------------- src/qemu/qemu_hotplug.h | 8 ++ 16 files changed, 436 insertions(+), 143 deletions(-) -- 2.13.0

2 20

[libvirt] [PATCH] fix error message spacing in qemuDomainDetachNetDevice
by Ján Tomko 19 Oct '17

19 Oct '17

Move the space after the colon. --- Pushed as trivial, suggested by John in review: https://www.redhat.com/archives/libvir-list/2017-October/msg00833.html src/qemu/qemu_hotplug.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c index 57240ce67..1a0844701 100644 --- a/src/qemu/qemu_hotplug.c +++ b/src/qemu/qemu_hotplug.c @@ -5219,7 +5219,7 @@ qemuDomainDetachNetDevice(virQEMUDriverPtr driver, if (qemuIsMultiFunctionDevice(vm->def, &detach->info)) { virReportError(VIR_ERR_OPERATION_FAILED, - _("cannot hot unplug multifunction PCI device :%s"), + _("cannot hot unplug multifunction PCI device: %s"), dev->data.disk->dst); goto cleanup; } -- 2.13.0

1 0

[libvirt] How can I tell if I'm using qemu-kvm or qemu-kvm-ev from libvirt Python binding?
by Yaniv Kaul 19 Oct '17

19 Oct '17

I'm trying to (optionally) use iothreads, which only exist on qemu-kvm-ev. I was hoping to see it in the domcapabilities, but I don't see it there. How do I know if it's supported or not? TIA, Y.

3 3

[libvirt] [PATCH 0/2] More hotplug cleanups
by Ján Tomko 19 Oct '17

19 Oct '17

Remove some dead code. Ján Tomko (2): qemuIsMultiFunctionDevice: return early for non-PCI addresses qemu: remove pointless address validation on hot unplug src/qemu/qemu_hotplug.c | 56 ++++++++----------------------------------------- 1 file changed, 9 insertions(+), 47 deletions(-) -- 2.13.0

2 4

[libvirt] [PATCH v6 0/9] Work around the kernel mdev uevent race in nodedev
by Erik Skultety 19 Oct '17

19 Oct '17

v5 here: https://www.redhat.com/archives/libvir-list/2017-October/msg00440.html Since v5: - fixed minor nitpicks - added 3 more patches as per reviewer's suggestion to split some of the changes even more - patches {2,6,7,8,9}/9 are without any change Erik Skultety (9): nodedev: Move privileged flag from udev private data to driver's state (NEW) nodedev: udev: Introduce udevEventMonitorSanityCheck helper function (ACKed) nodedev: udev: Convert udev private data to a lockable object (ACKed with fixes) nodedev: udev: Remove driver locks from stateInitialize and (NEW) stateCleanup nodedev: udev: Unlock the private data before setting up 'system' node (NEW) nodedev: udev: Split udevEventHandleCallback in two functions (ACKed) nodedev: udev: Convert udevEventHandleThread to an actual thread (ACKed) routine util: Introduce virFileWaitForExists (ACKed) nodedev: udev: Hook up virFileWaitForAccess to work around uevent race (ACKed) src/conf/virnodedeviceobj.h | 1 + src/libvirt_private.syms | 1 + src/node_device/node_device_udev.c | 283 +++++++++++++++++++++++++++---------- src/node_device/node_device_udev.h | 3 - src/util/virfile.c | 31 ++++ src/util/virfile.h | 2 + 6 files changed, 245 insertions(+), 76 deletions(-) -- 2.13.6

2 14

[libvirt] [PATCH 00/14] introduce virDomainSetLifecycleAction() API
by Pavel Hrdina 19 Oct '17

19 Oct '17

Pavel Hrdina (14): conf: rename lifecycle enum values to correspond with typedef keyword conf: rename virDomainLifecycleAction enum functions conf: introduce virDomainLifecycle enum to list all lifecycle types conf: merge virDomainLifecycleCrashAction with virDomainLifecycleAction qemu: pass virDomainObjPtr to qemuBuildCommandLine qemu: pass priv data to qemuBuildMonitorCommandLine qemu: pass priv data to qemuBuildPMCommandLine qemu: pass priv data to qemuBuildMasterKeyCommandLine qemu: pass priv data instead of qemuCaps and autoNodeset lib: introduce virDomainSetLifecycleAction() API virsh: introduce set-lifecycle-action command qemu: move detection whether to use -no-reboot to qemu_domain qemu: send allowReboot in migration cookie qemu: implement virDomainSetLifecycleAction() API docs/formatdomain.html.in | 6 +++ include/libvirt/libvirt-domain.h | 28 ++++++++++ src/conf/domain_conf.c | 84 ++++++++++++++++++++++++----- src/conf/domain_conf.h | 26 ++------- src/driver-hypervisor.h | 7 +++ src/libvirt-domain.c | 60 +++++++++++++++++++++ src/libvirt_private.syms | 7 ++- src/libvirt_public.syms | 5 ++ src/libxl/libxl_conf.c | 43 ++++----------- src/libxl/libxl_domain.c | 40 +++++++------- src/lxc/lxc_native.c | 6 +-- src/qemu/qemu_command.c | 93 +++++++++++++------------------- src/qemu/qemu_command.h | 11 +--- src/qemu/qemu_domain.c | 40 ++++++++++++++ src/qemu/qemu_domain.h | 9 ++++ src/qemu/qemu_driver.c | 112 +++++++++++++++++++++++++++++++++++---- src/qemu/qemu_migration.c | 7 ++- src/qemu/qemu_migration_cookie.c | 25 ++++++++- src/qemu/qemu_migration_cookie.h | 5 ++ src/qemu/qemu_parse_command.c | 8 +-- src/qemu/qemu_process.c | 53 ++++++++++++------ src/remote/remote_driver.c | 1 + src/remote/remote_protocol.x | 14 ++++- src/test/test_driver.c | 8 +-- src/vmx/vmx.c | 6 +-- src/vz/vz_sdk.c | 12 ++--- src/xenapi/xenapi_utils.c | 40 +++++++------- src/xenapi/xenapi_utils.h | 4 +- src/xenconfig/xen_common.c | 12 ++--- src/xenconfig/xen_sxpr.c | 18 +++---- tests/qemuxml2xmltest.c | 3 +- tools/virsh-domain.c | 102 +++++++++++++++++++++++++++++++++++ tools/virsh.pod | 7 +++ 33 files changed, 658 insertions(+), 244 deletions(-) -- 2.13.6

2 22

[libvirt] [PATCH] bhyve: Fix build
by Jiri Denemark 19 Oct '17

19 Oct '17

Commit v3.8.0-95-gfd885a06a dropped nmodels parameter from several APIs in src/cpu/cpu.h, but failed to update all callers. Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- Pushed under the build-breaker rule. src/bhyve/bhyve_driver.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/bhyve/bhyve_driver.c b/src/bhyve/bhyve_driver.c index c096b5562..5c432b25e 100644 --- a/src/bhyve/bhyve_driver.c +++ b/src/bhyve/bhyve_driver.c @@ -1433,7 +1433,7 @@ bhyveConnectBaselineCPU(virConnectPtr conn, if (!(cpus = virCPUDefListParse(xmlCPUs, ncpus, VIR_CPU_TYPE_HOST))) goto cleanup; - if (!(cpu = cpuBaseline(cpus, ncpus, NULL, 0, + if (!(cpu = cpuBaseline(cpus, ncpus, NULL, !!(flags & VIR_CONNECT_BASELINE_CPU_MIGRATABLE)))) goto cleanup; -- 2.14.2

1 0

[libvirt] [CFP] Virt & IaaS Devroom at FOSDEM18
by Stefan Hajnoczi 18 Oct '17

18 Oct '17

I am excited to announce that the call for proposals is now open for the Virtualization & IaaS devroom at the upcoming FOSDEM 2018, to be hosted on February 3 and 4, 2018. This year will mark FOSDEM’s 18th 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 3 & 4, 2018. This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, oVirt, QEMU, KVM, libvirt, and Foreman. We would like to invite all those who are involved in these fields to submit your proposals by December 1st, 2017. 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, bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as Apache CloudStack, OpenStack, oVirt, QEMU, OpenNebula, and Ganeti. This devroom will host presentations that focus on topics of shared interest, such as KVM; 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. Important Dates Submission deadline: 01 December 2017 Acceptance notifications: 14 December 2017 Final schedule announcement: 21 December 2017 Devroom: 03 and 04 February 2018 (two days- different rooms) 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 45 minutes, with 35 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) Submission Guidelines 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. Call for Mentors Interested in mentoring newcomer speakers? We'd love to have your help! Please email iaas-virt-devroom at lists.fosdem.org with a short speaker biography and any specific fields of expertise (for example, KVM, OpenStack, storage, etc.) so that we can match you with a newcomer speaker from a similar field. Estimated time investment can be as low as a 5-10 hours in total, usually distributed weekly or bi-weekly. Never mentored a newcomer speaker but interested to try? As the mentoring program coordinator, email Brian Proffitt[3] and he will be happy to answer your questions! 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 me, Brian Proffitt, 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://penta.fosdem.org/submission/FOSDEM18> https://penta.fosdem.org/submission/FOSDEM18 [2] iaas-virt-devroom at lists.fosdem.org <https://lists.fosdem.org/listinfo/fosdem> [3] bkp at redhat.com

1 0

[libvirt] [PATCH] virsh: domifaddr: clarify description of --full option
by Chen Hanxiao 18 Oct '17

18 Oct '17

From: Chen Hanxiao <chenhanxiao(a)gmail.com> Option --full will always display the name and MAC address of the interface. Both virsh help and virsh man page didn't mention that. Signed-off-by: Chen Hanxiao <chenhanxiao(a)gmail.com> --- tools/virsh-domain-monitor.c | 2 +- tools/virsh.pod | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/virsh-domain-monitor.c b/tools/virsh-domain-monitor.c index 4c50155e1..35d04b22a 100644 --- a/tools/virsh-domain-monitor.c +++ b/tools/virsh-domain-monitor.c @@ -2153,7 +2153,7 @@ static const vshCmdOptDef opts_domifaddr[] = { {.name = "full", .type = VSH_OT_BOOL, .flags = VSH_OFLAG_NONE, - .help = N_("display full fields")}, + .help = N_("always display names and MACs of interfaces")}, {.name = "source", .type = VSH_OT_STRING, .flags = VSH_OFLAG_NONE, diff --git a/tools/virsh.pod b/tools/virsh.pod index 9304ca525..db1ede880 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -766,9 +766,9 @@ addresses, or limited output just for one interface if I<interface> is specified. Note that I<interface> can be driver dependent, it can be the name within guest OS or the name you would see in domain XML. Moreover, the whole command may require a guest agent to be configured for the queried domain under -some drivers, notably qemu. If I<--full> is specified, the interface name is -always displayed when the interface has multiple addresses or alias, otherwise -it only displays the interface name for the first address, and "-" for the +some drivers, notably qemu. If I<--full> is specified, the interface name and MAC +address is always displayed when the interface has multiple addresses or alias, +otherwise it only displays the interface name for the first address, and "-" for the others. The I<--source> argument specifies what data source to use for the addresses, currently one of 'lease' to read DHCP leases, or 'agent' to query the guest OS via an agent. If unspecified, 'lease' is the default. -- 2.13.5

2 1