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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
This simply replaces the existing -oo rhv-direct option with a new -oo
rhv-proxy option. Note that using this option "bare" (ie. just “-oo
rhv-proxy”) does nothing in the current commit because the default is
still to use the proxy.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2033096
Thanks: Nir Soffer
$ git shortlog 5b5fac3e0b10..41126802097f
Laszlo Ersek (3):
Demote "Std_utils.wrap" to an internal function in Tools_utils
Tools_utils.wrap: only wrap text for TTYs
add common ("standard") option --wrap
(We can't separate out the docs update, otherwise the docs test
"docs/test-v2v-docs.sh" fails right after the submodule update, which
introduces the common "--wrap" option.)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Some extra text about interactive passwords was left over after making
the change to require -ip passwordfile.
Reported-by: Ming Xie
Fixes: 8abc07a8589a48c79cc65159640e0d8ab3c9b261
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1960087
Commit 258e4b718d5d introduced the "copy_from_libosinfo" branch in
"copy_drivers" with higher priority than the existent
"copy_from_virtio_win".
This introduced a conflict with the documentation ("docs/virt-v2v.pod").
The documentation stated (and still states) that the VIRTIO_WIN env var,
when set, dictates where virt-v2v look for the virtio-win drivers. The
conflict is that, even in case we set VIRTIO_WIN, virt-v2v still consults
libosinfo first.
Skip the "copy_from_libosinfo" branch in case VIRTIO_WIN is set, plus
explain in the documentation that VIRTIO_WIN, when set, overrides
libosinfo.
NOTE: the necessity of this fix is made apparent by the next patch in the
series. Namely, "copy_from_libosinfo" has a bug in the architecture
filter. Once we fix that bug in the next patch, *and* install (e.g.)
"virtio-win-1.9.24-4.el8.noarch" on the conversion host, the "i-ova" test
case will suddenly prefer the virtio drivers exposed via libosinfo, in
spite of the "tests/test-v2v-i-ova.sh" script explicitly setting
VIRTIO_WIN to "test-data/fake-virtio-win". The symptom is that the pvpanic
device will be enabled in the domain XML, due to it being supported by the
actual (not fake) virtio-win drivers.
Fixes: 258e4b718d5d80c79634fe864c8c52b12e41777c
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2043333
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220201123219.9317-2-lersek@redhat.com>
Acked-by: Richard W.M. Jones <rjones@redhat.com>
As far as I've ever seen, you always need a password to access the
/folder directory of a VMware server. If the password isn't specified
to virt-v2v using the -ip option then it used to try to ask for it
interactively when virt-v2v started. Actually it asked for the
password several times -- at least twice.
After we added the cookie-script feature (commit 2b9a11743b "v2v:
vcenter: Implement cookie scripts.") it tries to ask interactively at
random points during the conversion, which is obviously bad from a UI
point of view but also because the password is requested without a
prompt looks like a hang.
We could solve this by prompting for a password. But virt-v2v is not
primarily an interactive tool and it's an easier fix is to require the
caller to use the -ip passwordfile option (in this particular mode).
Reported-by: Xinyu Li
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1960087
We never supported this because OpenSSH sftp server does not know how
to open and get the size of a block device. Before modular virt-v2v,
we would detect this situation and print an error:
virt-v2v: error: guest disk sda appears to be zero bytes in size.
There could be several reasons for this:
Check that the guest doesn't really have a zero-sized disk. virt-v2v
cannot convert such a guest.
If you are converting a guest from an ssh source and the guest has a disk
on a block device (eg. on a host partition or host LVM LV), then
conversions of this type are not supported. See the virt-v2v-input-xen(1)
manual for a workaround.
This error was lost in the conversion to modularity, but in any case
the proper way to detect this is in the input_xen driver itself.
In addition to this, when we removed the old virt-v2v-copy-to-local
tool, the text referring to the workaround in the manual became
meaningless, so I added the (ugly, manual) workaround that you have to
do back into the manual, minus the bit about the tool that we removed.
In future we could consider other ways to convert a remote block
device over SSH transparently. (Sending a "dd" command, maybe?)
I also checked what happens when we try to convert an empty disk, and
it fails during inspection with a reasonable error message, so we
don't need to do anything to restore the above error:
$ virt-v2v -i disk /var/tmp/empty -o null
[ 1.1] Opening the source
[ 7.0] Inspecting the source
virt-v2v: error: inspection could not detect the source guest (or physical
machine).
Assuming that you are running virt-v2v/virt-p2v on a source which is
supported (and not, for example, a blank disk), then this should not
happen.
No root device found in this operating system image.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2041852
Reported-by: Xiaodai Wang
Commit 2c91610ab3 ("v2v/input_libvirt_xen_ssh.ml: Remove obsolete
error check.") was incomplete. We no longer need to use the direct
backend to work around bug 1140166, because we use nbdkit + the ssh
plugin instead of qemu's ssh backend. The manual page still mentioned
this.
Fixes: commit 2c91610ab35ad1e8b49596bcaa94731c67031180
Thanks: Xiaodai Wang, Laszlo Ersek
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
