[libvirt] guys is the header file broken??
by Dravid Kumar
cause i get this error
me.cpp: In function ‘int main(int, char**)’:
me.cpp:23:45: error: ‘virConnectCreateXML’ was not declared in this scope
dom = virConnectCreateXML(conn, xmlconfig, 0);
^
me.cpp:27:5: error: return-statement with no value, in function returning
‘int’ [-fpermissive]
return;
^
me.cpp:30:57: error: ‘virDomainName’ was not declared in this scope
fprintf(stderr, "Guest %s has booted", virDomainName(dom));
for the attached cpp file
8 years, 9 months
[libvirt] CfP 11th Workshop on Virtualization in High-Performance Cloud Computing (VHPC '16)
by VHPC 16
====================================================================
CALL FOR PAPERS
11th Workshop on Virtualization in High-Performance Cloud Computing (VHPC
'16)
held in conjunction with the International Supercomputing Conference - High
Performance,
June 19-23, 2016, Frankfurt, Germany.
====================================================================
Date: June 23, 2016
Workshop URL: http://vhpc.org
Paper Submission Deadline: April 25, 2016
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.
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. Topics include, but are not limited to:
- Virtualization in supercomputing environments, HPC clusters, cloud HPC
and grids
- OS-level virtualization including container runtimes (Docker, rkt et al.)
- Lightweight compute node operating systems/VMMs
- Optimizations of virtual machine monitor platforms, hypervisors
- QoS and SLA in hypervisors and network virtualization
- Cloud based network and system management for SDN and NFV
- Management, deployment and monitoring of virtualized environments
- Virtual per job / on-demand clusters and cloud bursting
- Performance measurement, modelling and monitoring of virtualized/cloud
workloads
- Programming models for virtualized environments
- Virtualization in data intensive computing and Big Data processing
- Cloud reliability, fault-tolerance, high-availability and security
- Heterogeneous virtualized environments, virtualized accelerators, GPUs
and co-processors
- Optimized communication libraries/protocols in the cloud and for HPC in
the cloud
- Topology management and optimization for distributed virtualized
applications
- Adaptation of emerging HPC technologies (high performance networks, RDMA,
etc..)
- I/O and storage virtualization, virtualization aware file systems
- Job scheduling/control/policy in virtualized environments
- Checkpointing and migration of VM-based large compute jobs
- Cloud frameworks and APIs
- Energy-efficient / power-aware virtualization
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
April 25, 2016 - Paper submission deadline
May 30, 2016 Acceptance notification
June 23, 2016 - Workshop Day
July 25, 2016 - Camera-ready version due
Chair
Michael Alexander (chair), TU Wien, 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
Costas Bekas, IBM Research, Switzerland
Jakob Blomer, CERN
Ron Brightwell, Sandia National Laboratories, USA
Roberto Canonico, University of Napoli Federico II, Italy
Julian Chesterfield, OnApp, UK
Stephen Crago, USC ISI, USA
Christoffer Dall, Columbia University, USA
Patrick Dreher, MIT, USA
Robert Futrick, Cycle Computing, USA
Robert Gardner, University of Chicago, USA
William Gardner, University of Guelph, Canada
Wolfgang Gentzsch, UberCloud, USA
Kyle Hale, Northwestern University, USA
Marcus Hardt, Karlsruhe Institute of Technology, Germany
Krishna Kant, Templte University, USA
Romeo Kinzler, IBM, Switzerland
Brian Kocoloski, University of Pittsburgh, USA
Kornilios Kourtis, IBM Research, Switzerland
Nectarios Koziris, National Technical University of Athens, Greece
John Lange, University of Pittsburgh, USA
Nikos Parlavantzas, IRISA, France
Kevin Pendretti, Sandia National Laboratories, USA
Che-Rung Roger Lee, National Tsing Hua University, Taiwan
Giuseppe Lettieri, University of Pisa, Italy
Qing Liu, Oak Ridge National Laboratory, USA
Paul Mundt, Adaptant, Germany
Amer Qouneh, University of Florida, USA
Carlos Reaño, Technical University of Valencia, Spain
Seetharami Seelam, IBM Research, USA
Josh Simons, VMWare, USA
Borja Sotomayor, University of Chicago, USA
Dieter Suess, TU Wien, Austria
Craig Stewart, Indiana University, USA
Anata Tiwari, San Diego Supercomputer Center, USA
Kurt Tutschku, Blekinge Institute of Technology, Sweden
Amit Vadudevan, Carnegie Mellon University, USA
Yasuhiro Watashiba, Osaka University, Japan
Nicholas Wright, Lawrence Berkeley National Laboratory, USA
Chao-Tung Yang, Tunghai University, Taiwan
Gianluigi Zanetti, CRS4, Italy
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.
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=21801
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) 2016, June 19-23,
Frankfurt, Germany.
8 years, 9 months
[libvirt] netlink message help
by Vasiliy Tolstov
I'm try to implement adding addresses to ehternet devices via libvirt
and i need to add address with peer (like point to point)
in iproute : ip a add xx.xx.xx.xx peer yy.yy.yy.yy dev tapNNN
In netlink as i see i need to add in payload IFA_LOCAL address , after
that IFA_ADDRESS, but this is not works =(. Can somebody helps me?
--
Vasiliy Tolstov,
e-mail: v.tolstov(a)selfip.ru
8 years, 9 months
[libvirt] [libvirt-perl][PATCH] Add VIR_MIGRATE_PARAM_DISKS_PORT constant
by Michal Privoznik
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
Changes | 1 +
Virt.xs | 13 +++++++++++--
lib/Sys/Virt/Domain.pm | 6 ++++++
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/Changes b/Changes
index 8f2cba6..9ca0a76 100644
--- a/Changes
+++ b/Changes
@@ -9,6 +9,7 @@ Revision history for perl module Sys::Virt
- Add VIR_DOMAIN_EVENT_ID_JOB_COMPLETED constant and callback
- Add VIR_ERR_NO_SERVER constant
- Add VIR_DOMAIN_EVENT_DEFINED_FROM_SNAPSHOT constant
+ - Add VIR_MIGRATE_PARAM_DISKS_PORT constant
1.3.2 2016-03-01
diff --git a/Virt.xs b/Virt.xs
index 2148eaf..358a396 100644
--- a/Virt.xs
+++ b/Virt.xs
@@ -4479,7 +4479,7 @@ _migrate(dom, destcon, newparams, flags=0)
virTypedParameter *params;
int nparams;
CODE:
- nparams = 6;
+ nparams = 7;
Newx(params, nparams, virTypedParameter);
strncpy(params[0].field, VIR_MIGRATE_PARAM_URI,
@@ -4506,6 +4506,10 @@ _migrate(dom, destcon, newparams, flags=0)
VIR_TYPED_PARAM_FIELD_LENGTH);
params[5].type = VIR_TYPED_PARAM_STRING;
+ strncpy(params[6].field, VIR_MIGRATE_PARAM_DISKS_PORT,
+ VIR_TYPED_PARAM_FIELD_LENGTH);
+ params[6].type = VIR_TYPED_PARAM_INT;
+
nparams = vir_typed_param_from_hv(newparams, params, nparams);
vir_typed_param_add_string_list_from_hv(newparams, ¶ms, &nparams,
@@ -4534,7 +4538,7 @@ _migrate_to_uri(dom, desturi, newparams, flags=0)
virTypedParameter *params;
int nparams;
PPCODE:
- nparams = 6;
+ nparams = 7;
Newx(params, nparams, virTypedParameter);
strncpy(params[0].field, VIR_MIGRATE_PARAM_URI,
@@ -4561,6 +4565,10 @@ _migrate_to_uri(dom, desturi, newparams, flags=0)
VIR_TYPED_PARAM_FIELD_LENGTH);
params[5].type = VIR_TYPED_PARAM_STRING;
+ strncpy(params[6].field, VIR_MIGRATE_PARAM_DISKS_PORT,
+ VIR_TYPED_PARAM_FIELD_LENGTH);
+ params[6].type = VIR_TYPED_PARAM_INT;
+
nparams = vir_typed_param_from_hv(newparams, params, nparams);
vir_typed_param_add_string_list_from_hv(newparams, ¶ms, &nparams,
@@ -7586,6 +7594,7 @@ BOOT:
REGISTER_CONSTANT_STR(VIR_MIGRATE_PARAM_URI, MIGRATE_PARAM_URI);
REGISTER_CONSTANT_STR(VIR_MIGRATE_PARAM_LISTEN_ADDRESS, MIGRATE_PARAM_LISTEN_ADDRESS);
REGISTER_CONSTANT_STR(VIR_MIGRATE_PARAM_MIGRATE_DISKS, MIGRATE_PARAM_MIGRATE_DISKS);
+ REGISTER_CONSTANT_STR(VIR_MIGRATE_PARAM_DISKS_PORT, MIGRATE_PARAM_DISK_PORT);
REGISTER_CONSTANT(VIR_DOMAIN_XML_SECURE, XML_SECURE);
REGISTER_CONSTANT(VIR_DOMAIN_XML_INACTIVE, XML_INACTIVE);
diff --git a/lib/Sys/Virt/Domain.pm b/lib/Sys/Virt/Domain.pm
index 3e9e7ba..45b8ed1 100644
--- a/lib/Sys/Virt/Domain.pm
+++ b/lib/Sys/Virt/Domain.pm
@@ -981,6 +981,12 @@ or ::). This default may be a security risk if guests, or other
untrusted users have the ability to connect to the virtualization
host, thus use of an explicit restricted listen address is recommended.
+=item C<Sys::Virt::Domain::MIGRATE_PARAM_DISK_PORT>
+
+Port that destination server should use for incoming disks migration. Type is
+VIR_TYPED_PARAM_INT. If set to 0 or omitted, libvirt will choose a suitable
+default. At the moment this is only supported by the QEMU driver.
+
=back
=item C<Sys::Virt::Domain::MIGRATE_PARAM_MIGRATE_DISKS>
--
2.4.10
8 years, 9 months
[libvirt] [PATCH v2] qemu: Move last error save/restore to qemuBuildNetCommandLine
by John Ferlan
Commit 'ef2ab8fd' moved just the virDomainConfNWFilterTeardown and left
the logic to save/restore the current error essentially doing nothing
in the error path for qemuBuildCommandLine. So move it to where it
was meant to be.
Although the original code would reset the filter on command creation
errors after building the network command portion and commit 'ef2ab8fd'
altered that logic, the teardown is called during qemuProcessStop from
virDomainConfVMNWFilterTeardown and that code has the save/restore
last error logic, so just allow that code to handle the teardown rather
than running it twice. The qemuProcessStop would be called in the failure
path of qemuBuildCommandLine.
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
v1:
http://www.redhat.com/archives/libvir-list/2016-March/msg00566.html
Changes - just move the save/restore error logic from mainline to the
BuildNetCommandLine function where it's used.
src/qemu/qemu_command.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index b18e425..954f802 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -8077,8 +8077,13 @@ qemuBuildNetCommandLine(virCommandPtr cmd,
return 0;
error:
+ /* free up any resources in the network driver
+ * but don't overwrite the original error */
+ originalError = virSaveLastError();
for (i = 0; last_good_net != -1 && i <= last_good_net; i++)
virDomainConfNWFilterTeardown(def->nets[i]);
+ virSetError(originalError);
+ virFreeError(originalError);
return -1;
}
@@ -9407,11 +9412,6 @@ qemuBuildCommandLine(virConnectPtr conn,
error:
virObjectUnref(cfg);
- /* free up any resources in the network driver
- * but don't overwrite the original error */
- originalError = virSaveLastError();
- virSetError(originalError);
- virFreeError(originalError);
virCommandFree(cmd);
return NULL;
}
--
2.5.0
8 years, 9 months
[libvirt] [PATCH] tests: Set PATH in each test
by Michal Privoznik
Currently we spawn couple of binaries in our test suite.
Moreover, we provide some spoofed versions of system binaries
hoping that those will be executed instead of the system ones.
For instance, for testing SSH socket we have written our own ssh
binary for producing predictable results. We certainly don't want
to execute the system ssh binary.
However, in order to prefer our binaries over system ones, we
need to set PATH environment variable. But this is done only at
the Makefile level. So if anybody runs a test by hand that
expects our spoofed binary, the test ends up executing real
system binaries. This is not good. In fact, it's terribly wrong.
The fix lies in a small trick - putting our build directory at
the beginning of the PATH environment variable in each test.
Hopefully, since every test has this VIRT_TEST_MAIN* wrapper, we
can fix this at a single place.
Moreover, while this removes setting PATH for our tests written
in bash, it's safe as we are not calling anything ours that would
require PATH change there.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
tests/Makefile.am | 3 ---
tests/testutils.c | 21 ++++++++++++++++++++-
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 90981dc..74f7f5a 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -462,8 +462,6 @@ TESTS = $(test_programs) \
# intermediate shell variable, but must do all the expansion in make
lv_abs_top_builddir=$(shell cd '$(top_builddir)' && pwd)
-path_add = $(subst :,$(PATH_SEPARATOR),\
- $(subst !,$(lv_abs_top_builddir)/,!daemon:!tools:!tests))
VIR_TEST_EXPENSIVE ?= $(VIR_TEST_EXPENSIVE_DEFAULT)
TESTS_ENVIRONMENT = \
@@ -472,7 +470,6 @@ TESTS_ENVIRONMENT = \
abs_builddir=$(abs_builddir) \
abs_srcdir=$(abs_srcdir) \
CONFIG_HEADER="$(lv_abs_top_builddir)/config.h" \
- PATH="$(path_add)$(PATH_SEPARATOR)$$PATH" \
SHELL="$(SHELL)" \
LIBVIRT_DRIVER_DIR="$(lv_abs_top_builddir)/src/.libs" \
LIBVIRT_AUTOSTART=0 \
diff --git a/tests/testutils.c b/tests/testutils.c
index 88c4d4b..9211b94 100644
--- a/tests/testutils.c
+++ b/tests/testutils.c
@@ -806,6 +806,24 @@ virTestGetRegenerate(void)
return testRegenerate;
}
+static int
+virTestSetEnvPath(void)
+{
+ int ret = -1;
+ const char *path = getenv("PATH");
+ char *new_path = NULL;
+
+ if (strstr(path, abs_builddir) != path &&
+ (virAsprintf(&new_path, "%s:%s", abs_builddir, path) < 0 ||
+ setenv("PATH", new_path, 1) < 0))
+ goto cleanup;
+
+ ret = 0;
+ cleanup:
+ VIR_FREE(new_path);
+ return ret;
+}
+
int virtTestMain(int argc,
char **argv,
int (*func)(void))
@@ -818,7 +836,8 @@ int virtTestMain(int argc,
virFileActivateDirOverride(argv[0]);
- if (!virFileExists(abs_srcdir))
+ if (virTestSetEnvPath() < 0 ||
+ !virFileExists(abs_srcdir))
return EXIT_AM_HARDFAIL;
progname = last_component(argv[0]);
--
2.4.10
8 years, 9 months
[libvirt] [PATCH v3 0/2] nodedev: Expose PCI header type information
by Martin Kletzander
v3: changed 'header' to 'capability', only reported for non-endpoints
v2: Removed <multifunction/> reporting.
https://www.redhat.com/archives/libvir-list/2016-March/msg00774.html
v1: https://www.redhat.com/archives/libvir-list/2016-March/msg00645.html
Martin Kletzander (2):
nodedev: Indent PCI express for future fix
nodedev: Expose PCI header type
docs/schemas/nodedev.rng | 11 +++++++
src/conf/node_device_conf.c | 20 ++++++++++++
src/conf/node_device_conf.h | 1 +
src/libvirt_private.syms | 3 ++
src/node_device/node_device_udev.c | 37 ++++++++++++----------
src/util/virpci.c | 33 +++++++++++++++++++
src/util/virpci.h | 12 +++++++
.../pci_0000_00_02_0_header_type.xml | 15 +++++++++
.../pci_0000_00_1c_0_header_type.xml | 20 ++++++++++++
tests/nodedevxml2xmltest.c | 2 ++
10 files changed, 138 insertions(+), 16 deletions(-)
create mode 100644 tests/nodedevschemadata/pci_0000_00_02_0_header_type.xml
create mode 100644 tests/nodedevschemadata/pci_0000_00_1c_0_header_type.xml
--
2.7.3
8 years, 9 months
[libvirt] [PATCH] network: differentiate macvtap/bridge from host-bridge based networks
by Laine Stump
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1316465
An attempt to simplify the code for the VIR_NETWORK_FORWARD_BRIDGE
case of networkUpdateState in commit b61db335 (first in release
1.2.14) resulted in networks based on macvtap bridge mode being
erroneously marked as inactive any time libvirtd was restarted.
The problem is that the original code had differentiated between a
network using tap devices to connect to an existing host-bridge device
(forward mode of VIR_NETWORK_FORWARD_BRIDGE and a non-NULL
def->bridge), and one using macvtap bridge mode to connect to any
ethernet device (still forward mode VIR_NETWORK_FORWARD_BRIDGE, but
null def->bridge), but the changed code assumed that all networks with
VIR_NETWORK_FORWARD_BRIDGE were tap + host-bridge networks, so a null
def->bridge was interpreted as "inactive".
This patch restores the original code in networkUpdateState, as well
as fixing two other pre-existing similar problems - the cases for
VIR_NETWORK_FORWARD_BRIDGE in both networkStartNetwork and
networkShutdownNetwork have always made the same mistake - treating
macvtap-bridge-mode networks as tap+host-bridge.
---
src/network/bridge_driver.c | 31 +++++++++++++++++++++----------
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/src/network/bridge_driver.c b/src/network/bridge_driver.c
index 01c2ed6..b164334 100644
--- a/src/network/bridge_driver.c
+++ b/src/network/bridge_driver.c
@@ -406,7 +406,8 @@ networkUpdateState(virNetworkObjPtr obj,
break;
case VIR_NETWORK_FORWARD_BRIDGE:
- if (!(obj->def->bridge && virNetDevExists(obj->def->bridge) == 1)) {
+ if (obj->def->bridge) {
+ if (virNetDevExists(obj->def->bridge) != 1)
obj->active = 0;
break;
}
@@ -2490,10 +2491,15 @@ networkStartNetwork(virNetworkDriverStatePtr driver,
break;
case VIR_NETWORK_FORWARD_BRIDGE:
- if (networkStartNetworkBridge(network) < 0)
- goto cleanup;
- break;
-
+ if (network->def->bridge) {
+ if (networkStartNetworkBridge(network) < 0)
+ goto cleanup;
+ break;
+ }
+ /* intentionally fall through to the macvtap/direct case for
+ * VIR_NETWORK_FORWARD_BRIDGE with no bridge device defined
+ * (since that is macvtap bridge mode).
+ */
case VIR_NETWORK_FORWARD_PRIVATE:
case VIR_NETWORK_FORWARD_VEPA:
case VIR_NETWORK_FORWARD_PASSTHROUGH:
@@ -2562,9 +2568,14 @@ networkShutdownNetwork(virNetworkDriverStatePtr driver,
break;
case VIR_NETWORK_FORWARD_BRIDGE:
- ret = networkShutdownNetworkBridge(network);
- break;
-
+ if (network->def->bridge) {
+ ret = networkShutdownNetworkBridge(network);
+ break;
+ }
+ /* intentionally fall through to the macvtap/direct case for
+ * VIR_NETWORK_FORWARD_BRIDGE with no bridge device defined
+ * (since that is macvtap bridge mode).
+ */
case VIR_NETWORK_FORWARD_PRIVATE:
case VIR_NETWORK_FORWARD_VEPA:
case VIR_NETWORK_FORWARD_PASSTHROUGH:
@@ -4691,8 +4702,8 @@ networkGetNetworkAddress(const char *netname, char **netaddr)
if ((dev_name = netdef->bridge))
break;
/*
- * fall through if netdef->bridge wasn't set, since this is
- * also a direct-mode interface.
+ * fall through if netdef->bridge wasn't set, since that is
+ * macvtap bridge mode network.
*/
case VIR_NETWORK_FORWARD_PRIVATE:
case VIR_NETWORK_FORWARD_VEPA:
--
2.5.0
8 years, 9 months
[libvirt] [PATCH v2 0/2] qemu: Support for QXL heads
by Martin Kletzander
v2: don't change heads when migrating
v1: https://www.redhat.com/archives/libvir-list/2016-March/msg00410.html
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1283207
Martin Kletzander (2):
qemu: Check for qxl's max_outputs parameter
qemu: Add support to QXL's max_outputs parameter
src/qemu/qemu_capabilities.c | 4 ++
src/qemu/qemu_capabilities.h | 2 +
src/qemu/qemu_command.c | 8 ++++
src/qemu/qemu_migration.c | 50 ++++++++++++++++++++--
.../qemuxml2argv-video-qxl-heads.args | 28 ++++++++++++
.../qemuxml2argv-video-qxl-heads.xml | 47 ++++++++++++++++++++
tests/qemuxml2argvtest.c | 8 ++++
.../qemuxml2xmlout-video-qxl-heads.xml | 47 ++++++++++++++++++++
tests/qemuxml2xmltest.c | 2 +
9 files changed, 192 insertions(+), 4 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-heads.args
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-video-qxl-heads.xml
create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-video-qxl-heads.xml
--
2.7.3
8 years, 9 months
