Since RHEV 3.3, OS variant names like "RHEL6x64" were deprecated and
replaced by names like "rhel_6x64". "RHEL7x64" was never valid, and
we should have used "rhel_7x64". "Windows2012R2x64" was also never
valid and should have been "windows_2012R2x64".
For backwards compatibility, RHEV still understands the old names, and
we still pass them for compatiblity with old RHEV.
However for the new OS variants supported by virt-v2v in RHEL 7.2, use
the new names.
This commit also adds support for SLES and ppc64.
This updates commit 3c51302d69
and also RHBZ#1213324.
This is for consistency with the rest of the documentation.
This commit also adds the files to EXTRA_DIST so they are shipped in
the tarball.
This updates commit 4e4ece5364.
The old version of virt-p2v had a whole custom-written dialog which
interacted with NetworkManager over dbus. After trying that approach,
it's really complex to get right.
Instead this button simply opens NetworkManager's connection editor.
This also adds nm-applet to the disk and starts it. However nm-applet
does not display any visible indication -- probably because we are
lacking a system tray.
Matchbox only supports a single window on screen. This worked fine
until we added the NetworkManager connection dialog -- which tries to
open in a new top level window, and of course fails.
Metacity supports multiple top-level windows so doesn't suffer this
problem.
Apart from that it's hard to tell the difference between the two.
Display a warning if the number of vCPUs or memory selected in the GUI
would be larger than the limits currently supported on RHEL 6 and RHEL 7.
This is just a warning -- the user is free to ignore it and continue
anyway.
This warning does not apply if the selections were made through the
kernel command line, because there is no place to display the warning
for automated conversions.
Add the Types.target_firmware type, which stores our final decision
for whether the guest requires BIOS or UEFI on the target.
Not all output modes support UEFI. In order to fail as early as
possible if conversion isn't going to be possible, there is an
output#supported_firmware method which returns the list of supported
target_firmware.
Add the target_firmware parameter to output#create_metadata so it can
select the correct firmware in the final metadata.
Use a heuristic to detect if the guest could boot with UEFI.
This is only used where we have missing metadata (in the
source.s_firmware == UnknownFirmware case). Currently that only
applies for `-i disk' and `-i libvirt/libvirtxml'.
Eventually we'll be able to get this information from the libvirt
metadata (RHBZ#1217444), so it'll only be used for `-i disk'.
Also modify the input_* drivers so they pull out the firmware from the
metadata. Currently this is only possible for `-i ova', since libvirt
does not expose it (RHBZ#1217444).
Old virt-v2v had a bunch of code for removing EFI configuration from a
Linux guest, and replacing it with grub. I copied this code to new
virt-v2v but it was never tested.
Now that OVMF exists, we can simply boot EFI guests directly on KVM.
Thus these hacks can finally be removed.
This test fails on recent kernels, sometimes.
Apparently calling 'fusermount -u mp' can exit with an EBUSY error,
but still unmount the filesystem. Or possibly guestmount crashes
coincidentally. It's impossible to debug because debugging tools like
strace prevent fuse from working at all.
guestunmount had a -v / --verbose option, but it didn't change the
behaviour of the program in any way.
Make it print the invocations of the underlying fusermount program.
