September 2018 - Libguestfs - libguestfs List Archives

[PATCH v2] launch: add support for autodetection of appliance image format
by Pavel Butsykin 06 Feb '20

06 Feb '20

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

2 4

1.39 proposal: Let's split up the libguestfs git repo and tarballs
by Richard W.M. Jones 29 Nov '19

29 Nov '19

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 18

[hivex PATCH] Re-allocating unused blocks before assigning new blocks
by Shreyas Khare 03 Jan '19

03 Jan '19

Hello Richard As discussed in the IRC channel, when merging a moderately large reg file (~35MB) to a hiv file (~118 MB); hivex generates a huge hiv file (~580 MB). These changes address that by creating a list of unallocated blocks and reassigning unused blocks. I used https://github.com/msuhanov/regf/blob/master/Windows%20registry%20file%20fo… as a reference for the structure of the hiv file (in addition to the source code itself) Attaching the patch file. Shreyas -- NOTICE OF CONFIDENTIALITY: At Rapid7, the privacy of our customers, partners, and employees is paramount. If you received this email in error, please notify the sender and delete it from your inbox right away. Learn how Rapid7 handles privacy at rapid7.com/privacy-policy <https://www.rapid7.com/privacy-policy/>. To opt-out of Rapid7 marketing emails, please click here <https://information.rapid7.com/manage-subscription.html> or email privacy(a)rapid7.com <mailto:mailto:privacy@rapid7.com>.

2 3

[PATCH v2 0/3] v2v: -o rhv-upload: Add a test.
by Richard W.M. Jones 21 Nov '18

21 Nov '18

v1 was here: https://www.redhat.com/archives/libguestfs/2018-September/msg00121.html v2: - Rewrote patch 2 from scratch so it incorporates Nir's suggestions. - Add fake module to EXTRA_DIST. - Retested. Unfortunately I am no longer able to test the ordinary conversion path because ovirtsdk4 is incompatible with Fedora 29 / Python 3.7: https://bugzilla.redhat.com/show_bug.cgi?id=1622043 so I'm unable to verify that the changes (esp patch 2) don't break this. Rich.

3 15

OpenStack output workflow
by Fabien Dupont 12 Oct '18

12 Oct '18

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#fil… [2] https://gist.github.com/fdupont-redhat/934b3efb6d66a991a80149235066d7d7#fil… -- *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

2 10

[PATCH] v2v: ovf: add firmware and machine type element
by Tomáš Golembiovský 10 Oct '18

10 Oct '18

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

3 5

[PATCH v2] lib: Use qemu-img info -U option to avoid locking error.
by Richard W.M. Jones 04 Oct '18

04 Oct '18

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

3 7

[PATCH] v2v: -it vddk: Add a warning about using vddk* options (RHBZ#1527334).
by Richard W.M. Jones 04 Oct '18

04 Oct '18

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

2 1

[PATCH] v2v: Remove ‘-io vimapiver’ option (RHBZ#1527334).
by Richard W.M. Jones 04 Oct '18

04 Oct '18

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

2 1

Re: [Libguestfs] Up Guest network
by Richard W.M. Jones 30 Sep '18

30 Sep '18

[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/

1 0