[libvirt] [python PATCH] rpm: use new python macros for build/install rules
by Daniel P. Berrangé
The new %py{2,3}_{build,install} macros ensure that the right compiler
and linker flags are used when building python modules.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
libvirt-python.spec.in | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/libvirt-python.spec.in b/libvirt-python.spec.in
index 5bcf1eb..8dd261f 100644
--- a/libvirt-python.spec.in
+++ b/libvirt-python.spec.in
@@ -119,19 +119,35 @@ exit 1
%endif
%if %{with_python2}
+%if 0%{?fedora} >= 29 || 0%{?rhel} >= 8
+%py2_build
+%else
CFLAGS="$RPM_OPT_FLAGS" %{__python2} setup.py build
%endif
+%endif
%if %{with_python3}
+%if 0%{?fedora} >= 29 || 0%{?rhel} >= 8
+%py3_build
+%else
CFLAGS="$RPM_OPT_FLAGS" %{__python3} setup.py build
%endif
+%endif
%install
%if %{with_python2}
+%if 0%{?fedora} || 0%{?rhel} >= 8
+%py2_install
+%else
%{__python2} setup.py install --skip-build --root=%{buildroot}
%endif
+%endif
%if %{with_python3}
+%if 0%{?fedora} || 0%{?rhel} >= 8
+%py3_install
+%else
%{__python3} setup.py install --skip-build --root=%{buildroot}
%endif
+%endif
%check
%if %{with_python2}
--
2.20.1
5 years, 7 months
[libvirt] [jenkins-ci PATCH] Ensure ca-certificates are installed
by Daniel P. Berrangé
On Red Hat variant distros ca-certificates gets pulled in
automatically by other packages we require. This doesn't
happen on Debian and so any use of https URIs fails. This
prevents git from cloning submodules over https.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
guests/vars/mappings.yml | 4 ++++
guests/vars/projects/base.yml | 1 +
2 files changed, 5 insertions(+)
diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml
index 50f07fa..b369c0a 100644
--- a/guests/vars/mappings.yml
+++ b/guests/vars/mappings.yml
@@ -99,6 +99,10 @@ mappings:
bash-completion:
default: bash-completion
+ ca-certificates:
+ default: ca-certificates
+ FreeBSD:
+
ccache:
default: ccache
CentOS:
diff --git a/guests/vars/projects/base.yml b/guests/vars/projects/base.yml
index b3d1d47..a7e572b 100644
--- a/guests/vars/projects/base.yml
+++ b/guests/vars/projects/base.yml
@@ -5,6 +5,7 @@ packages:
- autopoint
- bash
- bash-completion
+ - ca-certificates
- ccache
- chrony
- cppi
--
2.19.2
5 years, 7 months
[libvirt] [PATCH libvirt-python v3] Implement virDomainGetStateParams API
by Bjoern Walk
From: Marc Hartmayer <mhartmay(a)linux.ibm.com>
This patch adds the Python binding for the virDomainGetStateParams API.
The Python side can be generated automatically, the C side cannot.
Reviewed-by: Boris Fiuczynski <fiuczy(a)linux.ibm.com>
Signed-off-by: Marc Hartmayer <mhartmay(a)linux.ibm.com>
Signed-off-by: Bjoern Walk <bwalk(a)linux.ibm.com>
---
generator.py | 1 +
libvirt-override-api.xml | 6 +++++
libvirt-override.c | 48 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+)
diff --git a/generator.py b/generator.py
index ffa3ce56..005be502 100755
--- a/generator.py
+++ b/generator.py
@@ -496,6 +496,7 @@ skip_impl = (
'virConnectBaselineHypervisorCPU',
'virDomainGetLaunchSecurityInfo',
'virNodeGetSEVInfo',
+ 'virDomainGetStateParams',
)
lxc_skip_impl = (
diff --git a/libvirt-override-api.xml b/libvirt-override-api.xml
index 7f578e01..fab62447 100644
--- a/libvirt-override-api.xml
+++ b/libvirt-override-api.xml
@@ -754,5 +754,11 @@
<arg name='conn' type='virConnectPtr' info='pointer to hypervisor connection'/>
<arg name='flags' type='int' info='unused, always pass 0'/>
</function>
+ <function name='virDomainGetStateParams' file='python'>
+ <info>Extract domain state and additional information (if available).</info>
+ <arg name='dom' type='virDomainPtr' info='pointer to the domain'/>
+ <arg name='flags' type='unsigned int' info='extra flags; not used yet, so callers should always pass 0'/>
+ <return type='char *' info="dictionary of state data"/>
+ </function>
</symbols>
</api>
diff --git a/libvirt-override.c b/libvirt-override.c
index c5e2908c..e96a35a0 100644
--- a/libvirt-override.c
+++ b/libvirt-override.c
@@ -9946,6 +9946,51 @@ libvirt_virNodeGetSEVInfo(PyObject *self ATTRIBUTE_UNUSED,
#endif /* LIBVIR_CHECK_VERSION(4, 5, 0) */
+#if LIBVIR_CHECK_VERSION(5, 3, 0)
+static PyObject *
+libvirt_virDomainGetStateParams(PyObject *self ATTRIBUTE_UNUSED,
+ PyObject *args)
+{
+ PyObject *py_retval = VIR_PY_NONE;
+ PyObject *pyobj_domain;
+ virDomainPtr domain;
+ int state;
+ int reason;
+ virTypedParameterPtr params = NULL;
+ int nparams = 0;
+ unsigned int flags;
+ int c_retval;
+
+ if (!PyArg_ParseTuple(args, (char *)"OI:virDomainGetStateParams",
+ &pyobj_domain, &flags))
+ return NULL;
+ domain = (virDomainPtr) PyvirDomain_Get(pyobj_domain);
+
+ LIBVIRT_BEGIN_ALLOW_THREADS;
+ c_retval = virDomainGetStateParams(domain, &state, &reason, ¶ms,
+ &nparams, flags);
+ LIBVIRT_END_ALLOW_THREADS;
+
+ if (c_retval < 0)
+ goto error;
+
+ if ((py_retval = PyTuple_New(3)) == NULL)
+ goto error;
+
+ VIR_PY_TUPLE_SET_GOTO(py_retval, 0, libvirt_intWrap(state), error);
+ VIR_PY_TUPLE_SET_GOTO(py_retval, 1, libvirt_intWrap(reason), error);
+ VIR_PY_TUPLE_SET_GOTO(py_retval, 2, getPyVirTypedParameter(params, nparams), error);
+
+ return py_retval;
+
+error:
+ Py_XDECREF(py_retval);
+ virTypedParamsFree(params, nparams);
+ return VIR_PY_NONE;
+}
+#endif /* LIBVIR_CHECK_VERSION(5, 2, 0) */
+
+
/************************************************************************
* *
* The registration stuff *
@@ -10192,6 +10237,9 @@ static PyMethodDef libvirtMethods[] = {
{(char *) "virDomainGetLaunchSecurityInfo", libvirt_virDomainGetLaunchSecurityInfo, METH_VARARGS, NULL},
{(char *) "virNodeGetSEVInfo", libvirt_virNodeGetSEVInfo, METH_VARARGS, NULL},
#endif /* LIBVIR_CHECK_VERSION(4, 5, 0) */
+#if LIBVIR_CHECK_VERSION(5, 3, 0)
+ {(char *) "virDomainGetStateParams", libvirt_virDomainGetStateParams, METH_VARARGS, NULL},
+#endif /* LIBVIR_CHECK_VERSION(5, 3, 0) */
{NULL, NULL, 0, NULL}
};
--
2.19.1
5 years, 7 months
[libvirt] [PATCH v2 0/3] qemu: don't duplicate suspended events and state changes
by Nikolay Shirokovskiy
Patches 1 and 2 are already Reviewed-by: John. Patch 3 needs Peter comments.
Diff from v1:
============
- minor rebase changes
- minor changes according to review
[1] PATCH v1 : https://www.redhat.com/archives/libvir-list/2018-October/msg00591.html
Nikolay Shirokovskiy (3):
qemu: Pass stop reason from qemuProcessStopCPUs to stop handler
qemu: Map suspended state reason to suspended event detail
qemu: Don't duplicate suspend events and state changes
src/qemu/qemu_domain.c | 34 ++++++++++++++++++++++++++++++++++
src/qemu/qemu_domain.h | 7 +++++++
src/qemu/qemu_driver.c | 26 +++-----------------------
src/qemu/qemu_migration.c | 42 ++++++------------------------------------
src/qemu/qemu_migration.h | 4 ----
src/qemu/qemu_process.c | 38 +++++++++++++++++++++++++-------------
6 files changed, 75 insertions(+), 76 deletions(-)
--
1.8.3.1
5 years, 7 months
[libvirt] [PATCH 0/3] vir*ObjListAddLocked(): Produce better error message than 'Duplicate key'
by Michal Privoznik
*** BLURB HERE ***
Michal Prívozník (3):
DO NOT APPLY: Simple reproducer for virDomainObjListRemove
virDomainObjListAddLocked: Produce better error message than
'Duplicate key'
virNWFilterBindingObjListAddLocked: Produce better error message than
'Duplicate key'
src/conf/virdomainobjlist.c | 36 +++++++++++++++++-----------
src/conf/virnwfilterbindingobjlist.c | 29 +++++++++++++---------
2 files changed, 40 insertions(+), 25 deletions(-)
--
2.19.2
5 years, 7 months
[libvirt] [PATCH 0/4] qemu: Use PCI by default on RISC-V
by Andrea Bolognani
Now that the patches necessary to enable pcie-root-port usage on
RISC-V have been merged into QEMU, we can go ahead and start using
PCI by default on such guests when appropriate.
The full series, with patch 3/4 in its unabridged form, can be
obtained from
https://github.com/andreabolognani/libvirt/tree/riscv-pci-by-default
Andrea Bolognani (4):
qemu: Require PCIe Root Port for PCI by default on ARM virt
qemu: Unify address assignment for virt guests
tests: Refresh capabilities for QEMU 4.0.0 on RISC-V
news: Document PCI by default on RISC-V
docs/news.xml | 12 +
src/qemu/qemu_domain_address.c | 45 +-
.../caps_4.0.0.riscv32.replies | 3864 ++++++++--------
.../caps_4.0.0.riscv32.xml | 19 +-
.../caps_4.0.0.riscv64.replies | 3876 +++++++++--------
.../caps_4.0.0.riscv64.xml | 19 +-
.../riscv64-virt-headless.riscv64-latest.args | 20 +-
7 files changed, 4206 insertions(+), 3649 deletions(-)
--
2.20.1
5 years, 7 months
[libvirt] [PATCH] virsh.pod: Improve native configuration format doc
by Han Han
Add native guest format of BSD hypervisor and VMware/ESX. Quote native
guest format of domxml-from-native for domxml-to-native.
Signed-off-by: Han Han <hhan(a)redhat.com>
---
tools/virsh.pod | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/tools/virsh.pod b/tools/virsh.pod
index a0fe949c55..b3819b9414 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -1607,21 +1607,17 @@ Convert the file I<config> in the native guest configuration format
named by I<format> to a domain XML format. For QEMU/KVM hypervisor,
the I<format> argument must be B<qemu-argv>. For Xen hypervisor, the
I<format> argument may be B<xen-xm>, B<xen-xl>, or B<xen-sxpr>. For
-LXC hypervisor, the I<format> argument must be B<lxc-tools>.
+LXC hypervisor, the I<format> argument must be B<lxc-tools>. For
+VMware/ESX hypervisor, the I<format> argument must be B<vmware-vmx>.
+For the BSD hypervisor, the I<format> argument must be B<bhyve-argv>.
=item B<domxml-to-native> I<format>
{ [I<--xml>] I<xml> | I<--domain> I<domain-name-or-id-or-uuid> }
Convert the file I<xml> into domain XML format or convert an existing
I<--domain> to the native guest configuration format named by I<format>.
-The I<xml> and I<--domain> arguments are mutually exclusive.
-
-For the QEMU/KVM hypervisor, the I<format> argument must be B<qemu-argv>.
-
-For the Xen hypervisor, the I<format> argument may be B<xen-xm>, B<xen-xl>,
-or B<xen-sxpr>.
-
-For the LXC hypervisor, the I<format> argument must be B<lxc-tools>.
+The I<xml> and I<--domain> arguments are mutually exclusive. For the types
+of I<format> argument, refer to B<domxml-from-native>.
=item B<dump> I<domain> I<corefilepath> [I<--bypass-cache>]
{ [I<--live>] | [I<--crash>] | [I<--reset>] } [I<--verbose>] [I<--memory-only>]
--
2.20.1
5 years, 7 months
[libvirt] [PATCH] qemu_hotplug: Remove virQEMUDriverPtr arguments
by Suyang Chen
Since commit 2e6ecba1bcac, the pointer to the qemu driver is saved in
domain object's private data and hence does not have to be passed as
yet another parameter if domain object is already one of them.
This just changed qemuDomainChangeDiskLive and
qemuDomainChangeEjectableMedia functions
Signed-off-by: Suyang Chen <dawson0xff(a)gmail.com>
---
src/qemu/qemu_driver.c | 5 ++---
src/qemu/qemu_hotplug.c | 29 ++++++++++++++---------------
src/qemu/qemu_hotplug.h | 3 +--
3 files changed, 17 insertions(+), 20 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index b27c6ce98e..5d064030e9 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -8100,7 +8100,6 @@ qemuDomainDetachDeviceLive(virDomainObjPtr vm,
static int
qemuDomainChangeDiskLive(virDomainObjPtr vm,
virDomainDeviceDefPtr dev,
- virQEMUDriverPtr driver,
bool force)
{
virDomainDiskDefPtr disk = dev->data.disk;
@@ -8136,7 +8135,7 @@ qemuDomainChangeDiskLive(virDomainObjPtr vm,
goto cleanup;
}
- if (qemuDomainChangeEjectableMedia(driver, vm, orig_disk,
+ if (qemuDomainChangeEjectableMedia(vm, orig_disk,
dev->data.disk->src, force) < 0)
goto cleanup;
@@ -8165,7 +8164,7 @@ qemuDomainUpdateDeviceLive(virDomainObjPtr vm,
switch ((virDomainDeviceType)dev->type) {
case VIR_DOMAIN_DEVICE_DISK:
qemuDomainObjCheckDiskTaint(driver, vm, dev->data.disk, NULL);
- ret = qemuDomainChangeDiskLive(vm, dev, driver, force);
+ ret = qemuDomainChangeDiskLive(vm, dev, force);
break;
case VIR_DOMAIN_DEVICE_GRAPHICS:
diff --git a/src/qemu/qemu_hotplug.c b/src/qemu/qemu_hotplug.c
index 41d60277d1..4bcec0e982 100644
--- a/src/qemu/qemu_hotplug.c
+++ b/src/qemu/qemu_hotplug.c
@@ -844,14 +844,13 @@ qemuDomainChangeMediaBlockdev(virQEMUDriverPtr driver,
* Returns 0 on success, -1 on error and reports libvirt error
*/
int
-qemuDomainChangeEjectableMedia(virQEMUDriverPtr driver,
- virDomainObjPtr vm,
+qemuDomainChangeEjectableMedia(virDomainObjPtr vm,
virDomainDiskDefPtr disk,
virStorageSourcePtr newsrc,
bool force)
{
- virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(driver);
qemuDomainObjPrivatePtr priv = vm->privateData;
+ virQEMUDriverConfigPtr cfg = virQEMUDriverGetConfig(priv->driver);
virStorageSourcePtr oldsrc = disk->src;
bool sharedAdded = false;
int ret = -1;
@@ -862,27 +861,27 @@ qemuDomainChangeEjectableMedia(virQEMUDriverPtr driver,
if (virDomainDiskTranslateSourcePool(disk) < 0)
goto cleanup;
- if (qemuAddSharedDisk(driver, disk, vm->def->name) < 0)
+ if (qemuAddSharedDisk(priv->driver, disk, vm->def->name) < 0)
goto cleanup;
sharedAdded = true;
- if (qemuDomainDetermineDiskChain(driver, vm, disk, NULL, true) < 0)
+ if (qemuDomainDetermineDiskChain(priv->driver, vm, disk, NULL, true) < 0)
goto cleanup;
if (qemuDomainPrepareDiskSource(disk, priv, cfg) < 0)
goto cleanup;
- if (qemuHotplugPrepareDiskSourceAccess(driver, vm, newsrc, false) < 0)
+ if (qemuHotplugPrepareDiskSourceAccess(priv->driver, vm, newsrc, false) < 0)
goto cleanup;
- if (qemuHotplugAttachManagedPR(driver, vm, newsrc, QEMU_ASYNC_JOB_NONE) < 0)
+ if (qemuHotplugAttachManagedPR(priv->driver, vm, newsrc, QEMU_ASYNC_JOB_NONE) < 0)
goto cleanup;
if (virQEMUCapsGet(priv->qemuCaps, QEMU_CAPS_BLOCKDEV))
- rc = qemuDomainChangeMediaBlockdev(driver, vm, disk, oldsrc, newsrc, force);
+ rc = qemuDomainChangeMediaBlockdev(priv->driver, vm, disk, oldsrc, newsrc, force);
else
- rc = qemuDomainChangeMediaLegacy(driver, vm, disk, newsrc, force);
+ rc = qemuDomainChangeMediaLegacy(priv->driver, vm, disk, newsrc, force);
virDomainAuditDisk(vm, oldsrc, newsrc, "update", rc >= 0);
@@ -891,8 +890,8 @@ qemuDomainChangeEjectableMedia(virQEMUDriverPtr driver,
/* remove the old source from shared device list */
disk->src = oldsrc;
- ignore_value(qemuRemoveSharedDisk(driver, disk, vm->def->name));
- ignore_value(qemuHotplugPrepareDiskSourceAccess(driver, vm, oldsrc, true));
+ ignore_value(qemuRemoveSharedDisk(priv->driver, disk, vm->def->name));
+ ignore_value(qemuHotplugPrepareDiskSourceAccess(priv->driver, vm, oldsrc, true));
/* media was changed, so we can remove the old media definition now */
virObjectUnref(oldsrc);
@@ -905,13 +904,13 @@ qemuDomainChangeEjectableMedia(virQEMUDriverPtr driver,
/* undo changes to the new disk */
if (ret < 0) {
if (sharedAdded)
- ignore_value(qemuRemoveSharedDisk(driver, disk, vm->def->name));
+ ignore_value(qemuRemoveSharedDisk(priv->driver, disk, vm->def->name));
- ignore_value(qemuHotplugPrepareDiskSourceAccess(driver, vm, newsrc, true));
+ ignore_value(qemuHotplugPrepareDiskSourceAccess(priv->driver, vm, newsrc, true));
}
/* remove PR manager object if unneeded */
- ignore_value(qemuHotplugRemoveManagedPR(driver, vm, QEMU_ASYNC_JOB_NONE));
+ ignore_value(qemuHotplugRemoveManagedPR(priv->driver, vm, QEMU_ASYNC_JOB_NONE));
/* revert old image do the disk definition */
if (oldsrc)
@@ -1315,7 +1314,7 @@ qemuDomainAttachDeviceDiskLive(virQEMUDriverPtr driver,
if ((disk->device == VIR_DOMAIN_DISK_DEVICE_CDROM ||
disk->device == VIR_DOMAIN_DISK_DEVICE_FLOPPY) &&
(orig_disk = virDomainDiskFindByBusAndDst(vm->def, disk->bus, disk->dst))) {
- if (qemuDomainChangeEjectableMedia(driver, vm, orig_disk,
+ if (qemuDomainChangeEjectableMedia(vm, orig_disk,
disk->src, false) < 0)
return -1;
diff --git a/src/qemu/qemu_hotplug.h b/src/qemu/qemu_hotplug.h
index 7ac03b7810..a60df36f74 100644
--- a/src/qemu/qemu_hotplug.h
+++ b/src/qemu/qemu_hotplug.h
@@ -26,8 +26,7 @@
# include "qemu_domain.h"
# include "domain_conf.h"
-int qemuDomainChangeEjectableMedia(virQEMUDriverPtr driver,
- virDomainObjPtr vm,
+int qemuDomainChangeEjectableMedia(virDomainObjPtr vm,
virDomainDiskDefPtr disk,
virStorageSourcePtr newsrc,
bool force);
--
2.20.1
5 years, 7 months
[libvirt] CfP VHPC19: HPC Virtualization-Containers: Paper due May 1, 2019 (extended)
by VHPC 19
====================================================================
CALL FOR PAPERS
14th Workshop on Virtualization in High-Performance Cloud Computing
(VHPC '19) held in conjunction with the International Supercomputing
Conference - High Performance, June 16-20, 2019, Frankfurt, Germany.
(Springer LNCS Proceedings)
====================================================================
Date: June 20, 2019
Workshop URL: http://vhpc.org
Paper Submission Deadline: May 1, 2019 (extended)
Springer LNCS, rolling abstract submission
Abstract/Paper Submission Link: https://edas.info/newPaper.php?c=25685
Call for Papers
Containers and virtualization technologies constitute key enabling
factors 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-containerization 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; lastly, unikernels provide
for many virtualization benefits with a minimized OS/library surface.
I/O Virtualization in turn allows physical network interfaces 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 is furthermore enabling
virtualization of HPC infrastructures.
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, containers-virtualization
and the cloud.
Major Topics:
- HPC on Containers and VMs
- Containerized applications with OS-level virtualization
- Lightweight applications with Unikernels
- HP-as-a-Service
each major topic encompassing design/architecture, management,
performance management, modeling and configuration/tooling:
Design / Architecture:
- Containers and OS-level virtualization (LXC, Docker, rkt,
Singularity, Shifter, i.a.)
- Hypervisor support for heterogeneous resources (GPUs, co-processors,
FPGAs, etc.)
- Hypervisor extensions to mitigate side-channel attacks
([micro-]architectural timing attacks, privilege escalation)
- VM & Container trust and security models
- Multi-environment coupling, system software supporting in-situ
analysis with HPC simulation
- Cloud reliability, fault-tolerance and high-availability
- Energy-efficient and power-aware virtualization
- Containers inside VMs with hypervisor isolation
- Virtualization support for emerging memory technologies
- Lightweight/specialized operating systems in conjunction with
virtual machines
- Hypervisor support for heterogeneous resources (GPUs, co-processors,
FPGAs, etc.)
- Novel unikernels and use cases for virtualized HPC environments
- ARM-based hypervisors, ARM virtualization extensions
Management:
- Container and VM management for HPC and cloud environments
- HPC services integration, services to support HPC
- Service and on-demand scheduling & resource management
- Dedicated workload management with VMs or containers
- Workflow coupling with VMs and containers
- Unikernel, lightweight VM application management
- Environments and tools for operating containerized environments
(batch, orchestration)
- Novel models for non-HPC workload provisioning on HPC resources
Performance Measurements and Modeling:
- Performance improvements for or driven by unikernels
- Optimizations of virtual machine monitor platforms and hypervisors
- Scalability analysis of VMs and/or containers at large scale
- Performance measurement, modeling and monitoring of
virtualized/cloud workloads
- Virtualization in supercomputing environments, HPC clusters, HPC in
the cloud
Configuration / Tooling:
- Tool support for unikernels: configuration/build environments,
debuggers, profilers
- Job scheduling/control/policy and container placement in virtualized
environments
- Operating MPI in containers/VMs and Unikernels
- Software defined networks and network virtualization
- GPU virtualization operationalization
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
May 1, 2019 - Abstract/Paper extended submission deadline
(Springer LNCS)
May 20, 2019 - Acceptance notification
June 20th, 2019 - Workshop Day
July 10th, 2019 - Camera-ready version due
Chair
Michael Alexander (chair), University of Vienna, Austria
Anastassios Nanos (co-chair), SunLight.io, UK
Andrew Younge (co-chair), Sandia National Laboratories
Program committee
Stergios Anastasiadis, University of Ioannina, Greece
Jakob Blomer, CERN, Europe
Eduardo César, Universidad Autonoma de Barcelona, Spain
Taylor Childers, Argonne National Laboratory, USA
Stephen Crago, USC ISI, USA
Tommaso Cucinotta, St. Anna School of Advanced Studies, Italy
Christoffer Dall, Columbia University, USA
François Diakhaté, CEA, France
Patrick Dreher, MIT, USA
Kyle Hale, Northwestern University, USA
Bob Killen, University of Michigan, USA
Brian Kocoloski, Washington University, USA
John Lange, University of Pittsburgh, USA
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, Western New England University, USA
Carlos Reaño, Queen’s University Belfast, UK
Borja Sotomayor, University of Chicago, USA
Jonathan Sparks, Cray, USA
Joe Stubbs, Texas Advanced Computing Center, USA
Anata Tiwari, San Diego Supercomputer Center, USA
Kurt Tutschku, Blekinge Institute of Technology, Sweden
John Walters, USC ISI, USA
Yasuhiro Watashiba, Osaka University, Japan
Chao-Tung Yang, Tunghai University, Taiwan
Na Zhang, VMware, USA
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, keywords, 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.springernature.com/cs-proceeding/llncs/llncs2e.zip
Abstract, Paper Submission Link:
https://edas.info/newPaper.php?c=25685
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) 2019, June
16-20, Frankfurt, Germany.
5 years, 7 months