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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When virt-v2v was part of libguestfs, before it was a separate
component, we prefixed all test names with 'test-v2v-*' in order to
distinguish them from tests for other components. Since virt-v2v is
now separate, we no longer need to do this. Thus we can remove the
'-v2v-' part of every test name, which reduces typing and makes the
names nicer.
Note that we cannot remove the 'test-' prefix. This is because
automake reserves an unspecified list of words (eg. "compile") and
tests using those names will fail. Keeping the 'test-' prefix avoids
this.
Bump the required version of libnbd to 1.14 (released Aug 2022). This
allows us to remove a check for older nbdcopy in the code.
RHEL 9 (our new minimum) has libnbd 1.20
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
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
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
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.
The configuration (--dump-config) and version of nbdkit won't change
while we are running, so we only need to get it once. We also don't
need the config parameter to Nbdkit.version so drop that.
VMs converted by virt-v2v are pets not cattle so we want to create
permanent non-running machines. (They may later or even soon
afterwards be started up by some other tool, at which point they also
become Instances.) Therefore use a different kind and slightly
restructure the yaml around this.
Thanks: Lee Yarwood
Add various information which we have but cannot add to the Kubevirt
yaml in any other place.
Example output:
...
metadata:
name: fedora-39
labels:
libguestfs.org/virt-v2v-version: "2.5.4"
libguestfs.org/osinfo: fedora39
...
Thanks: Bella Khizgiyaev, Liran Rotenberg
Fixes: https://issues.redhat.com/browse/RHEL-45992
Use unique v2vtransferN.json for every transfer, like like
out.paramsN.json. If we keep the temporary files after the import, the
content of the file can help debugging.
Related to #46
This log[1] is proved confusing for developers:
cannot read /etc/vdsm/vdsm.id, using any host: [Errno 2] No such file or directory: '/etc/vdsm/vdsm.id'
This is actually a debug message, that can help RHV developers to
understand where virt-v2v was running. To make this more clear, in the
expected case when running on non-oVirt host, we log now:
not an oVirt host, using non-oVirt host
For any other error, we can degrade to remote transfer, but we want to
warn the user about this, so we log:
warning: cannot read host id, using non-oVirt host: [Errno 2] No such file or directory: '/etc/vdsm/vdsm.id'
[1] https://github.com/libguestfs/virt-v2v/issues/46#issuecomment-2039604719
RWMJ: Changed "any host" to "non-oVirt host" to make it clearer.
We write the json inside a with block, so what actually happen is:
1. Computing the values
2. Dumping the json to stdout
3. Closing the connection
If some code in sdk.Connection.close() write something to stdout, it
will corrupt our json output. Avoid this by moving the output out of the
with block.
This will not prevent bad code to write something before the json. We
need to log bad json in the Ocaml code to reveal such issue.
If parsing params fail we get unhelpful error:
virt-v2v: error: internal error: invalid argument:
/tmp/v2v.CtVpBL/v2vtransfer.json: JSON parse error: end of file expected
near 'e'
Change the parsing code to read the entire json text and include it in
the error message. This will make it clear why the json could not be
parsed, and help to find the root cause for having invalid json.
Example error:
$ cat out.params0.json
This is not a json document
$ python output/rhv-upload-transfer.py out.params0.json
Traceback (most recent call last):
File "/home/nsoffer/src/virt-v2v/output/rhv-upload-transfer.py", line 261, in <module>
raise RuntimeError(f"Cannot parse params {data!r}: {e}").with_traceback(
File "/home/nsoffer/src/virt-v2v/output/rhv-upload-transfer.py", line 259, in <module>
params = json.loads(data)
^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.12/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.12/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib64/python3.12/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
RuntimeError: Cannot parse params 'This is not a json document\n': Expecting value: line 1 column 1 (char 0)
Related to #46
This function was used by -o libvirt / -o local to check that we have
UEFI firmware for the target architecture. All it does is called
find_uefi_firmware early so that we fail early.
The same check was copied into -o qemu, probably wrongly as we call
find_uefi_firmware just below, so the early fail is not necessary.
This allows us to remove error_unless_uefi_firmware completely since
it is no longer used anywhere.
This code is needed to check whether virtio-scsi driver was installed.
This reverts commit f0afc439524853508938b2bfc758896f053462e3.
Message-Id: <20230310175433.781335-2-andrey.drobyshev@virtuozzo.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
OCaml 4.08 introduces a stdlib Option module which looks a bit like
ours but has a number of differences. In particular our functions
Option.may and Option.default have no corresponding functions in
stdlib, although there are close enough equivalents.
This change was automated using this command:
$ perl -pi.bak \
-e 's/Option.may/Option.iter/g; s/Option.default /Option.value ~default:/g' \
`git ls-files`
Update common module to include:
commit cffa077323fafcdfcf78e230c022afa891a6b3ff
Author: Richard W.M. Jones <rjones@redhat.com>
Date: Mon Feb 20 12:11:51 2023 +0000
mlstdutils: Rework the Option module to be compatible with stdlib
commit 007d0506c538db0a43fec7e9986a95ecdcd48b56
Author: Richard W.M. Jones <rjones@redhat.com>
Date: Mon Feb 20 12:18:29 2023 +0000
mltools: Replace Option.may with Option.iter
As with the prior commit, prefer -cpu host for all guests (except when
we have more information from the source hypervisor). Although there
is the disadvantage that -cpu host is non-migratable, in practice it
would be very difficult to live migrate a host launched using direct
qemu commands.
Note that after this change, gcaps_arch_min_version is basically an
informational field. No output uses it, but it will appear in debug
output and there's the possibility we might use it for a future output
mode.
Thanks: Laszlo Ersek
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In the case where the source hypervisor doesn't specify a CPU model,
previously we chose qemu64 (qemu's most basic model), except for a few
guests that we know won't work on qemu64, eg. RHEL 9 requires
x86_64-v2 where we use <cpu mode='host-model'/>
However we recently encountered an obscure KVM bug related to this
(https://bugzilla.redhat.com/show_bug.cgi?id=2168082). Windows 11
thinks the qemu64 CPU model when booted on real AMD Milan is an AMD
Phenom and tried to apply an ancient erratum to it. Since KVM didn't
emulate the correct MSRs for this it caused the guest to fail to boot.
After discussion upstream we can't see any reason not to give all
guests host-model. This should fix the bug above and also generally
improve performance by allowing the guest to exploit all host
features.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2168082#c19
Related: https://listman.redhat.com/archives/libguestfs/2023-February/030624.html
Thanks: Laszlo Ersek, Dr. David Alan Gilbert, Daniel Berrangé
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Some guests require not just a specific architecture, but cannot run
on qemu's default CPU model, eg. requiring x86_64-v2. Since we
anticipate future guests requiring higher versions, let's encode the
minimum architecture version instead of a simple boolean.
This patch essentially just remaps:
gcaps_default_cpu = true => gcaps_arch_min_version = 0
gcaps_default_cpu = false => gcaps_arch_min_version = 2
I removed a long comment about how this capability is used because we
intend to completely remove use of the capability in a coming commit.
Updates: commit a50b975024ac5e46e107882e27fea498bf425685
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
For RHEL >= 9 / x86-64 guests we cannot use the default qemu CPU
(eg. "qemu64"), and so we have a mechanism for conversion to indicate
to the output modes that a more capable CPU is required. We
previously picked cpu='host-passthrough' (ie. the equivalent of qemu's
-cpu host). However this is not live migratable. cpu='host-model' is
a better choice as it is more likely to be migratable.
See also discussion here:
https://listman.redhat.com/archives/libguestfs/2023-February/030625.html
and previous discussion here:
https://listman.redhat.com/archives/libguestfs/2022-April/thread.html#28711
Acked-by: Laszlo Ersek <lersek@redhat.com>
Because this regexp was not anchored at both ends it would still
report a match for incorrect names.
Update common submodule to get this commit:
mlpcre: Remove ~anchored trap
PCRE2_ANCHORED only anchors the regexp at the start (ie. equivalent
to adding ^ at the beginning). It *does not* anchor it at the end as
well (for which there is a separate PCRE2_ENDANCHORED which has
various traps of its own).
Everywhere I've tried to use ~anchored I've fallen into the trap of
believing it anchors both ends, causing actual bugs. So remove it
completely from the bindings.
Replace ~anchored:true with ^...$ around the regular expression.
Fixes: commit 8a9c914544a49bed13eb5baf42290f835bdee7b5
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2162332
Reported-by: Ming Xie
For -o rhv-upload, the -os parameter specifies the storage domain.
Because the RHV API allows globs when searching for a domain, if you
used a parameter like -os 'data*' then this would confuse the Python
code, since it can glob to the name of a storage domain, but then
later fail when we try to exact match the storage domain we found.
The result of this was a confusing error in the precheck script:
IndexError: list index out of range
This fix validates the output storage parameter before trying to use
it. Since valid storage domain names cannot contain glob characters
or spaces, it avoids the problems above and improves the error message
that the user sees:
$ virt-v2v [...] -o rhv-upload -os ''
...
RuntimeError: The storage domain (-os) parameter ‘’ is not valid
virt-v2v: error: failed server prechecks, see earlier errors
$ virt-v2v [...] -o rhv-upload -os 'data*'
...
RuntimeError: The storage domain (-os) parameter ‘data*’ is not valid
virt-v2v: error: failed server prechecks, see earlier errors
Although the IndexError should no longer happen (except in extremely
rare cases like the storage domain being renamed), I also added a
try...catch around that code to improve the error.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1986386
Reported-by: Junqin Zhou
Reviewed-by: Nir Soffer <nsoffer@redhat.com>
This commit splits up any long lines found in errors, warnings or
other messages. OCaml ignores whitespace following "\<CR>" within a
string, eg:
"long string \
more stuff"
is parsed as:
"long string more stuff"
Thanks: Laszlo Ersek, for working out the OCaml syntax for this
Kubevirt supports something like RFC 1123 names (without the length
restriction). Helpfully it prints the regexp that it uses the
validate the names, so just use the same regexp.
Note that virt-v2v never renames guests (since that would add
unpredictability for automation). You must use the -on option to
rename the guest if the name is wrong. Hence this is an error, not a
warning or an attempt to rename the guest.
Reported-by: Ming Xie
Fixes: commit bfa62b4683d312fc2fa9bb3c08963fc4846831b9
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2162332
Apparently this element doesn't go in the obvious place (under
"resources", next to memory), but in a whole new section under "cpu",
which makes no logical sense but here we are. Also verified this
against Kubevirt examples/vm-template-fedora.yaml
Reported-by: Ming Xie
Fixes: commit bfa62b4683d312fc2fa9bb3c08963fc4846831b9