Bug 590751 - virt-v2v fails to remove a kernel with dependent kmods
virt-v2v fails to remove a kernel with dependent kmods
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-v2v (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Matthew Booth
Virtualization Bugs
:
Depends On:
Blocks: 642467 660539
  Show dependency treegraph
 
Reported: 2010-05-10 11:41 EDT by Kirby Zhou
Modified: 2011-02-11 04:41 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 642467 (view as bug list)
Environment:
Last Closed: 2011-02-11 04:41:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kirby Zhou 2010-05-10 11:41:23 EDT
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):

hivex-1.2.0-2.el6.1.x86_64
virt-v2v-0.2.0-2.el6.x86_64
libguestfs-1.0.85-1.el6.1.x86_64
libguestfs-tools-1.0.85-1.el6.1.x86_64
qemu-kvm-0.12.1.2-2.17.el6.x86_64
qemu-kvm-tools-0.12.1.2-2.17.el6.x86_64
libvirt-0.7.6-2.el6.x86_64
guestfish-1.0.85-1.el6.1.x86_64
libguestfs-mount-1.0.85-1.el6.1.x86_64

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 
[aliases]
rhel.5.kernel-xen=kernel
[files]
rhel.5.x86_64.kernel=/root/kernel-2.6.18-194.el5.x86_64.rpm
[deps]
[libvirtxml]
bridge.xenbr0=vbr0
bridge.xenbr1=vbr1

]# cat kirby-dev.xml 
<domain type='xen' id='57'>
  <name>kirby-dev</name>
  <uuid>8859ada6-2fa6-d53a-1f2f-c36e0614d807</uuid>
  <memory>8388608</memory>
  <currentMemory>8388608</currentMemory>
  <vcpu>8</vcpu>
  <bootloader>/usr/bin/pygrub</bootloader>
  <clock offset='utc'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <disk type='block' device='disk'>
      <driver name='phy'/>
      <source dev='/dev/vgxpool/kirby-dev'/>
      <target dev='xvda' bus='xen'/>
    </disk>
    <disk type='block' device='disk'>
      <driver name='phy'/>
      <source dev='/dev/vgxpool/kirby-dev-data0'/>
      <target dev='xvdb' bus='xen'/>
    </disk>
    <interface type='bridge'>
      <mac address='00:16:3e:72:70:57'/>
      <source bridge='vbr0'/>
      <script path='vif-bridge'/>
      <target dev='vif57.0'/>
    </interface>
    <interface type='bridge'>
      <mac address='00:16:3e:72:70:58'/>
      <source bridge='vbr1'/>
      <script path='vif-bridge'/>
      <target dev='vif57.1'/>
    </interface>
    <console type='pty' tty='/dev/pts/12'>
      <source path='/dev/pts/12'/>
      <target port='0'/>
    </console>
  </devices>
</domain>

Additional info:

On domU:
[root@xen-727057^10.227 ~]# rpm -qa 'kernel*'
kernel-xen-devel-2.6.18-164.10.1.el5
kernel-xen-devel-2.6.18-164.6.1.el5
kernel-xen-2.6.18-194.el5
kernel-xen-debuginfo-2.6.18-194.el5
kernel-devel-2.6.18-164.el5
kernel-debuginfo-common-2.6.18-194.el5
kernel-devel-2.6.18-194.el5
kernel-headers-2.6.18-194.el5
kernel-devel-2.6.18-164.10.1.el5
kernel-xen-devel-2.6.18-194.el5
kernel-xen-2.6.18-164.6.1.el5
kernel-xen-2.6.18-164.10.1.el5
kernel-doc-2.6.18-194.el5
[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
#boot=/dev/xvda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
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 12:54:31 EDT
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
inclusion.
Comment 3 Kirby Zhou 2010-05-12 10:45:41 EDT
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=10.0.2.0/8 -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:10.0.2.2:39516 


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 11:03:58 EDT
Kirby,

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 11:07:19 EDT
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->set_selinux(1);

    $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 11:07:59 EDT
Any plan to do with virt-v2v in RHEL6?
Comment 7 Kirby Zhou 2010-05-12 12:31:40 EDT
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
<virt-v2v>
  <path-root>/var/lib/virt-v2v/software</path-root>
  <iso-path>/var/lib/virt-v2v/transfer.iso</iso-path>
  <app os='rhel' major='5' minor='5' arch='x86_64' name='kernel'>
    <path>rhel/5/kernel-2.6.18-194.el5.x86_64.rpm</path>
  </app>
  <network type='bridge' name='xenbr0'>
    <network type='bridge' name='vbr0'/>
  </network>
  <network type='bridge' name='xenbr1'>
    <network type='bridge' name='vbr1'/>
  </network>
</virt-v2v>
Comment 8 Matthew Booth 2010-05-12 12:42:54 EDT
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 13:07:53 EDT
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 10:30:32 EDT
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 03:39:36 EDT
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 04:41:37 EST
We worked round this by no longer removing kernels.

Note You need to log in before you can comment on or make changes to this bug.