[libvirt] [PATCH 0/6] Hyper-V method invocation support
by Sri Ramanujam
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
8 years
[libvirt] [PATCH v3] hyperv: recognize array property as distinct type.
by Dawid Zamirski
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
8 years
[libvirt] [PATCH] xenconfig: avoid double free on OOM testing
by Jim Fehlig
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
8 years
[libvirt] VHPC at ISC extension - Papers due May 2
by VHPC 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.
8 years
[libvirt] [RFC PATCH 00/11] Add mdev reporting capability to the nodedev driver
by Erik Skultety
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
8 years
[libvirt] Trouble with virsh on Windows
by Charles Bancroft
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
8 years
[libvirt] [PATCH v2 0/2] Use the shared keycodemap database
by Daniel P. Berrange
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
8 years
[libvirt] [REPOST PATCH 0/5] Split out network object into its own module
by John Ferlan
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
8 years
[libvirt] [PATCH 00/38] Implement sparse streams for libvirt
by Michal Privoznik
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
8 years
[libvirt] [PATCH 0/4] domain capabilities fix and test improvement
by Pavel Hrdina
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
8 years
