[Libguestfs] [PATCH] virt-v2v: Convert RedHat.pm to Linux.pm - for SUSE support

[Mike Latimer]

Thanks for the comments, Matt.

On Thursday, October 03, 2013 05:34:27 PM Matthew Booth wrote:
> > -    # There should be an installed virtio capable kernel if virtio was
> > installed -    die("virtio configured, but no virtio kernel found")
> > +    # Warn if there is no installed virtio capable kernel. It is safe to
> > +    # continue and attempt to install a virtio kernel next.
> > +    logmsg NOTICE, __x('virtio capable guest, but no virtio kernel
> > found.')> 
> >          if ($virtio && !defined($boot_kernel));
> 
> No. This indicates an error in the program rather than something the
> user can fix. This is also why it's a plain die with no translation.

If a virtio kernel must be installed prior to _configure_kernel, why is there 
the ability to install a replacement kernel immediately after this message? It 
doesn't really matter to SUSE though - adding 'kernel' to the deps for virtio 
in virt-v2v.db will trigger the installation of the correct kernel in the 
install_capabilities step.

> > @@ -1631,14 +1752,38 @@ sub _install_any
> > 
> >      # If we're installing a kernel, check which kernels are there first
> >      my @k_before = $g->glob_expand('/boot/vmlinuz-*') if
> >      defined($kernel);
> > 
> > +    # If a SLES11 kernel is being added, add -base kernel
> > +    if (defined($kernel)) {
> > +        if (_is_suse_family($g, $root) &&
> > +            ($g->inspect_get_major_version($root) == 11)) {
> > +            my $tmp;
> > +            push(@$tmp, $kernel);
> > +            $tmp->[1][0] = $tmp->[0][0].'-base';
> > +            for my $count (1..4) {
> > +                if (defined($tmp->[0][$count])) {
> > +                    $tmp->[1][$count] = $tmp->[0][$count];
> > +                }
> > +            }
> > +            $kernel = $tmp;
> > +        }
> > +    }
> 
> For sanity, I think we need $kernel to be the same data structure in
> all cases. Lets either unconditionally convert $kernel into a list (of
> lists), or see of -base can be added to the @install list or something
> like that. Bear in mind, though, that in the former case you'd also
> have to update _install_yum and _install_up2date.

The problem with @install is that it is processed separately from $kernel in 
_install_config. This causes the two packages to be installed by separate rpm 
commands, and the dependencies cannot be satisfied. This is why I had to add 
the -base package to $kernel somehow...  (Note - This doesn't effect zypper 
installs at all as it will satisfy dependencies automatically.)

I'll think about it some more...

> > @@ -2235,6 +2541,10 @@ sub _remap_block_devices
...
> I've had a change to think about this change properly, and I'm pretty
> sure it's not required. The reason is that the only place %idemap is
> modified is in the section guarded:
> 
> if ($libata) {
> ...
> }
> 
> If the guest is using libata it will not have any references to
> /dev/hdX devices, as IDE devices are presented as SCSI devices. That's
> a NAK to this bit of the patch. Instead, you need to work out when SLES
> switched to libata and set $libata accordingly above.

If there are never any hdX devices in libata machines, why are they renamed in 
the first place? The code I proposed just tracks any such changes and adds them 
to the list of remaps to perform. (i.e. if hda --> sda, and sda --> vda, then 
hda --> vda as well.)

However, SLES seems to be similar to RHEL5, where libata is in use, but udev 
calls them hdX anyway (for hvm guests). I can add SLES to the list of 
$libata=0 environments, but wasn't sure if that was the best long term 
approach.

Thanks,
Mike