[PATCH v2 2/2] qemu-nbd: Removed deprecated --partition option
by Eric Blake
The option was deprecated in 4.0.0 (commit 0ae2d546); it's now been
long enough with no complaints to follow through with that process.
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
docs/interop/qemu-nbd.rst | 15 ++---
qemu-deprecated.texi | 49 ++++++--------
qemu-nbd.c | 133 +-------------------------------------
3 files changed, 24 insertions(+), 173 deletions(-)
diff --git a/docs/interop/qemu-nbd.rst b/docs/interop/qemu-nbd.rst
index 873bb9e17d56..2e20f84cf025 100644
--- a/docs/interop/qemu-nbd.rst
+++ b/docs/interop/qemu-nbd.rst
@@ -72,13 +72,6 @@ driver options if ``--image-opts`` is specified.
Export the disk as read-only.
-.. option:: -P, --partition=NUM
-
- Deprecated: Only expose MBR partition *NUM*. Understands physical
- partitions 1-4 and logical partition 5. New code should instead use
- :option:`--image-opts` with the raw driver wrapping a subset of the
- original image.
-
.. option:: -B, --bitmap=NAME
If *filename* has a qcow2 persistent bitmap *NAME*, expose
@@ -224,14 +217,14 @@ a 1 megabyte subset of a raw file, using the export name 'subset':
-t -x subset -p 10810 \
--image-opts driver=raw,offset=1M,size=1M,file.driver=file,file.filename=file.raw
-Serve a read-only copy of just the first MBR partition of a guest
-image over a Unix socket with as many as 5 simultaneous readers, with
-a persistent process forked as a daemon:
+Serve a read-only copy of a guest image over a Unix socket with as
+many as 5 simultaneous readers, with a persistent process forked as a
+daemon:
::
qemu-nbd --fork --persistent --shared=5 --socket=/path/to/sock \
- --partition=1 --read-only --format=qcow2 file.qcow2
+ --read-only --format=qcow2 file.qcow2
Expose the guest-visible contents of a qcow2 file via a block device
/dev/nbd0 (and possibly creating /dev/nbd0p1 and friends for
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 358eb6deebdc..f152e8816164 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -319,37 +319,6 @@ The above, converted to the current supported format:
@section Related binaries
-@subsection qemu-nbd --partition (since 4.0.0)
-
-The ``qemu-nbd --partition $digit'' code (also spelled @option{-P})
-can only handle MBR partitions, and has never correctly handled
-logical partitions beyond partition 5. If you know the offset and
-length of the partition (perhaps by using @code{sfdisk} within the
-guest), you can achieve the effect of exporting just that subset of
-the disk by use of the @option{--image-opts} option with a raw
-blockdev using the @code{offset} and @code{size} parameters layered on
-top of any other existing blockdev. For example, if partition 1 is
-100MiB long starting at 1MiB, the old command:
-
-@code{qemu-nbd -t -P 1 -f qcow2 file.qcow2}
-
-can be rewritten as:
-
-@code{qemu-nbd -t --image-opts driver=raw,offset=1M,size=100M,file.driver=qcow2,file.file.driver=file,file.file.filename=file.qcow2}
-
-Alternatively, the @code{nbdkit} project provides a more powerful
-partition filter on top of its nbd plugin, which can be used to select
-an arbitrary MBR or GPT partition on top of any other full-image NBD
-export. Using this to rewrite the above example results in:
-
-@code{qemu-nbd -t -k /tmp/sock -f qcow2 file.qcow2 &}
-@code{nbdkit -f --filter=partition nbd socket=/tmp/sock partition=1}
-
-Note that if you are exposing the export via /dev/nbd0, it is easier
-to just export the entire image and then mount only /dev/nbd0p1 than
-it is to reinvoke @command{qemu-nbd -c /dev/nbd0} limited to just a
-subset of the image.
-
@subsection qemu-img convert -n -o (since 4.2.0)
All options specified in @option{-o} are image creation options, so
@@ -406,3 +375,21 @@ trouble after a recent upgrade.
The "autoload" parameter has been ignored since 2.12.0. All bitmaps
are automatically loaded from qcow2 images.
+
+@section Related binaries
+
+@subsection qemu-nbd --partition (removed in 5.0.0)
+
+The ``qemu-nbd --partition $digit'' code (also spelled @option{-P})
+could only handle MBR partitions, and never correctly handled logical
+partitions beyond partition 5. Exporting a partition can still be
+done by utilizing the @option{--image-opts} option with a raw blockdev
+using the @code{offset} and @code{size} parameters layered on top of
+any other existing blockdev. For example, if partition 1 is 100MiB
+long starting at 1MiB, the old command:
+
+@code{qemu-nbd -t -P 1 -f qcow2 file.qcow2}
+
+can be rewritten as:
+
+@code{qemu-nbd -t --image-opts driver=raw,offset=1M,size=100M,file.driver=qcow2,file.file.driver=file,file.file.filename=file.qcow2}
diff --git a/qemu-nbd.c b/qemu-nbd.c
index 108a51f7eb01..a04930770ff7 100644
--- a/qemu-nbd.c
+++ b/qemu-nbd.c
@@ -100,7 +100,6 @@ static void usage(const char *name)
"\n"
"Exposing part of the image:\n"
" -o, --offset=OFFSET offset into the image\n"
-" -P, --partition=NUM only expose partition NUM\n"
" -B, --bitmap=NAME expose a persistent dirty bitmap\n"
"\n"
"General purpose options:\n"
@@ -156,96 +155,6 @@ QEMU_COPYRIGHT "\n"
, name);
}
-struct partition_record
-{
- uint8_t bootable;
- uint8_t start_head;
- uint32_t start_cylinder;
- uint8_t start_sector;
- uint8_t system;
- uint8_t end_head;
- uint8_t end_cylinder;
- uint8_t end_sector;
- uint32_t start_sector_abs;
- uint32_t nb_sectors_abs;
-};
-
-static void read_partition(uint8_t *p, struct partition_record *r)
-{
- r->bootable = p[0];
- r->start_head = p[1];
- r->start_cylinder = p[3] | ((p[2] << 2) & 0x0300);
- r->start_sector = p[2] & 0x3f;
- r->system = p[4];
- r->end_head = p[5];
- r->end_cylinder = p[7] | ((p[6] << 2) & 0x300);
- r->end_sector = p[6] & 0x3f;
-
- r->start_sector_abs = ldl_le_p(p + 8);
- r->nb_sectors_abs = ldl_le_p(p + 12);
-}
-
-static int find_partition(BlockBackend *blk, int partition,
- uint64_t *offset, uint64_t *size)
-{
- struct partition_record mbr[4];
- uint8_t data[MBR_SIZE];
- int i;
- int ext_partnum = 4;
- int ret;
-
- ret = blk_pread(blk, 0, data, sizeof(data));
- if (ret < 0) {
- error_report("error while reading: %s", strerror(-ret));
- exit(EXIT_FAILURE);
- }
-
- if (data[510] != 0x55 || data[511] != 0xaa) {
- return -EINVAL;
- }
-
- for (i = 0; i < 4; i++) {
- read_partition(&data[446 + 16 * i], &mbr[i]);
-
- if (!mbr[i].system || !mbr[i].nb_sectors_abs) {
- continue;
- }
-
- if (mbr[i].system == 0xF || mbr[i].system == 0x5) {
- struct partition_record ext[4];
- uint8_t data1[MBR_SIZE];
- int j;
-
- ret = blk_pread(blk, mbr[i].start_sector_abs * MBR_SIZE,
- data1, sizeof(data1));
- if (ret < 0) {
- error_report("error while reading: %s", strerror(-ret));
- exit(EXIT_FAILURE);
- }
-
- for (j = 0; j < 4; j++) {
- read_partition(&data1[446 + 16 * j], &ext[j]);
- if (!ext[j].system || !ext[j].nb_sectors_abs) {
- continue;
- }
-
- if ((ext_partnum + j + 1) == partition) {
- *offset = (uint64_t)ext[j].start_sector_abs << 9;
- *size = (uint64_t)ext[j].nb_sectors_abs << 9;
- return 0;
- }
- }
- ext_partnum += 4;
- } else if ((i + 1) == partition) {
- *offset = (uint64_t)mbr[i].start_sector_abs << 9;
- *size = (uint64_t)mbr[i].nb_sectors_abs << 9;
- return 0;
- }
- }
-
- return -ENOENT;
-}
-
static void termsig_handler(int signum)
{
atomic_cmpxchg(&state, RUNNING, TERMINATE);
@@ -617,7 +526,7 @@ int main(int argc, char **argv)
int64_t fd_size;
QemuOpts *sn_opts = NULL;
const char *sn_id_or_name = NULL;
- const char *sopt = "hVb:o:p:rsnP:c:dvk:e:f:tl:x:T:D:B:L";
+ const char *sopt = "hVb:o:p:rsnc:dvk:e:f:tl:x:T:D:B:L";
struct option lopt[] = {
{ "help", no_argument, NULL, 'h' },
{ "version", no_argument, NULL, 'V' },
@@ -626,7 +535,6 @@ int main(int argc, char **argv)
{ "socket", required_argument, NULL, 'k' },
{ "offset", required_argument, NULL, 'o' },
{ "read-only", no_argument, NULL, 'r' },
- { "partition", required_argument, NULL, 'P' },
{ "bitmap", required_argument, NULL, 'B' },
{ "connect", required_argument, NULL, 'c' },
{ "disconnect", no_argument, NULL, 'd' },
@@ -657,7 +565,6 @@ int main(int argc, char **argv)
int ch;
int opt_ind = 0;
int flags = BDRV_O_RDWR;
- int partition = 0;
int ret = 0;
bool seen_cache = false;
bool seen_discard = false;
@@ -793,15 +700,6 @@ int main(int argc, char **argv)
readonly = true;
flags &= ~BDRV_O_RDWR;
break;
- case 'P':
- warn_report("The '-P' option is deprecated; use --image-opts with "
- "a raw device wrapper for subset exports instead");
- if (qemu_strtoi(optarg, NULL, 0, &partition) < 0 ||
- partition < 1 || partition > 8) {
- error_report("Invalid partition '%s'", optarg);
- exit(EXIT_FAILURE);
- }
- break;
case 'B':
bitmap = optarg;
break;
@@ -898,7 +796,7 @@ int main(int argc, char **argv)
error_report("List mode is incompatible with a file name");
exit(EXIT_FAILURE);
}
- if (export_name || export_description || dev_offset || partition ||
+ if (export_name || export_description || dev_offset ||
device || disconnect || fmt || sn_id_or_name || bitmap ||
seen_aio || seen_discard || seen_cache) {
error_report("List mode is incompatible with per-device settings");
@@ -1162,33 +1060,6 @@ int main(int argc, char **argv)
}
fd_size -= dev_offset;
- if (partition) {
- uint64_t limit;
-
- if (dev_offset) {
- error_report("Cannot request partition and offset together");
- exit(EXIT_FAILURE);
- }
- ret = find_partition(blk, partition, &dev_offset, &limit);
- if (ret < 0) {
- error_report("Could not find partition %d: %s", partition,
- strerror(-ret));
- exit(EXIT_FAILURE);
- }
- /*
- * MBR partition limits are (32-bit << 9); this assert lets
- * the compiler know that we can't overflow 64 bits.
- */
- assert(dev_offset + limit >= dev_offset);
- if (dev_offset + limit > fd_size) {
- error_report("Discovered partition %d at offset %" PRIu64
- " size %" PRIu64 ", but size exceeds file length %"
- PRId64, partition, dev_offset, limit, fd_size);
- exit(EXIT_FAILURE);
- }
- fd_size = limit;
- }
-
export = nbd_export_new(bs, dev_offset, fd_size, export_name,
export_description, bitmap, readonly, shared > 1,
nbd_export_closed, writethrough, NULL,
--
2.24.1
4 years, 9 months
[PATCH v2 1/2] docs: Fix typo in qemu-nbd -P replacement
by Eric Blake
The suggested replacement for the deprecated 'qemu-nbd -P' referw to
'file.backing.opt' instead of 'file.file.opt'; using the example
verbatim results in:
qemu-nbd: Failed to blk_new_open 'driver=raw,offset=1m,size=100m,file.driver=qcow2,file.backing.driver=file,file.backing.filename=file4': A block device must be specified for "file"
Correct this text, prior to actually finishing the deprecation process.
Fixes: 0ae2d54645eb
Reported-by: Max Reitz <mreitz(a)redhat.com>
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
qemu-deprecated.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/qemu-deprecated.texi b/qemu-deprecated.texi
index 0968d37c745a..358eb6deebdc 100644
--- a/qemu-deprecated.texi
+++ b/qemu-deprecated.texi
@@ -335,7 +335,7 @@ top of any other existing blockdev. For example, if partition 1 is
can be rewritten as:
-@code{qemu-nbd -t --image-opts driver=raw,offset=1M,size=100M,file.driver=qcow2,file.backing.driver=file,file.backing.filename=file.qcow2}
+@code{qemu-nbd -t --image-opts driver=raw,offset=1M,size=100M,file.driver=qcow2,file.file.driver=file,file.file.filename=file.qcow2}
Alternatively, the @code{nbdkit} project provides a more powerful
partition filter on top of its nbd plugin, which can be used to select
--
2.24.1
4 years, 9 months
[PATCH v3 0/6] Add support for SPAPR vTPM for pSeries VM
by Stefan Berger
QEMU 5.0 will have SPAPR vTPM support. This series of patches
adds support for the XML and command line creation of the
SPAPR vTPM for pSeries VMs along with test cases.
Regards,
Stefan
v2->v3:
- Applied Jan's R-b's
- Fixed issue in 4/6.
v1->v2:
- Applied R-b to unmodified patches
- Addressed Ján's comments; added patch is 1/6
Stefan Berger (6):
conf: Introduce VIR_DOMAIN_TPM_MODEL_DEFAULT as default model
conf: Add support for tpm-spapr to domain XML
qemu: Extend QEMU capabilities with 'tpm-spapr'
qemu: Extend QEMU with tpm-spapr support
tests: Extend ppc64 capabilities data with TPM related XML and
responses
tests: Add test for domain XML with tpm-spapr TPM device model
docs/formatdomain.html.in | 7 +-
docs/schemas/domaincommon.rng | 4 +
src/conf/domain_conf.c | 2 +
src/conf/domain_conf.h | 2 +
src/qemu/qemu_capabilities.c | 6 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 15 +-
src/qemu/qemu_domain.c | 27 +-
src/qemu/qemu_domain_address.c | 9 +
tests/domaincapsdata/qemu_5.0.0.ppc64.xml | 115 +
.../caps_5.0.0.ppc64.replies | 24695 ++++++++++++++++
.../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1128 +
.../tpm-emulator-spapr.ppc64-latest.args | 45 +
tests/qemuxml2argvdata/tpm-emulator-spapr.xml | 60 +
tests/qemuxml2argvtest.c | 4 +
15 files changed, 26110 insertions(+), 10 deletions(-)
create mode 100644 tests/domaincapsdata/qemu_5.0.0.ppc64.xml
create mode 100644 tests/qemucapabilitiesdata/caps_5.0.0.ppc64.replies
create mode 100644 tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
create mode 100644 tests/qemuxml2argvdata/tpm-emulator-spapr.ppc64-latest.args
create mode 100644 tests/qemuxml2argvdata/tpm-emulator-spapr.xml
--
2.17.1
4 years, 9 months
[hooks PATCH v2] Don't allow @localhost email addresses in commit message
by Daniel P. Berrangé
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
update | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/update b/update
index 247b008..7f26035 100755
--- a/update
+++ b/update
@@ -41,6 +41,10 @@
# When this boolean is true, you may not push a merge commit to BRANCH_NAME.
# By default, you may.
#
+# hooks.allowlocalhostemail
+# When this boolean is true, commit message email addresses are
+# allowed to refer to @localhost
+#
# ---------------------------------------------------------------------
# Allow people to change server-side git config in very specific ways.
# To enable this, on the server, you must do something like the following,
@@ -264,6 +268,19 @@ if [ $check_diff = yes ]; then
fi
done
fi
+
+ allow_localhost_email=$(git config --bool hooks.allowlocalhostemail)
+ if [ "$allow_localhost_email" != "true" ]; then
+ for rev in `git log --format=%h $oldrev..$newrev`
+ do
+ git show $rev | grep -E '<.*(a)localhost.*>' >/dev/null 2>&1
+ if test $? != 0
+ then
+ echo "*** Update hook: @localhost email address is forbidden $rev" >&2
+ exit 1
+ fi
+ done
+ fi
fi
# --- Finished
--
2.24.1
4 years, 9 months
[PATCH v2 0/6] Add support for SPAPR vTPM for pSeries VM
by Stefan Berger
QEMU 5.0 will have SPAPR vTPM support. This series of patches
adds support for the XML and command line creation of the
SPAPR vTPM for pSeries VMs along with test cases.
Regards,
Stefan
v1->v2:
- Applied R-b to unmodified patches
- Addressed Ján's comments; added patch is 1/6
Stefan Berger (6):
conf: Introduce VIR_DOMAIN_TPM_MODEL_DEFAULT as default model
conf: Add support for tpm-spapr to domain XML
qemu: Extend QEMU capabilities with 'tpm-spapr'
qemu: Extend QEMU with tpm-spapr support
tests: Extend ppc64 capabilities data with TPM related XML and
responses
tests: Add test for domain XML with tpm-spapr TPM device model
docs/formatdomain.html.in | 7 +-
docs/schemas/domaincommon.rng | 4 +
src/conf/domain_conf.c | 2 +
src/conf/domain_conf.h | 2 +
src/qemu/qemu_capabilities.c | 6 +
src/qemu/qemu_capabilities.h | 1 +
src/qemu/qemu_command.c | 15 +-
src/qemu/qemu_domain.c | 27 +-
src/qemu/qemu_domain_address.c | 10 +
tests/domaincapsdata/qemu_5.0.0.ppc64.xml | 115 +
.../caps_5.0.0.ppc64.replies | 24695 ++++++++++++++++
.../qemucapabilitiesdata/caps_5.0.0.ppc64.xml | 1128 +
.../tpm-emulator-spapr.ppc64-latest.args | 45 +
tests/qemuxml2argvdata/tpm-emulator-spapr.xml | 60 +
tests/qemuxml2argvtest.c | 4 +
15 files changed, 26111 insertions(+), 10 deletions(-)
create mode 100644 tests/domaincapsdata/qemu_5.0.0.ppc64.xml
create mode 100644 tests/qemucapabilitiesdata/caps_5.0.0.ppc64.replies
create mode 100644 tests/qemucapabilitiesdata/caps_5.0.0.ppc64.xml
create mode 100644 tests/qemuxml2argvdata/tpm-emulator-spapr.ppc64-latest.args
create mode 100644 tests/qemuxml2argvdata/tpm-emulator-spapr.xml
--
2.17.1
4 years, 9 months
[libvirt PATCH v2 00/56] the gnulib saga: the season finale
by Daniel P. Berrangé
This is a followup to
v1: https://www.redhat.com/archives/libvir-list/2020-January/msg00900.html
At the end of this series we have 100% eliminated use of GNULIB
from libvirt.
The first 10 or so patches have been reviewed by Pavel already
but I include them here anyway. Rather than wait for all of
the series to be review, it is probably more productive to
push patches in batches of 10 or so.
Some things to note
- I have build tested this on Travis platforms and manually
via FreeBSD 11/12. This covers make, make syntax-check &
make check
- I've validated that virsh still works with mingw64 builds
on Windows 2008r2.
- I've done basic functional testing on Fedora 31, starting
and stopping VMs & other other simple APIs
The config.h we generate is much much smaller than before as we
eliminated alot of gnulib macros.
The risk here is that we are no longer setting some HAVE_XXX
in config.h that we rely on. To mitigate this I did a diff
of config.h before & after this series to determinw which
HAVE_XXX we no longer set. I then grepped the source to see
if we actually use any of them. This identified a few mistakes
which I fixed in testing this series.
The builds times for libvirt after applying this series have
some significant gains, improving speed of all stages (autogen,
configure & make).
Overall while this was time consuming work (due to massive number
of builds for testing each step), it is surprising just how easy
it was eliminate need for GNULIB. GLib helped a little bit in
this respect, but the biggest factor is simply that a large
number of issues GNULIB fixes only matter for ancient / obsolete
OS platforms.
With libvirt only targetting modern Linux, FreeBSD, macOS & MinGW,
the only really hard stuff where GNULIB was a big help is the
Windows sockets portability.
GNULIB was a pretty valuable approach when there were countless
flavours of UNIX to worry about with poor levels of POSIX API
compatibility. With a typical modern set of platforms, I think
it is better to just use a library like GLib and deal with any
other portability problems explicitly.
Almost certainly someone will appear after next release and
complain that libvirt no longer builds on some platform that
we don't officially support. My expectation is that when this
happens it will be reasonably easy to fix whatever problem
they report. Also at that time we can also consider whether
the platform needs to be added to CI.
Daniel P. Berrangé (56):
tests: stop setting $SHELL env variable
util: add a virArchFromHost() impl for Windows
util: add API for reading password from the console
src: remove usage of strchrnul function
build: generate configmake.h in root directory
util: use getgrouplist() directly instead of mgetgroups
tools: replace wcwidth() with g_unichar_* APIs
src: remove unused sys/utsname.h includes
util: explicitly include windows.h
storage: remove use of stat-time.h headers
src: implement APIs for passing FDs over UNIX sockets
rpc: conditionalize signal handling
src: only import sys/uio.h when journald is built
src: replace mkdir() with g_mkdir()
m4: disable polkit build on Windows
util: conditionalize more of virCommand on WIN32
src: remove all traces of Cygwin support
util: conditionalize virProcess APIs on Windows
src: conditionalize use of net/if.h
configure: add check for sys/ioctl.h
src: conditionalize use of S_ISSOCK macro
configure: request system specific extensions
src: stop using O_DIRECTORY in resctrl
src: ensure O_CLOEXEC is defined on Windows
src: conditionalize use of F_DUPFD_CLOEXEC
src: conditionalize use of O_DIRECT
src: conditionalize use of O_BINARY
src: conditionalize use of chown & stat constants
src: convert all code to use virsocket.h
tests: conditionalize use of SIGPIPE
src: conditionalize EAI_ADDRFAMILY
bootstrap: remove 18 more gnulib modules
src: introduce helper API for creating GSource for socket
rpc: convert RPC client to use GMainLoop instead of poll
tests: convert eventtest to use public event APIs
tests: remove event loop from command test
tests: refactor event test to not run lock step
tools: convert to use g_poll instead of poll
util: import an event loop impl based on GMainContext
util: switch to use the GLib event loop impl
util: delete the poll() based event loop impl
src: conditionalize / remove use of poll.h
util: conditionalize FD stream to exclude WIN32
src: remove sys/wait.h from many files
configure: request 64-bit APIs on 32-bit platforms
examples: remove obsolete workaround for mingw
src: introduce a wrapper for the pipe2() system call
src: convert code to use virPipe APIs
tools: conditionalize use of O_SYNC flag
m4: add check for pthread library
src: assume sys/sysmacros.h always exists on Linux
src: add define of ENOMSG for MinGW
src: optionally include xlocale.h header
src: ensure use of g_printf / g_fprintf functions
src: remove virFilePrintf in favour of g_fprintf
gnulib: delete all gnulib integration
.color_coded.in | 2 -
.gitignore | 9 +-
.gitmodules | 3 -
.gnulib | 1 -
.ycm_extra_conf.py.in | 2 -
Makefile.am | 46 +-
README-hacking | 9 +-
autogen.sh | 219 +----
bootstrap | 1073 -------------------------
bootstrap.conf | 136 ----
build-aux/syntax-check.mk | 132 +--
ci/build.sh | 4 +-
config-post.h | 5 +-
configure.ac | 49 +-
docs/compiling.html.in | 25 -
docs/hacking.html.in | 5 +-
examples/c/domain/domtop.c | 15 -
examples/c/domain/suspend.c | 14 -
gnulib/lib/Makefile.am | 30 -
libvirt.spec.in | 2 -
m4/virt-compile-pie.m4 | 2 +-
m4/virt-compile-warnings.m4 | 18 +-
m4/virt-polkit.m4 | 4 +
m4/virt-pthread.m4 | 26 +-
m4/virt-win-common.m4 | 8 +-
m4/virt-win-cygwin.m4 | 32 -
m4/virt-win-symbols.m4 | 4 +-
m4/virt-win-windres.m4 | 4 +-
m4/virt-xdr.m4 | 9 +-
po/POTFILES.in | 3 +-
src/Makefile.am | 17 +-
src/admin/Makefile.inc.am | 2 -
src/bhyve/Makefile.inc.am | 1 -
src/conf/domain_audit.c | 4 +-
src/conf/network_conf.c | 2 -
src/esx/esx_util.c | 3 +-
src/esx/esx_util.h | 1 -
src/interface/Makefile.inc.am | 1 -
src/internal.h | 30 +
src/libvirt-domain.c | 2 +
src/libvirt.c | 10 +-
src/libvirt_private.syms | 24 +-
src/libxl/Makefile.inc.am | 1 -
src/libxl/libxl_conf.c | 2 -
src/libxl/libxl_migration.c | 6 +-
src/locking/Makefile.inc.am | 9 +-
src/locking/lock_daemon.c | 2 +-
src/logging/Makefile.inc.am | 2 -
src/logging/log_daemon.c | 2 +-
src/logging/log_handler.c | 6 +-
src/lxc/Makefile.inc.am | 2 -
src/lxc/lxc_container.c | 1 -
src/lxc/lxc_controller.c | 8 +-
src/lxc/lxc_driver.c | 8 +-
src/lxc/lxc_process.c | 5 +-
src/network/Makefile.inc.am | 3 +-
src/network/bridge_driver.c | 1 -
src/node_device/Makefile.inc.am | 2 -
src/nwfilter/Makefile.inc.am | 1 -
src/nwfilter/nwfilter_dhcpsnoop.c | 3 -
src/nwfilter/nwfilter_learnipaddr.c | 4 +-
src/openvz/openvz_conf.c | 5 +-
src/openvz/openvz_driver.c | 1 -
src/qemu/Makefile.inc.am | 1 -
src/qemu/qemu_agent.c | 4 +-
src/qemu/qemu_capabilities.c | 1 -
src/qemu/qemu_conf.c | 4 +-
src/qemu/qemu_domain.c | 4 +-
src/qemu/qemu_driver.c | 4 +-
src/qemu/qemu_interface.c | 4 +-
src/qemu/qemu_migration.c | 28 +-
src/qemu/qemu_monitor.c | 3 +-
src/qemu/qemu_monitor_json.c | 4 +-
src/qemu/qemu_tpm.c | 5 +-
src/remote/Makefile.inc.am | 1 -
src/remote/qemu_protocol.x | 1 -
src/remote/remote_daemon.c | 3 +-
src/remote/remote_protocol.x | 2 +-
src/rpc/Makefile.inc.am | 3 -
src/rpc/genprotocol.pl | 2 +-
src/rpc/virnetclient.c | 248 +++---
src/rpc/virnetdaemon.c | 44 +-
src/rpc/virnetdaemon.h | 4 +
src/rpc/virnetprotocol.x | 2 +-
src/rpc/virnetsocket.c | 44 +-
src/secret/Makefile.inc.am | 1 -
src/security/Makefile.inc.am | 1 -
src/security/security_dac.c | 4 +
src/security/security_manager.c | 2 +
src/security/security_selinux.c | 16 +-
src/storage/Makefile.inc.am | 16 -
src/storage/storage_backend_iscsi.c | 1 -
src/storage/storage_backend_logical.c | 1 -
src/storage/storage_util.c | 25 +-
src/util/Makefile.inc.am | 6 +-
src/util/iohelper.c | 4 +
src/util/viralloc.h | 3 +-
src/util/virarch.c | 52 +-
src/util/virarptable.c | 1 -
src/util/virbitmap.c | 4 +-
src/util/vircgroup.c | 18 +-
src/util/vircommand.c | 183 +++--
src/util/virdevmapper.c | 4 +-
src/util/virdnsmasq.c | 9 +-
src/util/virevent.c | 21 +-
src/util/vireventglib.c | 455 +++++++++++
src/util/vireventglib.h | 28 +
src/util/vireventglibwatch.c | 248 ++++++
src/util/vireventglibwatch.h | 48 ++
src/util/vireventpoll.c | 772 ------------------
src/util/vireventpoll.h | 126 ---
src/util/virfdstream.c | 131 ++-
src/util/virfile.c | 102 +--
src/util/virfile.h | 3 -
src/util/virgettext.c | 3 +
src/util/virhook.c | 1 -
src/util/virhostcpu.c | 1 -
src/util/virhostmem.c | 1 -
src/util/viriptables.c | 1 -
src/util/virlog.c | 8 +-
src/util/virnetdev.c | 1 -
src/util/virnetdev.h | 4 +-
src/util/virnetdevbridge.c | 8 +-
src/util/virnetdevip.c | 4 +-
src/util/virnetdevmacvlan.c | 3 +-
src/util/virnetdevtap.c | 4 +-
src/util/virnetdevveth.c | 2 -
src/util/virnetdevvportprofile.c | 3 +-
src/util/virnetlink.c | 3 +-
src/util/virpolkit.c | 4 +-
src/util/virprocess.c | 108 ++-
src/util/virresctrl.c | 2 +-
src/util/virsocket.c | 139 +++-
src/util/virsocket.h | 21 +-
src/util/virsocketaddr.c | 2 -
src/util/virsocketaddr.h | 20 +-
src/util/virstring.c | 3 +
src/util/virsysinfo.c | 15 +-
src/util/virsystemd.c | 9 +-
src/util/virutil.c | 146 +++-
src/util/virutil.h | 36 +
src/util/virxdrdefs.h | 12 +-
src/vbox/Makefile.inc.am | 1 -
src/vbox/vbox_MSCOMGlue.c | 6 +-
src/vz/Makefile.inc.am | 1 -
src/vz/vz_driver.c | 1 -
tests/Makefile.am | 26 +-
tests/commanddata/test27.log | 6 +-
tests/commanddata/test3.log | 2 +-
tests/commandhelper.c | 5 +-
tests/commandtest.c | 115 +--
tests/eventtest.c | 219 +++--
tests/fdstreamtest.c | 42 +-
tests/libxlmock.c | 2 +-
tests/nsstest.c | 3 +-
tests/qemusecuritytest.c | 2 +-
tests/shunloadtest.c | 2 +-
tests/ssh.c | 3 +-
tests/testutils.c | 5 +-
tests/testutils.h | 6 -
tests/testutilsqemu.c | 4 +-
tests/virauthconfigtest.c | 2 +
tests/vircgroupmock.c | 8 +-
tests/virkeyfiletest.c | 2 +
tests/virlockspacetest.c | 4 +-
tests/virnetmessagetest.c | 2 +
tests/virnetsockettest.c | 3 +-
tests/virnettlscontexttest.c | 3 +-
tests/virnettlshelpers.c | 1 -
tests/virnettlssessiontest.c | 3 +-
tests/virportallocatormock.c | 5 +-
tests/virstringtest.c | 37 +-
tests/virtestmock.c | 9 +-
tests/virtimetest.c | 2 +
tests/viruritest.c | 2 +
tests/vshtabletest.c | 4 +
tools/Makefile.am | 9 +-
tools/nss/libvirt_nss.c | 7 +-
tools/virsh-domain.c | 72 +-
tools/virsh.c | 6 -
tools/virt-admin.c | 5 -
tools/virt-login-shell.c | 6 +-
tools/vsh-table.c | 2 +-
tools/vsh.c | 31 +-
184 files changed, 2295 insertions(+), 3708 deletions(-)
delete mode 160000 .gnulib
delete mode 100755 bootstrap
delete mode 100644 bootstrap.conf
delete mode 100644 gnulib/lib/Makefile.am
delete mode 100644 m4/virt-win-cygwin.m4
create mode 100644 src/util/vireventglib.c
create mode 100644 src/util/vireventglib.h
create mode 100644 src/util/vireventglibwatch.c
create mode 100644 src/util/vireventglibwatch.h
delete mode 100644 src/util/vireventpoll.c
delete mode 100644 src/util/vireventpoll.h
--
2.24.1
4 years, 9 months
Disabling PCI "hot-unplug" for a guest (and/or a single PCI device)
by Laine Stump
Although I've never experienced it, due to not running Windows guests,
I've recently learned that a Windows guest permits a user (hopefully
only one with local admin privileges??!) to "hot-unplug" any PCI device.
I've also learned that some hypervisor admins don't want to permit
admins of the virtual machines they're managing to unplug PCI devices. I
believe this is impossible to prevent on an i440fx-based machinetype,
and can only be done on a q35-based machinetype by assigning the devices
to the root bus (so that they are seen as integrated devices) rather
than to a pcie-root-port. But when libvirt is assigning PCI addresses to
devices in a q35-base guest, it will *always* assign a PCIe device to a
pcie-root-port specifically so that hotplug is possible (this was done
to maintain functional parity with i440fx guests, where all PCI slots
support hotplug).
To make the above-mentioned admins happy, we need to make it possible to
(easily) create guest configurations for q35-based virtual machines
where the PCI devices can't be hot-unplugged by the guest OS.
Thinking in the context of a management platform (e.g. OpenStack or
ovirt) that goes through libvirt to use QEMU (and forgetting about
i440fx, concentrating only on q35), I can think of a few different ways
this could be done:
1) Rather than leaving the task of assignung the PCI addresses of
devices to libvirt (which is what essentially *all* management apps that
use libvirt currently do), the management application could itself
directly assign the PCI addressed of all devices to be slots on pcie.0.
This is problematic because once a management application has taken over
the PCI address assignment of a single device, it must learn the rules
of what type of device can be plugged into what type of PCI controller
(including plugging in new controllers when necessary), and keep track
of which slots on which PCI controllers are already in use - effectively
tossing that part of libvirt's functionality / embedded knowledge /
usefulness to management applications out the window. It's even more of
a problem for management applications that have no provision for
manually assigning PCI addresses - virt-manager for example only
supports this by using "XML mode" where the froopy point-click UI is
swapped out for an edit window where the user is simply presented with
the full XML for a device and allowed to tweak it around as they see fit
(including duplicate addresses, plugging the wrong kind of device into
the wrong slot, referencing non-existent controllers, etc). (NB: you
could argue that management could just take over PCI address assignment
in the case of wanting hotplug disabled, and only care about / support
pcie.0 (which makes the task much easier, since you just ignore the
existence of any other PCI controllers, leaving you with a homogenous
array of 32 slot x 8 functions, but becomes much more complicated if you
want to allow a mix of hotpluggable and non-hotpluggable devices, and
you *know* someone will)
2) libvirt could gain a knob "somewhere" in the domain XML to force a
single device, or all devices, to be assigned to a PCI address on pcie.0
rather than on a pcie-root-port. This could be thought of as a "hint"
about device placement, as well as extra validation in the case that a
PCI address has been manually assigned. So, for example, let's say a
"hotplug='disable'" option is added somewhere at the top level of the
domain (maybe "<hotplug enable='no'/>" inside <features> or something
like that); when PCI addresses are assigned by libvirt, it would attempt
to find a slot on a controller that didn't support hotplug. And/or a
similar knob could be added to each device. In both cases, the setting
would be used both when assigning PCI addresses and also to validate
user-provided PCI addresses to assure that the desired criterion was met
(otherwise someone would manually select a PCI address on a controller
that supported hotplug, but then set "hotplug='disabled'" and expect
hotplug to be magically disabled on the slot).
Some of you will remember that I proposed such a knob for libvirt a few
years ago when we were first fleshing out support for QEMU's PCI Express
controllers and the Q35 machinetype, and it was rejected as "libvirt
dictating policy". Of course at that time there weren't actual users
demanding the functionality, and now there are. Aside from that, all I
can say is that it isn't libvirt dictating this policy, it's the user of
libvirt, and libvirt is just following directions :-) (and that I really
really dislike the idea of a forced handover of the entire task of
assigning/managing device PCI addresses to management apps just because
they decide they want to disable guest-initiated hotplug
3) qemu could add a "hotpluggable=no" commandline option to all PCI
devices (including vfio-pci) and then do whatever is necessary to make
sure this is honored in the emulated hardware (is it possible to set
this on a per-slot basis in a PCI controller? Or must it be done for an
entire controller? I suppose it's not as much of an issue for
pcie-root-port, as long as you're not using multiple functions). libvirt
would then need to add this option to the XML for each device, and
management applications would need to set it - it would essentially look
the same to the management application, but it would be implemented
differently - instead of libvirt using that flag to make a choice about
which slot to assign, it would assign PCI addresses in the same manner
as before, and use the libvirt XML flag to set a QEMU commandline flag
for the device.
The upside of this is that we would be disabling hotplug by "disabling
hotplug" rather than by "assigning the device to a slot that
coincidentally doesn't support hotplug", making it all more orthogonal -
everything else in a guest's config could remain exactly the same while
enabling/disabling hotplug. (Another upside is that it could possibly be
made to work for i440fx machine types, but we're not supposed to care
about that any more, so I won't mention it :-)) The downside is that it
requires a new feature in QEMU (whose difficulty/feasibility I have 0
knowledge of), so there are 3 layers of work rather than 2.
So does anyone have any different (and hopefully better) idea of how to
do this? Arguments for/against the 3 possibilities I've listed here?
4 years, 9 months
[libvirt PATCH] rpc: gendispatch: trim Flags from the return struct name
by Ján Tomko
This lets it generate the remote dispatch for StorageVolGetInfoFlags.
Signed-off-by: Ján Tomko <jtomko(a)redhat.com>
---
src/remote/remote_daemon_dispatch.c | 35 -----------------------------
src/remote/remote_protocol.x | 2 +-
src/rpc/gendispatch.pl | 1 +
3 files changed, 2 insertions(+), 36 deletions(-)
diff --git a/src/remote/remote_daemon_dispatch.c b/src/remote/remote_daemon_dispatch.c
index b08bd5b8ba..2741a32f63 100644
--- a/src/remote/remote_daemon_dispatch.c
+++ b/src/remote/remote_daemon_dispatch.c
@@ -7162,41 +7162,6 @@ remoteDispatchDomainInterfaceAddresses(virNetServerPtr server G_GNUC_UNUSED,
}
-static int
-remoteDispatchStorageVolGetInfoFlags(virNetServerPtr server G_GNUC_UNUSED,
- virNetServerClientPtr client,
- virNetMessagePtr msg G_GNUC_UNUSED,
- virNetMessageErrorPtr rerr,
- remote_storage_vol_get_info_flags_args *args,
- remote_storage_vol_get_info_flags_ret *ret)
-{
- int rv = -1;
- virStorageVolPtr vol = NULL;
- virStorageVolInfo tmp;
- virConnectPtr conn = remoteGetStorageConn(client);
-
- if (!conn)
- goto cleanup;
-
- if (!(vol = get_nonnull_storage_vol(conn, args->vol)))
- goto cleanup;
-
- if (virStorageVolGetInfoFlags(vol, &tmp, args->flags) < 0)
- goto cleanup;
-
- ret->type = tmp.type;
- ret->capacity = tmp.capacity;
- ret->allocation = tmp.allocation;
- rv = 0;
-
- cleanup:
- if (rv < 0)
- virNetMessageSaveError(rerr);
- virObjectUnref(vol);
- return rv;
-}
-
-
static int
remoteDispatchNetworkPortGetParameters(virNetServerPtr server G_GNUC_UNUSED,
virNetServerClientPtr client,
diff --git a/src/remote/remote_protocol.x b/src/remote/remote_protocol.x
index 1f7963510a..d4393680e9 100644
--- a/src/remote/remote_protocol.x
+++ b/src/remote/remote_protocol.x
@@ -6367,7 +6367,7 @@ enum remote_procedure {
REMOTE_PROC_NODE_DEVICE_EVENT_UPDATE = 377,
/**
- * @generate: none
+ * @generate: server
* @priority: high
* @acl: storage_vol:read
*/
diff --git a/src/rpc/gendispatch.pl b/src/rpc/gendispatch.pl
index 8656c8f205..987a136566 100755
--- a/src/rpc/gendispatch.pl
+++ b/src/rpc/gendispatch.pl
@@ -994,6 +994,7 @@ elsif ($mode eq "server") {
} else {
my $struct_name = $call->{ProcName};
$struct_name =~ s/Get//;
+ $struct_name =~ s/Flags$//;
splice(@args_list, $call->{ret_offset}, 0, ("&tmp"));
--
2.21.0
4 years, 9 months
[PATCH 0/9] qemu: Properly support 'volume' type backing stores
by Peter Krempa
We didn't bother to translate the disk source when an user used
<backingStore type='volume'>.
Peter Krempa (9):
virDomainDiskAddISCSIPoolSourceHost: Sanitize handling of string list
virDomainDiskAddISCSIPoolSourceHost: use g_new0 instead of VIR_ALLOC_N
virDomainDiskAddISCSIPoolSourceHost: Remove 'cleanup' label
virDomainDiskAddISCSIPoolSourceHost: Remove ternary operator
virDomainDiskAddISCSIPoolSourceHost: Take virStorageSourcePtr instead
of virDomainDiskDefPtr
virDomainDiskTranslateSourcePoolAuth: Take virStorageSourcePtr instead
of virDomainDiskDefPtr
virDomainDiskTranslateISCSIDirect: Take virStorageSourcePtr instead of
virDomainDiskDefPtr
virDomainDiskTranslateSourcePool: split code to setup one storage
source
virDomainDiskTranslateSourcePool: Translate 'VOLUME' disks in whole
backing chain
src/conf/domain_conf.c | 188 ++++++++++++++++++++---------------------
1 file changed, 92 insertions(+), 96 deletions(-)
--
2.24.1
4 years, 9 months
[libvirt] Designing XML for HMAT
by Michal Privoznik
Dear list,
QEMU gained support for configuring HMAT recently (see
v4.2.0-415-g9b12dfa03a
and friends). HMAT stands for Heterogeneous Memory Attribute Table and
defines
various attributes to NUMA. Guest OS/app can read these information and fine
tune optimization. See [1] for more info (esp. links in the transcript).
QEMU defines so called initiator, which is an attribute to a NUMA node
and if
specified points to another node that has the best performance to this node.
For instance:
-machine hmat=on \
-m 2G,slots=2,maxmem=4G \
-object memory-backend-ram,size=1G,id=m0 \
-object memory-backend-ram,size=1G,id=m1 \
-numa node,nodeid=0,memdev=m0 \
-numa node,nodeid=1,memdev=m1,initiator=0 \
-smp 2,sockets=2,maxcpus=2 \
-numa cpu,node-id=0,socket-id=0 \
-numa cpu,node-id=0,socket-id=1
creates a machine with 2 NUMA nodes, node 0 has CPUs and node 1 has
memory only
and it's initiator is node 0 (yes, HMAT allows you to create CPU-less "NUMA"
nodes). The initiator of node 0 is not specified, but since the node has at
least one CPU it is initiator to itself (and has to be per specs).
This could be represented by an attribute to our /domain/cpu/numa/cell
element.
For instance like this:
<domain>
<vcpu>2</vcpu>
<cpu>
<numa>
<cell id='0' cpus='0,1' memory='1' unit='GiB'/>
<cell id='1' memory='1' unit='GiB' initiator='0'/>
</numa>
</cpu>
</domain>
Then, QEMU allows us to control two other important memory attributes:
1) hmat-lb for Latency and Bandwidth
2) hmat-cache for cache attributes
For example:
-machine hmat=on \
-m 2G,slots=2,maxmem=4G \
-object memory-backend-ram,size=1G,id=m0 \
-object memory-backend-ram,size=1G,id=m1 \
-smp 2,sockets=2,maxcpus=2 \
-numa node,nodeid=0,memdev=m0 \
-numa node,nodeid=1,memdev=m1,initiator=0 \
-numa cpu,node-id=0,socket-id=0 \
-numa cpu,node-id=0,socket-id=1 \
-numa
hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-latency,latency=5
\
-numa
hmat-lb,initiator=0,target=0,hierarchy=memory,data-type=access-bandwidth,bandwidth=200M
\
-numa
hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,latency=10
\
-numa
hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-bandwidth,bandwidth=100M
\
-numa
hmat-cache,node-id=0,size=10K,level=1,associativity=direct,policy=write-back,line=8
\
-numa
hmat-cache,node-id=1,size=10K,level=1,associativity=direct,policy=write-back,line=8
This extends previous example by defining some latencies and cache
attributes.
The node 0 has access latency of 5 ns and bandwidth of 200MB/s and node
1 has
access latency of 10ns and bandwidth of only 100MB/s. The memory cache
level 1
on both nodes is 10KB, cache line is 8B long with write-back policy and
direct
associativity (whatever that means).
For better future extensibility I'd express these as separate elements,
rather
than attributes to <cell/> element. For instance like this:
<domain>
<vcpu>2</vcpu>
<cpu>
<numa>
<cell id='0' cpus='0,1' memory='1' unit='GiB'>
<latencies>
<latency type='access' value='5'/>
<bandwidth type='access' unit='MiB' value='200'/>
</latencies>
<caches>
<cache level='1' associativity='direct' policy='write-back'>
<size unit='KiB' value='10'/>
<line unit='B' value='8'/>
</cache>
</caches>
</cell>
<cell id='1' memory='1' unit='GiB' initiator='0'>
<latencies>
<latency type='access' value='10'/>
<bandwidth type='access' unit='MiB' value='100'/>
</latencies>
<caches>
<cache level='1' associativity='direct' policy='write-back'>
<size unit='KiB' value='10'/>
<line unit='B' value='8'/>
</cache>
</caches>
</cell>
</numa>
</cpu>
</domain>
Thing is, the @hierarchy argument accepts: memory (referring to whole
memory),
or first-level|second-level|third-level (referring to side caches for each
domain). I haven't figured out yet, how to express the levels in XML yet.
The @data-type argument accepts access|read|write (this is expressed by
@type
attribute to <latency/> and <bandwidth/> elements). Latency and
bandwidth can
be combined with each type: access-latency, read-latency, write-latency,
access-bandwidth, read-bandwidth, write-bandwidth. And these 6 can then be
combined with aforementioned @hierarchy, producing 24 combinations (if I
read
qemu cmd line specs correctly [2]).
What are your thoughts?
Michal
1: https://bugzilla.redhat.com/show_bug.cgi?id=1786303
2:
https://git.qemu.org/?p=qemu.git;a=blob;f=qemu-options.hx;h=d4b73ef60c1d4...
4 years, 9 months