[PATCH v2] launch: add support for autodetection of appliance image format
by Pavel Butsykin
This feature allows you to use different image formats for the fixed
appliance. The raw format is used by default.
Signed-off-by: Pavel Butsykin <pbutsykin(a)virtuozzo.com>
---
lib/launch-direct.c | 2 ++
lib/launch-libvirt.c | 19 ++++++++++++-------
m4/guestfs_appliance.m4 | 11 +++++++++++
3 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/lib/launch-direct.c b/lib/launch-direct.c
index 0be662e25..b9b54857a 100644
--- a/lib/launch-direct.c
+++ b/lib/launch-direct.c
@@ -592,7 +592,9 @@ launch_direct (guestfs_h *g, void *datav, const char *arg)
append_list ("id=appliance");
append_list ("cache=unsafe");
append_list ("if=none");
+#ifndef APPLIANCE_FMT_AUTO
append_list ("format=raw");
+#endif
} end_list ();
start_list ("-device") {
append_list ("scsi-hd");
diff --git a/lib/launch-libvirt.c b/lib/launch-libvirt.c
index 4adb2cfb3..030ea6911 100644
--- a/lib/launch-libvirt.c
+++ b/lib/launch-libvirt.c
@@ -212,9 +212,10 @@ get_source_format_or_autodetect (guestfs_h *g, struct drive *drv)
/**
* Create a qcow2 format overlay, with the given C<backing_drive>
- * (file). The C<format> parameter, which must be non-NULL, is the
- * backing file format. This is used to create the appliance overlay,
- * and also for read-only drives.
+ * (file). The C<format> parameter is the backing file format.
+ * The C<format> parameter can be NULL, in this case the backing
+ * format will be determined automatically. This is used to create
+ * the appliance overlay, and also for read-only drives.
*/
static char *
make_qcow2_overlay (guestfs_h *g, const char *backing_drive,
@@ -223,8 +224,6 @@ make_qcow2_overlay (guestfs_h *g, const char *backing_drive,
char *overlay;
struct guestfs_disk_create_argv optargs;
- assert (format != NULL);
-
if (guestfs_int_lazy_make_tmpdir (g) == -1)
return NULL;
@@ -232,8 +231,10 @@ make_qcow2_overlay (guestfs_h *g, const char *backing_drive,
optargs.bitmask = GUESTFS_DISK_CREATE_BACKINGFILE_BITMASK;
optargs.backingfile = backing_drive;
- optargs.bitmask |= GUESTFS_DISK_CREATE_BACKINGFORMAT_BITMASK;
- optargs.backingformat = format;
+ if (format) {
+ optargs.bitmask |= GUESTFS_DISK_CREATE_BACKINGFORMAT_BITMASK;
+ optargs.backingformat = format;
+ }
if (guestfs_disk_create_argv (g, overlay, "qcow2", -1, &optargs) == -1) {
free (overlay);
@@ -461,7 +462,11 @@ launch_libvirt (guestfs_h *g, void *datav, const char *libvirt_uri)
/* Note that appliance can be NULL if using the old-style appliance. */
if (appliance) {
+#ifdef APPLIANCE_FMT_AUTO
+ params.appliance_overlay = make_qcow2_overlay (g, appliance, NULL);
+#else
params.appliance_overlay = make_qcow2_overlay (g, appliance, "raw");
+#endif
if (!params.appliance_overlay)
goto cleanup;
}
diff --git a/m4/guestfs_appliance.m4 b/m4/guestfs_appliance.m4
index 81c43879f..4e1ec8135 100644
--- a/m4/guestfs_appliance.m4
+++ b/m4/guestfs_appliance.m4
@@ -139,3 +139,14 @@ AC_SUBST([GUESTFS_DEFAULT_PATH])
AC_DEFINE_UNQUOTED([GUESTFS_DEFAULT_PATH], ["$GUESTFS_DEFAULT_PATH"],
[Define guestfs default path.])
+
+AC_ARG_ENABLE([appliance-fmt-auto],
+ [AS_HELP_STRING([--enable-appliance-fmt-auto],
+ [enable autodetection of appliance image format @<:@default=no@:>@])],
+ [ENABLE_APPLIANCE_FMT_AUTO="$enableval"],
+ [ENABLE_APPLIANCE_FMT_AUTO=no])
+
+if test "x$ENABLE_APPLIANCE_FMT_AUTO" = "xyes"; then
+ AC_DEFINE([APPLIANCE_FMT_AUTO], [1],
+ [Define to 1 if enabled autodetection of appliance image format.])
+fi
--
2.13.0
4 years, 9 months
1.39 proposal: Let's split up the libguestfs git repo and tarballs
by Richard W.M. Jones
My contention is that the libguestfs git repository is too large and
unwieldy. There are too many separate, unrelated projects and as a
result of that the source has too many dependencies and takes too long
to build and test.
The project divides (sort of) naturally into layers -- the library,
the bindings, the various virt tools -- and could be split along those
lines into separate projects which can then be released and evolve at
their own pace.
My suggested split would be something like this:
* libguestfs: The library, daemon and appliance. That would include
the following directories in a single project:
appliance
bash
contrib
daemon
docs
examples
gnulib
lib
logo
test-tool
tmp
utils
website
* 1 project for each language binding:
csharp
erlang
gobject
golang
haskell
java
lua
ocaml
php
perl
python
ruby
* virt-customize and related tools, we'd probably call this subproject
"virt-builder". It would include virt-builder, virt-customize and
virt-sysprep, since they share a lot of common code.
* 1 project for each of the following items:
small tools written in C
(virt-cat, virt-filesystems, virt-log, virt-ls, virt-tail,
virt-diff, virt-edit, virt-format, guestmount, virt-inspector,
virt-make-fs, virt-rescue)
guestfish
virt-alignment-scan and virt-df
virt-dib
virt-get-kernel
virt-resize
virt-sparsify
virt-v2v and virt-p2v
virt-win-reg
* I'd be inclined to drop the legacy Perl tools virt-tar,
virt-list-filesystems, virt-list-partitions unless someone
especially wished to step forward to maintain them.
* common code and generator: Off to the side we'd somehow need to
package up the common code and the generator for use by all of the
above projects. It wouldn't be a separate project for downstream
packagers, but instead the code would be included (ie. duplicated)
in tarballs and upstream available as a side git repo that you'd
need to include when building (git submodule?). This is somewhat
unspecified.
M4, PO, and tests would be split between the projects as appropriate.
My proposal would be to do this incrementally, rather than all at
once, moving the easier things out first.
Thoughts?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
4 years, 11 months
[PATCH nbdkit 0/7] server: Implement NBD_FLAG_CAN_MULTI_CONN.
by Richard W.M. Jones
First thing to say is that I need to do a *lot* more testing on this,
so this is just an early peek. In particular, although it passed
‘make check && make check-valgrind’ I have *not* tested it against a
multi-conn-aware client such as the Linux kernel >= 4.9.
This implements NBD_FLAG_CAN_MULTI_CONN, described in the protocol doc
as:
"NBD_FLAG_CAN_MULTI_CONN: Indicates that the server operates
entirely without cache, or that the cache it uses is shared among
all connections to the given device. In particular, if this flag is
present, then the effects of NBD_CMD_FLUSH and NBD_CMD_FLAG_FUA MUST
be visible across all connections when the server sends its reply to
that command to the client. In the absence of this flag, clients
SHOULD NOT multiplex their commands over more than one connection to
the export."
This is necessary to support the Linux nbd client -C option.
The only plugin which sets the flag so far is file. The ocaml, sh and
nbd plugins allow the flag to be controlled or passed through.
Notable also is that the blocksize filter has to filter out this flag,
because I'm not convinced that the bounce buffer is safe. However I
believe the other filters *are* safe (although not really certain
about the fua filter, and the new cache filter is tricky too).
My feeling is that we should set the flag unconditionally for all
readonly connections, but I can think of nasty corner cases where it
might not work. We should most probably set it in all plugins that
are readonly (eg. nbdkit-pattern-plugin).
Rich.
5 years, 6 months
[PATCH nbdkit] Add support for writing plugins in Rust.
by Richard W.M. Jones
This adds very rough support for writing nbdkit plugins in Rust. This
is not very idiomatic -- essentially we're handling the direct C calls
from nbdkit in Rust. We have to use ‘unsafe’ in a few places because
there's no way to tell the Rust code that nbdkit satisfies guarantees
(eg. around thread safety, always returning leaked pointers back to
the close function, always doing bounds checking).
See the TODO file changes for the mising bits.
TBH there's not much to review here.
Rich.
5 years, 7 months
[PATCH 0/3] RFC: v2v: add -o json output mode
by Pino Toscano
This series adds a new output mode for virt-v2v, called -o json.
It produces local files, just like -o local, although the metadata
produced is a JSON file with data that v2v collected in the conversion
process. This can be useful for converting to unsupported destinations,
still based on QEMU/KVM.
In addition to a simple different metadata, it offers a way to relocate
the disks, with %{...}-like variables (only 3 added ATM, more can be
added) to change their paths depending on data of the guest/disks.
Thanks,
Pino Toscano (3):
common/mlpcre: add offset flag for PCRE.matches
v2v: add Var_expander
v2v: add -o json output mode
.gitignore | 1 +
common/mlpcre/PCRE.ml | 2 +-
common/mlpcre/PCRE.mli | 5 +-
common/mlpcre/pcre-c.c | 16 +-
common/mlpcre/pcre_tests.ml | 15 +-
v2v/Makefile.am | 36 +++-
v2v/cmdline.ml | 29 +++
v2v/create_json.ml | 348 ++++++++++++++++++++++++++++++++++
v2v/create_json.mli | 29 +++
v2v/dummy.c | 2 +
v2v/output_json.ml | 116 ++++++++++++
v2v/output_json.mli | 31 +++
v2v/var_expander.ml | 69 +++++++
v2v/var_expander.mli | 82 ++++++++
v2v/var_expander_tests.ml | 103 ++++++++++
v2v/virt-v2v-output-local.pod | 50 +++++
v2v/virt-v2v.pod | 15 +-
17 files changed, 937 insertions(+), 12 deletions(-)
create mode 100644 v2v/create_json.ml
create mode 100644 v2v/create_json.mli
create mode 100644 v2v/dummy.c
create mode 100644 v2v/output_json.ml
create mode 100644 v2v/output_json.mli
create mode 100644 v2v/var_expander.ml
create mode 100644 v2v/var_expander.mli
create mode 100644 v2v/var_expander_tests.ml
--
2.20.1
5 years, 7 months
[PATCH] v2v: windows: save log file from rhev-apt installer
by Tomáš Golembiovský
Store log from MSI installer. Log file will be located in firstboot
scripts-done directory with name rhev-apt.log. The path has to be
double-quoted to handle spaces in path name properly.
Hopefully this can help resolve RHBZ#1584678 someday.
Signed-off-by: Tomáš Golembiovský <tgolembi(a)redhat.com>
---
v2v/convert_windows.ml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/v2v/convert_windows.ml b/v2v/convert_windows.ml
index 1db3c0ea6..7ea56592c 100644
--- a/v2v/convert_windows.ml
+++ b/v2v/convert_windows.ml
@@ -378,7 +378,7 @@ echo Wait for PnP to complete
@echo off
echo installing rhev-apt
-\"\\rhev-apt.exe\" /S /v/qn
+\"\\rhev-apt.exe\" /S /v/qn /v/l*vx \"/v\\\"%cd%\\rhev-apt.log\\\"\"
echo starting rhev-apt
net start rhev-apt
--
2.20.1
5 years, 8 months
[PATCH v2 0/3] allow alternative guest tools directories for distributions
by Tomáš Golembiovský
First patch just fixes installing guest tools from directory that was broken.
Second patch revamps how virt-v2v chooses from which directory install guest
tools on Linux. Details in commit message.
v2:
- included comments from Pino and Rich
- added test
Tomáš Golembiovský (3):
v2v: fix path to source when copying files from guest tools directory
v2v: allow alternative directories for distributions
v2v: tests: test paths for installation of linux guest tools
v2v/Makefile.am | 1 +
v2v/test-v2v-copy-guest-tools.sh | 87 ++++++++++++++++++++++++++++++++
v2v/windows_virtio.ml | 82 ++++++++++++++++++------------
3 files changed, 137 insertions(+), 33 deletions(-)
create mode 100755 v2v/test-v2v-copy-guest-tools.sh
--
2.20.1
5 years, 8 months
[PATCH] inspect: fix icon of RHEL
by Pino Toscano
Use a better icon for RHEL guests, still provided by redhat-logos (or
equivalent in downstream distributions), and which fits a better
definition of logo for the distribution.
Thanks to Ray Strode for the hints.
---
lib/inspect-icon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/inspect-icon.c b/lib/inspect-icon.c
index e785a2172..5c7da0476 100644
--- a/lib/inspect-icon.c
+++ b/lib/inspect-icon.c
@@ -321,7 +321,7 @@ icon_rhel (guestfs_h *g, int major, size_t *size_r)
if (major < 7)
shadowman = "/usr/share/pixmaps/redhat/shadowman-transparent.png";
else
- shadowman = "/usr/share/pixmaps/fedora-logo-sprite.png";
+ shadowman = "/usr/share/icons/hicolor/96x96/apps/system-logo-icon.png";
return get_png (g, shadowman, size_r, 102400);
}
--
2.20.1
5 years, 8 months
[PATCH] v2v: -o libvirt: write win2k19 osinfo ID
by Pino Toscano
When writing the libosinfo metadata in the libvirt XML, use the newly
added (in osinfo-db) ID for Windows Server 2019; sadly, this version of
Windows has the same version as Windows Server 2016, so distinguish it
by looking at its product name.
---
v2v/create_libvirt_xml.ml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/v2v/create_libvirt_xml.ml b/v2v/create_libvirt_xml.ml
index a8dc1f2f0..dbc24315f 100644
--- a/v2v/create_libvirt_xml.ml
+++ b/v2v/create_libvirt_xml.ml
@@ -124,6 +124,11 @@ let get_osinfo_id = function
| { i_type = "windows"; i_major_version = 6; i_minor_version = 3 } ->
Some "http://microsoft.com/win/8.1"
+ | { i_type = "windows"; i_major_version = 10; i_minor_version = 0;
+ i_product_variant = "Server"; i_product_name = product }
+ when String.find product "2019" >= 0 ->
+ Some "http://microsoft.com/win/2k19"
+
| { i_type = "windows"; i_major_version = 10; i_minor_version = 0;
i_product_variant = "Server" } ->
Some "http://microsoft.com/win/2k16"
--
2.20.1
5 years, 8 months
[PATCH v2] inspect: return osinfo short IDs for recent Windows versions
by Pino Toscano
Return the right osinfo short IDs for the majority of Windows versions
since Windows XP.
---
Changes from v1:
- used the new win2k19 osinfo ID
lib/inspect-osinfo.c | 63 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/lib/inspect-osinfo.c b/lib/inspect-osinfo.c
index 816d317f1..e0d19c672 100644
--- a/lib/inspect-osinfo.c
+++ b/lib/inspect-osinfo.c
@@ -69,6 +69,69 @@ guestfs_impl_inspect_get_osinfo (guestfs_h *g, const char *root)
if (STREQ (distro, "msdos"))
return safe_strdup (g, "msdos6.22");
}
+ else if (STREQ (type, "windows")) {
+ CLEANUP_FREE char *product_name = NULL;
+ CLEANUP_FREE char *product_variant = NULL;
+
+ product_name = guestfs_inspect_get_product_name (g, root);
+ if (!product_name)
+ return NULL;
+ product_variant = guestfs_inspect_get_product_variant (g, root);
+ if (!product_variant)
+ return NULL;
+
+ switch (major) {
+ case 5:
+ switch (minor) {
+ case 1:
+ return safe_strdup (g, "winxp");
+ case 2:
+ if (strstr (product_name, "XP"))
+ return safe_strdup (g, "winxp");
+ else if (strstr (product_name, "R2"))
+ return safe_strdup (g, "win2k3r2");
+ else
+ return safe_strdup (g, "win2k3");
+ }
+ break;
+ case 6:
+ switch (minor) {
+ case 0:
+ if (strstr (product_variant, "Server"))
+ return safe_strdup (g, "win2k8");
+ else
+ return safe_strdup (g, "winvista");
+ case 1:
+ if (strstr (product_variant, "Server"))
+ return safe_strdup (g, "win2k8r2");
+ else
+ return safe_strdup (g, "win7");
+ case 2:
+ if (strstr (product_variant, "Server"))
+ return safe_strdup (g, "win2k12");
+ else
+ return safe_strdup (g, "win8");
+ case 3:
+ if (strstr (product_variant, "Server"))
+ return safe_strdup (g, "win2k12r2");
+ else
+ return safe_strdup (g, "win8.1");
+ }
+ break;
+ case 10:
+ switch (minor) {
+ case 0:
+ if (strstr (product_variant, "Server")) {
+ if (strstr (product_name, "2019"))
+ return safe_strdup (g, "win2k19");
+ else
+ return safe_strdup (g, "win2k16");
+ } else
+ return safe_strdup (g, "win10");
+ }
+ break;
+ }
+ }
/* No ID could be guessed, return "unknown". */
return safe_strdup (g, "unknown");
--
2.20.1
5 years, 8 months
