[libvirt] [libvirt-python][PATCH v2 0/4] Implement sparse streams
by Michal Privoznik
diff to v1:
- Martin's review worked in.
Patches 1-3 were ACKed already. Well, conditionally. Patch 4/4 wasn't. I'm
sending them again to make sure I've worked in the review as expected.
Michal Privoznik (4):
Implement virStreamSendHole/virStreamRecvHole
virStream: Introduce virStreamRecvFlags
virStream: Introduce virStreamSparse{Recv,Send}All
examples: Introduce sparsestream.py
examples/sparsestream.py | 117 +++++++++++++++++++++++++++++++++
generator.py | 5 ++
libvirt-override-virStream.py | 146 ++++++++++++++++++++++++++++++++++++++++++
libvirt-override.c | 102 +++++++++++++++++++++++++++++
sanitytest.py | 6 +-
5 files changed, 374 insertions(+), 2 deletions(-)
create mode 100755 examples/sparsestream.py
--
2.13.0
8 years
[libvirt] [PATCH] qemu: process: Clear priv->namespaces on VM shutdown
by Peter Krempa
Otherwise the private data entry would be kept across instances of the
same VM even if it's not configured to do so.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1453142
---
src/qemu/qemu_process.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/src/qemu/qemu_process.c b/src/qemu/qemu_process.c
index c19bd2925..ac17da668 100644
--- a/src/qemu/qemu_process.c
+++ b/src/qemu/qemu_process.c
@@ -6449,6 +6449,10 @@ void qemuProcessStop(virQEMUDriverPtr driver,
/* clean up migration data */
VIR_FREE(priv->migTLSAlias);
+ /* clear previously used namespaces */
+ virBitmapFree(priv->namespaces);
+ priv->namespaces = NULL;
+
/* The "release" hook cleans up additional resources */
if (virHookPresent(VIR_HOOK_DRIVER_QEMU)) {
char *xml = qemuDomainDefFormatXML(driver, vm->def, 0);
--
2.12.2
8 years
[libvirt] [libvirt-python][PATCH 0/4] Implement sparse streams
by Michal Privoznik
*** BLURB HERE ***
Michal Privoznik (4):
Implement virStreamSendHole/virStreamRecvHole
virStream: Introduce virStreamRecvFlags
virStream: Introduce virStreamSparse{Recv,Send}All
examples: Introduce sparsestream.py
examples/sparsestream.py | 119 ++++++++++++++++++++++++++++++++
generator.py | 5 ++
libvirt-override-virStream.py | 156 ++++++++++++++++++++++++++++++++++++++++++
libvirt-override.c | 102 +++++++++++++++++++++++++++
4 files changed, 382 insertions(+)
create mode 100755 examples/sparsestream.py
--
2.13.0
8 years
[libvirt] libvirt-question
by zhunxun＠gmail.com
Hello,does libvirt provides API to get qemu process ID by vm ID or name??or is there any methods to do this??
thanks!!
zhunxun(a)gmail.com
8 years
[libvirt] [PATCH] test: fixing variable names for test suite inside configure.ac.
by Julio Faracco
Both variables for gcov and oom have wrong names inside configure.ac.
For this reason, the Test Suite configuration is not showing the current
configuration.
Before patching:
configure: windres: no
configure:
configure: Test suite
configure:
configure: Coverage:
configure: Alloc OOM:
configure:
configure: Miscellaneous
After patching (using --enable-test-coverage and --enable-test-oom):
configure: windres: no
configure:
configure: Test suite
configure:
configure: Coverage: yes
configure: Alloc OOM: yes
configure:
configure: Miscellaneous
Signed-off-by: Julio Faracco <jcfaracco(a)gmail.com>
---
configure.ac | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 2e60513..246f4e0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1005,8 +1005,8 @@ LIBVIRT_WIN_RESULT_WINDRES
AC_MSG_NOTICE([])
AC_MSG_NOTICE([Test suite])
AC_MSG_NOTICE([])
-AC_MSG_NOTICE([ Coverage: $enable_coverage])
-AC_MSG_NOTICE([ Alloc OOM: $enable_oom])
+AC_MSG_NOTICE([ Coverage: $enable_test_coverage])
+AC_MSG_NOTICE([ Alloc OOM: $enable_test_oom])
AC_MSG_NOTICE([])
AC_MSG_NOTICE([Miscellaneous])
AC_MSG_NOTICE([])
--
2.7.4
8 years
[libvirt] [PATCH] qemu: Remove unused variables in qemuDomainUpdateDeviceConfig
by Kothapally Madhu Pavan
priv and qemuCaps variables are not used anymore.
Signed-off-by: Kothapally Madhu Pavan <kmp(a)linux.vnet.ibm.com>
---
src/qemu/qemu_driver.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
index 1c4873e..4721356 100644
--- a/src/qemu/qemu_driver.c
+++ b/src/qemu/qemu_driver.c
@@ -8172,8 +8172,6 @@ static int qemuDomainUpdateDeviceFlags(virDomainPtr dom,
virDomainDeviceDefPtr dev = NULL, dev_copy = NULL;
bool force = (flags & VIR_DOMAIN_DEVICE_MODIFY_FORCE) != 0;
int ret = -1;
- virQEMUCapsPtr qemuCaps = NULL;
- qemuDomainObjPrivatePtr priv;
virQEMUDriverConfigPtr cfg = NULL;
virCapsPtr caps = NULL;
unsigned int parse_flags = VIR_DOMAIN_DEF_PARSE_INACTIVE;
@@ -8192,8 +8190,6 @@ static int qemuDomainUpdateDeviceFlags(virDomainPtr dom,
if (!(vm = qemuDomObjFromDomain(dom)))
goto cleanup;
- priv = vm->privateData;
-
if (virDomainUpdateDeviceFlagsEnsureACL(dom->conn, vm->def, flags) < 0)
goto cleanup;
@@ -8220,12 +8216,6 @@ static int qemuDomainUpdateDeviceFlags(virDomainPtr dom,
goto endjob;
}
- if (priv->qemuCaps)
- qemuCaps = virObjectRef(priv->qemuCaps);
- else if (!(qemuCaps = virQEMUCapsCacheLookup(caps, driver->qemuCapsCache,
- vm->def->emulator)))
- goto endjob;
-
if (flags & VIR_DOMAIN_AFFECT_CONFIG) {
/* Make a copy for updated domain. */
vmdef = virDomainObjCopyPersistentDef(vm, caps, driver->xmlopt);
@@ -8273,7 +8263,6 @@ static int qemuDomainUpdateDeviceFlags(virDomainPtr dom,
qemuDomainObjEndJob(driver, vm);
cleanup:
- virObjectUnref(qemuCaps);
virDomainDefFree(vmdef);
if (dev != dev_copy)
virDomainDeviceDefFree(dev_copy);
8 years
[libvirt] [RFC] Fixing a regression caused by recent CPU driver changes
by Jiri Denemark
Hi all,
when I was enhancing libvirt's guest CPU configuration code to be able
to really ensure stable guest CPU ABI, I added a new attribute
//cpu/@check which is nicely backward compatible... an old libvirt will
just ignore it. However, even if check='full' will be ignored, an old
libvirt will still see the updated CPU definition (features added or
removed by the hypervisor will be shown there). And because we need QEMU
2.9.0 to check what features are going to be added or removed before we
actually start the domain, migrating such domain to an older libvirt or
QEMU may fail if QEMU enables a feature which is not supported by the
host CPU. Known features causing problems are, e.g., x2apic, hypervisor,
and arat. To make things even worse, updating a CPU definition with the
automatically added/removed features can be done since QEMU 1.5.0.
Even save/restore or snapshot revert on a single host running new
libvirt and QEMU < 2.9.0 is now affected by this regression.
The big question is how to fix the regression in a backward compatible
way and still keep the ability to properly check guest CPU ABI with new
enough libvirt and QEMU. Clearly, we need to keep both the original and
the updated CPU definition (or one of them and a diff against the
other).
I came up with the following options:
1. When migrating a domain, the domain XML would contain the original
CPU def while the updated one would be transferred in a migration
cookie.
- doesn't fix save/restore or snapshot revert
- could be fixed by not updating the CPU with QEMU < 2.9.0, but it
won't work when restore is done on a different host with older
QEMU (and yes, this happens in real life, e.g., with oVirt)
- doesn't even fix migration after save/restore or snapshot revert
2. Use migration cookie and change the save image format to contain
additional data (something like migration cookie) which a new libvirt
could make use of while old libvirt would ignore any additional data
it doesn't know about
- snapshot XML would need to be updated too, but that's trivial
- cleanly changing save image format requires its version to be
increased and old libvirt will just refuse to read such image
- this would fix save/restore on the same host or on a host with
older QEMU
- doesn't fix restore on a different host running older libvirt
- even this is done by oVirt
3. Use migration cookie and change the save image format without
increasing its version (and update snapshot XML)
- this fixes all cases
- technically possible by using one of the unused 32b ints and
adding \0 at the end of the domain XML followed by anothe XML with
the additional data (pointed to by the formerly unused uint32_t)
- very ugly hack
4. Format both CPUs in domain XML by adding a new subelement in <cpu>
which would list all extra features disabled or enabled by QEMU
- fixes all cases without the need to use migration cookie, change
save image format, or snapshot XML
- but it may be very confusing for users and it would need to be
documented as "output only, don't touch staff"
5. Add the additional data in <metadata>
- a bad joke really
So my preferred solution is 2. It breaks restore on a host with older
libvirt, but it was never guaranteed to work, even though it usually
just worked. And we could just tell oVirt to fix there usage :-) Also
additional data in save image header may be very useful in the future; I
think I remember someone sighing about the inability to store more than
just domain XML in a saved image when they were trying to fix some
compatibility issues.
Any thoughts about the options or even completely new ideas are very
welcome.
Thanks,
Jirka
8 years
[libvirt] Various apparmor related changes (part 1), version 2
by Stefan Bader
> Over the years there have been a bunch of changes to the
> apparmor profiles and/or virt-aa-helper which have been
> carried in Debian/Ubuntu but never made it upstream.
>
> In an attempt to clean this up and generally improve the
> apparmor based environments, we (Christian and I) went
> over the changes, cleaned out cruft as much as possible
> and would be sending out hunks of changes to this list
> for upstream inclusion.
>
> I hope doing multiple but smaller rounds of submissions
> will make it simpler to get those reviewed and hopefully
> accepted.
For the second version I added acks, merged the patches
related to explicit device denials and local apparmor
profiles, and split the 9p support one (holding back the
part allowing link access for later or to be replaced by
a safer solution).
I also tried to improve the explanation in the description
of patch #1 (virt-aa-helper: Ask for no deny rule for readonly
disk elements).
Thanks,
Stefan
8 years
[libvirt] [PATCH v3] Provide a useful README file
by Daniel P. Berrange
The current README file contents has almost no useful info, and that
which does exist is very outdated.
Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com>
---
Makefile.am | 1 +
README | 14 +----------
README.md | 80 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 82 insertions(+), 13 deletions(-)
mode change 100644 => 120000 README
create mode 100644 README.md
diff --git a/Makefile.am b/Makefile.am
index 333ec5a..db991ba 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -40,6 +40,7 @@ EXTRA_DIST = \
autogen.sh \
cfg.mk \
run.in \
+ README.md \
AUTHORS.in
pkgconfigdir = $(libdir)/pkgconfig
diff --git a/README b/README
deleted file mode 100644
index 3d5167d..0000000
--- a/README
+++ /dev/null
@@ -1,13 +0,0 @@
-
- LibVirt : simple API for virtualization
-
- Libvirt is a C toolkit to interact with the virtualization capabilities
-of recent versions of Linux (and other OSes). It is free software
-available under the GNU Lesser General Public License. Virtualization of
-the Linux Operating System means the ability to run multiple instances of
-Operating Systems concurrently on a single hardware system where the basic
-resources are driven by a Linux instance. The library aim at providing
-long term stable C API initially for the Xen paravirtualization but
-should be able to integrate other virtualization mechanisms if needed.
-
-Daniel Veillard <veillard(a)redhat.com>
diff --git a/README b/README
new file mode 120000
index 0000000..42061c0
--- /dev/null
+++ b/README
@@ -0,0 +1 @@
+README.md
\ No newline at end of file
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..f5d4cd2
--- /dev/null
+++ b/README.md
@@ -0,0 +1,80 @@
+[](https://travis-ci.org...
+
+Libvirt API for virtualization
+==============================
+
+Libvirt provides a portable, long term stable C API for managing the
+virtualization technologies provided by many operating systems. It
+includes support for QEMU, KVM, Xen, LXC, bhyve, Virtuozzo, VMware
+vCenter and ESX, VMware Desktop, Hyper-V, VirtualBox and the POWER
+Hypervisor.
+
+For some of these hypervisors, it provides a stateful management
+daemon which runs on the virtualization host allowing access to the
+API both by non-privileged local users and remote users.
+
+Layered packages provide bindings of the libvirt C API into other
+languages including Python, Perl, PHP, Go, Java, OCaml, as well as
+mappings into object systems such as GObject, CIM and SNMP.
+
+Further information about the libvirt project can be found on the
+website:
+
+* <https://libvirt.org>
+
+License
+-------
+
+The libvirt C API is distributed under the terms of GNU Lesser General
+Public License, version 2.1 (or later). Some parts of the code that are
+not part of the C library may have the more restrictive GNU General
+Public License, version 2.1 (or later). See the files COPYING.LESSER
+and COPYING for full license terms & conditions.
+
+Installation
+------------
+
+Libvirt uses the GNU Autotools build system, so in general can be built
+and installed with the usual commands. For example, to build in a manner
+that is suitable for installing as root, use:
+
+```
+$ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
+$ make
+$ sudo make install
+```
+
+While to build & install as an unprivileged user
+
+```
+$ ./configure --prefix=$HOME/usr
+$ make
+$ make install
+```
+
+
+The libvirt code relies on a large number of 3rd party libraries. These will
+be detected during execution of the configure script and a summary printed
+which lists any missing (optional) dependencies.
+
+Contributing
+------------
+
+The libvirt project welcomes contributions in many ways. For most components
+the best way to contribute is to send patches to the primary development
+mailing list, using the `git send-email` command. Further guidance on this
+can be found in the `HACKING` file, or the project website
+
+* <https://libvirt.org/contribute.html>
+
+Contact
+-------
+
+The libvirt project has two primary mailing lists:
+
+ * libvirt-users(a)redhat.com (**for user discussions**)
+ * libvir-list(a)redhat.com (**for development only**)
+
+Further details on contacting the project are available on the website
+
+* <https://libvirt.org/contact.html>
--
2.9.3
8 years
](https://travis-ci.org...](http://Status](https://travis-ci.org/libvirt/libvirt.svg)](https://travis-ci.org/libvirt/libvirt)){kind=link}