[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, 10 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
5 years
OpenStack output workflow
by Fabien Dupont
Hi,
There has been discussion about the OpenStack output and Richard asked for
a public thread on this list, so here it is.
For v2v from VMware to RHV, there is a Python script that does some extra
steps to create the virtual machine after the disks have been converted. We
want to have the same behavior for OpenStack, i.e. have virt-v2v create the
instance once the volumes have been created.
For that, I've written a Python script [1] that takes a JSON file (sample
here [2]) as input. I expect this JSON input to be generated by virt-v2v
openstack output module, from the command line options and the volumes ids
generated during conversion.
Here are the options I think we should have for the OpenStack output:
-o openstack
-oo os-auth-url='http://controller.example.com:5000/v3'
-oo os-user-domain-name='Default'
-oo os-project-name='v2v-project'
-oo os-username='admin'
-oo os-password='secret'
-oo server-id='01234567-89ab-cdef-0123-456789abcdef'
-oo destination_project_id='01234567-89ab-cdef-0123-456789abcdef'
-oo volume_type_id='01234567-89ab-cdef-0123-456789abcdef'
-oo flavor_id='01234567-89ab-cdef-0123-456789abcdef'
-oo
security_groups_ids='01234567-89ab-cdef-0123-456789abcdef,01234567-89ab-cdef-0123-456789abcdef'
--mac 01:23:45:67:89:ab:network:01234567-89ab-cdef-0123-456789abcdef
You'll see that the --mac option is not specific to OpenStack, but it shows
how it would look like with a network id. And it should be passed to the
post-conversion script.
The translation to JSON is pretty straight forward and should not be
difficult. We simply have to agree on the JSON keys we expect and the where
the new -oo keys go. Also, the script is quite simple and relies on
OpenStack Python SDK, which is also used by the OpenStack CLI, so no
additional dependencies are required and it should be easy to maintain.
[1]
https://gist.github.com/fdupont-redhat/934b3efb6d66a991a80149235066d7d7#f...
[2]
https://gist.github.com/fdupont-redhat/934b3efb6d66a991a80149235066d7d7#f...
--
*Fabien Dupont*
PRINCIPAL SOFTWARE ENGINEER
Red Hat - Solutions Engineering
fabien(a)redhat.com M: +33 (0) 662 784 971 <+33662784971>
<http://redhat.com> *TRIED. TESTED. TRUSTED.*
Twitter: @redhatway <https://twitter.com/redhatway> | Instagram: @redhatinc
<https://www.instagram.com/redhatinc/> | Snapchat: @redhatsnaps
6 years, 2 months
[PATCH] v2v: ovf: add firmware and machine type element
by Tomáš Golembiovský
Add oVirt specific elemnt to OVF. It represents the combination of
machine type (i440fx/q35) and firmware (BIOS/UEFI).
Signed-off-by: Tomáš Golembiovský <tgolembi(a)redhat.com>
---
v2v/create_ovf.ml | 20 +++++++++++++++++++-
v2v/create_ovf.mli | 2 +-
v2v/output_rhv.ml | 6 ++----
v2v/output_rhv_upload.ml | 4 ++--
v2v/output_vdsm.ml | 6 ++----
v2v/test-v2v-o-rhv.ovf.expected | 1 +
v2v/test-v2v-o-vdsm-options.ovf.expected | 1 +
7 files changed, 28 insertions(+), 12 deletions(-)
diff --git a/v2v/create_ovf.ml b/v2v/create_ovf.ml
index 2cf610333..1cab11dfd 100644
--- a/v2v/create_ovf.ml
+++ b/v2v/create_ovf.ml
@@ -462,6 +462,22 @@ let origin_of_source_hypervisor = function
*)
| _ -> None
+let get_ovirt_biostype guestcaps target_firmware =
+ let uefi_firmware =
+ match target_firmware with
+ | TargetBIOS -> None
+ | TargetUEFI -> Some (find_uefi_firmware guestcaps.gcaps_arch) in
+ let secure_boot_required =
+ match uefi_firmware with
+ | Some { Uefi.flags = flags }
+ when List.mem Uefi.UEFI_FLAG_SECURE_BOOT_REQUIRED flags -> true
+ | _ -> false in
+ match target_firmware, secure_boot_required with
+ | TargetUEFI, true -> 3 (* q35 + UEFI + secure boot *)
+ | TargetUEFI, _ -> 2 (* q35 + UEFI *)
+ (* 1 is q35 + SeaBIOS *)
+ | _, _ -> 0 (* i440fx + SeaBIOS *)
+
(* Generate the .meta file associated with each volume. *)
let create_meta_files output_alloc sd_uuid image_uuids targets =
(* Note: Upper case in the .meta, mixed case in the OVF. *)
@@ -506,7 +522,7 @@ let create_meta_files output_alloc sd_uuid image_uuids targets =
) (List.combine targets image_uuids)
(* Create the OVF file. *)
-let rec create_ovf source targets guestcaps inspect
+let rec create_ovf source targets guestcaps inspect target_firmware
output_alloc sd_uuid image_uuids vol_uuids vm_uuid ovf_flavour =
assert (List.length targets = List.length vol_uuids);
@@ -515,6 +531,7 @@ let rec create_ovf source targets guestcaps inspect
let vmtype = get_vmtype inspect in
let vmtype = match vmtype with `Desktop -> "0" | `Server -> "1" in
let ostype = get_ostype inspect in
+ let biostype = get_ovirt_biostype guestcaps target_firmware in
let ovf : doc =
doc "ovf:Envelope" [
@@ -562,6 +579,7 @@ let rec create_ovf source targets guestcaps inspect
e "VmType" [] [PCData vmtype];
(* See https://bugzilla.redhat.com/show_bug.cgi?id=1260590#c17 *)
e "DefaultDisplayType" [] [PCData "1"];
+ e "BiosType" [] [PCData (string_of_int biostype)];
] in
(match source.s_cpu_model with
diff --git a/v2v/create_ovf.mli b/v2v/create_ovf.mli
index 8200b76f9..cb6c12690 100644
--- a/v2v/create_ovf.mli
+++ b/v2v/create_ovf.mli
@@ -43,7 +43,7 @@ val ovf_flavour_to_string : ovf_flavour -> string
create OVF for another target management system then we would need
to heavily modify or even duplicate this code. *)
-val create_ovf : Types.source -> Types.target list -> Types.guestcaps -> Types.inspect -> Types.output_allocation -> string -> string list -> string list -> string -> ovf_flavour -> DOM.doc
+val create_ovf : Types.source -> Types.target list -> Types.guestcaps -> Types.inspect -> Types.target_firmware -> Types.output_allocation -> string -> string list -> string list -> string -> ovf_flavour -> DOM.doc
(** Create the OVF file.
Actually a {!DOM} document is created, not a file. It can be written
diff --git a/v2v/output_rhv.ml b/v2v/output_rhv.ml
index 5260ab030..ce57f0309 100644
--- a/v2v/output_rhv.ml
+++ b/v2v/output_rhv.ml
@@ -115,7 +115,7 @@ object
method as_options = sprintf "-o rhv -os %s" os
- method supported_firmware = [ TargetBIOS ]
+ method supported_firmware = [ TargetBIOS; TargetUEFI ]
(* RHV doesn't support serial consoles. This causes the conversion
* step to remove it.
@@ -270,12 +270,10 @@ object
(* This is called after conversion to write the OVF metadata. *)
method create_metadata source targets _ guestcaps inspect target_firmware =
- (* See #supported_firmware above. *)
- assert (target_firmware = TargetBIOS);
(* Create the metadata. *)
let ovf = Create_ovf.create_ovf source targets guestcaps inspect
- output_alloc esd_uuid image_uuids vol_uuids vm_uuid
+ target_firmware output_alloc esd_uuid image_uuids vol_uuids vm_uuid
Create_ovf.RHVExportStorageDomain in
(* Write it to the metadata file. *)
diff --git a/v2v/output_rhv_upload.ml b/v2v/output_rhv_upload.ml
index 63fa2411a..3dcd6d952 100644
--- a/v2v/output_rhv_upload.ml
+++ b/v2v/output_rhv_upload.ml
@@ -253,7 +253,7 @@ object
sprintf " -oc %s -op %s -os %s"
output_conn output_password output_storage
- method supported_firmware = [ TargetBIOS ]
+ method supported_firmware = [ TargetBIOS; TargetUEFI ]
(* rhev-apt.exe will be installed (if available). *)
method install_rhev_apt = true
@@ -407,7 +407,7 @@ If the messages above are not sufficient to diagnose the problem then add the
(* Create the metadata. *)
let ovf =
Create_ovf.create_ovf source targets guestcaps inspect
- output_alloc
+ target_firmware output_alloc
sd_uuid image_uuids vol_uuids vm_uuid
OVirt in
let ovf = DOM.doc_to_string ovf in
diff --git a/v2v/output_vdsm.ml b/v2v/output_vdsm.ml
index 9a1b748bc..f32acedae 100644
--- a/v2v/output_vdsm.ml
+++ b/v2v/output_vdsm.ml
@@ -123,7 +123,7 @@ object
| flav -> sprintf "-oo vdsm-ovf-flavour=%s"
(Create_ovf.ovf_flavour_to_string flav))
- method supported_firmware = [ TargetBIOS ]
+ method supported_firmware = [ TargetBIOS; TargetUEFI ]
(* RHV doesn't support serial consoles. This causes the conversion
* step to remove it.
@@ -240,11 +240,9 @@ object
(* This is called after conversion to write the OVF metadata. *)
method create_metadata source targets _ guestcaps inspect target_firmware =
- (* See #supported_firmware above. *)
- assert (target_firmware = TargetBIOS);
-
(* Create the metadata. *)
let ovf = Create_ovf.create_ovf source targets guestcaps inspect
+ target_firmware
output_alloc dd_uuid
vdsm_options.image_uuids
vdsm_options.vol_uuids
diff --git a/v2v/test-v2v-o-rhv.ovf.expected b/v2v/test-v2v-o-rhv.ovf.expected
index 7bcc456c5..c6bd05c56 100644
--- a/v2v/test-v2v-o-rhv.ovf.expected
+++ b/v2v/test-v2v-o-rhv.ovf.expected
@@ -25,6 +25,7 @@
<IsStateless>False</IsStateless>
<VmType>0</VmType>
<DefaultDisplayType>1</DefaultDisplayType>
+ <BiosType>0</BiosType>
<Section ovf:id='#VM_ID#' ovf:required='false' xsi:type='ovf:OperatingSystemSection_Type'>
<Info>Microsoft Windows 7 Phony Edition</Info>
<Description>Windows7</Description>
diff --git a/v2v/test-v2v-o-vdsm-options.ovf.expected b/v2v/test-v2v-o-vdsm-options.ovf.expected
index abaf37e54..f0d418b46 100644
--- a/v2v/test-v2v-o-vdsm-options.ovf.expected
+++ b/v2v/test-v2v-o-vdsm-options.ovf.expected
@@ -25,6 +25,7 @@
<IsStateless>False</IsStateless>
<VmType>0</VmType>
<DefaultDisplayType>1</DefaultDisplayType>
+ <BiosType>0</BiosType>
<OperatingSystemSection ovf:id='VM' ovf:required='false' ovirt:id='11'>
<Info>Microsoft Windows 7 Phony Edition</Info>
<Description>Windows7</Description>
--
2.18.0
6 years, 2 months
[PATCH v2] lib: Use qemu-img info -U option to avoid locking error.
by Richard W.M. Jones
https://bugs.launchpad.net/qemu/+bug/1740364
---
lib/guestfs-internal.h | 3 +++
lib/handle.c | 2 ++
lib/info.c | 39 +++++++++++++++++++++++++++++++++++++++
3 files changed, 44 insertions(+)
diff --git a/lib/guestfs-internal.h b/lib/guestfs-internal.h
index adeb9478a..c66c55e70 100644
--- a/lib/guestfs-internal.h
+++ b/lib/guestfs-internal.h
@@ -510,6 +510,9 @@ struct guestfs_h {
/* Cached features. */
struct cached_feature *features;
size_t nr_features;
+
+ /* Used by lib/info.c. -1 = not tested or error; else 0 or 1. */
+ int qemu_img_supports_U_option;
};
/**
diff --git a/lib/handle.c b/lib/handle.c
index a47aaafab..297ff6d67 100644
--- a/lib/handle.c
+++ b/lib/handle.c
@@ -101,6 +101,8 @@ guestfs_create_flags (unsigned flags, ...)
g->memsize = DEFAULT_MEMSIZE;
+ g->qemu_img_supports_U_option = -1; /* not tested, see lib/info.c */
+
/* Start with large serial numbers so they are easy to spot
* inside the protocol.
*/
diff --git a/lib/info.c b/lib/info.c
index 2eadc1c11..74e4424b8 100644
--- a/lib/info.c
+++ b/lib/info.c
@@ -57,6 +57,7 @@ cleanup_json_t_decref (void *ptr)
#endif
static json_t *get_json_output (guestfs_h *g, const char *filename);
+static int qemu_img_supports_U_option (guestfs_h *g);
static void set_child_rlimits (struct command *);
char *
@@ -149,6 +150,11 @@ get_json_output (guestfs_h *g, const char *filename)
guestfs_int_cmd_add_arg (cmd, "qemu-img");
guestfs_int_cmd_add_arg (cmd, "info");
+ switch (qemu_img_supports_U_option (g)) {
+ case -1: return NULL;
+ case 0: break;
+ default: guestfs_int_cmd_add_arg (cmd, "-U");
+ }
guestfs_int_cmd_add_arg (cmd, "--output");
guestfs_int_cmd_add_arg (cmd, "json");
if (filename[0] == '/')
@@ -218,3 +224,36 @@ set_child_rlimits (struct command *cmd)
guestfs_int_cmd_set_child_rlimit (cmd, RLIMIT_CPU, 10 /* seconds */);
#endif
}
+
+/**
+ * Test if the qemu-img info command supports the C<-U> option to
+ * disable locking. The result is memoized in the handle.
+ *
+ * Note this option was added in qemu 2.11. We can remove this test
+ * when we can assume everyone is using qemu >= 2.11.
+ */
+static int
+qemu_img_supports_U_option (guestfs_h *g)
+{
+ if (g->qemu_img_supports_U_option >= 0)
+ return g->qemu_img_supports_U_option;
+
+ CLEANUP_CMD_CLOSE struct command *cmd = guestfs_int_new_command (g);
+ int r;
+
+ guestfs_int_cmd_add_string_unquoted (cmd,
+ "qemu-img info --help | "
+ "grep -sq -- 'info.*-U'");
+ r = guestfs_int_cmd_run (cmd);
+ if (r == -1)
+ return -1;
+ if (!WIFEXITED (r)) {
+ guestfs_int_external_command_failed (g, r,
+ "qemu-img info -U option test",
+ NULL);
+ return -1;
+ }
+
+ g->qemu_img_supports_U_option = WEXITSTATUS (r) == 0;
+ return g->qemu_img_supports_U_option;
+}
--
2.19.0.rc0
6 years, 2 months
[PATCH] v2v: -it vddk: Add a warning about using vddk* options (RHBZ#1527334).
by Richard W.M. Jones
Stress these options shouldn't be used unless you know what you're
doing.
---
v2v/virt-v2v.pod | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod
index fbc5733a6..18db7206b 100644
--- a/v2v/virt-v2v.pod
+++ b/v2v/virt-v2v.pod
@@ -439,7 +439,8 @@ See L</INPUT FROM VDDK> below for details.
When using VDDK mode, these options are passed unmodified to the
L<nbdkit(1)> VDDK plugin. Please refer to L<nbdkit-vddk-plugin(1)>.
-These are all optional.
+Do not use these options unless you know what you are doing. These
+are all optional.
=item B<-ip> filename
@@ -1894,6 +1895,7 @@ Other options that you might need to add in rare circumstances include
I<-io vddk-config>, I<-io vddk-cookie>, I<-io vddk-nfchostport>,
I<-io vddk-port>, I<-io vddk-snapshot>, and I<-io vddk-transports>,
which are all explained in the L<nbdkit-vddk-plugin(1)> documentation.
+Do not use these options unless you know what you are doing.
=head2 VDDK: DEBUGGING VDDK FAILURES
--
2.19.0.rc0
6 years, 2 months
[PATCH] v2v: Remove ‘-io vimapiver’ option (RHBZ#1527334).
by Richard W.M. Jones
This option was added in error. It never had any effect and now the
nbdkit VDDK plugin ignores it. Virt-v2v users shouldn't have been
using it.
This removes the option completely (so if anyone was using it they
will now get an error).
---
v2v/cmdline.ml | 2 --
v2v/input_libvirt_vddk.ml | 4 +---
v2v/test-v2v-docs.sh | 1 -
v2v/virt-v2v.pod | 7 ++-----
4 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/v2v/cmdline.ml b/v2v/cmdline.ml
index cd2d279e9..6ec076151 100644
--- a/v2v/cmdline.ml
+++ b/v2v/cmdline.ml
@@ -259,8 +259,6 @@ let parse_cmdline () =
s_"Same as ‘-io vddk-thumbprint=thumbprint’";
[ L"vddk-transports" ], Getopt.String ("transports", set_input_option_compat "vddk-transports"),
s_"Same as ‘-io vddk-transports=transports’";
- [ L"vddk-vimapiver" ], Getopt.String ("apiver", set_input_option_compat "vddk-vimapiver"),
- s_"Same as ‘-io vddk-vimapiver=apiver’";
[ L"vdsm-compat" ], Getopt.String ("0.10|1.1", set_output_option_compat "vdsm-compat"),
s_"Same as ‘-oo vdsm-compat=0.10|1.1’";
[ L"vdsm-image-uuid" ], Getopt.String ("uuid", set_output_option_compat "vdsm-image-uuid"),
diff --git a/v2v/input_libvirt_vddk.ml b/v2v/input_libvirt_vddk.ml
index f74ca05af..2ca0ef1e0 100644
--- a/v2v/input_libvirt_vddk.ml
+++ b/v2v/input_libvirt_vddk.ml
@@ -44,8 +44,7 @@ let vddk_option_keys =
"port";
"snapshot";
"thumbprint";
- "transports";
- "vimapiver" ]
+ "transports" ]
let print_input_options () =
printf (f_"Input options (-io) which can be used with -it vddk:
@@ -64,7 +63,6 @@ All other settings are optional:
VDDK snapshot moref
-io vddk-transports=MODE:MODE:..
VDDK transports
- -io vddk-vimapiver=APIVER VDDK vimapiver
Refer to nbdkit-vddk-plugin(1) and the VDDK documentation for further
information on these settings.
diff --git a/v2v/test-v2v-docs.sh b/v2v/test-v2v-docs.sh
index 64dfe5492..dfb12bb14 100755
--- a/v2v/test-v2v-docs.sh
+++ b/v2v/test-v2v-docs.sh
@@ -46,7 +46,6 @@ $top_srcdir/podcheck.pl virt-v2v.pod virt-v2v \
--vddk-snapshot,\
--vddk-thumbprint,\
--vddk-transports,\
---vddk-vimapiver,\
--vdsm-compat,\
--vdsm-image-uuid,\
--vdsm-ovf-flavour,\
diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod
index e028540e2..fbc5733a6 100644
--- a/v2v/virt-v2v.pod
+++ b/v2v/virt-v2v.pod
@@ -437,8 +437,6 @@ See L</INPUT FROM VDDK> below for details.
=item B<-io vddk-transports=>MODE:MODE:...
-=item B<-io vddk-vimapiver=>APIVER
-
When using VDDK mode, these options are passed unmodified to the
L<nbdkit(1)> VDDK plugin. Please refer to L<nbdkit-vddk-plugin(1)>.
These are all optional.
@@ -1894,9 +1892,8 @@ SSL thumbprint:
Other options that you might need to add in rare circumstances include
I<-io vddk-config>, I<-io vddk-cookie>, I<-io vddk-nfchostport>,
-I<-io vddk-port>, I<-io vddk-snapshot>, I<-io vddk-transports> and
-I<-io vddk-vimapiver>, which are all explained in the
-L<nbdkit-vddk-plugin(1)> documentation.
+I<-io vddk-port>, I<-io vddk-snapshot>, and I<-io vddk-transports>,
+which are all explained in the L<nbdkit-vddk-plugin(1)> documentation.
=head2 VDDK: DEBUGGING VDDK FAILURES
--
2.19.0.rc0
6 years, 2 months
Re: [Libguestfs] Up Guest network
by Richard W.M. Jones
[I don't know - there's not really enough detail here to answer the
question, but maybe someone on the mailing list can help.]
On Sun, Sep 30, 2018 at 11:50:18AM +0300, "Анатолий (ytel2006)" wrote:
> Hello!
> Tell me, please, how can I start the network on the guest machine (inside the virtual server), if necessary, to install or update the software, and this software depends on the real IP address? For example, the ISPManager panel for installation or update, checks the IP address of the server.
>
> I tried to raise the network by deleting the udev rules for the network and setting the interface settings in / etc / sysconfig / network-scripts / ifcfg-eth0, but the network does not start with an error that the eth0 device is not initialized.
>
> With the --network option, virt-sysprep and virt-builder raises the network through the hypervisor, and without it, the network does not go up at all, even if all the necessary configs are configured
>
> those. I need to raise the network interface configured inside the guest system with virt-builder --some-parametrs --update --run-command 'yum install some-pkg'
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
6 years, 2 months
