12:48 p.m.
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