Bug 1494555

Created attachment 1330592 [details]
0001-v2v-linux-Fix-uninstallation-of-kmod-xenpv-from-etc-.patch

Created attachment 1330593 [details]
0002-v2v-linux-Fix-rewriting-of-grub2-GRUB_CMDLINE-.resum.patch

Created attachment 1330594 [details]
0003-v2v-linux-Properly-ignore-rpm-dpkg-move-aside-kernel.patch

Attached are the three patches, backported to the rhel-7.5
branch.  Instead of backporting the whole of PCRE, I have tried
to fix the Str regexps.

Note that the cherry-pick commit references are likely wrong
because these patches are not upstream and so don't have fixed
git commit hashes yet.

Patches 0001, and 0002 LGTM to me -- please push them to the rhel-7.5 branch.
Regarding patch 0003, the upstream commit d279d602bee77e469c613ae45e591441f834060e can be cherry-picked directly instead.

The three fixes are included in libguestfs 1.36.7, which we will pick with the rebase (bug 1472272).

For patch 1 "v2v: linux: Fix uninstallation of kmod-xenpv from /etc/rc.local script.
"

Try to reproduce the problem with builds:
virt-v2v-1.36.6-2.el7.x86_64
libguestfs-1.36.6-2.el7.x86_64

Steps:
1.Install kmod-xenpv package for xen-hvm-rhel5.11-x86_64 guest on rhel5 xen server
# rpm -q kmod-xenpv
kmod-xenpv-0.1-9.el5

2.Add below command to /etc/rc.local in guest
#cat /etc/rc.local 
....
touch /var/lock/subsys/local
insmod /lib/modules/2.6.18-398.el5/kernel/drivers/xenpv_hvm/blkfront/xen-vbd.ko

insmod /lib/modules/2.6.18-92.el5/extra/xenpv/0.1-9.el5/blkfront/xen-vbd.ko 

3.Use virt-v2v to convert above guest from xen server, there is no warning/error during conversion
# virt-v2v -ic xen+ssh://root.3.21 xen-hvm-rhel5.11-x86_64 -on xen-hvm-rhel5.11-x86_64-old -of raw
[   0.1] Opening the source -i libvirt -ic xen+ssh://root.3.21 xen-hvm-rhel5.11-x86_64
[   0.8] Creating an overlay to protect the source from being modified
[   1.5] Initializing the target -o libvirt -os default
[   1.5] Opening the overlay
[   4.7] Inspecting the overlay
[  24.0] Checking for sufficient free disk space in the guest
[  24.0] Estimating space required on target for each disk
[  24.0] Converting Red Hat Enterprise Linux Server release 5.11 (Tikanga) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 309.4] Mapping filesystem data to avoid copying unused and blank areas
[ 310.3] Closing the overlay
[ 310.5] Checking if the guest needs BIOS or UEFI to boot
[ 310.5] Assigning disks to buses
[ 310.5] Copying disk 1/1 to /var/lib/libvirt/images/xen-hvm-rhel5.11-x86_64-old-sda (raw)
    (100.00/100%)
[2169.5] Creating output metadata
Pool default refreshed

Domain xen-hvm-rhel5.11-x86_64-old defined from /tmp/v2vlibvirt3020a8.xml

[2169.6] Finishing off

4.Check the guest and find kmod-xenpv is uninstalled but command about insmod xen-vbd is not disabled in /etc/rc.local
# rpm -q kmod-xenpv
package kmod-xenpv is not installed

#cat /etc/rc.local 
.....
touch /var/lock/subsys/local
insmod /lib/modules/2.6.18-398.el5/kernel/drivers/xenpv_hvm/blkfront/xen-vbd.ko

insmod /lib/modules/2.6.18-92.el5/extra/xenpv/0.1-9.el5/blkfront/xen-vbd.ko 



Update virt-v2v/libguestfs to below builds to verify this problem
virt-v2v-1.36.7-1.el7.x86_64
libguestfs-1.36.7-1.el7.x86_64

After doing step1 to step3,check the guest and find that kmod-xenpv is uninstalled and command about insmod xen-vbd could be disabled in /etc/rc.local after v2v conversion
# rpm -q kmod-xenpv
package kmod-xenpv is not installed

#cat /etc/rc.local 
.....
touch /var/lock/subsys/local
#insmod /lib/modules/2.6.18-398.el5/kernel/drivers/xenpv_hvm/blkfront/xen-vbd.ko

#insmod /lib/modules/2.6.18-92.el5/extra/xenpv/0.1-9.el5/blkfront/xen-vbd.ko 


Addtional info:
1.Also verify problem on xen guests "xen-hvm-rhel5.11-i386"  and xen-pv-rhel5.11-x86_64, have same verify result with above
2.Verify the problem on vmware rhel5 guest, kmod-xenpv could be uninstalled and command about insmod xen-vbd could be disabled in /etc/rc.local  after v2v conversion with virt-v2v-1.36.7-1.el7.x86_64


Hi rjones, could you please help to check if above steps is enough to verify the patch? And do you think whether a v2v warning about xen-vbd is needed during conversion ?

The verification is correct.

I don't understand the comment about a warning.  Do you mean there
is a warning or there should be a warning?  I don't think there should
be any warning.

(In reply to Richard W.M. Jones from comment #10)
> The verification is correct.
> 
> I don't understand the comment about a warning.  Do you mean there
> is a warning or there should be a warning?  I don't think there should
> be any warning.

OK,get it,a warning I thought before was reminding customer "the command "insmod|modprobe /lib/modules/.../xen-vbd.ko has been disabled in /etc/rc.local"

We don't need to warn about normal conditions, so I think it's fine.

For second patch:v2v: linux: Fix rewriting of grub2 GRUB_CMDLINE=...resume=<device>...

-------------------------------------------------------------------------------
Try to reproduce the problem with builds:
virt-v2v-1.36.3-6.el7.x86_64
libguestfs-1.36.3-6.el7.x86_64

Steps:
For rhel6 guest:
1.1 Prepare a rhel6 guest and check its swap partition info
# cat /etc/fstab
....
/dev/sda2        	swap            	swap    defaults        0 0
...

1.2 Edit /boot/grub/grub.conf and add resume=<device> info 
#vi /boot/grub/grub.cfg
.... 
title Red Hat Enterprise Linux 6 (2.6.32-696.el6.x86_64)
        root (hd0,0)
        kernel /boot/vmlinuz-2.6.32-696.el6.x86_64 ro resume=/dev/sda2 root=UUID=e8cb7fcd-2b75-4f57-afd9-4755ed2aa241 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet
....

1.3 Use virt-v2v to convert this guest to rhv and check the resume=<device> in grub.cfg after finishing conversion
#cat /boot/grub/grub.cfg
.... 
title Red Hat Enterprise Linux 6 (2.6.32-696.el6.x86_64)
        root (hd0,0)
        kernel /boot/vmlinuz-2.6.32-696.el6.x86_64 ro resume=/dev/vda2 root=UUID=e8cb7fcd-2b75-4f57-afd9-4755ed2aa241 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet

* Result:
  Resume=/dev/sdaX could be updated to resume=/dev/vdaX in rhel6 grub file successfully after v2v conversion

For rhel7 guest:
2.1 Prepare a rhel7 guest which has swap partition and swap file
    # cat /etc/fstab
   ....
   /dev/sda2    swap swap    defaults   0 0
   /swapfile    swap swap    sw    0 0
   ....

2.2 Add some resume info into /etc/default/grub and do not add any content about resume=<device> in /etc/grub2.cfg and /boot/grub2/grub.cfg
    #vi /etc/default/grub
    ....
    GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sda2 resume=d975bf61-1876-4c2f-8926-0470bb3dfdf5 resume=/swapfile resume=/dev/X resume=/dev/"
   
    #cat /boot/grub2/grub.cfg
    ....
    linux16 /boot/vmlinuz-3.10.0-693.el7.x86_64 root=UUID=bd8e3cbd-91c5-4f88-89e5-7a12a2904a07 ro crashkernel=auto rhgb quiet
    ....
   
2.3 Use v2v to convert the guest to rhv and there is no error during conversion

2.4 Check /boot/grub2/grub.cfg in guest at rhv after finishing conversion, related resume=<device> info will be added to grub file
    # cat /boot/grub2/grub.cfg
    .....
      linux16 /boot/vmlinuz-3.10.0-693.el7.x86_64 root=UUID=bd8e3cbd-91c5-4f88-89e5-7a12a2904a07 ro crashkernel=auto rhgb quiet resume=/dev/sda2 resume=d975bf61-1876-4c2f-8926-0470bb3dfdf5 resume=/swapfile resume=/dev/X resume=/dev/
    ....

   * Result:
     Resume=/dev/sdaX can't be updated to resume=/dev/vdaX in rhel7 grub file after v2v conversion

--------------------------------------------------------------------------------
Verify the problem with builds:
virt-v2v-1.36.10-2.el7.x86_64
libguestfs-1.36.10-2.el7.x86_64
libvirt-3.9.0-3.el7.x86_64
qemu-kvm-rhev-2.10.0-9.el7.x86_64

Steps:
For rhel6 guest:
1. Convert the same rhel6 guest with above step 1.1 to rhv by virt-v2v

* Result:
  Resume=/dev/sdaX could be updated to resume=/dev/vdaX in rhel6 grub file successfully after v2v conversion

For rhel7 guest:
2. Convert the same rhel7 guest with above step 2.1 to rhv by virt-v2v and there is no error during conversion
  # virt-v2v resume-rhel7-99 -o rhv -os 10.73.131.93:/home/nfs_export
[   0.0] Opening the source -i libvirt resume-rhel7-99
[   0.0] Creating an overlay to protect the source from being modified
[   0.2] Initializing the target -o rhv -os 10.73.131.93:/home/nfs_export
[   0.3] Opening the overlay
[   1.2] Inspecting the overlay
[  12.1] Checking for sufficient free disk space in the guest
[  12.1] Estimating space required on target for each disk
[  12.1] Converting Red Hat Enterprise Linux Server 7.4 (Maipo) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[  58.6] Mapping filesystem data to avoid copying unused and blank areas
[  58.6] Closing the overlay
[  58.7] Checking if the guest needs BIOS or UEFI to boot
[  58.7] Assigning disks to buses
[  58.7] Copying disk 1/1 to /tmp/v2v.lxrCbb/bdf9c90b-e6f0-439c-aa9f-6305fd5fad7e/images/a38b0ff2-d1b5-451a-96e1-ce3ad6602ccf/90ed92e6-e38c-4865-9122-e09f6ca9651a (qcow2)
    (100.00/100%)
[  97.6] Creating output metadata
[  97.7] Finishing off


* Result:
  Resume=/dev/sdaX also can't be updated to resume=/dev/vdaX in rhel7 grub file after v2v conversion, details pls refer to v2v log"virt-v2v-resume-sda.log"

--------------------------------------------------------------------------------
Additional problem:v2v will not give a warning about the bogus "/dev/X" entry

For rhel7 guest:
 1.1 Only add invaild resume=<device> (such as:resume=/dev/X) into /etc/default/grub in rhel7 guest
    #vi /etc/default/grub
    ....
    GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/X"

 1.2 Use v2v to convert this guest, there is no any warning during conversion
# virt-v2v resume-rhel7-99 -o rhv -os 10.73.131.93:/home/nfs_export
[   0.0] Opening the source -i libvirt resume-rhel7-99
[   0.0] Creating an overlay to protect the source from being modified
[   1.1] Initializing the target -o rhv -os 10.73.131.93:/home/nfs_export
[   1.7] Opening the overlay
[  25.8] Inspecting the overlay
[  51.8] Checking for sufficient free disk space in the guest
[  51.8] Estimating space required on target for each disk
[  51.8] Converting Red Hat Enterprise Linux Server 7.4 (Maipo) to run on KVM
virt-v2v: This guest has virtio drivers installed.
[ 102.6] Mapping filesystem data to avoid copying unused and blank areas
[ 102.6] Closing the overlay
[ 102.7] Checking if the guest needs BIOS or UEFI to boot
[ 102.7] Assigning disks to buses
[ 102.7] Copying disk 1/1 to /tmp/v2v.uq4n4F/bdf9c90b-e6f0-439c-aa9f-6305fd5fad7e/images/a7b4403a-6633-4f1a-af00-7ab40259442a/b5230c68-50eb-4823-b2a3-8da7bcfeee30 (qcow2)
    (100.00/100%)
[ 173.9] Creating output metadata
[ 173.9] Finishing off
3.Check /boot/grub2/grub.cfg in guest at rhv after finishing conversion, resume=/dev/X will be added in grub file

For rhel6 guest:
 2.1 Add invaild resume=<device> (such as:resume=/dev/X) into /boot/grub/grub.conf in rhel6 guest 
#vi /boot/grub/grub.cfg
.... 
title Red Hat Enterprise Linux 6 (2.6.32-696.el6.x86_64)
        root (hd0,0)
        kernel /boot/vmlinuz-2.6.32-696.el6.x86_64 ro resume=/dev/X root=UUID=e8cb7fcd-2b75-4f57-afd9-4755ed2aa241 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=128M  KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet

 2.2 Use v2v to convert this guest, there is no any warning during conversion but converted guest can't boot into os due to kernel panic 
  
--------------------------------------------------------------------------------

Hi rjones,
  Both old v2v builds and latest v2v builds can't update resume=/dev/sdaX to resume=/dev/vdaX in rhel7 grub file after finishing conversion, please refer to details v2v log,besides,for above addtional problem "v2v will not give a warning about the bogus "/dev/X" entry", do I need to file another bug to strack this problem?

Created attachment 1360244 [details]
virt-v2v-resume-sda-rhel7.log

That's approximately the reverse of what I was expecting.  Will
need to take a closer look at this next week.

For patch3:v2v: linux: Properly ignore rpm/dpkg-move-aside kernels.


Due to Pino said patch3 is in a code specific for grub2,use rhel7 guest to test this patch


Reproduce this patch with below builds:
virt-v2v-1.36.3-6.el7.x86_64
libguestfs-1.36.3-6.el7.x86_64


Verify the patch with below builds:
virt-v2v-1.36.10-3.el7.x86_64
libguestfs-1.36.10-3.el7.x86_64


Steps:
Sceanrio1：
1.In rhel7 guest, copy vmlinuz-3.10.0-693.el7.x86_64 as vmlinuz-3.10.0-693.el7.x86_64.rpmsave in /boot.Original guest could reboot normally after copying
#ls /boot
....
vmlinuz-3.10.0-693.el7.x86_64
vmlinuz-3.10.0-693.el7.x86_64.rpmsave

2.Do not edit grub.conf in guest
#cat /boot/grub/grub.conf
....
linux16 /vmlinuz-3.10.0-693.el7.x86_64 root=/dev/mapper/rhel-root ro crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet LANG=en_US.UTF-8
....

Result1:
1.1 Use old v2v(1.36.3-6) to convert the guest, the conversion could be finished without error
1.2 Use new v2v(1.36.10-3) to convert the guest, the conversion could be finished without error


Sceanrio2：
1.In rhel7 guest, copy vmlinuz-3.10.0-693.el7.x86_64 as vmlinuz-3.10.0-693.el7.x86_64.rpmsave in /boot.
#ls /boot
....
vmlinuz-3.10.0-693.el7.x86_64
vmlinuz-3.10.0-693.el7.x86_64.rpmsave

2.Edit grub.conf in guest to make vmlinuz-*.rpmsave as boot image, original guest could reboot normally after editing
#cat /boot/grub/grub.conf
....
linux16 /vmlinuz-3.10.0-693.el7.x86_64.rpmsave root=/dev/mapper/rhel-root ro crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet LANG=en_US.UTF-8
....

Result2:
2.1 Use old v2v(1.36.3-6) to convert the guest, the conversion could be finished without error and vmlinuz file will be corrected as vmlinuz-3.10.0-693.el7.x86_64 in grub.cfg in converted guest
2.2 Use new v2v(1.36.10-3) to convert the guest,the conversion could be finished without error and vmlinuz file will be corrected as vmlinuz-3.10.0-693.el7.x86_64 in grub.cfg in converted guest


Sceanrio3：
1.In rhel7 guest, copy vmlinuz-3.10.0-693.el7.x86_64 as vmlinuz-3.10.0-693.el7.x86_64.rpmsave in /boot and delete original vmlinuz file
#ls /boot
....
vmlinuz-3.10.0-693.el7.x86_64.rpmsave

2.Edit grub.conf in guest to make vmlinuz-*.rpmsave as boot image, original guest could reboot normally after editing
#cat /boot/grub/grub.conf
....
linux16 /vmlinuz-3.10.0-693.el7.x86_64.rpmsave root=/dev/mapper/rhel-root ro crashkernel=auto rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet LANG=en_US.UTF-8
....
 
Result3:
3.1 Use old v2v(1.36.3-6) to convert the guest, the conversion will be failed with virt-v2v:error:no installed kernel packages were found.
3.2 Use new v2v(1.36.10-3) to convert the guest,the conversion will be failed with virt-v2v:error:no installed kernel packages were found


Due to can't find the difference between old v2v builds and new v2v builds for testing patch3 from above result and rjones suggest to see a difference in the debug output. so compare the debug outputs of old v2v and new v2v for scenario2's result and find two difference:

Difference1:the debug output of new v2v has below part but debug log of old v2v doesn't have:
....
libguestfs: trace: v2v: find "/boot"
libguestfs: trace: v2v: find0 "/boot" "/tmp/libguestfsm0d8C9/find4.txt"
guestfsd: main_loop: new request, len 0x34
find /sysroot/boot -print0
libguestfs: trace: v2v: find0 = 0
libguestfs: trace: v2v: find = ["/.vmlinuz-3.10.0-693.el7.x86_64.hmac", "/System.map-3.10.0-693.el7.x86_64", "/config-3.10.0-693.el7.x86_64", "/efi", "/efi/EFI", "/efi/EFI/redhat", "/grub2", "/grub2/device.map", "/grub2/fonts", "/grub2/fonts/unicode.pf2", "/grub2/grub.cfg", "/grub2/grubenv", "/grub2/i386-pc", "/grub2/i386-pc/acpi.mod", "/grub2/i386-pc/adler32.mod", "/grub2/i386-pc/affs.mod", "/grub2/i386-pc/afs.mod", "/grub2/i386-pc/ahci.mod", "/grub2/i386-pc/all_video.mod"
.......
/grub2/locale/uk.mo", "/grub2/locale/vi.mo", "/grub2/locale/zh_CN.mo", "/grub2/locale/zh_TW.mo", "/initramfs-0-rescue-acd9b2fd1f8f4842b7b98344a756997d.img", "/initramfs-3.10.0-693.el7.x86_64.img", "/initrd-plymouth.img", "/symvers-3.10.0-693.el7.x86_64.gz", "/vmlinuz-0-rescue-acd9b2fd1f8f4842b7b98344a756997d", "/vmlinuz-3.10.0-693.el7.x86_64", "/vmlinuz-3.10.0-693.el7.x86_64.rpmsave"]
....

Difference2:the debug output of old v2v has v2v: statns "/boot/vmlinuz-3.10.0-693.el7.x86_64.rpmsave" but debug log of new v2v build doesn't have:

1.the debug log of Old v2v builds:
....
libguestfs: trace: v2v: command = "/boot/vmlinuz-3.10.0-693.el7.x86_64.rpmsave\n"
libguestfs: trace: v2v: statns "/boot/vmlinuz-3.10.0-693.el7.x86_64.rpmsave"
guestfsd: main_loop: new request, len 0x58
guestfsd: main_loop: proc 421 (statns) took 0.00 seconds
libguestfs: trace: v2v: statns = <struct guestfs_statns = st_dev: 2049, st_ino: 68, st_mode: 33261, st_nlink: 1, st_uid: 0, st_gid: 0, st_rdev: 0, st_size: 5875184, st_blksize: 4096, st_blocks: 11480, st_atime_sec: 1512368881, st_atime_nsec: 620422806, st_mtime_sec: 1512368881, st_mtime_nsec: 709432768, st_ctime_sec: 1512368881, st_ctime_nsec: 709432768, st_spare1: 0, st_spare2: 0, st_spare3: 0, st_spare4: 0, st_spare5: 0, st_spare6: 0, >
libguestfs: trace: v2v: statns "/boot/vmlinuz-0-rescue-acd9b2fd1f8f4842b7b98344a756997d"

2.the debug log of new v2v builds:
....
libguestfs: trace: v2v: command = "/boot/vmlinuz-3.10.0-693.el7.x86_64.rpmsave\n"
libguestfs: trace: v2v: statns "/boot/vmlinuz-0-rescue-acd9b2fd1f8f4842b7b98344a756997d"
guestfsd: main_loop: new request, len 0x64
guestfsd: main_loop: proc 421 (statns) took 0.00 seconds
libguestfs: trace: v2v: statns = <struct guestfs_statns = st_dev: 2049, st_ino: 75, st_mode: 33261, st_nlink: 1, st_uid: 0, st_gid: 0, st_rdev: 0, st_size: 5878400, st_blksize: 4096, st_blocks: 11488, st_atime_sec: 1503306813, st_atime_nsec: 596000000, st_mtime_sec: 1503306813, st_mtime_nsec: 797000000, st_ctime_sec: 1503306813, st_ctime_nsec: 797000000, st_spare1: 0, st_spare2: 0, st_spare3: 0, st_spare4: 0, st_spare5: 0, st_spare6: 0, >
libguestfs: trace: v2v: statns "/boot/vmlinuz-3.10.0-693.el7.x86_64"


Hi rjones,

   Could you please help to see if difference of debug log is expected?

Yes, I believe that's correct.  The only difference would be the
minor change in the debug log observed.  There would be no observable
difference in the behaviour of virt-v2v itself from patch 3.

(In reply to mxie from comment #14)
> Created attachment 1360244 [details]
> virt-v2v-resume-sda-rhel7.log

I see what's going on in comment 13 / comment 14:

The regular expression only matches the final instance of resume=...
on the grub command line.  Since the command line has the unlikely
content of:

resume=/dev/sda2 resume=d975bf61-1876-4c2f-8926-0470bb3dfdf5 resume=/swapfile resume=/dev/X resume=/dev/

and only the final one (resume=/dev/) is matched, nothing gets
rewritten.

Real guests should only have one resume= on the command line so
it should work for those.

(In reply to Richard W.M. Jones from comment #18)
> (In reply to mxie from comment #14)
> > Created attachment 1360244 [details]
> > virt-v2v-resume-sda-rhel7.log
> 
> I see what's going on in comment 13 / comment 14:
> 
> The regular expression only matches the final instance of resume=...
> on the grub command line.  Since the command line has the unlikely
> content of:
> 
> resume=/dev/sda2 resume=d975bf61-1876-4c2f-8926-0470bb3dfdf5
> resume=/swapfile resume=/dev/X resume=/dev/
> 
> and only the final one (resume=/dev/) is matched, nothing gets
> rewritten.
> 
> Real guests should only have one resume= on the command line so
> it should work for those.

I also tried to only add resume=/dev/sda2 to grub command line in rhel7 guest, but resume=/dev/sdaX still can't be updated to resume=/dev/vdaX in rhel7 grub file after v2v conversion

(In reply to mxie from comment #19)
> (In reply to Richard W.M. Jones from comment #18)
> > (In reply to mxie from comment #14)
> > > Created attachment 1360244 [details]
> > > virt-v2v-resume-sda-rhel7.log
> > 
> > I see what's going on in comment 13 / comment 14:
> > 
> > The regular expression only matches the final instance of resume=...
> > on the grub command line.  Since the command line has the unlikely
> > content of:
> > 
> > resume=/dev/sda2 resume=d975bf61-1876-4c2f-8926-0470bb3dfdf5
> > resume=/swapfile resume=/dev/X resume=/dev/
> > 
> > and only the final one (resume=/dev/) is matched, nothing gets
> > rewritten.
> > 
> > Real guests should only have one resume= on the command line so
> > it should work for those.
> 
> I also tried to only add resume=/dev/sda2 to grub command line in rhel7
> guest, but resume=/dev/sdaX still can't be updated to resume=/dev/vdaX in
> rhel7 grub file after v2v conversion

Hi,rjones, I have attached the log "rhel7-resume-only-sda "for above scenario for your reference

Created attachment 1373676 [details]
rhel7-resume-only-sda.log

The case in comment 19 - comment 21 didn't work because of the quoting
around the resume=... parameter:

libguestfs: trace: v2v: aug_get "/files/etc/default/grub/GRUB_CMDLINE_LINUX_DEFAULT"
guestfsd: main_loop: new request, len 0x60
guestfsd: main_loop: proc 19 (aug_get) took 0.00 seconds
libguestfs: trace: v2v: aug_get = ""resume=/dev/sda2""

The regular expression matches ‘/dev/sda2"’ and because that
isn't a correct device name it doesn't get rewritten.

(Note this was also a bug in old virt-v2v so it's not a regression).

I tried to come up with a simple fix for this, but it's
not trivial and would have a high risk of causing regressions.

You can however see if

  GRUB_CMDLINE_LINUX_DEFAULT=resume=/dev/sda2

works.

According to comment22, move this bug from ON_QA to ASSIGNED for now.

With rjones' confirmation, file bug 1532224 to track patch2's problem (comment13), so move this bug to VERIFIED

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0677