IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This models a UEFI NVRAM variable which controls whether or not EFI
binary signatures are verified, which is an initial step in the long
chain of operations commonly known as "secure boot". I added plenty
of documentation explaining what this really means as it is
non-obvious.
Thanks: Daniel Berrange, Andrea Bolognani
SMM is only a small part of enabling secure boot, so remove this
comment. Probably we don't need to use smm=on at all since it may be
enabled implicitly by other SB features.
Update the qemu shell script to simply find the UEFI paths as
required.
Remove lib/uefi.ml:find_uefi_firmware as this function is no longer
needed.
Remove common/mlv2v/ everywhere. This contained a list of UEFI code
and NVRAM files which is no longer used.
Update common submodule. This pulls in:
Richard W.M. Jones (5):
mlcustomize/customize_run.ml: Move 'in' to new line
mlstdutils/guestfs_config: Define host_os
mlcustomize, mltools: Check guest OS is compatible before allowing --run
Remove mlv2v/ subdirectory
qemuopts: Add ability to add raw, unquoted output to qemu scripts
qemuopts: Fix missing break statement
In -i libvirt / -i libvirtxml we didn't trim whitespace
around the name, so:
<name> foo </name>
would set the input name to the literal string " foo ".
It is not possible to specify an optional <checksum> field for each
disk. This gives the expected checksum (to be supplied by some higher
level management tool), and virt-v2v will verify that the checksum of
the actual disk presented matches the expected checksum.
<domain type='kvm'>
...
<devices>
<disk type='file' device='disk'>
<driver name='qemu' type='raw'/>
<source file='/path/to/disk/image'/>
<target dev='hda' bus='ide'/>
<checksum method='md5' fail='warn'>
a07aeb7de93e9b60d9155294cf332508
</checksum>
</disk>
$ virt-v2v-in-place -i libvirtxml file.xml
...
[ 0.0] Checking md5 checksum of disk 1/2
warning: bad checksum for disk 1/2
Expected checksum: a07aeb7de93e9b60d9155294cf332508
Actual checksum: e83009eb529a958875008103bb248017
Unfortunately support has not yet been added to oVirt. However I have
inferred the correct ostype value based on existing entries.
Also pull in the following commit from the common submodule:
Richard W.M. Jones (1):
mlcustomize: Add heuristic support for Windows Server 2025
Related: https://issues.redhat.com/browse/RHEL-65009
Related: https://issues.redhat.com/browse/RHEL-65010
Reported-by: Ming Xie
After previous changes, this library is no longer used. We have
switched to json-c, for better compatibility with libvirt.
(cherry picked from
guestfs-tools commit e6dcf7e3a7e9170978e57ce6df1b34f92fac5ae3)
We don't use Jansson explicitly, but used it implicitly wherever the
OCaml JSON_parser module is used. This module was switched over to
using json-c. Update the build dependencies accordingly.
Pulls in the following commit from the common submodule:
Richard W.M. Jones (1):
mltools: Replace jansson with json-c
This will eventually replace Jansson for all JSON parsing. However
this commit simply introduces the new dependency in the configure
script and documents it.
I chose json-c 0.14 as the baseline since that is the version in RHEL 9.
Probably earlier versions would work.
(cherry picked from libguestfs commit 53872a0a1a267040677572c30b68bd1e8b62ebe3)
All recent compilers support this (except MS compilers which we don't
care about). Assume it is supported. We test it in ./configure and
hard fail if it doesn't work.
We still define HAVE_ATTRIBUTE_CLEANUP but you can now assume it is
always defined and don't have to check it.
(cherry picked from libguestfs commit e37768d8892d6f467c7834f8b142b89f8f0af7dc)
The previous firmware section in Kubevirt YAML didn't match the
current specification. Unclear if it matched a previous spec or if we
just guessed at the format.
After this change, for BIOS:
..
spec:
template:
spec:
domain:
firmware:
bootloader:
bios: {}
..
For UEFI:
..
spec:
template:
spec:
domain:
firmware:
bootloader:
efi:
persistent: true
..
Link: https://kubevirt.io/api-reference/v1.3.1/definitions.html#_v1_firmware
Reported-by: Martin Necas
Fixes: https://issues.redhat.com/browse/RHEL-58065
Another weird corner case in YAML is that empty dictionaries have a
special representation. Empty lists also have a special
representation, that we got wrong.
Link: https://stackoverflow.com/a/33510095
Previously several empty Kubevirt YAML nodes were represented as empty
lists (List []). Our YAML generator incorrectly generated "{}" for
this, but this is the YAML for empty dictionary, not list. However as
a consequence of two bugs cancelling out, this actually generated the
expected YAML.
Since we're going to fix the bug in our YAML generator, replace
List [] with Assoc [] so the output will remain the same.
eg:
[ 9.3] Converting Windows Server 2022 Phony Edition (win2k22) to run on KVM
Reported-by: Ming Xie
Fixes: https://issues.redhat.com/browse/RHEL-56784
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
For the phony Windows guest we used the registry information from a
32 bit Windows 7 instance. This version of Windows is EOL. Newer
Windows changed the versioning scheme so we now use the build ID to
distinguish between versions, but we have not tested this in virt-v2v
upstream before.
I grabbed HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion
from a real 64 bit Windows 2022 Server instance, minus identifying strings.
Various tests had to be updated because they contained references to
Windows 7, or because virtio-win contains more drivers for Windows
2022.
Adds the two v2v-customize-*.pod snippets.
Also update the common submodule to get:
Richard W.M. Jones (1):
mlcustomize: Include v2v-customize-*.pod in EXTRA_DIST
Updates: commit f720aff7d690ead787b2ec9d4dabdff2b2923efd
Windows 2022 (and possibly earlier versions back to around 2019) will
force offline any non-boot disks which change bus, apparently as a
security mitigation. The effect of this is that although the system
drive (C:) is present after conversion, other drives may seem to
disappear.
Running a Powershell script to bring all disks online seems risky.
The compromise is to bring online only virtio disks at first boot.
To further reduce risk, we only do this if there are non-system disks
(ie. > 1 disks in total), and only if we installed virtio drivers.
Fixes: https://issues.redhat.com/browse/RHEL-55763
Fixes: https://issues.redhat.com/browse/RHEL-55837
Related: https://issues.redhat.com/browse/MTV-1299
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1662286
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Thanks: Martin Necas
Acked-by: Martin Necas
Commit ade62ebdb5 ("v2v: Add support for virt-customize options")
included --inject* options that covered facilities for injecting QEMU
guest agent etc which are already part of virt-v2v. We shouldn't add
the options for that.
The generator in libguestfs was changed so we can now exclude those
options from virt-v2v.
Update common submodule to include:
Richard W.M. Jones (1):
mlcustomize: Update generated options for virt-v2v
Fixes: commit ade62ebdb50e32a05c336ffcf4c08c6996a3af36
For higher level tools making further arbitrary changes to the guest
post-conversion, especially adding more firstboot scripts, it's useful
if we have various features from virt-customize. Particularly the
ability to upload and run scripts. Since we have the virt-customize
code in the common/ submodule, the easiest thing to do is to add the
virt-customize options, the same way it is done in virt-builder and
virt-sysprep.
Also updates the common submodule to get:
Richard W.M. Jones (1):
mlcustomize: Move virt-customize modules to mlcustomize/
