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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Since OCaml 4.07 (released 2018-07-10) the always-loaded standard
library module has been called Stdlib. The old Pervasives module was
finally removed in OCaml 5.
$ perl -pi.bak -e 's/Pervasives\./Stdlib./g' -- `git ls-files`
OCaml >= 4.07 is now required.
Also update the common submodule with:
commit d61cd820b49e403848d15c5deaccbf8dd7045370
Author: Jürgen Hötzel
Date: Sat May 20 18:16:40 2023 +0200
Add support for OCaml 5.0
eBlocker (https://eblocker.org) provides an OVA which contains this
manifest (*.mf) file:
SHA256 (eBlockerVM-2.9.1-amd64.ovf) = 7b25ea03c3b9eb143c7f6d1e8f76c3717e5b928f007e571cd96132bf6a15a30d
SHA256 (eBlocker VM-disk001.vmdk) = 646d1ec6ddf5a6d6604dbec421624ca2cea6ee5b57bf80ae635bf8f4f0bfea45
Note that the manifest is not conforming with the OVFS specification
which says the line format should be:
file_digest = algorithm "(" file_name ")" "=" sp digest nl
Space (sp) is not permitted after the algorithm or before the = sign.
However let's be tolerant of the extra whitespace.
Right now wait-pnp is the only firstboot script which does its logging
into a separate log file. Let's align its behaviour with that of the the
other scripts so that logs go to the common log file, i.e.
"C:\Program Files\Guestfs\Firstboot\log.txt".
Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Message-Id: <20230316173438.100162-3-andrey.drobyshev@virtuozzo.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
During conversion we copy the necessary drivers to the directory
"%systemroot%\Drivers\Virtio", adding it to the DevicePath registry
value. As documented in [1], this should be enough for Windows to find
device drivers and successfully install them.
However, it doesn't always happen. Commit 73e009c04 ("v2v: windows:
Document use of pnputil to install drivers.") describes such issues with
Win2k12R2. I'm seeing the same problem with Win2k16 and netkvm.sys
driver not being installed.
That same commit 73e009c04 suggests adding a firstboot script invoking
pnputil at an early stage to install all the drivers we put into the
drivers store. So let's add such a script to make sure all the
necessary drivers are installed.
[1] https://learn.microsoft.com/en-us/windows-hardware/drivers/install/how-windows-selects-a-driver-for-a-device
Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20230316173438.100162-2-andrey.drobyshev@virtuozzo.com>
The test checks that the newly introduced --block-driver option doesn't
break conversion. Basically its logic somewhat repeats test-v2v-i-disk.sh
and test-v2v-in-place.sh, but with the new option being set.
The checks it performs are:
1. Run disk-sourced conversion (-i disk) based on the phony windows.img
and check that it completes (i.e. produces converted disk and
corresponding domain XML;
2. Run libvirt-sourced in-place conversion based on an XML with virtio
vda disk specified (virtio-blk case) and check that the resulting
image has the phony viostor driver installed.
3. Run libvirt-sourced in-place conversion based on an XML with scsi
sda disk specified (virtio-scsi case) and check that the resulting
image has the phony vioscsi driver installed.
Note that the latter 2 cases aren't really comprehensive as v2v actually
copies all the drivers present in $VIRTIO_WIN, regardless of the block
driver specified. The real difference comes from the PCI ID values written
into the registry. But since we can't test real Windows and evaluate
those values, we're doing the best we can here, i.e. testing that conversion
doesn't break and drivers are still present with --block-driver option
being set explicitly.
Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Message-Id: <20230310175433.781335-7-andrey.drobyshev@virtuozzo.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The option takes values of "virtio-scsi", "virtio-blk" (with the latter
being the default). It maps on the convert option with the same name
introduced in the previous commits, thus allowing us to alter the order in
which the VirtIO block drivers are going to be searched for. This is
useful if we want the virtio-scsi driver to be installed during
conversion instead of the default virtio-blk.
Also update the docs accordingly.
Originally-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Message-Id: <20230310175433.781335-6-andrey.drobyshev@virtuozzo.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: fix the docs to placate "test-v2v-docs.sh"]
When injecting a block VirtIO driver during conversion, we rely on the
predefined list of names of such drivers. Order in this list denotes the
priority (see common/mlcustomize/inject_virtio_win.ml).
This commit introduces the "block_driver" convert option, setting its
value to the default Virtio_blk and making sure it's being properly passed
to the conversion functions. Along with the means of altering the drivers
list (introduced in a separate commit in the common submodule), this option
will be brought to command line, giving us the opportunity to choose the
block driver to be used on conversion.
Originally-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Message-Id: <20230310175433.781335-4-andrey.drobyshev@virtuozzo.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Andrey Drobyshev (2):
inject_virtio_win: add Virtio_SCSI to block_type
inject_virtio_win: write the proper block controller PCI ID to Win registry
Richard W.M. Jones (2):
mlcustomize: Fix overlong comment
mlcustomize: Add accessors for block driver priority list
Roman Kagan (1):
inject_virtio_win: match only vendor/device/revision
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Starting with Openstack 17.1 the overcloudrc file may contain an
environment variable called "OS_CLOUD" which references a separate
clouds.yaml file. It appears this variable overrides all other
authentication environment variables. Thus if you copy overcloudrc
without also copying clouds.yaml then things don't work.
Note the presence of the clouds.yaml file and reference the Openstack
documentation.
Also use F<> more consistently around filenames.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2172075
Reported-by: Ming Xie
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 a50b975024
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
RHEL >= 9 and compatible distros like Rocky >= 9 will not boot using
the default qemu CPU. You will see an error at boot:
Fatal glibc error: CPU does not support x86-64-v2
Instead you need to use -cpu host.
In commit f28757c6d1 ("convert_linux: set "gcaps_default_cpu = false"
for x86_64 RHEL-9.0+ guests") we fixed this specifically for RHEL >= 9.
This commit extends the same fix to all RHEL family distros.
Updates: commit f28757c6d1
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2166619
Reported-by: Ming Xie
Thanks: Laszlo Ersek
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 8a9c914544
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2162332
Reported-by: Ming Xie
In various places we used PCRE.compile ~anchored:true (PCRE2_ANCHORED)
thinking it means that the regular expression is anchored at both
ends. However this is not what it means (it only anchors the start).
Replace with ^...$
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>
Update common module to 3253cd99d135d5eb788a0477459b43a269e8cca6
No significant changes that affect virt-v2v now, but it adds some
extra functions to Std_utils that might be used one day.
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 bfa62b4683
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 bfa62b4683
Update common submodule, picking up:
mltools: Move DOM code from virt-v2v to mltools
This is a simple library for generating XML output. We would like to
use this in the new guestfs-tools program 'virt-drivers', so move it
to common/mltools.
This is a straightforward code move, the library has no significant
dependencies.
Do this so that .depend files are generated correctly, including
dependencies on the modules that were moved into common/mldrivers.
Fixes: commit 4b9c8e1560
Update common to get this commit:
mldrivers: New directory containing driver detection code
Move the existing code from virt-v2v for handling driver detection.
This is just code motion from virt-v2v, so that we can create a new
tool (in guestfs-tools) called 'virt-drivers'.
This so far only handles Linux (because virt-v2v doesn't do Windows
driver detection), but we will add Windows support in future.
This is just code motion.
As with other modules, we want to move these to common/ (so it can be
used in guestfs-tools), so remove the minimal dependencies that remain
on the Types module.
The existing function Inspect_source.get_firmware_bootable_device
detected if the guest could boot using UEFI through inspection (rather
than whatever the hypervisor told us).
Move this function to a new module, renaming it as
Firmware.detect_firmware.
Since we intend to move this into common/ (so it can be used in
guestfs-tools), remove the i_firmware field from the inspect struct
and pass it around as a separate argument.
As this module is generally useful we would like to use the same code
in guestfs-tools (ie. move it into common/). In preparation for doing
that, remove dependencies on the virt-v2v specific Types module.
This change is mostly routine avoidance of the inspect struct, but I
changed the way that we determine which version of RPM is installed.
Instead of consulting inspect.i_apps, actually run 'rpm --version'
(inside the guest) and parse the output. Note the only place we do
this, we're going to run 'rpm' soon anyway, so we know this is OK.
