Bug 590751

Summary: virt-v2v fails to remove a kernel with dependent kmods
Product: Red Hat Enterprise Linux 6 Reporter: Kirby Zhou <kirbyzhou>
Component: virt-v2vAssignee: Matthew Booth <mbooth>
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: dallan, mshao, rwu
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 642467 (view as bug list) Environment:
Last Closed: 2011-02-11 09:41:37 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 642467, 660539    

Description Kirby Zhou 2010-05-10 15:41:23 UTC
Description of problem:

How to do virt-v2v with old XEN domU?

I ran virt-v2v under a RHEL6 box with a RHEL-5.5 domU copied from a old dom0, but failed. virt-v2v doest not work with Xen-DOMU from RHEL5. It can not install a workable kernel to domU.

Version-Release number of selected component (if applicable):


How reproducible:

Steps to Reproduce:

~]# virt-v2v -i libvirtxml /root/kirby-dev.xml                        
virt-v2v: No bootable kernels installed, and no replacement specified in configuration.
Unable to continue.

]# virt-v2v -i libvirtxml -s /root/virt-v2v.conf /root/kirby-dev.xml
virt-v2v: No bootable kernels installed, and no replacement specified in configuration.
Unable to continue.
        (in cleanup) umount: /tmp/transferKOhsii: umount: /sysroot/tmp/transferKOhsii: not mounted at /usr/share/perl5/Sys/VirtV2V/GuestOS/RedHat.pm line 1137.

]# cat /root/virt-v2v.conf 

]# cat kirby-dev.xml 
<domain type='xen' id='57'>
  <clock offset='utc'/>
    <disk type='block' device='disk'>
      <driver name='phy'/>
      <source dev='/dev/vgxpool/kirby-dev'/>
      <target dev='xvda' bus='xen'/>
    <disk type='block' device='disk'>
      <driver name='phy'/>
      <source dev='/dev/vgxpool/kirby-dev-data0'/>
      <target dev='xvdb' bus='xen'/>
    <interface type='bridge'>
      <mac address='00:16:3e:72:70:57'/>
      <source bridge='vbr0'/>
      <script path='vif-bridge'/>
      <target dev='vif57.0'/>
    <interface type='bridge'>
      <mac address='00:16:3e:72:70:58'/>
      <source bridge='vbr1'/>
      <script path='vif-bridge'/>
      <target dev='vif57.1'/>
    <console type='pty' tty='/dev/pts/12'>
      <source path='/dev/pts/12'/>
      <target port='0'/>

Additional info:

On domU:
[root@xen-727057^10.227 ~]# rpm -qa 'kernel*'
[root@xen-727057^10.227 ~]# cat /etc/grub.conf 
# 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/vgxen/lvroot
#          initrd /initrd-version.img
title Red Hat Enterprise Linux Server (2.6.18-194.el5xen)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-194.el5xen ro root=/dev/vgxen/lvroot console=xvc0 rhgb quiet
        initrd /initrd-2.6.18-194.el5xen.img
title Red Hat Enterprise Linux Server (2.6.18-164.10.1.el5xen)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-164.10.1.el5xen ro root=/dev/vgxen/lvroot console=xvc0 rhgb quiet
        initrd /initrd-2.6.18-164.10.1.el5xen.img
title Red Hat Enterprise Linux Server (2.6.18-164.6.1.el5xen)
        root (hd0,0)
        kernel /vmlinuz-2.6.18-164.6.1.el5xen ro root=/dev/vgxen/lvroot console=xvc0 rhgb quiet
        initrd /initrd-2.6.18-164.6.1.el5xen.img
[root@xen-727057^10.227 ~]#

Comment 2 RHEL Product and Program Management 2010-05-10 16:54:31 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for

Comment 3 Kirby Zhou 2010-05-12 14:45:41 UTC
ps shows that:

/usr/libexec/qemu-kvm -drive file=/dev/vgxpool/kirby-dev,cache=off,if=virtio -drive file=/dev/vgxpool/kirby-dev-data0,cache=off,if=virtio -cdrom /tmp/UcOlkwkJ6g.iso -enable-kvm -nodefaults -nographic -serial stdio -m 500 -no-reboot -no-hpet -net user,vlan=0,net= -net nic,model=virtio,vlan=0 -kernel /tmp/libguestfs56DIZG/kernel -initrd /tmp/libguestfs56DIZG/initrd -append panic=1 console=ttyS0 udevtimeout=300 noapic acpi=off printk.time=1 cgroup_disable=memory selinux=1 enforcing=0 guestfs_vmchannel=tcp: 

sub _ensure_transfer_mounted
    my $self = shift;

    # Return immediately if it's already mounted
    return if(exists($self->{transfer_mount}));

    my $g = $self->{g};

    # Find the transfer device
    my @devices = $g->list_devices();
    my $transfer = $devices[$#devices];
    print "@devices\n";

    $self->{transfer_mount} = $g->mkdtemp("/tmp/transferXXXXXX");
    $g->mount_ro($transfer, $self->{transfer_mount});

$g->list_devices() returns '/dev/vda /dev/vdb'.
But there are actually 3 block devices, kirby-dev, kirby-dev-data0 and a cdrom iso.

Comment 4 Matthew Booth 2010-05-12 15:03:58 UTC

This is an extremely old version of virt-v2v, which will be rebased. The focus of virt-v2v development at the moment is RHEL 5 for RHEV.

I don't know what the procedure is for handling this, but there's little point in continuing testing against virt-v2v 0.2.0.

Comment 5 Kirby Zhou 2010-05-12 15:07:19 UTC
I think the bug maybe is inside the libguestfs

sub get_guestfs_handle
    my @params = \@_; # Initialise parameters with list of devices

    my $g = open_guest(@params, rw => 1);

    # Mount the transfer iso if GuestOS needs it
    my $transferiso = Sys::VirtV2V::GuestOS->get_transfer_iso();
    print "$transferiso\n";
    $g->add_cdrom($transferiso) if(defined($transferiso));

    # Enable selinux in the guest

    $g->launch ();
    $g->wait_ready ();
    print $g->list_devices(), "\n";

    return $g;

No matter call or do not call $g->add_cdrom, $g->list_devices() always return
/dev/vda/ and dev/vdb without the cdrom device.

Comment 6 Kirby Zhou 2010-05-12 15:07:59 UTC
Any plan to do with virt-v2v in RHEL6?

Comment 7 Kirby Zhou 2010-05-12 16:31:40 UTC
Try virt-v2v-0.4.0, also failed.

]# virt-v2v -f virt-v2v.conf -i libvirtxml kirby-dev.xml 
command: error: Failed dependencies:
        kernel(rhel5_arch_x86_64_kernel_ga) = 933336f8fd8c90e0eee641788ca0d19ea5064a25 is needed by (installed) kmod-gnbd-xen-0.1.5-2.el5.x86_64
        kernel(rhel5_fs_partitions_ga) = 6f5f46197e4d5d5e21c8a5645c5d344ba987ac85 is needed by ( at /usr/share/perl5/Sys/VirtV2V/GuestOS/RedHat.pm line 657.

]# cat virt-v2v.conf
  <app os='rhel' major='5' minor='5' arch='x86_64' name='kernel'>
  <network type='bridge' name='xenbr0'>
    <network type='bridge' name='vbr0'/>
  <network type='bridge' name='xenbr1'>
    <network type='bridge' name='vbr1'/>

Comment 8 Matthew Booth 2010-05-12 16:42:54 UTC
The latest version is 0.5.3, but I don't have a brew build for RHEL 6 for it. You could take the RHEL 5 srpm and rebuild, but there are some RHEL 5 specific hacks in there which might prevent it from working correctly.

However, the above looks like a genuine bug. Sounds like we should look for kmods when trying to remove a kernel. Is there any chance you could ask the QA team doing RHEL 5 testing (includes rwu, osier, nzhang) to add your guest to their tests?

Comment 9 Kirby Zhou 2010-05-12 17:07:53 UTC
You are right, but to remove a kernel is really a necessary job for virt-v2v?
Maybe drop the feature can make problem much simpler.

Comment 10 RHEL Product and Program Management 2010-07-15 14:30:32 UTC
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 12 Rita Wu 2010-10-09 07:39:36 UTC
Hello Kirby,

Is your image quite different between normal image? What's the condition of your image? I cannot reproduce it with image which uses block device and doesn't register to RHN.

Comment 13 Matthew Booth 2011-02-11 09:41:37 UTC
We worked round this by no longer removing kernels.