Cloned to RHEL7 for verification that the new virt-v2v (as part of libguestfs) now reports parse errors of grub.conf from Augeas, rather than printing that the virtio kernel couldn't be found. +++ This bug was initially created as a clone of Bug #1219216 +++ Description of problem: augeas tool fails to find the kernel line in /boot/grub/grub.conf if unexpected console lines are present when trying to virt-v2v a guest Version-Release number of selected component (if applicable): virt-v2v-0.9.1-5.el6_5.x86_64 How reproducible: Always Steps to Reproduce: 1. *note: This was encountered by customer extracting a VM from an ESX environment, and adding it to a RHEV 3.5 environment, but from what I see that shouldn't matter and I was able to reproduce it by extracting a local kvm guest. 2. Add the "serial" and "terminal" lines to the grub.conf of a VM guest to be converted. (Examples at the bottom of this post) 3. Attempt a virt-v2v of that VM guest: Example: # virt-v2v -ic qemu:///session -o rhev -os myrhev.redhat.com:/exportdomain --network rhevm kvmr6n1 Actual results: virt-v2v fails with the following two lines in the virt-v2v.log: virtio configured, but no virtio kernel found at /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm line 1007. virt-v2v: Transferring storage volume New Virtual Machine_New Virtual Machine: 161061273600 bytes Expected results: Successfully create the VM for import (in this case in the RHEV 3.5 export domain. Additional info: Notes from support case is that one of the aug_match() calls in /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm is having problems with those two lines" "The problem seems the be the augeas tool: /usr/share/perl5/vendor_perl/Sys/VirtConvert/Converter/RedHat.pm: ... 141 sub list_kernels ... 150 # Look for a kernel, starting with the default 151 my @paths = eval { 152 # Get a list of all kernels 153 my @ret = $g->aug_match("/files$grub_conf/title/kernel"); We use aug_match which does not return the value. The problem is the two lines related to the serial console serial -unit=0 -speed=115200 terminal -timeout=10 serial console " Example grub.conf with the "serial" and "terminal" lines.... # grub.conf generated by anaconda # # Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/mapper/vg00-lv_root # initrd /initrd-[generic-]version.img #boot=/dev/sda serial -unit=0 -speed=115200 terminal -timeout=10 serial console default=0 timeout=10 #splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Red Hat Enterprise Linux Server (2.6.32-220.23.1.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-220.23.1.el6.x86_64 ro root=/dev/mapper/vg00-lv_root initrd /initramfs-2.6.32-220.23.1.el6.x86_64.img --- Additional comment from Dominic Cleal on 2015-05-07 10:40:45 BST --- (In reply to Dylan Gross from comment #0) > We use aug_match which does not return the value. The problem is the two > lines > related to the serial console > > serial -unit=0 -speed=115200 > terminal -timeout=10 serial console > " Are these actually valid and working configuration directives? The documentation suggests it must be two hyphens, not one: https://www.gnu.org/software/grub/manual/legacy/Serial-terminal.html https://www.gnu.org/software/grub/manual/legacy/serial.html https://www.gnu.org/software/grub/manual/legacy/terminal.html I see nothing there to suggest that "-unit=0" is valid. --- Additional comment from Dominic Cleal on 2015-05-07 12:05:03 BST --- Checked the GRUB 0.97 source code too, and it doesn't parse options with only one hyphen, which makes me believe this is a configuration error. Augeas generally only tries to parse valid configs, not be tolerant of errors. --- Additional comment from Dylan Gross on 2015-05-28 14:56:58 BST --- Customer confirmed that we he did remedy those incorrect arguments with double-hyphens, the virt-v2v no longer failed. If that is the intended behaviour of augeas when parsing, then this is probably "NOTABUG". Perhaps the error about not being able to match a kernel line could be more specific about failing on a different line. Or maybe not. I don't know enough about how the parsing is being done to know if it can get that granular. --- Additional comment from Dominic Cleal on 2015-05-28 15:05:04 BST --- (In reply to Dylan Gross from comment #4) > Customer confirmed that we he did remedy those incorrect arguments with > double-hyphens, the virt-v2v no longer failed. If that is the intended > behaviour of augeas when parsing, then this is probably "NOTABUG". Indeed. > Perhaps the error about not being able to match a kernel line could be more > specific about failing on a different line. Or maybe not. I don't know > enough about how the parsing is being done to know if it can get that > granular. Yeah, it looks like virt-v2v isn't showing that Augeas hasn't managed to parse the file. It should be possible to report Augeas' own error output (from /augeas//error), like we did here for netcf: https://lists.fedorahosted.org/pipermail/netcf-devel/2014-September/000907.html or Puppet: https://github.com/puppetlabs/puppet/blob/4.1.0/lib/puppet/provider/augeas/augeas.rb#L327-L354 I don't know whether you'd prefer to move this bug or recreate one against v2v.
To try to reproduce this with new virt-v2v: $ virt-builder centos-6 $ guestfish -a centos-6.img -i ><fs> vi /boot/grub/grub.conf # After editing the serial and terminal lines, the file looks like below: ><fs> cat /boot/grub/grub.conf [...comments...] serial -unit=0 -speed=115200 terminal -timeout=10 serial console default=0 timeout=5 title CentOS 6 (2.6.32-504.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-504.el6.x86_64 ro [...etc...] initrd /initramfs-2.6.32-504.el6.x86_64.img ><fs> exit $ virt-v2v --version virt-v2v 1.29.48fedora=23,release=1.fc23,libvirt $ virt-v2v -i disk centos-6.img -o null [ 0.0] Opening the source -i disk centos-6.img [ 0.1] Creating an overlay to protect the source from being modified [ 0.3] Opening the overlay [ 15.9] Initializing the target -o null [ 15.9] Inspecting the overlay [ 20.3] Checking for sufficient free disk space in the guest [ 20.3] Estimating space required on target for each disk [ 20.3] Converting CentOS release 6.6 (Final) to run on KVM virt-v2v: error: libguestfs error: aug_get: no matching node
Upstream fix: https://github.com/libguestfs/libguestfs/commit/659d56db3cc4333e7410cac6720c20b3b7fa66ad Note that after applying this fix, conversion will still fail (which it should do - the grub configuration of the guest is incorrect). However the error message changes to be more explanatory: $ virt-v2v -i disk centos-6.img -o null [ 0.0] Opening the source -i disk centos-6.img [ 0.3] Creating an overlay to protect the source from being modified [ 0.4] Opening the overlay [ 46.8] Initializing the target -o null [ 46.8] Inspecting the overlay [ 51.5] Checking for sufficient free disk space in the guest [ 51.5] Estimating space required on target for each disk [ 51.5] Converting CentOS release 6.6 (Final) to run on KVM virt-v2v: error: no kernels were found in the grub configuration. This probably indicates that virt-v2v was unable to parse the grub configuration of this guest.
I can reproduce this issue with package version: libguestfs-1.28.1-1.43.el7.x86_64 libvirt-1.2.17-1.el7.x86_64 virt-v2v-1.28.1-1.43.el7.x86_64 Steps: 1. Prepare a health guest, then add serial and terminal lines to grub.conf file: # cat /boot/grub/grub.conf serial -unit=0 -speed=115200 terminal -timeout=10 serial console default=0 timeout=5 splashimage=(hd0,0)/grub/splash.xpm.gz hiddenmenu title Red Hat Enterprise Linux 6 (2.6.32-570.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-570.el6.x86_64 ro root=/dev/mapper/VolGroup-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD rd_LVM_LV=VolGroup/lv_swap SYSFONT=latarcyrheb-sun16 crashkernel=auto rd_LVM_LV=VolGroup/lv_root KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM rhgb quiet initrd /initramfs-2.6.32-570.el6.x86_64.img 2. Convert this guest to rhevm target: # virt-v2v -o rhev -os 10.66.90.115:/vol/v2v_auto/iscsi_export --network rhevm rhel6.7-snap5 -on rhel6.7-snap5-test [ 0.0] Opening the source -i libvirt rhel6.7-snap5 [ 0.0] Creating an overlay to protect the source from being modified [ 0.0] Opening the overlay [ 95.0] Initializing the target -o rhev -os 10.66.90.115:/vol/v2v_auto/iscsi_export virt-v2v: warning: cannot write files to the NFS server as 36:36, even though we appear to be running as root. This probably means the NFS client or idmapd is not configured properly. You will have to chown the files that virt-v2v creates after the run, otherwise RHEV-M will not be able to import the VM. [ 95.0] Inspecting the overlay [ 107.0] Checking for sufficient free disk space in the guest [ 107.0] Estimating space required on target for each disk [ 107.0] Converting Red Hat Enterprise Linux Server release 6.7 Beta (Santiago) to run on KVM virt-v2v: error: libguestfs error: aug_get: no matching node If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Then try to verify with new build: libvirt-1.2.17-1.el7.x86_64 libguestfs-1.28.1-1.44.el7.x86_64 virt-v2v-1.28.1-1.44.el7.x86_64 Steps: # virt-v2v -o rhev -os 10.66.90.115:/vol/v2v_auto/iscsi_export --network rhevm rhel6.7-snap5 -on rhel6.7-snap5-test [ 0.0] Opening the source -i libvirt rhel6.7-snap5 [ 0.0] Creating an overlay to protect the source from being modified [ 0.0] Opening the overlay [ 92.0] Initializing the target -o rhev -os 10.66.90.115:/vol/v2v_auto/iscsi_export virt-v2v: warning: cannot write files to the NFS server as 36:36, even though we appear to be running as root. This probably means the NFS client or idmapd is not configured properly. You will have to chown the files that virt-v2v creates after the run, otherwise RHEV-M will not be able to import the VM. [ 92.0] Inspecting the overlay [ 101.0] Checking for sufficient free disk space in the guest [ 101.0] Estimating space required on target for each disk [ 101.0] Converting Red Hat Enterprise Linux Server release 6.7 Beta (Santiago) to run on KVM virt-v2v: error: no kernels were found in the grub configuration. This probably indicates that virt-v2v was unable to parse the grub configuration of this guest. If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Result: Error message is clear, so move this bug from ON_QA 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/RHBA-2015-2183.html