Red Hat Bugzilla – Bug 1176801
File /etc/sysconfig/kernel isn't updated when convert XenPV guest with regular kernel installed
Last modified: 2016-11-03 13:48:57 EDT
Created attachment 972354 [details] detail debug log Description of problem: File /etc/sysconfig/kernel isn't updated when convert XenPV guest with regular kernel installed Version-Release number of selected component (if applicable): libvirt-1.2.8-11.el7.x86_64 libguestfs-1.28.1-1.18.el7.x86_64 virt-v2v-1.28.1-1.18.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. Install a regular kernel before conversion (without xen in the kernel's name ) if guest is 32b-pv you can do this : # rpm -ivh kernel-2.6.18-398.el5.i686.rpm # cat /boot/grub/grub.conf ... #boot=/dev/xvda default=1 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Red Hat Enterprise Linux Server (2.6.18-398.el5) root (hd0,0) kernel /vmlinuz-2.6.18-398.el5 ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.18-398.el5.img title Red Hat Enterprise Linux Server (2.6.18-398.el5xen) root (hd0,0) kernel /vmlinuz-2.6.18-398.el5xen ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.18-398.el5xen.img # cat /etc/sysconfig/kernel # UPDATEDEFAULT specifies if new-kernel-pkg should make # new kernels the default UPDATEDEFAULT=yes # DEFAULTKERNEL specifies the default kernel package type DEFAULTKERNEL=kernel-xen 2. Use virt-v2v convert this guest to libvirt: # virt-v2v -ic xen+ssh://10.66.106.64 xen-pv-rhel5.11-i386 -on xen-pv-rhel5.11-i386-check [ 0.0] Opening the source -i libvirt -ic xen+ssh://10.66.106.64 xen-pv-rhel5.11-i386 [ 1.0] Creating an overlay to protect the source from being modified [ 1.0] Opening the overlay [ 4.0] Initializing the target -o libvirt -os default [ 4.0] Inspecting the overlay [ 11.0] Checking for sufficient free disk space in the guest [ 11.0] Estimating space required on target for each disk [ 11.0] Converting Red Hat Enterprise Linux Server release 5.11 (Tikanga) to run on KVM virt-v2v: This guest has virtio drivers installed. [ 22.0] Mapping filesystem data to avoid copying unused and blank areas [ 22.0] Closing the overlay [ 22.0] Copying disk 1/1 to /var/lib/libvirt/images/xen-pv-rhel5.11-i386-check-sda (raw) (100.00/100%) [ 172.0] Creating output metadata Pool default refreshed Domain xen-pv-rhel5.11-i386-check defined from /tmp/v2vlibvirt41ce1c.xml [ 172.0] Finishing off 3. Boot up guest and check file /etc/sysconfig/kernel content. Actual results: 1. Guest can boot up with regular kernel. # uname -r 2.6.18-398.el5 2. File "/etc/sysconfig/kernel" doesn't change. # cat /etc/sysconfig/kernel # UPDATEDEFAULT specifies if new-kernel-pkg should make # new kernels the default UPDATEDEFAULT=yes # DEFAULTKERNEL specifies the default kernel package type DEFAULTKERNEL=kernel-xen Expected results: File "/etc/sysconfig/kernel" should be updated as following: # cat /etc/sysconfig/kernel # UPDATEDEFAULT specifies if new-kernel-pkg should make # new kernels the default UPDATEDEFAULT=yes # DEFAULTKERNEL specifies the default kernel package type DEFAULTKERNEL=kernel------------------->change "kernel-xen" to "kernel" Additional info: 1. I will attach detail debug log. 2. File "/etc/sysconfig/kernel" can be updated with old virt-v2v version on rhel6 host.
The only code in new virt-v2v which touches /etc/sysconfig/kernel is surrounded by: if family = `SUSE_family then ( ... update /etc/sysconfig/kernel ... ) so it will only have any effect on SUSE guests. However old virt-v2v had some code which modified DEFAULTKERNEL in /etc/sysconfig/kernel (unconditionally - for any Linux guest): # Ensure DEFAULTKERNEL is set to boot kernel package name # It's not fatal if this rpm command fails my ($kernel_pkg) = eval { $g->command_lines(['rpm', '-qf', "/lib/modules/$boot_kernel", '--qf', '%{NAME}\n']) }; if (defined($kernel_pkg) && $g->is_file_opts('/etc/sysconfig/kernel', followsymlinks=>1)) { eval { foreach my $path ($g->aug_match('/files/etc/sysconfig/kernel'. '/DEFAULTKERNEL/value')) { $g->aug_set($path, $kernel_pkg); } $g->aug_save(); }; # Propagate augeas errors augeas_error($g, $@) if ($@); } This code seems to have been omitted from new virt-v2v, which is a bug in new virt-v2v.
This is quite a serious bug and got lost somewhere. Moving to RHEL 7.3, but I'll take a look at it soon.
Upstream fix: https://github.com/libguestfs/libguestfs/commit/f37d363f1861301a0fee38785e1c7be3f75c3807
The above fix is in libguestfs >= 1.31.8, so it will be picked by the rebase (bug #1218766).
I can reproduce it following the steps in comment 0. # rpm -q virt-v2v libguestfs virt-v2v-1.28.1-1.55.el7.x86_64 libguestfs-1.28.1-1.55.el7.x86_64 And then update them to latest version and tested again. # rpm -q virt-v2v libguestfs virt-v2v-1.32.3-1.el7.x86_64 libguestfs-1.32.3-1.el7.x86_64 Steps: 1. Install a regular kernel before conversion (without xen in the kernel's name ) if guest is 32b-pv you can do this : # rpm -ivh kernel-2.6.18-398.el5.i686.rpm 2. Use virt-v2v convert this guest to libvirt. # virt-v2v -ic xen+ssh://10.66.106.64 xen-pv-rhel5.11-i386 -on xen-pv-rhel5.11-i386-check 3. Boot up guest and check file /etc/sysconfig/kernel content Actual Result: Guest can startup successfully and the /etc/sysconfig/kernel is right as below. # cat /etc/sysconfig/kernel # UPDATEDEFAULT specifies if new-kernel-pkg should make # new kernels the default UPDATEDEFAULT=yes # DEFAULTKERNEL specifies the default kernel package type DEFAULTKERNEL=kernel So move the 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://rhn.redhat.com/errata/RHSA-2016-2576.html