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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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 f720aff7d6
This tool can be used to estimate the disk space needed before doing a
virt-v2v conversion. It is a replacement for the old --print-estimate
option which was dropped in virt-v2v 2.0 (commit 5828c9c7d5 "v2v:
Remove --print-estimate option").
In Kubernetes and tools like Kubevirt, it's not possible to create
some disks and attach to them (in order to populate them with data) in
one step. This makes virt-v2v conversions awkward because ideally we
would like the output mode (-o kubevirt) to both create the target
disks and populate them at the same time.
To work around this problem, we need a tool which can inspect the
virt-v2v source hypervisor before we do the conversion in order to
find out how many disks are needed and their sizes. Then we can
create the target disks, and then we can run a second container with
virt-v2v attached to the disks to do the conversion and populate the
output.
This new tool essentially uses the same -i* options as virt-v2v (and
no -o* options) and outputs various useful metadata. Example:
$ virt-v2v-inspector --quiet -i disk fedora-32.img
virt-v2v-inspector: The QEMU Guest Agent will be installed for this guest
at first boot.
virt-v2v-inspector: warning: /files/boot/grub2/device.map/hd0 references
unknown device "vda". You may have to fix this entry manually after
conversion.
<?xml version='1.0' encoding='utf-8'?>
<v2v-inspection>
<!-- generated by virt-v2v-inspector 2.1.9local,libvirt -->
<program>virt-v2v-inspector</program>
<package>virt-v2v</package>
<version>2.1.9</version>
<disks>
<disk index='0'>
<virtual-size>6442450944</virtual-size>
<allocated estimated='true'>1400897536</allocated>
</disk>
</disks>
<operatingsystem>
<name>linux</name>
<distro>fedora</distro>
<osinfo>fedora32</osinfo>
<arch>x86_64</arch>
<major_version>32</major_version>
<minor_version>0</minor_version>
<package_format>rpm</package_format>
<package_management>dnf</package_management>
<product_name>Fedora 32 (Thirty Two)</product_name>
</operatingsystem>
</v2v-inspection>
There should be sufficient information in the <disks> section to
allocate target disks, plus additional information is printed which
might be useful.
Note that we do a full conversion in order to generate this
information. In particular it's not possible to generate the
<allocated/> estimate without this. It's plausible we could have a
--no-convert option, but I'm not sure it's worthwhile: it would only
save a little time, but would make everything less accurate, plus
maybe it is a good idea to find out if conversion is going to work
before we create the target disks?
I chose XML instead of JSON for output. XML allows us to annotate
elements with attributes like "estimated='true'". It also lets us
represent 64 bit number accurately, where JSON cannot represent such
numbers.
The output can be written to stdout (the default, or you can use "-O -"),
but for use from another program it is usually better to write the
output to a file using "-O output.xml".
Acked-by: Laszlo Ersek <lersek at redhat.com>
Add a new front end called virt-v2v-in-place which implements simple
in-place conversion support for local disks.
Commit 255722cbf3 ("v2v: Modular virt-v2v") temporarily dropped this
feature. This commit adds it back.
This was deprecated in commit 4bde87e340
(from Nov 2018).
This will temporarily make it impossible to convert from Xen guests
which use block devices over SSH, but I hope to solve that after the
virt-v2v split.
Run a msgmerge of the translations with the up-to-date template.
Do it manually before adding virt-v2v to Weblate, so we can edit them
(e.g. removing the obsolete messages, which are largely from libguestfs
sources).
Start the message extraction from the toplevel source directory, so the
file references are relative to that, instead of relative to this
po-docs subdirectory.
In addition, remove the reference to POTFILES-pl, as there are no Perl
sources in virt-v2v.
Also update/regenerate podfiles accordingly.
With the Weblate adoption, we let it update the po files from the
catalog template. The po4a behaviour of extracting the template,
merging the existing translations, and creating the translated PODs at
once is problematic. Hence, split the extraction and the translated POD
generation in two.
Use po4a-gettextize to extract the catalog template only, not doing it
anymore automatically at each build. There is no more need for a
po4a.conf file.
Use po4a-translate to create translated PODs from the po files, keeping
the fixup of the generated files (to avoid spurious =encoding, etc).
Add a silent rule to hide the po4a-translate command lines by default.
These changes also allow us to get rid of the POD existance checks with
associated error message pointing to the update-po rule. Now each
translated POD file is generated because of make dependency, and it
depends only on its po file.
The virt-v2v man page uses also additional POD snippets, so list them
as dependencies to make sure they are up-to-date.
This does not change the behaviour at the moment, however it will matter
when each traslated POD file will be generated on its own.
Use a LINGUAS file with the list of available translations instead of
defining them in a make variable. This way Weblate will be able to
update the list using an available addon, and we do not need to list
those not built.
Accordingly, rename the variable with built languages to
'linguas_translated'.
