This cannot work because there is no Gtk or SDL output mode
in RHEL 8's qemu-kvm.
In addition you will have to edit the -display option in the
qemu script.
RHEL 8 does not have qemu-system-x86_64 (etc), and in addition the
qemu binary is located in /usr/libexec. Encode the path to this
binary directly in the script.
Note that we don't support people running qemu directly like this.
It's just for quick testing of converted VMs, and to help us with
support cases.
This disables support for unsupported remote drive protocols:
* ftp
* ftps
* http
* https
* tftp
* gluster
* iscsi
* sheepdog
* ssh
Note 'nbd' is not disabled, and of course 'file' works.
We hope to gradually add some of these back over the lifetime of RHEL 8.
vCenter 7 answers with an HTTP/2 status string, so we cannot extract
the status code from it by using fixed positions in that string.
Hence, pick the status code by reading what's after the whitespace.
Tested with vCenter 6.5 and 7.
(cherry picked from commit d2aa82317964d62fcc8dc7b6737773003d04b998
in virt-v2v)
This new operation removes the Kerberos /etc/krb5.keytab file from the
guest.
Thanks to Christian Heimes and François Cami for the hints.
Related to RHBZ#1789592.
(cherry picked from commit faa5d8507f)
This new operation unenrolls the guest from a IPA server offline, by
removing the configuration files and certificates.
Thanks to Christian Heimes and François Cami for the hints.
(cherry picked from commit 0a53e2c7fc)
Add a simple side effect to make operation flag that a regeneration of
the system CA store is needed. In case it is flagged, regenerate the
system CA store directly, or using a firstboot script in case of
incompatible architectures.
This change is almost a no-op, since no operation requires the
regeneration of the system CA store yet.
(cherry picked from commit bb7fc6d0a1)
Add an helper function to run a command in the guest, checking for the
host/guest compatibility. This is mostly extracted from the internal
do_run helper currently in the Customize_run module of virt-customize.
(cherry picked from commit e73eca3b73f7d0a54615c5dc55eadd09dc170035
in libguestfs-common)
The kernel returns xattr names in a slightly peculiar format. We
parsed this format several times in the code. Refactor this parsing
so we only do it in one place.
(cherry picked from commit 5c175fe732)
Instead of running firstboot script during early boot schedule a task
delayed for 2 minutes.
During the first boot, after virt-v2v conversion, Windows installs the
drivers injected by virt-v2v. When this installation is finished
Windows enforces some kind of internal reboot. This unfortunately
terminates any running firstboot scripts thus killing the installation
of qemu-ga MSI.
This is just a best-effort mitigation. It can still happen (e.g. with
slow disk drives) that the drivers are not yet installed when the
delayed installation starts. On the other hand we cannot delay it too
much otherwise we risk that the users logs in and will be doing some
work when the MSI installation starts. After MSI installation finishes
the VM needs to be rebooted which would be annoying if that would happen
under users hands. Although this is not a best fix (that may come later
as it is more complex, e.g. introducing waiting mechanism), the delay as
it is defined works in most cases. And it dramaticaly improves the
situations -- originaly I experienced more than 90% failure rate.
Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
(cherry picked from commit dc66e78fa37db33e3c7358b7f7c7fa809cf62f9d
in virt-v2v)
The detection was incorrectly matching only 32-bit installer on all
architectures.
Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
(cherry picked from commit 45acf8d0557bee948c035305a6bafc6c9963a467
in virt-v2v)
- match log file with script name
- restart manually only after successfull install, this also helps
debugging because we can log the installer return code
Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
(cherry picked from commit 59f9ff40621240a6eed28c4425d3d69d8b21bc0e
in virt-v2v)
Use firstboot script to install MSI with QEMU-GA from virtio-win ISO or
oVirt/RHV guest tools ISO.
Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
(cherry picked from commit 00b4ed312b)
The debug message was slightly changed too to better match the similar
message for ISO case. It refers to the root directory instead of the
specific subdirectory inside guest tools.
Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
(cherry picked from commit f4bda5571a)
There was no source directory for EL8 guest agent (only EL6 and EL7).
RHBZ#1791802
Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
(cherry picked from commit 79dd6a6bbb7e95691be18f54d601318d7d713702
in virt-v2v)
The command as documented was wrong. We need to use the --set option
to change the policy.
Fixes commit d5cbe7b4bee5dec9e28b1db03e933c97ef6d11e0.
Thanks: Xiaodai Wang
(cherry picked from commit 0edf419e983fe75daef9eaa7bd0578cbcada2e73
in virt-v2v)
This is actually not required, because ovirtsdk4 will use the system's
global trust store if necessary. Therefore we can make it optional in
all cases.
(cherry picked from commit 65ee9387d4be0e3c5cd214b967fef7a1a8841233
in virt-v2v)
"qemu-img convert" detects zeroes in allocated areas and punch holes in
the destination image. This may save space on the destination image, but
slows down conversion when using outputs such as rhv-upload, which have
very large overhead per requests.
Using the -S flag, we can treat small areas filled with zeroes as data,
limiting the number of requests, and speeding the operation.
Here is an example converting Fedora 30 image:
$ virt-builder fedora-30 -o src.img
...
$ qemu-img map -f raw --output json src.img | wc -l
213
$ qemu-img convert -f raw -O raw -t none -T none src.img dst.img
$ qemu-img map -f raw --output json dst.img | wc -l
1443
$ ls -lhs *.img
1.2G -rw-r--r--. 1 nsoffer nsoffer 6.0G Nov 1 21:48 dst.img
1.2G -rw-r--r--. 1 nsoffer nsoffer 6.0G Nov 1 21:46 src.img
Qemu did 1443 writes instead of 213 (5.8X). Lets repeat this conversion
with the -S option:
$ qemu-img convert -f raw -O raw -t none -T none -S 64k src.img dst.img
$ qemu-img map -f raw --output json dst.img | wc -l
213
$ ls -lhs *.img
1.2G -rw-r--r--. 1 nsoffer nsoffer 6.0G Nov 1 21:48 dst.img
1.2G -rw-r--r--. 1 nsoffer nsoffer 6.0G Nov 1 21:46 src.img
Picking a good value for -S is not easy. Testing show that 64k is best
value for this test image for limiting the number of requests:
$ for size in 4k 8k 16k 32k 64k; do \
printf "%5s: " $size; \
qemu-img convert -f raw -O raw -t none -T none -S $size src.img dst.img; \
qemu-img map -f raw --output json dst.img | wc -l; \
done
4k: 1443
8k: 731
16k: 521
32k: 387
64k: 213
We need more testing with oVirt to measure the performance improvement
and pick a good value. This should probably be an option, but lets start
with a minimal change.
(cherry picked from commit 2aa78ade2d48e926b7b04050338ebd8a0c5e3f05
in virt-v2v)
We were not considering failures while initializing the transfer. In
this case the transfer phase can change to PAUSED_SYSTEM or
FINISHED_FAILURE, and transfer_url will be None, which failed the
upload with a misleading error:
RuntimeError: direct upload to host not supported, requires
ovirt-engine >= 4.2 and only works when virt-v2v is run within the
oVirt/RHV environment, eg. on an oVirt node
Change the wait loop to consider all cases:
- Transfer failed and was removed
- Transfer failed and will be removed soon
- Transfer paused by the system (cancel required)
- Unexpected transfer phase (cancel required)
- Timeout waiting for TRANSFERRING state (cancel required)
Reported-by: Xiaodai Wang
(cherry picked from commit 40e1844827e4d096b1919a2159f9effc41915a73
in virt-v2v)
Checking status more frequently save a couple of seconds. Here is
an example flow tested with oVirt upload_disk.py example:
With 5 seconds wait:
Created disk in 11.085111 seconds
Created transfer in 1.857502 seconds
With 1 second wait:
Created disk in 4.991227 seconds
Created transfer in 1.961243 seconds
(cherry picked from commit 8816c5db220f518ef70beec7ac543290e3d5c0c7
in virt-v2v)
Check for the INITIALIZING state of the image transfer right away,
without waiting 5 seconds even before the first time: this way, if the
transfer is already in the right state then there is no need to wait.
In some cases we have observed the time taken for a Cinder volume to
attach to the conversion appliance can be longer than the current 60
seconds. Increase the timeout to 5 minutes.
Thanks: Ming Xie.
(cherry picked from commit e2ce290f6e366716f857eeaddc1dc680e5608c80
in virt-v2v)
The first split does not care about the whole string, it is just trying to get
the command name in front, so triml is just right.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Starting from libguestfs/virt-v2v 1.39.12, virt-v2v attempts to
uninstall the VMware tools from Windows guests, so there is no need to
remove them manually before the conversion.
Thanks to: Ming Xie.
(cherry picked from commit 397b4a90d16f4eb116d55605cbdf3bd844108315
in virt-v2v)
This way it is possible to specify the UUID of the LUKS device instead
of the libguestfs device name to decrypt a device during the inspection.
Make the usage of the new luks_uuid API conditional, so other projects
using the common submodule do not require a libguestfs version bump.
(cherry picked from commit bb4a2dc17a78b53437896d4215ae82df8e11b788
in libguestfs-common)
PT: the documentation was amended manually.
In the future it will be also something else other than the device name.
(cherry picked from commit c863ee5e1df5e1eca7ad6821bd2db3796277a6bd
in libguestfs-common)
PT: the documentation was amended manually.
This allows multiple --key parameters on the command line to match a
single device. For example:
tool --key /dev/sda1:key:trykey1 --key /dev/sda1:key:trykey2
would try "trykey1" and "trykey2" against /dev/sda1.
(cherry picked from commit c10c8baedb88e7c2988a01b70fc5f81fa8e4885c
in libguestfs-common)
Refactor this code to use guestfs_int_split_string function which
slightly simplifies it. This should have no effect.
(cherry picked from commit 530d0beef74d48617717463a5b585f21e2ed62be
in libguestfs-common)
Easily reproducible using:
$ guestfish --key dev1:key:key1 --key dev2:key:key2
causing this stack trace (or others depending on where the memory
corruption was caught):
Program received signal SIGABRT, Aborted.
0x00007ffff7905625 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff7905625 in raise () from /lib64/libc.so.6
#1 0x00007ffff78ee8d9 in abort () from /lib64/libc.so.6
#2 0x00007ffff79494af in __libc_message () from /lib64/libc.so.6
#3 0x00007ffff7950a6c in malloc_printerr () from /lib64/libc.so.6
#4 0x00007ffff79528d0 in _int_free () from /lib64/libc.so.6
#5 0x00005555555bdd6e in free_key_store ()
#6 0x0000555555589027 in main ()
(gdb) quit
(cherry picked from commit 8c42f772614b44a8cb974afa904ec9f518431ab2
in libguestfs-common)
For Linux the guest itself remembers the IP address associated with
each MAC address. Thus it doesn't matter if the interface type
changes (ie. to virtio-net), because as long as we preserve the MAC
address the guest will use the same IP address or the same DHCP
configuration.
However on Windows this association is not maintained by MAC address.
In fact the MAC address isn't saved anywhere in the guest registry.
(It seems instead this is likely done through PCI device type and
address which we don't record at the moment and is almost impossible
to preserve.) When a guest which doesn't use DHCP is migrated, the
guest sees the brand new virtio-net devices and doesn't know what to
do with them, and meanwhile the right static IPs are still associated
with the old and now-defunct interfaces in the registry.
We cannot collect the required information from within the guest.
However we can collect it outside the tool by some other means
(eg. using VMware Tools APIs) and present this information to virt-v2v
which then writes it into the Windows guest at firstboot time.
This commit adds the --mac ..:ip:.. sub-option which creates a
Powershell script to set network adapters at firstboot. An option
such as:
--mac 00:0c:29:e6:3d:9d:ip:192.168.0.89,192.168.0.1,24,192.168.0.254
approximately turns into this script:
# Wait for the netkvm (virtio-net) driver to become active.
$adapters = @()
While (-Not $adapters) {
Start-Sleep -Seconds 5
$adapters = Get-NetAdapter -Physical |
Where DriverFileName -eq "netkvm.sys"
}
$mac_address = '00-0c-29-e6-3d-9d'
$ifindex = (Get-NetAdapter -Physical |
Where MacAddress -eq $mac_address).ifIndex
if ($ifindex) {
New-NetIPAddress -InterfaceIndex $ifindex
-IPAddress '192.168.0.89'
-DefaultGateway '192.168.0.1'
-PrefixLength 24
Set-DnsClientServerAddress -InterfaceIndex $ifindex
-ServerAddresses ('192.168.0.254')
}
Thanks: Brett Thurber for diagnosing the problem and suggesting paths
towards a fix.
(cherry picked from commit dfd9fac743)
