[INCOMPLETE PATCH nbdkit] ssh: Allow the remote file to be created
by Richard W.M. Jones
This patch is incomplete (missing tests) so for discussion only, but
it implements nbdkit-ssh-plugin create=true option which creates the
remote file.
Example:
$ nbdkit ssh host=foo /var/tmp/newdisk create=true create-size=100M
$ nbdsh -u nbd://localhost
The disk is only created on first connection (which works the same way
as nbdkit-vddk-plugin). So if you just want to create the remote disk
and not do anything else, you should do something like this:
nbdkit -U - ssh host=foo /var/tmp/newdisk create=true create-size=100M \
--run 'nbdinfo --can connect $uri'
If the remote disk already exists, it is truncated but not recreated
(in this case you'll notice the remote ctime is not touched).
For some reason I don't understand, create-mode=0777 is ineffective.
sftp-server has a -u option to set the umask, or else it uses the
remote user's umask. I verified that openssh does *not* use the -u
option and that the umask of sftp-server is 0002, yet the permissions
on the file are still 0700.
Rich.
2 years, 7 months
[virt-v2v RFC] output_qemu: rewrite output disk mapping
by Laszlo Ersek
The current code handles some nonexistent cases (such as SCSI floppies,
virtio-block CD-ROMs), and does not create proper drives (that is,
back-ends with no media inserted) for removable devices (floppies,
CD-ROMs).
Rewrite the whole logic:
- handle only those scenarios that QEMU can support,
- separate the back-end (-drive) and front-end (-device) options,
- wherever / whenever a host-bus adapter front-end is needed
(virtio-scsi-pci, isa-fdc), create it,
- assign front-ends to buses (= parent front-ends) and back-ends
explicitly.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2074805
Signed-off-by: Laszlo Ersek <lersek(a)redhat.com>
---
output/output_qemu.ml | 197 ++++++++++++++++----
1 file changed, 160 insertions(+), 37 deletions(-)
diff --git a/output/output_qemu.ml b/output/output_qemu.ml
index da7278b88b67..a25b49d86679 100644
--- a/output/output_qemu.ml
+++ b/output/output_qemu.ml
@@ -127,7 +127,7 @@ module QEMU = struct
machine, false in
let smm = secure_boot_required in
- let machine =
+ let machine_str =
match machine with
| I440FX -> "pc"
| Q35 -> "q35"
@@ -153,7 +153,7 @@ module QEMU = struct
arg_list "-device" ["vmgenid"; sprintf "guid=%s" genid; "id=vmgenid0"]
);
- arg_list "-machine" (machine ::
+ arg_list "-machine" (machine_str ::
(if smm then ["smm=on"] else []) @
["accel=kvm:tcg"]);
@@ -184,52 +184,175 @@ module QEMU = struct
);
);
- let make_disk if_name i = function
- | BusSlotEmpty -> ()
+ (* For IDE disks, IDE CD-ROMs, SCSI disks, SCSI CD-ROMs, and floppies, we
+ * need host-bus adapters (HBAs) between these devices and the PCI(e) root
+ * bus. Some machine types create these HBAs automatically (despite
+ * "-no-user-config -nodefaults"), some don't...
+ *)
+ let parent_ctrl_needed target_bus dev_filter =
+ try ignore (List.find dev_filter (Array.to_list target_bus)); true
+ with Not_found -> false
+ and disk_cdrom_filter =
+ function
+ | BusSlotDisk _
+ | BusSlotRemovable { s_removable_type = CDROM } -> true
+ | _ -> false
+ and floppy_filter =
+ function
+ | BusSlotRemovable { s_removable_type = Floppy } -> true
+ | _ -> false in
+ let ide_ctrl_needed =
+ parent_ctrl_needed target_buses.target_ide_bus disk_cdrom_filter
+ and scsi_ctrl_needed =
+ parent_ctrl_needed target_buses.target_scsi_bus disk_cdrom_filter
+ and floppy_ctrl_needed =
+ parent_ctrl_needed target_buses.target_floppy_bus floppy_filter in
- | BusSlotDisk d ->
- (* Find the corresponding target disk. *)
- let outdisk = disk_path output_storage output_name d.s_disk_id in
+ if ide_ctrl_needed then (
+ match machine with
+ | I440FX -> ()
+ (* The PC machine has a built-in controller of type "piix3-ide"
+ * providing buses "ide.0" and "ide.1", with each bus fitting two
+ * devices.
+ *)
+ | Q35 -> ()
+ (* The Q35 machine has a built-in controller of type "ich9-ahci"
+ * providing buses "ide.0" through "ide.5", with each bus fitting one
+ * device.
+ *)
+ | Virt -> warning (f_"The Virt machine has no support for IDE. Please \
+ report a bug for virt-v2v.")
+ );
- arg_list "-drive" ["file=" ^ outdisk; "format=" ^ output_format;
- "if=" ^ if_name; "index=" ^ string_of_int i;
- "media=disk"]
+ if scsi_ctrl_needed then
+ (* We need to add the virtio-scsi HBA on all three machine types. The bus
+ * provided by this device will be called "scsi0.0".
+ *)
+ arg_list "-device" [ "virtio-scsi-pci"; "id=scsi0" ];
- | BusSlotRemovable { s_removable_type = CDROM } ->
- arg_list "-drive" ["format=raw"; "if=" ^ if_name;
- "index=" ^ string_of_int i; "media=cdrom"]
+ if floppy_ctrl_needed then (
+ match machine with
+ | I440FX -> ()
+ (* The PC machine has a built-in controller of type "isa-fdc"
+ * providing bus "floppy-bus.0", fitting two devices.
+ *)
+ | Q35 -> arg_list "-device" [ "isa-fdc"; "id=floppy-bus" ]
+ (* On the Q35 machine, we need to add the same HBA manually. Note that
+ * the bus name will have ".0" appended automatically.
+ *)
+ | Virt -> warning (f_"The Virt machine has no support for floppies. \
+ Please report a bug for virt-v2v.")
+ );
- | BusSlotRemovable { s_removable_type = Floppy } ->
- arg_list "-drive" ["format=raw"; "if=" ^ if_name;
- "index=" ^ string_of_int i; "media=floppy"]
- in
- Array.iteri (make_disk "virtio") target_buses.target_virtio_blk_bus;
- Array.iteri (make_disk "ide") target_buses.target_ide_bus;
+ let add_disk_backend disk_id backend_name =
+ (* Add a drive (back-end) for a "virtio-blk-pci", "ide-hd", or "scsi-hd"
+ * device (front-end). The drive has a backing file, identified by
+ * "disk_id".
+ *)
+ let outdisk = disk_path output_storage output_name disk_id in
+ arg_list "-drive" [ "file=" ^ outdisk; "format=" ^ output_format;
+ "if=none"; "id=" ^ backend_name; "media=disk" ]
- let make_scsi i = function
- | BusSlotEmpty -> ()
+ and add_cdrom_backend backend_name =
+ (* Add a drive (back-end) for an "ide-cd" or "scsi-cd" device (front-end).
+ * The drive is empty -- there is no backing file.
+ *)
+ arg_list "-drive" [ "if=none"; "id=" ^ backend_name; "media=cdrom" ]
- | BusSlotDisk d ->
- (* Find the corresponding target disk. *)
- let outdisk = disk_path output_storage output_name d.s_disk_id in
+ and add_floppy_backend backend_name =
+ (* Add a drive (back-end) for a "floppy" device (front-end). The drive is
+ * empty -- there is no backing file. *)
+ arg_list "-drive" [ "if=none"; "id=" ^ backend_name; "media=disk" ] in
- arg_list "-drive" ["file=" ^ outdisk; "format=" ^ output_format;
- "if=scsi"; "bus=0"; "unit=" ^ string_of_int i;
- "media=disk"]
+ let add_virtio_blk disk_id frontend_ctr =
+ (* Create a "virtio-blk-pci" device (front-end), together with its drive
+ * (back-end). The disk identifier is mandatory.
+ *)
+ let backend_name = sprintf "drive-vblk-%d" frontend_ctr in
+ add_disk_backend disk_id backend_name;
+ arg_list "-device" [ "virtio-blk-pci"; "drive=" ^ backend_name ]
- | BusSlotRemovable { s_removable_type = CDROM } ->
- arg_list "-drive" ["format=raw"; "if=scsi"; "bus=0";
- "unit=" ^ string_of_int i; "media=cdrom"]
+ and add_ide disk_id frontend_ctr =
+ (* Create an "ide-hd" or "ide-cd" device (front-end), together with its
+ * drive (back-end). If a disk identifier is passed in, then "ide-hd" is
+ * created (with a non-empty drive); otherwise, "ide-cd" is created (with
+ * an empty drive).
+ *)
+ let backend_name = sprintf "drive-ide-%d" frontend_ctr
+ and ide_bus, ide_unit =
+ match machine with
+ | I440FX -> frontend_ctr / 2, frontend_ctr mod 2
+ | Q35 -> frontend_ctr, 0
+ | Virt -> 0, 0 (* should never happen, see warning above *) in
+ let common_props = [ sprintf "bus=ide.%d" ide_bus;
+ sprintf "unit=%d" ide_unit;
+ "drive=" ^ backend_name ] in
+ (match disk_id with
+ | Some id ->
+ add_disk_backend id backend_name;
+ arg_list "-device" ([ "ide-hd" ] @ common_props)
+ | None ->
+ add_cdrom_backend backend_name;
+ arg_list "-device" ([ "ide-cd" ] @ common_props))
+
+ and add_scsi disk_id frontend_ctr =
+ (* Create a "scsi-hd" or "scsi-cd" device (front-end), together with its
+ * drive (back-end). If a disk identifier is passed in, then "scsi-hd" is
+ * created (with a non-empty drive); otherwise, "scsi-cd" is created (with
+ * an empty drive).
+ *)
+ let backend_name = sprintf "drive-scsi-%d" frontend_ctr in
+ let common_props = [ sprintf "lun=%d" frontend_ctr;
+ "drive=" ^ backend_name ] in
+ (match disk_id with
+ | Some id ->
+ add_disk_backend id backend_name;
+ arg_list "-device" ([ "scsi-hd" ] @ common_props)
+ | None ->
+ add_cdrom_backend backend_name;
+ arg_list "-device" ([ "scsi-cd" ] @ common_props))
- | BusSlotRemovable { s_removable_type = Floppy } ->
- arg_list "-drive" ["format=raw"; "if=scsi"; "bus=0";
- "unit=" ^ string_of_int i; "media=floppy"]
- in
- Array.iteri make_scsi target_buses.target_scsi_bus;
+ and add_floppy frontend_ctr =
+ (* Create a "floppy" (front-end), together with its empty drive
+ * (back-end).
+ *)
+ let backend_name = sprintf "drive-floppy-%d" frontend_ctr in
+ add_floppy_backend backend_name;
+ arg_list "-device" [ "floppy"; "bus=floppy-bus.0";
+ sprintf "unit=%d" frontend_ctr;
+ "drive=" ^ backend_name ] in
- (* XXX Highly unlikely that anyone cares, but the current
- * code ignores target_buses.target_floppy_bus.
+ (* Add virtio-blk-pci devices for BusSlotDisk elements on
+ * "target_virtio_blk_bus".
*)
+ Array.iteri
+ (fun frontend_ctr disk ->
+ match disk with
+ | BusSlotDisk d -> add_virtio_blk d.s_disk_id frontend_ctr
+ | _ -> ())
+ target_buses.target_virtio_blk_bus;
+
+ let add_disk_or_cdrom bus_adder frontend_ctr slot =
+ (* Add a disk or CD-ROM front-end to the IDE or SCSI bus. *)
+ match slot with
+ | BusSlotDisk d ->
+ bus_adder (Some d.s_disk_id) frontend_ctr
+ | BusSlotRemovable { s_removable_type = CDROM } ->
+ bus_adder None frontend_ctr
+ | _ -> () in
+
+ (* Add disks and CD-ROMs to the IDE and SCSI buses. *)
+ Array.iteri (add_disk_or_cdrom add_ide) target_buses.target_ide_bus;
+ Array.iteri (add_disk_or_cdrom add_scsi) target_buses.target_scsi_bus;
+
+ (* Add floppies. *)
+ Array.iteri
+ (fun frontend_ctr disk ->
+ match disk with
+ | BusSlotRemovable { s_removable_type = Floppy } ->
+ add_floppy frontend_ctr
+ | _ -> ())
+ target_buses.target_floppy_bus;
let net_bus =
match guestcaps.gcaps_net_bus with
base-commit: e3226dd431e7476cae2d0ca54b2332344de2d201
--
2.19.1.3.g30247aa5d201
2 years, 7 months
Feature gaps in nbdkit vs qemu curl & ssh block driver
by Richard W.M. Jones
Hi Eric,
I was talking to Jonathon just now about feature gaps in nbdkit vs
qemu's curl and ssh drivers. Two that he has identified are below.
Mainly writing this email to document them, but your thoughts welcome.
(1) qemu curl has a "readahead" setting
Looking at the code, it seems this causes the read to be extended by a
fixed size (if I understand it all correctly, which may not be true!).
eg. If readahead = 64K, then every read will read the requested amount + 64K.
That seems a bit odd though. What happens if two adjacent requests
come in? Is the readahead coalesced with the second request?
Anyway, nbdkit-readahead-filter exists, but it has a lot of problems.
We actually _stopped_ using it with virt-v2v because it caused more
trouble than it is worth. In particular:
- Because it increases request sizes greatly, this ends up breaking
some plugins (notably VDDK which as you know has trouble handling
large requests). We could fix this by inserting a filter to break
up large requests, but that's just trouble mainly because of the
next point.
- It's completely synchronous, so it slows the read request because
you have to wait for the over-read.
- It tries to be "adaptive" but in practice isn't very. So it
guesses wrong most of the time about what you'd want to read next.
For these reasons I believe this filter needs a complete, from-scratch
rewrite.
(2) qemu ssh can create a remote disk
This is a simple feature request. I added something similar recently
for nbdkit-vddk-plugin:
https://gitlab.com/nbdkit/nbdkit/-/commit/a39d5773afc3ebab7e5768118a2bccb...
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
2 years, 7 months
[PATCH] -o rhv-upload: wait for VM creation task
by Tomáš Golembiovský
oVirt API call for VM creation finishes before the VM is actually
created. Entities may be still locked after virt-v2v terminates and if
user tries to perform (scripted) actions after virt-v2v those operations
may fail. To prevent this it is useful to monitor the task and wait for
the completion. This will also help to prevent some corner case
scenarios (that would be difficult to debug) when the VM creation job
fails after virt-v2v already termintates with success.
Thanks: Nir Soffer
Signed-off-by: Tomáš Golembiovský <tgolembi(a)redhat.com>
Reviewed-by: Arik Hadas <ahadas(a)redhat.com>
---
output/rhv-upload-createvm.py | 57 ++++++++++++++++++++++++++++++++++-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/output/rhv-upload-createvm.py b/output/rhv-upload-createvm.py
index 50bb7e34..c6a6fbd6 100644
--- a/output/rhv-upload-createvm.py
+++ b/output/rhv-upload-createvm.py
@@ -19,12 +19,54 @@
import json
import logging
import sys
+import time
+import uuid
from urllib.parse import urlparse
import ovirtsdk4 as sdk
import ovirtsdk4.types as types
+
+def debug(s):
+ if params['verbose']:
+ print(s, file=sys.stderr)
+ sys.stderr.flush()
+
+
+def jobs_completed(system_service, correlation_id):
+ jobs_service = system_service.jobs_service()
+
+ try:
+ jobs = jobs_service.list(
+ search="correlation_id=%s" % correlation_id)
+ except sdk.Error as e:
+ debug(
+ "Error searching for jobs with correlation id %s: %s" %
+ (correlation_id, e))
+ # We dont know, assume that jobs did not complete yet.
+ return False
+
+ # STARTED is the only "in progress" status, other mean the job has
+ # already terminated
+ if all(job.status != types.JobStatus.STARTED for job in jobs):
+ failed_jobs = [(job.description, str(job.status))
+ for job in jobs
+ if job.status != types.JobStatus.FINISHED]
+ if failed_jobs:
+ raise RuntimeError(
+ "Failed to create a VM! Failed jobs: %r" % failed_jobs)
+ return True
+ else:
+ jobs_status = [(job.description, str(job.status)) for job in jobs]
+ debug("Some jobs with correlation id %s are running: %s" %
+ (correlation_id, jobs_status))
+ return False
+
+
+# Seconds to wait for the VM import job to complete in oVirt.
+timeout = 5 * 60
+
# Parameters are passed in via a JSON doc from the OCaml code.
# Because this Python code ships embedded inside virt-v2v there
# is no formal API here.
@@ -67,6 +109,7 @@ system_service = connection.system_service()
cluster = system_service.clusters_service().cluster_service(params['rhv_cluster_uuid'])
cluster = cluster.get()
+correlation_id = str(uuid.uuid4())
vms_service = system_service.vms_service()
vm = vms_service.add(
types.Vm(
@@ -77,5 +120,17 @@ vm = vms_service.add(
data=ovf,
)
)
- )
+ ),
+ query={'correlation_id': correlation_id},
)
+
+# Wait for the import job to finish
+endt = time.time() + timeout
+while True:
+ time.sleep(1)
+ if jobs_completed(system_service, correlation_id):
+ break
+ if time.time() > endt:
+ raise RuntimeError(
+ "Timed out waiting for VM creation!"
+ " Jobs still running for correlation id %s" % correlation_id)
--
2.35.1
2 years, 7 months
[v2v PATCH] output_openstack: work around non-blocking bug in openstack CLI
by Laszlo Ersek
The openstack output module currently passes the "--non-bootable" and
"--read-write" options to the "openstack volume create" command. There is
a bug in the "openstack" utility however (that is, in the
python-openstackclient project @ dabaec5a7b1b) where it assumes that the
image creation API blocks, and as soon as it completes, the readonly and
bootable flags can be tweaked with the APIs that exist for those purposes.
The image creation API does not block however, and when the "openstack"
command line utility tries to set the readonly & bootable flags, those
APIs fail because image creation is still in progress. This results in an
obscure error message on the virt-v2v standard error:
> [ 322.8] Initializing the target -o openstack
> openstack [...] volume create -f json --size 20 --description virt-v2v
> temporary volume for esx6.7-win2016-x86_64 --non-bootable --read-write
> esx6.7-win2016-x86_64-sda
> Failed to set volume read-only access mode flag: Invalid volume: Volume
> 009dc6bd-2f80-4ac3-b5e7-771863aca237 status must be available to update
> readonly flag, but current status is: creating. (HTTP 400) (Request-ID:
> req-6f56ce4c-249b-4112-9c52-dd91b7f5aae9)
Given that "--non-bootable" and "--read-write" are both defaults for VM
image creation, according to
<https://docs.openstack.org/python-openstackclient/yoga/cli/command-object...>,
work the symptom around by simply not passing these options.
(Tested only with "make check"; I don't have an Openstack setup.)
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2074801
Signed-off-by: Laszlo Ersek <lersek(a)redhat.com>
---
output/output_openstack.ml | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/output/output_openstack.ml b/output/output_openstack.ml
index d0af2ac79e7e..aa01d5a67c50 100644
--- a/output/output_openstack.ml
+++ b/output/output_openstack.ml
@@ -277,9 +277,7 @@ The os-* parameters and environment variables are optional.
List.push_back_list args [ "volume"; "create";
"-f"; "json";
"--size"; size_gb;
- "--description"; description;
- "--non-bootable";
- "--read-write" ];
+ "--description"; description ];
Option.may (
fun os -> List.push_back_list args [ "--type"; os ]
) output_storage;
--
2.19.1.3.g30247aa5d201
2 years, 7 months
[PATCH virt-v2v 0/2] -o qemu: Fix various things
by Richard W.M. Jones
I guess this output mode is not used very much because it's quite
broken at the moment. In particular it used the qemu -balloon option,
removed in 2018. Also my recent fix to vsock support was broken.
I've tested it a bit more now and it's now possible to run the shell
script to boot a converted Linux guest.
Rich.
2 years, 7 months
xfs protofiles for libguestfs
by Alli
Hi all,
I hope I am in the right place, I found this email by following the
link in the project README. We are collecting use cases for xfs dev
projects, one of which would be enhancing xfs protofiles, which is a
type of script that facilitates filesystem generation. I am not very
familiar with libguestfs, but a coworker suggested that this might be
of interest to your project. More specifically, the task would be to
add attributes to the files generated by the protofile script. Does
this sound like something that might be of use to libguestfs? I did
take a quick glance through the libguestfs code, and didnt notice any
current usage of xfs protofiles, but I thought it was worth asking if protofiles might become of interest if we did add this feature. Thanks!
Allison
2 years, 7 months
[libguestfs-common PATCH] options: attempt naming all decrypted LUKS devices by UUID
by Laszlo Ersek
In commit 2d8c0f8d40b5 ("options: decrypt LUKS-on-LV devices",
2022-02-28), in order to keep that change as contained as possible, we
didn't modify the naming scheme of those decrypted LUKS devices that
originated directly from partitions -- we passed "name_decrypted_by_uuid =
false" for partitions fetched with guestfs_list_partitions().
Turns out that this is exactly what prevents us from decrypting the
following block device structure (seen in RHEL6 guests; for example one
installed from "RHEL-6.10-20180525.0-Server-x86_64-dvd1.iso"):
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> vda 252:0 0 9G 0 disk
> ├─vda1 252:1 0 1G 0 part /boot
> ├─vda2 252:2 0 7G 0 part
> │ └─luks-37f5c9df-acda-4955-8cfd-872f0da5e35b (dm-0) 253:0 0 7G 0 crypt /
> └─vda3 252:3 0 1023M 0 part [SWAP]
> sr0 11:0 1 1024M 0 rom
The problem is that we prefer (a) make_mapname() due to the LUKS header
residing directly on a partition, so we call the plaintext device
"/dev/mapper/cryptsda2"; however (b) "/etc/fstab" in the guest refers to
the same plaintext device by the standard, UUID-based
"/dev/mapper/luks-37f5c9df-acda-4955-8cfd-872f0da5e35b" pathname.
Therefore "inspect_get_mountpoints" in "libguestfs/daemon/inspect.ml"
returns the latter pathname -- which we can't mount.
Hardwire "name_decrypted_by_uuid = true" in "options/decrypt.c" -- by
which effort we can as well remove the "name_decrypted_by_uuid" parameter.
Testing: the libguestfs, guestfs-tools, and virt-v2v test suites (make
check) pass with this update. Furthermore, "guestfish -i", virt-inspector,
and virt-v2v now recognize the above blockdev / fs structure (and the
converted guest boots).
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1658128
Signed-off-by: Laszlo Ersek <lersek(a)redhat.com>
---
options/decrypt.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/options/decrypt.c b/options/decrypt.c
index b899a0028620..1cd7b627e264 100644
--- a/options/decrypt.c
+++ b/options/decrypt.c
@@ -111,15 +111,15 @@ make_mapname (const char *device)
}
return mapname;
}
static bool
decrypt_mountables (guestfs_h *g, const char * const *mountables,
- struct key_store *ks, bool name_decrypted_by_uuid)
+ struct key_store *ks)
{
bool decrypted_some = false;
const char * const *mnt_scan = mountables;
const char *mountable;
while ((mountable = *mnt_scan++) != NULL) {
CLEANUP_FREE char *type = NULL;
@@ -144,16 +144,15 @@ decrypt_mountables (guestfs_h *g, const char * const *mountables,
/* Grab the keys that we should try with this device, based on device name,
* or UUID (if any).
*/
keys = get_keys (ks, mountable, uuid);
assert (keys[0] != NULL);
/* Generate a node name for the plaintext (decrypted) device node. */
- if (!name_decrypted_by_uuid || uuid == NULL ||
- asprintf (&mapname, "luks-%s", uuid) == -1)
+ if (uuid == NULL || asprintf (&mapname, "luks-%s", uuid) == -1)
mapname = make_mapname (mountable);
/* Try each key in turn. */
key_scan = (const char * const *)keys;
while ((key = *key_scan++) != NULL) {
int r;
@@ -188,20 +187,19 @@ inspect_do_decrypt (guestfs_h *g, struct key_store *ks)
CLEANUP_FREE_STRING_LIST char **partitions = guestfs_list_partitions (g);
CLEANUP_FREE_STRING_LIST char **lvs = NULL;
bool need_rescan;
if (partitions == NULL)
exit (EXIT_FAILURE);
- need_rescan = decrypt_mountables (g, (const char * const *)partitions, ks,
- false);
+ need_rescan = decrypt_mountables (g, (const char * const *)partitions, ks);
if (need_rescan) {
if (guestfs_lvm_scan (g, 1) == -1)
exit (EXIT_FAILURE);
}
lvs = guestfs_lvs (g);
if (lvs == NULL)
exit (EXIT_FAILURE);
- decrypt_mountables (g, (const char * const *)lvs, ks, true);
+ decrypt_mountables (g, (const char * const *)lvs, ks);
}
base-commit: ab708d11d832457d2a0c74e7a6d8c219a4fdd90f
--
2.19.1.3.g30247aa5d201
2 years, 7 months
[PATCH v2v 0/2] output: Remove -o json mode [in stages]
by Richard W.M. Jones
I'd like to remove the unused -o json mode. The implementation is
over-complicated and the only potential user (KubeVirt) isn't using it
now and would be better off with a proper -o kubevirt mode, which I'm
going to implement later.
My plan would be to add the patches in two stages. The first patch,
which only removes the documentation but leaves the feature and test,
would be applied to stable branch virt-v2v 2.0. The second patch
would be go on the development branch 2.1 (which hasn't yet been
created). The first stable release without this feature would be 2.2.
For RHEL I'd probably put both patches in 9.1, even though we're
planning to ship virt-v2v 2.0.x there. It means there will be an
option/feature present in RHEL 9.0 which is removed in 9.1.
Rich.
2 years, 7 months
