Bug 590751

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.

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.

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.

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.

Any plan to do with virt-v2v in RHEL6?

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>

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?

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.

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. **

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.

We worked round this by no longer removing kernels.