[v2v PATCH] convert/libosinfo-c.c: turn caml_copy_*() return blocks into root values
by Laszlo Ersek
caml_copy_string() and caml_copy_int64() create OCaml blocks
<https://ocaml.org/manual/intfc.html#sss:c-simple-allocation> that as such
are subject to movement or release by the garbage collector
<https://ocaml.org/manual/intfc.html#ss:c-blocks>.
In order for the GC to see that a block is in use (and should not be
collected, plus its inward references should be updated when it is moved),
the block needs to be reachable (directly or indirectly) from a "root"
value.
In each of the following patterns:
Store_field (parent_block_v, field_n, caml_copy_string (str))
Store_field (parent_block_v, field_n, caml_copy_int64 (i64))
the block produced by caml_copy_*() hangs in the air temporarily, before a
reference to it is added, originating from the parent block. If
Store_field() triggered a garbage collection just before creating the
reference, the retval block of caml_copy_*() could be moved (or even
released), and then the new reference inside the parent block would point
to garbage.
Store_field() is apparently documented to never invalidate its last
argument by calling the garbage collector, so the code we currently have
in "libosinfo-c.c" is safe.
However, the following warning
<https://ocaml.org/manual/intfc.html#ss:c-simple-gc-harmony> does apply to
Store_field():
> The first argument of Store_field and Store_double_field must be a
> variable declared by CAMLparam* or a parameter declared by CAMLlocal* to
> ensure that a garbage collection triggered by the evaluation of the
> other arguments will not invalidate the first argument after it is
> computed.
meaning that the *first* argument of Store_field() *could* be released or
moved by a garbage collection that is triggered by the evaluation of the
last argument. And, in order to protect the first arg from such a release
(or, to be notified if the first arg is moved), the first arg must be
(temporarily) registered as a "root" value (with the "rootness"
substituting for other inward edge(s) from other blocks).
Keeping in mind the first and last (block) args' *different* exposures to
garbage collection is difficult. Therefore, for every Store_field() call
where the last arg is not an unboxed integer (in practice: Val_bool()),
but a block created with caml_copy_*(), track that block (at least
temporarily -- "long enough") as a root value, via a new local CAML value
called "copyv".
For consistency, update the one
CAMLreturn (caml_copy_string (id))
call we have as well.
Suggested-by: Richard W.M. Jones <rjones(a)redhat.com>
Ref: https://listman.redhat.com/archives/libguestfs/2022-January/msg00037.html
Signed-off-by: Laszlo Ersek <lersek(a)redhat.com>
---
convert/libosinfo-c.c | 25 ++++++++++++++++---------
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/convert/libosinfo-c.c b/convert/libosinfo-c.c
index b8e78bec5c1c..ec7c06d379e3 100644
--- a/convert/libosinfo-c.c
+++ b/convert/libosinfo-c.c
@@ -183,23 +183,26 @@ value
v2v_osinfo_os_get_id (value osv)
{
CAMLparam1 (osv);
+ CAMLlocal1 (copyv);
const gchar *id;
id = osinfo_entity_get_id (OSINFO_ENTITY(OsinfoOs_t_val (osv)));
- CAMLreturn (caml_copy_string (id));
+ copyv = caml_copy_string (id);
+ CAMLreturn (copyv);
}
static value
glist_to_value_list (GList *list)
{
CAMLparam0 ();
- CAMLlocal2 (rv, v);
+ CAMLlocal3 (rv, v, copyv);
GList *l;
rv = Val_emptylist;
for (l = list; l != NULL; l = l->next) {
v = caml_alloc (2, 0);
- Store_field (v, 0, caml_copy_string (l->data));
+ copyv = caml_copy_string (l->data);
+ Store_field (v, 0, copyv);
Store_field (v, 1, rv);
rv = v;
}
@@ -211,7 +214,7 @@ value
v2v_osinfo_os_get_device_drivers (value osv)
{
CAMLparam1 (osv);
- CAMLlocal3 (rv, v, vi);
+ CAMLlocal4 (rv, v, vi, copyv);
OsinfoDeviceDriverList *list;
gint i, len;
@@ -230,9 +233,11 @@ v2v_osinfo_os_get_device_drivers (value osv)
vi = caml_alloc (6, 0);
str = osinfo_device_driver_get_architecture (driver);
- Store_field (vi, 0, caml_copy_string (str));
+ copyv = caml_copy_string (str);
+ Store_field (vi, 0, copyv);
str = osinfo_device_driver_get_location (driver);
- Store_field (vi, 1, caml_copy_string (str));
+ copyv = caml_copy_string (str);
+ Store_field (vi, 1, copyv);
b = osinfo_device_driver_get_pre_installable (driver);
Store_field (vi, 2, Val_bool (b));
b = osinfo_device_driver_get_signed (driver);
@@ -243,7 +248,8 @@ v2v_osinfo_os_get_device_drivers (value osv)
/* Same as OSINFO_DEVICE_DRIVER_DEFAULT_PRIORITY in libosinfo 1.7.0+. */
i64 = 50;
#endif
- Store_field (vi, 4, caml_copy_int64 (i64));
+ copyv = caml_copy_int64 (i64);
+ Store_field (vi, 4, copyv);
l = osinfo_device_driver_get_files (driver);
Store_field (vi, 5, glist_to_value_list (l));
g_list_free (l);
@@ -286,7 +292,7 @@ value
v2v_osinfo_os_get_all_devices (value osv)
{
CAMLparam1 (osv);
- CAMLlocal3 (retvalv, linkv, propsv);
+ CAMLlocal4 (retvalv, linkv, propsv, copyv);
g_autoptr (OsinfoDeviceList) dev_list = NULL;
OsinfoList *ent_list;
gint ent_nr;
@@ -310,7 +316,8 @@ v2v_osinfo_os_get_all_devices (value osv)
prop_val = osinfo_entity_get_param_value (ent, device_prop[prop_nr]);
if (prop_val == NULL)
prop_val = "";
- Store_field (propsv, prop_nr, caml_copy_string (prop_val));
+ copyv = caml_copy_string (prop_val);
+ Store_field (propsv, prop_nr, copyv);
}
linkv = caml_alloc (2, 0);
base-commit: f0cea012d0183edf6f7b769c28d5038593f3fe6a
--
2.19.1.3.g30247aa5d201
2 years, 10 months
[PATCH v1] docs: domain: document legacy audio for qemu
by Olaf Hering
Adding a blurb like this was forgotten in 2009.
Signed-off-by: Olaf Hering <olaf(a)aepfle.de>
---
docs/formatdomain.rst | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
index d4f30bb8af..f07ea34232 100644
--- a/docs/formatdomain.rst
+++ b/docs/formatdomain.rst
@@ -7079,6 +7079,20 @@ is permitted with the following attributes.
The audio format, one of ``s8``, ``u8``, ``s16``, ``u16``,
``s32``, ``u32``, ``f32``. The default is hypervisor specific.
+Note:
+If no ``<audio/>`` element is defined, and the ``graphics`` element is set to
+either 'vnc' or 'sdl', the libvirtd or virtqemud process will honor the following
+environment variables:
+
+* ``SDL_AUDIODRIVER``
+
+ Valid values are 'pulseaudio', 'esd', 'alsa' or 'arts'.
+
+* ``QEMU_AUDIO_DRV``
+
+ Valid values are 'pa', 'pulseaudio', 'none', 'alsa', 'coreaudio', 'jack',
+ 'oss', 'sdl', 'spice' or 'file'.
+
None audio backend
^^^^^^^^^^^^^^^^^^
2 years, 10 months
[PATCH v2v 1/3] lib/utils.ml: Make with_nbd_connect_unix meta_contexts erasable
by Richard W.M. Jones
Make the meta_contexts parameter of Utils.with_nbd_connect_unix
optional and erasable. This involves three connected changes, we
first make it optional (ie. '?meta_contexts'), providing the obvious
default of empty list. We then need to move it to the first parameter
so OCaml can erase it even if we partially apply this function.
Finally remove the label from the function parameter 'f'.
I'm not quite sure why the last change is necessary, but OCaml cannot
erase ?meta_contexts without it, and in any case it's not necessary to
label this parameter as it doesn't add any extra type safety and you
wouldn't want callers to swap over the socket and function parameter
because that would make calling code less clear. (The same applies to
~socket but I didn't change that).
---
lib/utils.ml | 4 ++--
lib/utils.mli | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/lib/utils.ml b/lib/utils.ml
index d6861d0889..863cfc4eb0 100644
--- a/lib/utils.ml
+++ b/lib/utils.ml
@@ -165,7 +165,7 @@ let rec wait_for_file filename timeout =
let metaversion = Digest.to_hex (Digest.string Config.package_version_full)
-let with_nbd_connect_unix ~socket ~meta_contexts ~f =
+let with_nbd_connect_unix ?(meta_contexts = []) ~socket f =
let nbd = NBD.create () in
protect
~f:(fun () ->
@@ -181,7 +181,7 @@ let get_disk_allocated ~dir ~disknr =
let socket = sprintf "%s/out%d" dir disknr
and alloc_ctx = "base:allocation" in
with_nbd_connect_unix ~socket ~meta_contexts:[alloc_ctx]
- ~f:(fun nbd ->
+ (fun nbd ->
if NBD.can_meta_context nbd alloc_ctx then (
(* Get the list of extents, using a 2GiB chunk size as hint. *)
let size = NBD.get_size nbd
diff --git a/lib/utils.mli b/lib/utils.mli
index 3096eb1466..76a2ec8c40 100644
--- a/lib/utils.mli
+++ b/lib/utils.mli
@@ -78,9 +78,9 @@ val metaversion : string
Eventually we may switch to using an "open metadata" format instead
(eg. XML). *)
-val with_nbd_connect_unix : socket:string ->
- meta_contexts:string list ->
- f:(NBD.t -> 'a) ->
+val with_nbd_connect_unix : ?meta_contexts:string list ->
+ socket:string ->
+ (NBD.t -> 'a) ->
'a
(** [with_nbd_connect_unix socket meta_contexts f] calls function [f] with the
NBD server at Unix domain socket [socket] connected, and the metadata
--
2.32.0
2 years, 10 months
Virt-v2v performance benchmarking part 1 [long]
by Richard W.M. Jones
This email is about looking at the historical performance of virt-v2v
through the versions over the past year. The year has seen some very
significant changes to virt-v2v meant to improve modularity,
flexibility and in some cases performance. The main change that could
affect performance is exposing the disk image pipelines of the input
and output sides, and using nbdcopy (instead of qemu-img convert) to
copy the data. So for the sake of this email when I talk about
virt-v2v, I also mean nbdkit and libnbd which we've been
co-developing.
My first challenge is to try to make some kind of test case that we
can use for testing conversion and copying performance. For this I'm
using Linux. Because Windows conversions are always simpler than
Linux conversions, and because Windows is proprietary, it's neither
necessary or convenient to create a test case around Windows. I
created a simple and reproducible pair of test cases by doing:
$ mkdir /var/tmp/3G
$ dd if=/dev/urandom of=/var/tmp/3G/1 bs=1M count=1024
$ cp /var/tmp/3G/1 /var/tmp/3G/2
$ cp /var/tmp/3G/1 /var/tmp/3G/3
$ virt-builder fedora-35 --copy-in /var/tmp/3G:/var/tmp
$ virt-builder fedora-35 --copy-in /var/tmp/3G:/var/tmp --format=qcow2
$ ls -lsh fedora-35.*
3.9G -rw-r--r--. 1 rjones rjones 6.0G Jan 7 11:33 fedora-35.img
3.9G -rw-r--r--. 1 rjones rjones 3.9G Jan 7 11:37 fedora-35.qcow2
The test case should be locally reproducible for anyone wanting to try
to reproduce the results. Also the amount of used disk space can be
easily adjusted by using more or fewer 1GB random files, in case
copying is too fast or slow on local hardware.
The test case could then be copied to VMware or used locally, with
virt-v2v commands like these:
$ virt-v2v -i disk fedora-35.img -o null
$ virt-v2v -i disk fedora-35.qcow2 -o null
$ virt-v2v -i disk fedora-35.img -o local -os /var/tmp ; time sync
$ virt-v2v -i disk fedora-35.qcow2 -o local -os /var/tmp ; time sync
$ virt-v2v -ic esxi://... -it vddk [etc] fedora-35 [-o ...]
A few remarks:
- Old virt-v2v handled -o null very efficiently by throwing away the
data inside qemu-img convert. Modular virt-v2v runs an
nbdkit-null-plugin instance on the output side and always copies
the data to it. This is always going to be a bit slower.
Therefore I'm preferring the tests that write to local disk.
- Old virt-v2v did not sync the data to disk, but nbdcopy always
does, so with old virt-v2v you have to add a "time sync" command
and include that in the copying time for fairness.
- Raw and qcow2 use different code paths in the new virt-v2v, so
benchmarking both is useful.
- Copying from VMware can test raw over HTTP, VDDK, SSH which are all
different code paths. I'm not benchmarking this at the moment.
- Output to something other than null/local would also be
interesting, but I'm not benchmarking that at the moment.
>From the non-verbose output of virt-v2v we can derive 3 times of
interest for benchmarking performance:
$ virt-v2v -i disk fedora-35.img -o null
[ 1.1] Opening the source
[ 7.3] Inspecting the source
[ 12.4] Checking for sufficient free disk space in the guest
[ 12.4] Converting Fedora Linux 35 (Thirty Five) to run on KVM
[ 56.6] Mapping filesystem data to avoid copying unused and blank areas
[ 59.8] Closing the overlay
[ 60.3] Assigning disks to buses
[ 60.3] Checking if the guest needs BIOS or UEFI to boot
[ 61.3] Copying disk 1/1
█ 100% [****************************************]
[ 62.4] Creating output metadata
[ 62.4] Finishing off
=> Conversion time: 56.6 - 12.4 = 44.2
Mapping time: 59.8 - 56.6 = 3.2
Copying time: 62.4 - 61.3 = 1.1 (+ sync time for old virt-v2v)
The "mapping time" is the time taken to run fstrim over the source. I
include this because it regressed quite a lot just after we
modularised virt-v2v and was later fixed, although it's still not as
fast as old virt-v2v.
Now what I am doing is running some tests over every virt-v2v we have
released in CentOS 9 Stream over the last year. As mentioned above I
also need to do libnbd & nbdkit since we were co-developing those, so
I'm actually using RHEL 9 composes for this. However I am leaving
libguestfs, libvirt and qemu at the newest versions throughout this
because older versions had various problems running on current
hardware which have since been fixed (my theory is that the versions
of these should not make any significant difference).
Also:
$ virt-v2v --version
virt-v2v: symbol lookup error: virt-v2v: undefined symbol: guestfs_list_9p
This was easily fixed by adding a trivial LD_PRELOAD library which
just loaded phony symbols for guestfs_list_9p & guestfs_mount_9p_argv
(both dropped in later libguestfs).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
2 years, 10 months
Virt-v2v performance benchmarking part 2 [long]
by Richard W.M. Jones
This email continues my analysis of the performance of virt-v2v. The
first part is:
https://listman.redhat.com/archives/libguestfs/2022-January/msg00055.html
I used the standard guest (Fedora 35, 3G of additional random data) to
test virt-v2v versions 1.43.3-2.el9 through 1.45.96-1.el9. This range
covers (what we call) "old" virt-v2v (< 1.45.90), through new /
modular virt-v2v (>= 1.45.90). I also installed contemporary copies
of libnbd and nbdkit since virt-v2v and those other projects were
being simultaneously co-developed. But I was unable to use
contemporary qemu/libvirt/libguestfs so those versions are fixed at
the latest ones in RHEL 9.
I did local disk to local disk conversions of a raw and qcow2 format
standard guest. Disk to disk is not a very relevant test since
virt-v2v is almost never used by customers this way. In future
testing I will do more realistic tests involving VMware on the input
side. The commands used were:
$ virt-v2v -i disk fedora-35.img -o local -os /var/tmp/ ; time sync
$ virt-v2v -i disk fedora-35.qcow2 -o local -os /var/tmp/ ; time sync
I logged the test runs and manually added up the times for conversion,
map (fstrim), copying (including final sync), and total time. (Note
that total time isn't quite the same as conversion + map + copying
since there are some other smaller operations done by v2v.
I was able to test in total 8 different combinations of virt-v2v +
libnbd + nbdkit, with those having being built in the period
2021-02-27 through to a few days ago. (However I will only refer to
the version numbers, since the build dates are not relevant). I
repeated the first v2v test several times, and the times appeared to
be stable across runs to within a couple of seconds, therefore I
didn't repeat and average the times for other versions.
The test environment was an idle Intel NUC on RHEL 9/C9S. The tests
should be easily reproducible, albeit tedious to obtain and install
the builds.
Now refer to the attachment (LibreOffice Calc format).
Columns 1-4 represent old virt-v2v versions 1.43.3-2 through 1.45.3-3;
and cols 5-8 are for modular virt-v2v versions 1.45.94 through 1.45.96.
Qcow2 is broadly fine - modular virt-v2v is a little bit faster for
conversion, and copying is marginally less efficient (expected because
we are now copying between discrete qemu-nbd servers, instead of
having qemu-img convert read and write the qcow2 files directly), but
the total time does not change.
For raw format there is a problem, with modular virt-v2v being much
slower. This is likely to be some interaction with nbdkit, the cow
filter and block sizes which needs investigation.
As noted above, local disk to local disk is unrepresentative of real
customer conversions. Next week I will look at conversions from
VMware over VDDK.
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, 10 months
[v2v PATCH 0/9] generate virtio-transitional devices if told so by libosinfo
by Laszlo Ersek
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1942325
The first part of the series introduces the "gcaps_virtio_1_0" guest
capability (default value, according to the current virt-v2v assumption:
"true"), and updates the libvirt and JSON outputs to take the new
capability into account.
In the libvirt output, the virtio device models are flipped to -- or are
explicitly introduced as -- virtio-transitional if the machine type is
Q35 and the new "gcaps_virtio_1_0" capability is "false".
In the JSON output, we don't change any device models, only expose the
new capability, and allow CNV / KubeVirt to act upon it. This follows
the spirit of <https://bugzilla.redhat.com/show_bug.cgi?id=1942325#c11>.
The second part of the series wraps the osinfo_os_get_all_devices()
libosinfo API, and introduces a dependent function to retrieve the guest
OS's support for each of the Q35 chipset and the virtio-1.0 protocol
(extrapolated from support for virtio1.0-net), from the osinfo database.
The final patch in the series couples the two previous parts. The Notes
section of this patch contains extensive test results.
Thanks,
Laszlo
Laszlo Ersek (9):
lib/types: reformat "string_of_guestcaps"
lib/types: update "string_of_guestcaps"
lib/types: introduce the "gcaps_virtio_1_0" guest capability
output/create_libvirt_xml: pick "virtio-transitional" models when
needed
output/create_json: expose "gcaps_virtio_1_0"
convert/libosinfo: wrap osinfo_os_get_all_devices()
convert/libosinfo_utils: introduce "string_of_osinfo_device_list"
convert/libosinfo_utils: introduce "os_support_of_osinfo_device_list"
convert: determine machine type and virtio-1.0 from osinfo for x86
guests
convert/convert_linux.ml | 50 +++++++++------
convert/convert_windows.ml | 31 ++++++---
convert/libosinfo-c.c | 66 ++++++++++++++++++++
convert/libosinfo.ml | 14 +++++
convert/libosinfo.mli | 14 +++++
convert/libosinfo_utils.ml | 54 ++++++++++++++++
convert/libosinfo_utils.mli | 17 +++++
lib/types.ml | 24 +++++--
lib/types.mli | 4 ++
output/create_json.ml | 1 +
output/create_libvirt_xml.ml | 28 ++++++---
tests/test-v2v-cdrom.expected | 2 +-
tests/test-v2v-floppy.expected | 2 +-
tests/test-v2v-i-ova.xml | 8 +--
14 files changed, 266 insertions(+), 49 deletions(-)
base-commit: 07b12fe99fb9cf0b75fe45d3eaa07b4bbc1bbe89
--
2.19.1.3.g30247aa5d201
2 years, 10 months
Re: [Libguestfs] Windows new Filesystem
by Richard W.M. Jones
On Wed, Jan 05, 2022 at 04:37:42PM +0100, Gottschalk wrote:
> Hi Rich,
>
> i wish you a happy new year and health.
>
> We made a recovery from a VMware VM with a Windows 2019 Server.
>
> Guestfish lists a filesystem ReFs which is not mountable in guestfish version
> 1.36..13.
>
> We are using a Ubuntu 18.04.6 LTS Operating System.
>
> ><fs> add file034000.vmdk file034000_1.vmdk
> add: unknown optional argument "file034000_1.vmdk"
> ><fs> add file034000.vmdk
> ><fs> add file034000_1.vmdk
> ><fs> run
> 100%
> ⟦▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒⟧
> 00:00
> ><fs> list-filesystems
> /dev/sda1: ntfs
> /dev/sda2: vfat
> /dev/sda3: unknown
> /dev/sda4: ntfs
> /dev/sda5: unknown
> /dev/sdb1: unknown
> /dev/sdb2: ReFS
> /dev/sdb3: unknown
> ><fs> mount /dev/sdb2 /
> libguestfs: error: mount: /dev/sdb2 on / (options: ''): mount: /sysroot:
> unknown filesystem type 'ReFS'.
> ><fs>
>
> Have you any idea?
Sadly no one to my knowledge has written a ReFS driver for Linux at
all. If you can find one it should be possible (in fact, easy) to
make libguestfs use it, but without one it's not possible as far as I
know.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
2 years, 10 months
Re: [Libguestfs] virt-p2v-make-disk Question
by Laszlo Ersek
On 01/05/22 14:56, Richard W.M. Jones wrote:
> On Wed, Jan 05, 2022 at 01:46:08PM +0100, Tobias Soppa wrote:
>> Dear Richard,
>>
>> Sorry for bothering, but I didn't find another way to ask a question.
>>
>> Maybe you can point me to a chat or forum to receive support? I am not
>> sure whether I should use the libguestfs mailing list to send my
>> problem it to everyone?
>
> You can send any questions to libguestfs(a)redhat.com (without
> needing to subscribe). Or we're on IRC #guestfs on Libera.
>
>> For days I'm trying to boot from virt-p2v-make-disk made USB thumbdrive
>> but was never able to boot from it.
>>
>> I did produce several images in different ways and with different Linux
>> distributions, but the thumb drive is never bootable - not on a
>> physical machine, nor via Ventoy.
>>
>> It works in QEMU though, but I need it running on a physical machine. I
>> need to use (Secure) UEFI for booting and this works with any other
>> disk image.
>
> Probably UEFI is the problem here - in fact I doubt somehow that
> we support it at all.
The statement "works in QEMU" is unclear. If the QEMU guest in question
uses OVMF, then both cases (virt and phys) wouldn't differ with regard
to firmware type.
Secure Boot could be an issue too, yes; dependent on how the virt-p2v
UEFI bootloader is signed.
> Is it possible to turn it off and/or use the CMS module?
(*CSM -- compatibility support module)
It could be a workaround, yes.
>
>> Maybe because these discs are delivered with ISO filesystem and not as
>> .IMG images? I feel I terribly miss something here.
>
> We probably ought to deliver P2V as a UEFI binary, one day.
I've not delved into virt-p2v yet, but given that it uses GTK, it's
exceedingly unlikely that it can be built as a firmware-level binary
(such as "grub"), considering either UEFI or traditional BIOS.
The virt-p2v binary is an "ELF 64-bit LSB executable, x86-64, version 1
(SYSV), dynamically linked (uses shared libs)", so I think what we'd
actually do is: create a UEFI-bootable Linux image on the USB disk, and
continue using virt-p2v the same way -- once virt-p2v starts (as a Linux
process), the host firmware shouldn't matter.
If this is important, we should likely have an RFE (RHBZ) about it.
Thanks!
Laszlo
2 years, 10 months
Re: [Libguestfs] providing key for luks commands
by Richard W.M. Jones
On Wed, Jan 05, 2022 at 12:35:35PM +0000, Richard W.M. Jones wrote:
> On Tue, Jan 04, 2022 at 06:53:39PM -0800, Chris V wrote:
> > I am working on building an automated pipeline with a disk that contains a LUKS
> > partition. since it is running automated i need a method to provide the LUKS
> > key using a file but i keep getting prompted to enter the keys. I am creating
> > a file with only the key stored in it and using the --key option but i still
> > get the key prompt.
> >
> > here is the command that i am running, can you advise me on what i need to
> > change?:
> > sudo guestfish -a disk.qcow2 --key /dev/sda2:file:key.txt run : part-init /dev/
I should have read the command line a bit closer. The --key option
here only applies when you automatically mount the filesystems (with
the -i option). Otherwise IIRC it doesn't do anything. So the answer
below is still correct. I would definitely use a scripting language
with the API.
> > sda msdos : part-add /dev/sda p 2048 500000 : part-add /dev/sda p 500001
> > 2097118 : mkfs ext4 /dev/sda1 : luks-format /dev/sda2 0 : luks-open /dev/sda2
> > sda2_crypt : mkfs ext4 /dev/mapper/sda2_crypt
>
> The easiest way is probably this guestfish flag:
>
> --keys-from-stdin
> Read key or passphrase parameters from stdin. The default is to
> try to read passphrases from the user by opening /dev/tty.
>
> If there are multiple encrypted devices then you may need to supply
> multiple keys on stdin, one per line.
>
> You can feed the key by redirecting stdin.
>
> However a better way is likely to use the API directly for what you
> want, eg. through a Perl or Python script. You can supply the key
> directly as a parameter when using the API.
>
> https://libguestfs.org/guestfs.3.html#guestfs_luks_open
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, 10 months
providing key for luks commands
by Chris V
I am working on building an automated pipeline with a disk that contains a LUKS partition. since it is running automated i need a method to provide the LUKS key using a file but i keep getting prompted to enter the keys. I am creating a file with only the key stored in it and using the --key option but i still get the key prompt.
here is the command that i am running, can you advise me on what i need to change?:
sudo guestfish -a disk.qcow2 --key /dev/sda2:file:key.txt run : part-init /dev/sda msdos : part-add /dev/sda p 2048 500000 : part-add /dev/sda p 500001 2097118 : mkfs ext4 /dev/sda1 : luks-format /dev/sda2 0 : luks-open /dev/sda2 sda2_crypt : mkfs ext4 /dev/mapper/sda2_crypt
thanks
2 years, 10 months
