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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
VMs converted by virt-v2v are pets not cattle so we want to create
permanent non-running machines. (They may later or even soon
afterwards be started up by some other tool, at which point they also
become Instances.) Therefore use a different kind and slightly
restructure the yaml around this.
Thanks: Lee Yarwood
Add various information which we have but cannot add to the Kubevirt
yaml in any other place.
Example output:
...
metadata:
name: fedora-39
labels:
libguestfs.org/virt-v2v-version: "2.5.4"
libguestfs.org/osinfo: fedora39
...
Thanks: Bella Khizgiyaev, Liran Rotenberg
Fixes: https://issues.redhat.com/browse/RHEL-45992
When converting this phony Windows guest we didn't set the VIRTIO_WIN
environment variable. As a result the test output could change (and
break) depending on if the virtio-win package was installed or not.
Point VIRTIO_WIN to the fake virtio-win directory (as we do with other
Windows tests). We also need to modify the test output since the fake
virtio-win does contain enough for virt-v2v to think that virtio
driver installation was successful.
Fixes: commit af1f7b571fb21fdbfa2974ee54a22b4fdcbc886a
The existing test used a phony Windows image, but this has some
shortcomings including not testing any virtio paths. Add a second
test of a phony Fedora image to get a little more coverage.
The old tests' network bridge had a bogus <mac address="00:00:00:00:00:00">.
Older libvirt appeared to drop this completely. Newer libvirt appears
to rewrite it as a valid MAC, eg. <mac address="52:54:00:xx:xx:xx">
(for some randomly chosen "xx"'s). To make the tests stable, replace
the old bogus value with a valid value, and update the tests to check
for it.
In the LUKS-on-LVM conversion test, repeat the null conversion with such
"--key" options that exercise the recent "/dev/mapper/VG-LV" ->
"/dev/VG/LV" translation (unescaping) from libguestfs-common.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168506
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20230515175529.290724-3-lersek@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
In preparation for a subsequent patch, rename "VG" to "Volume-Group", and
"LV<n>" to "Logical-Volume-<n>", in the LUKS-on-LVM conversion test.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168506
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20230515175529.290724-2-lersek@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
The test checks that the newly introduced --block-driver option doesn't
break conversion. Basically its logic somewhat repeats test-v2v-i-disk.sh
and test-v2v-in-place.sh, but with the new option being set.
The checks it performs are:
1. Run disk-sourced conversion (-i disk) based on the phony windows.img
and check that it completes (i.e. produces converted disk and
corresponding domain XML;
2. Run libvirt-sourced in-place conversion based on an XML with virtio
vda disk specified (virtio-blk case) and check that the resulting
image has the phony viostor driver installed.
3. Run libvirt-sourced in-place conversion based on an XML with scsi
sda disk specified (virtio-scsi case) and check that the resulting
image has the phony vioscsi driver installed.
Note that the latter 2 cases aren't really comprehensive as v2v actually
copies all the drivers present in $VIRTIO_WIN, regardless of the block
driver specified. The real difference comes from the PCI ID values written
into the registry. But since we can't test real Windows and evaluate
those values, we're doing the best we can here, i.e. testing that conversion
doesn't break and drivers are still present with --block-driver option
being set explicitly.
Signed-off-by: Andrey Drobyshev <andrey.drobyshev@virtuozzo.com>
Message-Id: <20230310175433.781335-7-andrey.drobyshev@virtuozzo.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In the case where the source hypervisor doesn't specify a CPU model,
previously we chose qemu64 (qemu's most basic model), except for a few
guests that we know won't work on qemu64, eg. RHEL 9 requires
x86_64-v2 where we use <cpu mode='host-model'/>
However we recently encountered an obscure KVM bug related to this
(https://bugzilla.redhat.com/show_bug.cgi?id=2168082). Windows 11
thinks the qemu64 CPU model when booted on real AMD Milan is an AMD
Phenom and tried to apply an ancient erratum to it. Since KVM didn't
emulate the correct MSRs for this it caused the guest to fail to boot.
After discussion upstream we can't see any reason not to give all
guests host-model. This should fix the bug above and also generally
improve performance by allowing the guest to exploit all host
features.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=2168082#c19
Related: https://listman.redhat.com/archives/libguestfs/2023-February/030624.html
Thanks: Laszlo Ersek, Dr. David Alan Gilbert, Daniel Berrangé
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
"windows.img" is created as an empty phony image if the libguestfs
appliance lacks the ntfs feature group.
"tests/Makefile.am" deals well with this, because for the "central"
"windows.vmdk" target, we restrict the VMDK conversion to a non-empty
"windows.img". Subsequently, dependent test cases check for "windows.vmdk"
specifically, and if that file is missing, the tests are skipped (they
exit with code 77).
"test-v2v-i-ova.sh" and "test-v2v-i-ova-directory.sh" are exceptions
however. They perform the same conversion manually (in their own separate
workspace directories). They assume that, if "windows.img" exists, it can
be converted to VMDK. When the image size is zero, the conversion breaks,
and both test cases fail. Skip both tests if "windows.img" is empty.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Richard W.M. Jones <rjones@redhat.com>
[lersek@redhat.com: replace further occurrences of windows.img with $f]
In case the libguestfs appliance lacks the btrfs feature group, we create
a zero-sized phony Fedora/BTRFS image variant, causing this test case to
fail. In that situation, the test should just be skipped.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Richard W.M. Jones <rjones@redhat.com>
Test Fedora 37 (up from 35) and RHEL 8.7 (up from 8.4). In particular
the virt-builder RHEL 8.4 template's repository URLs no longer work so
it could not be tested.
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>
This only tests that it doesn't completely fail, which it did before
we fixed nbdcopy. I checked the file sizes manually and with
compression the resulting file is about half the size.
This test is a clone of tests/test-v2v-of-option.sh. In order to
compare the sizes across the two tests, and to keep the tests fairly
similar I added an ls -l command to the original test.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Port guestfs-tools commit 27da4b0c4991 ("inspector: add LUKS-on-LVM test",
2022-02-28) to virt-v2v. While at it, account for virt-v2v commit
fd7cd0c0fd22 ("test-data/phony-guests: Increase size of root filesystem",
2022-06-08).
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220614112709.12210-4-lersek@redhat.com>
Acked-by: Richard W.M. Jones <rjones@redhat.com>
Clarify that our current usage of "luks" stands for "lvm-on-luks" (IOW,
that the decrypted LUKS devices are Physical Volumes for LVM).
(This is a port of libguestfs patch 'tests: rename "luks" to
"lvm-on-luks"' -- commit 39a5bb6fda4d. See also guestfs-tools commit
8f2bbc3d50d8 -- 'inspector: rename "luks" to "lvm-on-luks"', 2022-02-28.)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220614112709.12210-3-lersek@redhat.com>
Acked-by: Richard W.M. Jones <rjones@redhat.com>
The intent (even before RHBZ#2028764) has been to install the QEMU guest
agent in the converted domain unconditionally. Therefore, in order for the
GA to be actually accessible from the host side, augment the libvirt
output module with a "guest agent connection" also unconditionally.
For starters, the domain needs a virtio-serial device. Then there must be
a port on the device that (in the guest) the GA identifies by name, and
that (on the host) is exposed as a listening socket (usually in the unix
address family). The adress of that port (usually a pathname, i.e., for a
unix domain socket) is then passed to whatever host-side application wants
to talk to the GA.
The minimal domain XML fragment for that ("minimal" for our purposes) is
<controller type='virtio-serial' model='virtio'>
<channel type='unix'>
<target type='virtio' name='org.qemu.guest_agent.0'/>
</channel>
The "controller" element is needed because "controller/@model" is where we
regulate "virtio" vs. "virtio-transitional".
Everything else is filled in by libvirt. Notably, libvirt (a) creates and
binds the unix domain socket itself (usually
"/var/lib/libvirt/qemu/channel/target/DOMAIN/org.qemu.guest_agent.0"), (b)
passes the file descriptor to QEMU, and (c) figures out the socket
pathname for commands such as
virsh domfsinfo DOMAIN
virsh domhostname DOMAIN --source agent
virsh domifaddr DOMAIN --source agent
virsh guestinfo DOMAIN
For QEMU, the corresponding options would be
-chardev socket,id=agent,server=on,wait=off,path=/tmp/DOMAIN-agent \
-device virtio-serial-pci,id=vioserial \
-device virtserialport,bus=vioserial.0,nr=1,chardev=agent,name=org.qemu.guest_agent.0 \
Note the "path=/tmp/DOMAIN-agent" property of "-chardev"; virt-v2v would
have to generate that (in place of the "fd=nnnn" property that libvirt
passes to QEMU).
Omit extending the QEMU output module for now, as the QGA protocol is
based on JSON, and one needs "virsh" or "virt-manager" (or another
management application interface) anyway, for efficiently exchanging
messages with QGA. I don't know of end-user tools that directly connect to
"/tmp/DOMAIN-agent".
Don't modify the RHV and OpenStack outputs either; both of these
management products likely configure the virtio-serial device
automatically, for the agent access.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2028764
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220613170135.12557-2-lersek@redhat.com>
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
As well as testing a full Fedora conversion which was not really
tested properly before, this also adds tests of conversions of Btrfs,
RAID and LUKS guests.
Remove "--selinux-relabel" options.
Do not add any "--no-selinux-relabel" options; rely on the internal check
for SELinux support instead ("is_selinux_guest" in
"common/mlcustomize/SELinux_relabel.ml").
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1554735
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2075718
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220510105307.15402-1-lersek@redhat.com>
Acked-by: Richard W.M. Jones <rjones@redhat.com>
[lersek@redhat.com: incorporate common submodule update]
oVirt API call for VM creation finishes before the VM is actually
created. Entities may be still locked after virt-v2v terminates and if
user tries to perform (scripted) actions after virt-v2v those operations
may fail. To prevent this it is useful to monitor the task and wait for
the completion. This will also help to prevent some corner case
scenarios (that would be difficult to debug) when the VM creation job
fails after virt-v2v already termintates with success.
Thanks: Nir Soffer
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1985827
Signed-off-by: Tomáš Golembiovský <tgolembi@redhat.com>
Reviewed-by: Arik Hadas <ahadas@redhat.com>
Reviewed-by: Nir Soffer <nsoffer@redhat.com>
We model NVMe devices in the source hypervisor.
We currently assume that no one is using the namespaces feature of
NVMe, ie. that each source device will appear in a Linux guest as
/dev/nvme0n1, /dev/nvme1n1, etc. We could fix this if it is a
problem, but it requires adjusting the current assumption for
removable devices that slots are simple integers.
The devices are mapped to virtio-blk, so in the target the device name
has to change from /dev/nvme0 to /dev/vda (etc.)
Reported-by: Ming Xie
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2070530
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.
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
Life would be too simple if we could just call osinfo_os_get_all_devices()
for determining virtio-1.0 support for Windows guests. Now that we've
extracted the libosinfo logic that identifies the "best" virtio driver
(for copying its files into the guest), fetch the list of devices
supported by the same "best driver" as well. Use that list, in addition to
the one from osinfo_os_get_all_devices(), for determining (Q35 and)
virtio-1.0 support.
Thankfully this mess is not needed when converting Linux guests.
With this, we need to revert the data for three Windows-based test cases
to their pre-f0cea012d018 status (modulo intermediary commits 4f6b143c1cb3
("output: -o libvirt, qemu: Use correct device name for vsock",
2022-01-20) and 4c3d0b8b3b4b ("output: -o libvirt: Fix <graphics/> element
port/autoport", 2022-01-20)). The reason is that those tests all set the
VIRTIO_WIN environment variable, in which case we simply assume
"virtio_1_0 = true" on the fallback ("Not_found" exception) branch.
Fixes: f0cea012d0183edf6f7b769c28d5038593f3fe6a
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2043333
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220201123219.9317-8-lersek@redhat.com>
Acked-by: Richard W.M. Jones <rjones@redhat.com>
Old virt-v2v used the same output format as input format when doing
disk to disk copies. Modular virt-v2v doesn't do this, it requires
using -of to set the output format to the same as the input format if
that is desired.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The error was:
virt-builder: error: cannot use ‘--update’ because no package manager
has been detected for this guest OS.
If this guest OS is a common one with ordinary package management then this
may have been caused by a failure of libguestfs inspection.
For OSes such as Windows that lack package management, this is not
possible. Try using one of the ‘--firstboot*’ flags instead (described
in the manual).
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Let's try to test only the latest versions of RHEL that we have in the
internal (to Red Hat) virt-builder repository.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[Laszlo reviewed an earlier version of this patch. I updated it with
a more consistent rationale and list of RHEL versions]
Ubuntu 14.04 failed in the --update command. These versions are out
of standard support (5 years) so drop them from testing. Add Ubuntu 20.04.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The image cannot be updated, see error below. In any case we are
testing a RHEL 6 image so it is not really necessary to continue to
test CentOS 6.
Loaded plugins: fastestmirror, security
Setting up Update Process
Error: Cannot retrieve repository metadata (repomd.xml) for repository: base. Please verify its path and try again
YumRepo Error: All mirror URLs are not using ftp, http[s] or file.
Eg. Invalid release/repo/arch combination/
removing mirrorlist with no valid mirrors: /var/cache/yum/x86_64/6/base/mirrorlist.txt
virt-builder: error: yum -y update: command exited with an error
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
For very old Fedora versions, it's no longer possible to download the
packages (required by virt-builder --update). We get this error:
Error: Cannot retrieve metalink for repository: fedora/20/x86_64. Please verify its path and try again
I also dropped Fedora 23 and 29. Although those can be updated, it's
not really worth testing long-obsolete versions of Fedora. More
useful is testing the long-term stable equivalents (ie. CentOS and
RHEL).
I did however add the current version of Fedora (35) because it's
worth testing that current Fedora conversions work.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
According to https://libvirt.org/formatdomain.html#vsock it's <vsock/>
not <viosock/>. There is also no model="none", we just omit it if not
present.
According to https://wiki.qemu.org/Features/VirtioVsock the qemu
parameter is -device vhost-vsock-pci.
Fixes: 05f780c16f0135c657615520c2245b42de1efc3e
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
According to https://libvirt.org/formatdomain.html only vnc and sdl
graphics types support port/autoport.
In addition, autoport='yes' is the non-deprecated replacement for
port='-1'. Since we don't need to support ancient libvirt, we don't
need to keep adding port='-1' in the autoport case. virt-xml-validate
rejects our XML if it has both attributes.
Thanks: Martin Kletzander
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Old virt-v2v would print a summary of the input and output options
before connecting to the input/output, looking something like this:
[ 0.2] Opening the source -i libvirt -ic [etc]
This gave reassurance that virt-v2v was doing something in the case
where the source was slow or unreachable. In particular if you use
-i libvirt with a vCenter URL, and the URL is wrong, libvirt hangs for
a few minutes without printing anything.
Modular virt-v2v rearranged things so the connecting phase was silent,
which meant that in the case above virt-v2v appeared to hang for a few
minutes printing nothing at all.
This change adds to_string functions to all the input and output
methods and uses them to print a message like:
[ 0.0] Setting up the source: -i libvirt -ic [etc]
The hang still happens, but at least it's now clear where it's hanging.
Note the old "Opening the source" message now refers to libguestfs
connecting to the NBD source disk pipeline.
Typical full output looks like this:
$ virt-v2v -i disk /var/tmp/fedora-35.img -o disk -os /var/tmp/out
[ 0.0] Setting up the source: -i disk /var/tmp/fedora-35.img
[ 1.1] Opening the source
[ 5.9] Inspecting the source
[ 11.5] Checking for sufficient free disk space in the guest
[ 11.5] Converting Fedora Linux 35 (Thirty Five) to run on KVM
virt-v2v: warning: /files/boot/grub2/device.map/hd0 references unknown
device "vda". You may have to fix this entry manually after conversion.
virt-v2v: This guest has virtio drivers installed.
[ 57.4] Mapping filesystem data to avoid copying unused and blank areas
[ 61.0] Closing the overlay
[ 61.7] Assigning disks to buses
[ 61.7] Checking if the guest needs BIOS or UEFI to boot
[ 61.7] Setting up the destination: -o disk -os /var/tmp/out
[ 62.8] Copying disk 1/1
█ 100% [****************************************]
[ 81.7] Creating output metadata
[ 81.7] Finishing off
Reported-by: Xiaodai Wang
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2041886
Fixes: commit 255722cbf39afc0b012e2ac00d16fa6ba2f8c21f
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Determine the machine type and virtio-1.0 support from osinfo, for x86
guests. This connects the previous two parts of this series.
Keep the original logic from commit ac39fa292c31 ("v2v: Set machine type
explicitly for outputs which support it (RHBZ#1581428).", 2020-12-04) for
non-x86 guests, and for the case when libosinfo does not recognize the
guest OS.
Update the "cdrom", "floppy", and "i-ova" test cases, which all use a
(phony) Windows 7 image -- Windows 7 does not support virtio-1.0-only
devices, according to libosinfo.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1942325
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20220106140910.13695-10-lersek@redhat.com>
Acked-by: Richard W.M. Jones <rjones@redhat.com>
Nir reports that, despite the comment we removed in commit a2a4f7a09996,
we generally cannot access the output NBD servers in the finalization
stage. In particular, in the "rhv_upload_finalize" function
[output/output_rhv_upload.ml], the output disks are disconnected before
"create_ovf" is called.
Consequently, the "get_disk_allocated" call in the "create_ovf" ->
"add_disks" -> "get_disk_allocated" chain fails.
Rich suggests that we explicitly restrict the "get_disk_allocated" call
with a new optional boolean parameter to the one output plugin that really
needs it, namely the old RHV one.
Accordingly, revert the VDSM test case to its state at (a2a4f7a09996^).
Cc: Nir Soffer <nsoffer@redhat.com>
Fixes: a2a4f7a09996a5e66d027d0d9692e083eb0a8128
Reported-by: Nir Soffer <nsoffer@redhat.com>
Suggested-by: Richard W.M. Jones <rjones@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2034240
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20211220135640.12436-1-lersek@redhat.com>
Tested-by: Nir Soffer <nsoffer@redhat.com>
[lersek@redhat.com: drop parens around condition in "if"; thanks: Rich]
Reviewed-by: Richard W.M. Jones <rjones@redhat.com>
If the only CD-ROM in "s_removables" is on an IDE controller, and the
guest kernel represents it with a /dev/hdX device node, then convert
references to this device node, in the boot config files, to /dev/cdrom.
On the destination (after conversion), /dev/cdrom will point to whataver
node we converted the CD-ROM to, masking a potential i440fx -> q35 (IDE ->
SATA) board change.
If the only CD-ROM is not on an IDE controller, or the guest is modern
enough to represent the IDE CD-ROM as /dev/sr0, then perform no
translation. Namely, /dev/sr0 survives a potential i440fx -> q35 (IDE ->
SATA) board change intact.
When multiple CD-ROMs exist, emit a warning, and attempt the conversion on
the first CD-ROM, as a guess. This may be inexact, but we can't do better,
because:
- SATA, SCSI, and (on modern guests) IDE CD-ROMs are lumped together in
the /dev/sr* namespace, on the source side, and "s_removable_slot" is
useless for telling them apart, as we don't know the exact controller
topology (and OS enumeration order);
- after conversion: some OSes don't create /dev/cdrom* symlinks to all
CD-ROMs, and even if multiple such symlinks are created, their order is
basically random.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1637857
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20211215153153.13468-1-lersek@redhat.com>
Acked-by: Richard W.M. Jones <rjones@redhat.com>
