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 using virt-v2v-in-place there is no easy way to get the
post-conversion metadata, such as the operating system and firmware
that virt-v2v detected inside the guest.
This commit adds new, optional '-O output.xml' to write this
information out to a file. The format is identical to
virt-v2v-inspector (and roughly a superset of virt-inspector).
Fixes: https://issues.redhat.com/browse/RHEL-58032
Thanks: Martin Necas
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.
When set, run up to N copies of nbdcopy in parallel. This only
applies for guests with multiple disks.
The default, as for all older versions of virt-v2v, is to copy disks
one at a time.
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
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/
With the "reboot after every step" change made in the previous commit,
it seems removal of VMware Tools is now more reliable. Update the
notes about this.
Updates: commit c952f310c902e438a8b0b5240a4b486b698bede8
Update the common submodule to get:
Richard W.M. Jones (2):
mlcustomize: Add some comments to firstboot batch file
mlcustomize: Reboot Windows between each firstboot script
Document that Windows may now reboot several times after conversion.
We use VMware's recommended method for removal, but we know from
experience that this rarely works. The alternate method being
proposed involves making very invasive changes to the Registry and
filesystem, which are inappropriate for virt-v2v to do and highly
risky. Therefore simply document this, with notes for the virt-v2v
user if they want to try the risky method.
Fixes: https://issues.redhat.com/browse/RHEL-51169
Thanks: Yan Vugenfirer
Reported-by: Ming Xie
Previously we removed this paragraph, believing that the -ip option
now copes with all cases. However this still isn't true because
libvirt runs this ssh command:
ssh -l root -T -e none -- [XEN-HOST] sh -c 'which virt-ssh-helper 1>/dev/null 2>&1; if test $? = 0; then virt-ssh-helper 'xen://'; else if 'nc' -q 2>&1 | grep "requires an argument" >/dev/null 2>&1; then ARG=-q0;else ARG=;fi;'nc' $ARG -U /var/run/libvirt/libvirt-sock; fi'
I checked with Dan and there is no way to suppress this or pass in a
password, so we still need ssh-agent even with -ip. Note this applies
to any libvirt ssh connection, thus to Xen or VMware over SSH.
Reported-by: Ming Xie
Fixes: https://issues.redhat.com/browse/RHEL-45527
Thanks: Daniel Berrange
This reverts commit 67fcf66904c7f1f6da858eba35e95dad670427c0.
The documentation suggested (correctly) that the -ip option did not
cover all cases where we make an ssh connection to either VMware or
Xen. However with the recent change where we use nbdkit-ssh-plugin in
preference to ssh/scp (commit fb72e05986, "virt-v2v: -i vmx: Replace
external ssh/scp with nbdkit-ssh-plugin") this should no longer be
true for VMware. And I don't think it was true for Xen for a while.
Therefore remove this paragraph in the documentation (in two places).
See-also: https://bugzilla.redhat.com/show_bug.cgi?id=1854275
See-also: https://lists.libguestfs.org/archives/list/guestfs@lists.libguestfs.org/thread/CKBEYJHUZWLDUUDWAJM2JU6QIKZGTD6F/
Suggested-by: Laszlo Ersek
It has frequently tripped us up that on RHEL / Fedora, installing the
right set of libvirt RPMs (such as the one pulled in by
"libvirt-daemon-kvm") does not result in an immediately running libvirt
system instance. Document the need, and the simplest method, for starting
libvirt up manually.
Thanks: Daniel Berrangé
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2182024
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20230629123443.188350-4-lersek@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@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"]
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
This was the only guest type which did not support ACPI. It also only
supported direct to libvirt output. It hasn't been tested for a long
time, and hasn't been supported by Red Hat for very much longer.
Removing this means we no longer have to think about non-ACPI guests.
This commit adds a new -o kubevirt mode. You can specify where to
place the disks and metadata (guest.yaml) file using -os. Also
allocation mode (-oa) and disk format (-of) may be set. For example:
$ virt-v2v -i disk guest.img -o kubevirt -os /var/tmp
will generate /var/tmp/guest.yaml and /var/tmp/guest-sda
This is not finalized since undoubtedly the way the disks are handled
will have to be changed in future.
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>
In commit af4a0454cdd2 ("input-xen: replace "enable LEGACY crypto" advice
with targeted ssh options", 2022-07-11), we documented how the libssh /
openssh crypto settings needed to be relaxed, for connecting to RHEL5
sshd.
It turns out that in RHEL9, the non-LEGACY crypto policies disable SHA1 in
signature algorithms even at the OpenSSL level. Explain how the user can
re-enable that separately, for individual virt-v2v invocations.
The method depends on Rich's libvirt commit 45912ac399ab ("rpc: Pass
OPENSSL_CONF through to ssh invocations", 2022-07-25), which is is going
to be released in upstream libvirt v8.6.0.
Thanks: Dmitry Belyavskiy & Rich Jones
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2062360
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220729105703.10150-1-lersek@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
- "KexAlgorithms": the Fedora 35 ssh binary, using the DEFAULT
crypto-policy, cannot log in to RHEL5 sshd without relaxing
"KexAlgorithms". The server offers three algorithms:
"diffie-hellman-group-exchange-sha1", "diffie-hellman-group14-sha1",
"diffie-hellman-group1-sha1"; and according to RFC 9142,
"diffie-hellman-group14-sha1" is the least deprecated from those. (The
RFC marks it as MAY be implemented, and marks the other two as SHOULD
NOT be implemented.) Recommend "diffie-hellman-group14-sha1".
- "MACs": the Fedora 35 ssh binary, using the FUTURE crypto-policy, cannot
log in to RHEL5 sshd without relaxing "MACs". The server offers
"hmac-md5", "hmac-sha1", "hmac-ripemd160", "hmac-ripemd160@openssh.com",
"hmac-sha1-96", "hmac-md5-96". After eliminating the MD5-based algos
(MD5 is considered completely broken), and the one based on truncated
SHA1, we're left with "hmac-sha1", "hmac-ripemd160", and
"hmac-ripemd160@openssh.com". RIPEMD-160 is generally trusted, but it is
compiled out of the Fedora 35 "ssh" client binary. Therefore only
"hmac-sha1" remains.
- "HostKeyAlgorithms", "PubkeyAcceptedAlgorithms": these options control
the usage of public key algorithms, for authenticating the server to the
client, and vice versa, respectively. RHEL5 sshd only supports "ssh-rsa"
and "ssh-dss", and from those, "ssh-rsa" is more commonly used (for
example, "ssh-keygen" defaults to creating "ssh-rsa" keys). Recommend
"ssh-rsa".
- "PubkeyAcceptedKeyTypes": this is the old ("legacy") name for
"PubkeyAcceptedAlgorithms". As of this writing, the latest upstream
release of libssh (also packaged in Fedora 35 -- libssh-0.9.6-1.fc35)
does not recognize the new "PubkeyAcceptedAlgorithms" option name, only
the original "PubkeyAcceptedKeyTypes". openssh-8.7p1-3.fc35 recognizes
both option variants. Include "PubkeyAcceptedKeyTypes" in the
recommendation along with "PubkeyAcceptedAlgorithms", for backward and
forward compatbility.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2062360
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220711070157.5399-3-lersek@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
My analysis in <https://bugzilla.redhat.com/show_bug.cgi?id=1854275#c33>
was partially wrong; I had missed that for the xen+ssh transport, the
client-side libvirt library launches a naked "ssh" utility, underneath
"Libvirt.Connect.connect_auth":
setup [input/input_xen_ssh.ml]
Libvirt.Connect.connect_auth
no effect of "-ip"
Nbdkit_ssh.create_ssh [input/nbdkit_ssh.ml]
starts nbdkit with the ssh
plugin honoring "-ip"
Which requires a password just the same, and ignores "-ip" just the same.
Recommend the ssh agent in the docs.
Fixes: 46298c6514710013c59828b4933f0b3b1a354566
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1854275
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2062360
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220711070157.5399-2-lersek@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
On the vmfs file system, ESXi encodes guest name characters that it
considers reserved with fairly unpredictable, proprietary rules. For
example, the ESXi webgui forbids backslash characters (\) completely, a
percent sign (%) is encoded as %25, and a dollar sign ($) is replaced with
underscore (_). Therefore the user can only construct the pathname part of
the ssh:// URI in two steps: (1) determine the precise absolute pathname
of the VMX file by way of logging in to the ESXi server interactively, and
*reading* (not guessing) whatever ESXi chose for naming directories and
files, (2) given the absolute, server-local pathname, percent-encode the
characters that are reserved in URIs, following the open standard(s) that
cover this.
Document this procedure: reorder the paragraphs of the affected section so
that they describe segments of the URI from the left to the right, and
then elaborate on the pathname segment.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1938954
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220518064930.7061-3-lersek@redhat.com>
Acked-by: Richard W.M. Jones <rjones@redhat.com>
I would like to remove the -o json option in virt-v2v 2.2.
It was added to support KubeVirt, but never actually used. It is
better for specific targets to implement a proper output mode (as we
will eventually do for KubeVirt) rather than relying on a custom
templating language which knows nothing about the target.
This preparatory patch removes only the documentation, although it
leaves a note in the main manual page that the feature existed and is
deprecated.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Unlike in the VMWare input module, we don't have "remote_file_exists" and
"scp_from_remote_to_temporary" functions in the Xen input module;
therefore, nothing inherently prevents "-ip" from satisfying all ssh
password requests when using input-xen. However, the Xen server still
needs to permit PasswordAuthentication; sync the appropriate note from the
input-vmware manual to the input-xen manual.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1854275
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220409065512.7515-1-lersek@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
[lersek@redhat.com: add missing "and" to commit message]
For traversing a backing chain of VMDK descriptor files over ssh, two
things are necessary:
- qemu-nbd with the ssh block driver, rather than nbdkit-ssh-plugin,
- a remote SSH URL (for qemu-nbd) without a query string appended, as
qemu-nbd cannot update the last pathname component (for tracking the
relative pathnames of VMDK descriptor files) if a query string is
appended.
Before commit 7a6f6113a25f ("v2v: -i vmx -it ssh: Replace qemu block ssh
driver with nbdkit-ssh-plugin.", 2019-10-08), we passed the
"?host_key_check=no" query string in the URL to qemu-nbd, so we can't just
return to that, for accessing snapshotted guests with vmx+ssh.
But, we shouldn't return to qemu-nbd for vmx+ssh even without a query
string, as that would undo the other benefit(s) of commit 7a6f6113a25f.
Instead, clearly document that snapshotted guests are not supported over
vmx+ssh, and cleanly reject this situation in the code as well. Recommend
the two alternative transports that allow the user to convert such guests.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1774386
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220409061252.6551-1-lersek@redhat.com>
[lersek@redhat.com: replace B<-...> with I<-...> in NOTES]
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Virt-v2v can use pnp_wait.exe to wait for new Windows devices to
activate. However this was not mentioned in the existing
documentation.
Also refine the documentation for pvvxsvc.exe (used only by SUSE
hosts) so that we don't mention the non-existent --firstboot* options.
This was incorrect documentation copied from virt-customize. Just say
that it's an alternative to RHSrvAny.
Reported-by: Ming Xie
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2059287#c6
Fixes: commit ee78c06b7f ("customize: add support for pvvxsvc")
Reviewed-by: Laszlo Ersek <lersek@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.
The functions "remote_file_exists" and "scp_from_remote_to_temporary"
[input/parse_domain_from_vmx.ml] rely on "ssh" and "scp" shell commands,
which intentionally only take a password from a tty. This means that for
vmx+ssh, "-ip" is incomplete.
Completing the feature would require a lot of work; we'd have to
reimplement "remote_file_exists" and "scp_from_remote_to_temporary" in C,
using libssh (an sftp session). For "remote_file_exists", we'd have to
replace "test -f" with sftp_lstat(). For "scp_from_remote_to_temporary",
we'd need to write an SFTP download loop. vmx+ssh is too niche for this,
so let's just document the limitation.
Extends: 784be60842d088596d7af938f90c689083677dca
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1854275
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220217145638.9324-1-lersek@redhat.com>
[lersek@redhat.com: add docs link to RHBZ#1854275 (Rich)]
Acked-by: Richard W.M. Jones <rjones@redhat.com>
