- Devel - libvirt List Archives

[libvirt] [PATCH 0/6] Hyper-V method invocation support
by Sri Ramanujam 19 Apr '17

19 Apr '17

This patchset introduces functionality to support invoking Hyper-V methods over WMI. It also includes implementations for virDomainSendKey and virDomainSetMemory as examples of how to use the new functionality. With this patchset, all the pieces should be in place to implement all parts of the driver. I've got about 30 functions pending, to be submitted after this patchset is ACKed. Additionally, this patchset includes a new function under util that converts numbers into their string representation. There is a variant for both signed and unsigned numbers. Since everything must be represented as a string at the XML layer, this function comes in handy throughout the Hyper-V driver and I thought it would have some utility as a convenience method for the whole project. Sri Ramanujam (6): hyperv: Functions to work with invocation parameters. hyperv: Generate object property type information. hyperv: add hypervInvokeMethod hyperv: support virDomainSendKey util: add virNumToStr hyperv: Add support for virDomainSetMemory src/hyperv/hyperv_driver.c | 182 +++++++ src/hyperv/hyperv_wmi.c | 879 ++++++++++++++++++++++++++++++++++ src/hyperv/hyperv_wmi.h | 93 +++- src/hyperv/hyperv_wmi_classes.h | 19 + src/hyperv/hyperv_wmi_generator.input | 116 +++++ src/hyperv/hyperv_wmi_generator.py | 15 +- src/hyperv/openwsman.h | 4 + src/util/virstring.c | 34 ++ src/util/virstring.h | 8 + 9 files changed, 1348 insertions(+), 2 deletions(-) -- 2.9.3

2 8

[libvirt] [PATCH v3] hyperv: recognize array property as distinct type.
by Dawid Zamirski 19 Apr '17

19 Apr '17

When hyperv code generator for WMI classes identifies common properties, it needs to take into account array type as a distinct type, i.e string != string[]. This is the case where v1 of the Msvm_VirtualSystemSettingData has Notes property as string whereas v2 uses Notes[], therefore they have to be treated as different fields and cannot be placed in the "common" struct. --- changes in v3: * add virBufferCheckError before calling virBufferContentAndReset. src/hyperv/hyperv_driver.c | 28 ++++++++++++++++++++++++++-- src/hyperv/hyperv_wmi_generator.py | 2 +- 2 files changed, 27 insertions(+), 3 deletions(-) diff --git a/src/hyperv/hyperv_driver.c b/src/hyperv/hyperv_driver.c index 090ea24..8e5eeda 100644 --- a/src/hyperv/hyperv_driver.c +++ b/src/hyperv/hyperv_driver.c @@ -894,8 +894,32 @@ hypervDomainGetXMLDesc(virDomainPtr domain, unsigned int flags) if (VIR_STRDUP(def->name, computerSystem->data.common->ElementName) < 0) goto cleanup; - if (VIR_STRDUP(def->description, virtualSystemSettingData->data.common->Notes) < 0) - goto cleanup; + if (priv->wmiVersion == HYPERV_WMI_VERSION_V1) { + if (VIR_STRDUP(def->description, + virtualSystemSettingData->data.v1->Notes) < 0) + goto cleanup; + } else if (priv->wmiVersion == HYPERV_WMI_VERSION_V2 && + virtualSystemSettingData->data.v2->Notes.data != NULL) { + char **notes = (char **) virtualSystemSettingData->data.v2->Notes.data; + virBuffer buf = VIR_BUFFER_INITIALIZER; + size_t i = 0; + + /* in practice Notes has 1 element */ + for (i = 0; i < virtualSystemSettingData->data.v2->Notes.count; i++) { + /* but if there's more than 1, separate by double new line */ + if (virBufferUse(&buf) > 0) + virBufferAddLit(&buf, "\n\n"); + + virBufferAdd(&buf, *notes, -1); + notes++; + } + + if (virBufferCheckError(&buf)) + cleanup; + + def->description = virBufferContentAndReset(&buf); + } + virDomainDefSetMemoryTotal(def, memorySettingData->data.common->Limit * 1024); /* megabyte to kilobyte */ def->mem.cur_balloon = memorySettingData->data.common->VirtualQuantity * 1024; /* megabyte to kilobyte */ diff --git a/src/hyperv/hyperv_wmi_generator.py b/src/hyperv/hyperv_wmi_generator.py index c15d97a..9aee0b9 100755 --- a/src/hyperv/hyperv_wmi_generator.py +++ b/src/hyperv/hyperv_wmi_generator.py @@ -251,7 +251,7 @@ class WmiClass: for cls in self.versions: for prop in cls.properties: # consdered same if matches by name AND type - key = "%s_%s" % (prop.name, prop.type) + key = "%s_%s_%s" % (prop.name, prop.type, prop.is_array) if key in property_info: property_info[key][1] += 1 -- 2.9.3

2 1

[libvirt] [PATCH] xenconfig: avoid double free on OOM testing
by Jim Fehlig 19 Apr '17

19 Apr '17

Fix xlconfig channel tests when OOM testing is enabled. TEST: xlconfigtest 32) Xen XL-2-XML Format channel-unix ... OK Test OOM for nalloc=55 ................................................*** Error in `/home/jfehlig/virt/upstream/libvirt/tests/.libs/xlconfigtest': double free or corruption (fasttop): 0x0000000000679550 *** ... (gdb) bt #0 0x00007ffff36875af in raise () from /lib64/libc.so.6 #1 0x00007ffff36889aa in abort () from /lib64/libc.so.6 #2 0x00007ffff36c5150 in __libc_message () from /lib64/libc.so.6 #3 0x00007ffff36cb4f6 in malloc_printerr () from /lib64/libc.so.6 #4 0x00007ffff36cbcee in _int_free () from /lib64/libc.so.6 #5 0x00007ffff782babf in virFree (ptrptr=0x7fffffffdca8) at util/viralloc.c:582 #6 0x000000000042f2f3 in xenParseXLChannel (conf=0x677350, def=0x6815b0) at xenconfig/xen_xl.c:788 #7 0x000000000042f44e in xenParseXL (conf=0x677350, caps=0x6832b0, xmlopt=0x67f6e0) at xenconfig/xen_xl.c:828 #8 0x00000000004105a3 in testCompareFormatXML ( xlcfg=0x6811e0 "/home/jfehlig/virt/upstream/libvirt/tests/xlconfigdata/test-channel-unix.cfg", xml=0x681110 "/home/jfehlig/virt/upstream/libvirt/tests/xlconfigdata/test-channel-unix.xml", replaceVars=false) at xlconfigtest.c:152 When a channel is successfully parsed and its path and name fields assigned from local variables, set the local variables to NULL to prevent a double free on error. Signed-off-by: Jim Fehlig <jfehlig(a)suse.com> --- src/xenconfig/xen_xl.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/xenconfig/xen_xl.c b/src/xenconfig/xen_xl.c index 43ecf4114..a5b342a86 100644 --- a/src/xenconfig/xen_xl.c +++ b/src/xenconfig/xen_xl.c @@ -759,8 +759,9 @@ xenParseXLChannel(virConfPtr conf, virDomainDefPtr def) if (STRPREFIX(type, "socket")) { channel->source->type = VIR_DOMAIN_CHR_TYPE_UNIX; - channel->source->data.nix.path = path; channel->source->data.nix.listen = 1; + channel->source->data.nix.path = path; + path = NULL; } else if (STRPREFIX(type, "pty")) { channel->source->type = VIR_DOMAIN_CHR_TYPE_PTY; VIR_FREE(path); @@ -771,6 +772,7 @@ xenParseXLChannel(virConfPtr conf, virDomainDefPtr def) channel->deviceType = VIR_DOMAIN_CHR_DEVICE_TYPE_CHANNEL; channel->targetType = VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_XEN; channel->target.name = name; + name = NULL; if (VIR_APPEND_ELEMENT(def->channels, def->nchannels, channel) < 0) goto cleanup; -- 2.11.0

2 2

[libvirt] VHPC at ISC extension - Papers due May 2
by VHPC 17 19 Apr '17

19 Apr '17

==================================================================== CALL FOR PAPERS 12th Workshop on Virtualization in High-Performance Cloud Computing (VHPC '17) held in conjunction with the International Supercomputing Conference - High Performance, June 18-22, 2017, Frankfurt, Germany. (Springer LNCS Proceedings) ==================================================================== Date: June 22, 2017 Workshop URL: http://vhpc.org Paper Submission Deadline: May 2, 2017 (extended), Springer LNCS, rolling abstract submission Abstract/Paper Submission Link: https://edas.info/newPaper.php?c=23179 Keynotes: Satoshi Matsuoka, Professor of Computer Science, Tokyo Institute of Technology and John Goodacre, Professor in Computer Architectures University of Manchester, Director of Technology and Systems ARM Ltd. Research Group and Chief Scientific Officer Kaleao Ltd. Call for Papers Virtualization technologies constitute a key enabling factor for flexible resource management in modern data centers, and particularly in cloud environments. Cloud providers need to manage complex infrastructures in a seamless fashion to support the highly dynamic and heterogeneous workloads and hosted applications customers deploy. Similarly, HPC environments have been increasingly adopting techniques that enable flexible management of vast computing and networking resources, close to marginal provisioning cost, which is unprecedented in the history of scientific and commercial computing. Various virtualization technologies contribute to the overall picture in different ways: machine virtualization, with its capability to enable consolidation of multiple underutilized servers with heterogeneous software and operating systems (OSes), and its capability to live-migrate a fully operating virtual machine (VM) with a very short downtime, enables novel and dynamic ways to manage physical servers; OS-level virtualization (i.e., containerization), with its capability to isolate multiple user-space environments and to allow for their coexistence within the same OS kernel, promises to provide many of the advantages of machine virtualization with high levels of responsiveness and performance; I/O Virtualization allows physical NICs/HBAs to take traffic from multiple VMs or containers; network virtualization, with its capability to create logical network overlays that are independent of the underlying physical topology and IP addressing, provides the fundamental ground on top of which evolved network services can be realized with an unprecedented level of dynamicity and flexibility; the increasingly adopted paradigm of Software-Defined Networking (SDN) promises to extend this flexibility to the control and data planes of network paths. Publication Accepted papers will be published in a Springer LNCS proceedings volume. Topics of Interest The VHPC program committee solicits original, high-quality submissions related to virtualization across the entire software stack with a special focus on the intersection of HPC and the cloud. Major Topics - Virtualization in supercomputing environments, HPC clusters, HPC in the cloud and grids - OS-level virtualization and containers (Docker, rkt, Singularity, Shifter, i.a.) - Lightweight/specialized operating systems, unikernels - Optimizations of virtual machine monitor platforms and hypervisors - Hypervisor support for heterogenous resources (GPUs, co-processors, FPGAs, etc.) - Virtualization support for emerging memory technologies - Virtualization in enterprise HPC and microvisors - Software defined networks and network virtualization - Management, deployment of virtualized environments and orchestration (Kubernetes i.a.), - Workflow-pipeline container-based composability - Performance measurement, modelling and monitoring of virtualized/cloud workloads - Virtualization in data intensive computing and Big Data processing - HPC convergence - Adaptation of HPC technologies in the cloud (high performance networks, RDMA, etc.) - ARM-based hypervisors, ARM virtualization extensions - I/O virtualization and cloud based storage systems - GPU, FPGA and many-core accelerator virtualization - Job scheduling/control/policy and container placement in virtualized environments - Cloud reliability, fault-tolerance and high-availability - QoS and SLA in virtualized environments - IaaS platforms, cloud frameworks and APIs - Large-scale virtualization in domains such as finance and government - Energy-efficient and power-aware virtualization - Container security - Configuration management tools for containers (including CFEngine, Puppet, i.a.) - Emerging topics including multi-kernel approaches and,NUMA in hypervisors The Workshop on Virtualization in High-Performance Cloud Computing (VHPC) aims to bring together researchers and industrial practitioners facing the challenges posed by virtualization in order to foster discussion, collaboration, mutual exchange of knowledge and experience, enabling research to ultimately provide novel solutions for virtualized computing systems of tomorrow. The workshop will be one day in length, composed of 20 min paper presentations, each followed by 10 min discussion sections, plus lightning talks that are limited to 5 minutes. Presentations may be accompanied by interactive demonstrations. Important Dates Rolling Abstract Submission May 2, 2017 - Paper submission deadline (extended) May 30, 2017 - Acceptance notification June 22, 2017 - Workshop Day July 18, 2017 - Camera-ready version due Chair Michael Alexander (chair), scaledinfra technologies, Austria Anastassios Nanos (co-chair), NTUA, Greece Balazs Gerofi (co-chair), RIKEN Advanced Institute for Computational Science, Japan Program committee Stergios Anastasiadis, University of Ioannina, Greece Jakob Blomer, CERN, Europe Ron Brightwell, Sandia National Laboratories, USA Eduardo César, Universidad Autonoma de Barcelona, Spain Julian Chesterfield, OnApp, UK Stephen Crago, USC ISI, USA Christoffer Dall, Columbia University, USA Patrick Dreher, MIT, USA Robert Futrick, Cycle Computing, USA Maria Girone, CERN, Europe Kyle Hale, Northwestern University, USA Romeo Kinzler, IBM, Switzerland Brian Kocoloski, University of Pittsburgh, USA Nectarios Koziris, National Technical University of Athens, Greece John Lange, University of Pittsburgh, USA Che-Rung Lee, National Tsing Hua University, Taiwan Giuseppe Lettieri, University of Pisa, Italy Qing Liu, Oak Ridge National Laboratory, USA Nikos Parlavantzas, IRISA, France Kevin Pedretti, Sandia National Laboratories, USA Amer Qouneh, University of Florida, USA Carlos Reaño, Technical University of Valencia, Spain Thomas Ryd, CFEngine, Norway Na Zhang, VMWare, USA Borja Sotomayor, University of Chicago, USA Craig Stewart, Indiana University, USA Anata Tiwari, San Diego Supercomputer Center, USA Kurt Tutschku, Blekinge Institute of Technology, Sweden Yasuhiro Watashiba, Osaka University, Japan Nicholas Wright, Lawrence Berkeley National Laboratory, USA Chao-Tung Yang, Tunghai University, Taiwan Paper Submission-Publication Papers submitted to the workshop will be reviewed by at least two members of the program committee and external reviewers. Submissions should include abstract, key words, the e-mail address of the corresponding author, and must not exceed 10 pages, including tables and figures at a main font size no smaller than 11 point. Submission of a paper should be regarded as a commitment that, should the paper be accepted, at least one of the authors will register and attend the conference to present the work. Accepted papers will be published in a Springer LNCS volume. . The format must be according to the Springer LNCS Style. Initial submissions are in PDF; authors of accepted papers will be requested to provide source files. Format Guidelines: ftp://ftp.springer.de/pub/tex/latex/llncs/latex2e/llncs2e.zip Abstract, Paper Submission Link: https://edas.info/newPaper.php?c=23179 Lightning Talks Lightning Talks are non-paper track, synoptical in nature and are strictly limited to 5 minutes. They can be used to gain early feedback on ongoing research, for demonstrations, to present research results, early research ideas, perspectives and positions of interest to the community. Submit abstract via the main submission link. General Information The workshop is one day in length and will be held in conjunction with the International Supercomputing Conference - High Performance (ISC) 2017, June 18-22, Frankfurt, Germany.

1 0

[libvirt] [RFC PATCH 00/11] Add mdev reporting capability to the nodedev driver
by Erik Skultety 19 Apr '17

19 Apr '17

This series enables the node device driver to report information about the existing mediated devices on the host. There is no device creation involved yet. The information reported by the node device driver is split into two parts, one that is reported within the physical parent's capabilities (the generic stuff that comes from the mdev types' sysfs attributes, note the 'description' attribute which is verbatim - raw,unstructured string) and the other that is reported within the mdev child device and merely contains the mdev type id, which the device was instantiated from, and the iommu group number. Basically, the format of the XML I went for is as follows: PCI parent: <device> <name>pci_0000_06_00_0</name> <path>/sys/devices/.../0000:06:00.0</path> <parent>pci_0000_05_08_0</parent> ... <capability type='pci'> ... <capability type='mdev'> <type id='nvidia-11'> <name>GRID M60-0B</name> <description>num_heads=2, frl_config=45, framebuffer=512M, max_resolution=2560x1600, max_instance=16</description> <device_api>vfio-pci</device_api> <available_instances>16</available_instances> </type> ... </capability> <iommuGroup number='20'> <address domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </iommuGroup> ... </capability> </device> mdev child: <device> <name>mdev_ef1212ff_ff23_4534_ffcd_01ff12017801</name> <path>/sys/devices/.../ef1212ff-ff23-4534-ffcd-01ff12017801</path> <parent>pci_0000_06_00_0</parent> <driver> <name>vfio_mdev</name> </driver> <capability type='mdev'> <type id='nvidia-18'/> <iommuGroup number='63'/> </capability> </device> Also, since we didn't have any node device driver documentation, I created a stub (comments are very welcome, you can shred it to pieces ;)) focusing on the PCI devices and then adding the mdev part into that. As I said, it's still a stub that needs lots of work on it, namely adding USBs and SCSI devices, but I figured that the fact some parts are missing should not be a show stopper for the nodedev-mdev patches. Thanks, Erik Erik Skultety (11): nodedev: Fix guideline violations in nodedev modules nodedev: Make use of the compile-time missing enum in switch error conf: nodedev: Split virNodeDeviceDefFormat into more functions nodedev: udevProcessPCI: Drop syspath variable docs: Use our XSLT template to generate list of supported pool types nodedev: Introduce the mdev capability to the nodedev driver structure nodedev: Fill in the mdev info for the parent PCI device nodedev: Introduce udevProcessMediatedDevice nodedev: Format the mdev capability of the PCI parent device docs: Provide a nodedev driver stub documentation docs: Document the mediated devices within the nodedev driver docs/drivers.html.in | 6 +- docs/drvnodedev.html.in | 275 +++++++++++++ docs/storage.html.in | 62 +-- include/libvirt/libvirt-nodedev.h | 1 + src/conf/node_device_conf.c | 625 ++++++++++++++++++------------ src/conf/node_device_conf.h | 21 +- src/conf/virnodedeviceobj.c | 3 +- src/libvirt-nodedev.c | 1 + src/libvirt_private.syms | 1 + src/node_device/node_device_driver.c | 30 +- src/node_device/node_device_driver.h | 82 ++-- src/node_device/node_device_hal.c | 9 + src/node_device/node_device_linux_sysfs.c | 1 + src/node_device/node_device_linux_sysfs.h | 9 +- src/node_device/node_device_udev.c | 456 ++++++++++++++++------ tools/virsh-nodedev.c | 2 + 16 files changed, 1110 insertions(+), 474 deletions(-) create mode 100644 docs/drvnodedev.html.in -- 2.12.2

6 29

[libvirt] Trouble with virsh on Windows
by Charles Bancroft 19 Apr '17

19 Apr '17

Hi List, I have a question about some troubles I am having with virsh on Windows x64. I am currently running a KVM server on a linux box and need to allow Windows clients to access it. I have set up the server for access with: ``` listen_tls = 0 listen_tcp = 1 auth_tcp = "none" ``` to allow for remote access while testing things. I have verified that I can connect remotely from other linux machines, but my windows machine always reports: ``` error: failed to connect to the hypervisor error: An error occurred, but the cause is unknown ``` On the server side I see: ``` 10435: error : virNetSocketReadWire:1793 : Cannot recv data: Connection reset by peer ``` This happens no matter what build of virsh for windows I am using. I have tried 3 different mingw-64 builds and versions and am about to just build my own from scratch. I have verified that it is not the firewall or the version of Windows I am using. I am also able to use virsh within a docker or from the Windows Subsystem for Linux bash prompt. Any ideas as to what could be causing this connection reset? It happens as soon as a connection attempt occurs and I am running out of idea. Thanks! Charles Bancroft Principal Scientist Siege Technologies

2 6

[libvirt] [PATCH v2 0/2] Use the shared keycodemap database
by Daniel P. Berrange 19 Apr '17

19 Apr '17

Changed in v2: - Fixed make syntax-check errors - Auto-generate man pages listing value key codes for use with the virDomainSendKey API / virsh send-key command Daniel P. Berrange (2): util: switch over to use keycodemapdb GIT submodule Add ability to generate man page describing key code names & values .gitignore | 3 +- .gitmodules | 3 + libvirt.spec.in | 1 + mingw-libvirt.spec.in | 2 + src/Makefile.am | 81 ++++++-- src/keycodemapdb | 1 + src/util/keymaps.csv | 464 ------------------------------------------ src/util/virkeycode-mapgen.py | 97 --------- src/util/virkeycode.c | 94 ++++----- tests/virkeycodetest.c | 5 + tools/virsh.pod | 20 ++ 11 files changed, 148 insertions(+), 623 deletions(-) create mode 160000 src/keycodemapdb delete mode 100644 src/util/keymaps.csv delete mode 100755 src/util/virkeycode-mapgen.py -- 2.9.3

2 9

[libvirt] [REPOST PATCH 0/5] Split out network object into its own module
by John Ferlan 18 Apr '17

18 Apr '17

Reposting with update to top of git tree commit id '0563d3f06' from: https://www.redhat.com/archives/libvir-list/2017-March/msg00892.html Previous cover letter - cut-n-pasted: Reached the last of the code from my RFC for making a common pool object - networkobj... For reference see patch 3 of: http://www.redhat.com/archives/libvir-list/2017-February/msg00519.html This series works through the network conf adjustments. This pile is fairly straightforward, like other series we split out anything referencing virNetworkPoolObj and go from there. There was one small detour to avoid a potentially conflict in names. John Ferlan (5): conf: Introduce virnetworkobj conf: Adjust coding style for network conf sources conf: Alter coding style of network conf function prototypes conf: Rename virNetworkObjAssignDef to virNetworkObjUpdateAssignDef conf: Use consistent function name prefixes for virnetworkobj po/POTFILES.in | 1 + src/Makefile.am | 3 +- src/conf/network_conf.c | 1388 ++-------------------------------- src/conf/network_conf.h | 204 ++--- src/conf/virnetworkobj.c | 1372 +++++++++++++++++++++++++++++++++ src/conf/virnetworkobj.h | 185 +++++ src/libvirt_private.syms | 57 +- src/network/bridge_driver.c | 62 +- src/network/bridge_driver.h | 2 +- src/network/bridge_driver_platform.h | 2 +- src/test/test_driver.c | 16 +- 11 files changed, 1763 insertions(+), 1529 deletions(-) create mode 100644 src/conf/virnetworkobj.c create mode 100644 src/conf/virnetworkobj.h -- 2.9.3

2 6

[libvirt] [PATCH 00/38] Implement sparse streams for libvirt
by Michal Privoznik 18 Apr '17

18 Apr '17

There were already some attempts to do this in the past, but neither of them was successful. Anyway, let me just show you how good these perform: 7.9G -rw-r--r-- 1 root root 21G Feb 15 14:04 /var/lib/libvirt/images/gentoo.qcow2 libvirt.git # time virsh vol-download --sparse /var/lib/libvirt/images/gentoo.qcow2 /mnt/floppy/gentoo.qcow2 real 0m41.627s user 0m3.880s sys 0m5.720s libvirt.git # time virsh vol-download /var/lib/libvirt/images/gentoo.qcow2 /mnt/floppy/gentoo.qcow2 real 2m22.357s user 1m20.590s sys 0m12.510s All the patches can be found on my github: https://github.com/zippy2/libvirt/tree/sparse_iohelper5 (Yes, weird name, but there were plenty of local attempts to implement this and I'm not throwing them away until the feature is merged) Michal Privoznik (38): fdstreamtest: Rename tempdir fdstreamtest: Print more info on read failure fdstream: s/struct virFDStreamData */virFDStreamDataPtr/ virFDStreamData: Turn into virObjectLockable virfdstream: Drop iohelper in favour of a thread virfdstream: Use messages instead of pipe iohelper: Remove unused mode util: Introduce virFileInData Introduce virStreamRecvFlags Implement virStreamRecvFlags to some drivers Introduce virStreamSkip Introduce virStreamHoleSize Introduce VIR_STREAM_RECV_STOP_AT_HOLE flag Introduce virStreamSparseRecvAll Introduce virStreamSparseSendAll Introduce virStreamInData virNetClientStreamNew: Track origin stream Track if stream is skippable RPC: Introduce virNetStreamSkip Introduce VIR_NET_STREAM_SKIP message type Teach wireshark plugin about VIR_NET_STREAM_SKIP daemon: Introduce virNetServerProgramSendStreamSkip virnetclientstream: Introduce virNetClientStreamSendSkip daemon: Implement VIR_NET_STREAM_SKIP handling virnetclientstream: Introduce virNetClientStreamHandleSkip remote_driver: Implement virStreamSkip virNetClientStreamRecvPacket: Introduce @flags argument Introduce virNetClientStreamHoleSize remote: Implement virStreamHoleSize virNetClientStream: Wire up VIR_NET_STREAM_SKIP remote_driver: Implement VIR_STREAM_RECV_STOP_AT_HOLE daemonStreamHandleRead: Wire up seekable stream daemon: Don't call virStreamInData so often fdstream: Implement sparse stream gendispatch: Introduce @sparseflag for our calls Introduce virStorageVol{Download,Upload}Flags virsh: Implement sparse stream to vol-download virsh: Implement sparse stream to vol-upload daemon/remote.c | 2 +- daemon/stream.c | 147 +++++- daemon/stream.h | 3 +- include/libvirt/libvirt-storage.h | 9 + include/libvirt/libvirt-stream.h | 86 +++- src/driver-stream.h | 23 + src/esx/esx_stream.c | 16 +- src/libvirt-storage.c | 4 +- src/libvirt-stream.c | 453 ++++++++++++++++++ src/libvirt_internal.h | 3 + src/libvirt_private.syms | 2 + src/libvirt_public.syms | 9 + src/libvirt_remote.syms | 3 + src/remote/remote_driver.c | 89 +++- src/remote/remote_protocol.x | 2 + src/rpc/gendispatch.pl | 21 +- src/rpc/virnetclient.c | 1 + src/rpc/virnetclientstream.c | 202 +++++++- src/rpc/virnetclientstream.h | 17 +- src/rpc/virnetprotocol.x | 16 +- src/rpc/virnetserverprogram.c | 33 ++ src/rpc/virnetserverprogram.h | 7 + src/storage/storage_driver.c | 4 +- src/storage/storage_util.c | 10 +- src/util/iohelper.c | 72 +-- src/util/virfdstream.c | 888 ++++++++++++++++++++++++++++------- src/util/virfdstream.h | 2 +- src/util/virfile.c | 81 ++++ src/util/virfile.h | 3 + src/virnetprotocol-structs | 4 + tests/fdstreamtest.c | 12 +- tests/virfiletest.c | 203 ++++++++ tools/virsh-util.c | 49 ++ tools/virsh-util.h | 24 + tools/virsh-volume.c | 49 +- tools/virsh.pod | 6 +- tools/wireshark/src/packet-libvirt.c | 48 ++ tools/wireshark/src/packet-libvirt.h | 2 + 38 files changed, 2284 insertions(+), 321 deletions(-) -- 2.10.2

2 44

[libvirt] [PATCH 0/4] domain capabilities fix and test improvement
by Pavel Hrdina 18 Apr '17

18 Apr '17

Pavel Hrdina (4): qemu: refactor qemuDomainMachineIs* and qemuDomainMachineNeedsFDC qemu: use qemuDomainMachineIsPSeries qemu: report IDE bus in domain capabilities only if it's supported tests: domaincapstest: add test for Q35 machine type src/qemu/qemu_alias.c | 4 +- src/qemu/qemu_capabilities.c | 20 ++-- src/qemu/qemu_command.c | 42 +++---- src/qemu/qemu_domain.c | 79 ++++++------- src/qemu/qemu_domain.h | 14 +-- src/qemu/qemu_domain_address.c | 16 +-- src/qemu/qemu_hotplug.c | 14 +-- src/qemu/qemu_parse_command.c | 8 +- .../qemu_2.6.0-gicv2-virt.aarch64.xml | 1 - .../qemu_2.6.0-gicv3-virt.aarch64.xml | 1 - tests/domaincapsschemadata/qemu_2.6.0.aarch64.xml | 1 - tests/domaincapsschemadata/qemu_2.6.0.ppc64le.xml | 1 - tests/domaincapsschemadata/qemu_2.7.0.s390x.xml | 1 - tests/domaincapsschemadata/qemu_2.8.0.s390x.xml | 1 - .../domaincapsschemadata/qemu_2.9.0-q35.x86_64.xml | 125 +++++++++++++++++++++ tests/domaincapstest.c | 4 + 16 files changed, 229 insertions(+), 103 deletions(-) create mode 100644 tests/domaincapsschemadata/qemu_2.9.0-q35.x86_64.xml -- 2.12.2

2 15