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

[Matthew Booth]

On Mon, 2013-10-07 at 10:58 -0600, Mike Latimer wrote:
> On Friday, October 04, 2013 09:38:58 AM Matthew Booth wrote:
> > It's specifically an error if we're attempting to configure virtio, and
> > there's no detected virtio kernel. It shouldn't have been possible to
> > get here in that state, hence it's a programmer error. The code below
> > attempts to install *any* kernel in the case that we aren't configuring
> > virtio.
> 
> Ok. I've added a 'kernel' dependency to the virtio capability for SUSE, and 
> this has resolved the above problem. It did bring up a versioning convention 
> difference between RedHat and SUSE, but I've worked around the problem. (SUSE 
> kernels include a build number that is not seen in the 'Linux kernel' string, 
> or in the name of the kernel. However, this complete version string is 
> required for kernel package installations. I now get this full version in 
> _inspect_linux_kernel, and use it later in a couple of places.)
> 
> Speaking of _inspect_linux_kernel, in my testing (under SUSE),
> $g->file('somefile') does not include the expected 'somefile:' at the beginning 
> of the return string. Because of this, the following code isn't correct:
> 
>   if($filedesc =~ /^$path: Linux kernel .*\bversion\s+(\S+)\b/) {
> 
> This works though:
> 
>   if($filedesc =~ /^Linux kernel .*\bversion\s+(\S+)\b/) {
> 
> The above "Linux kernel" string doesn't match the SUSE version output. 
> However, it's better if I don't modify the pattern to catch both version 
> strings, as the next 'else' case will determine the correct version from the 
> vmlinuz file. As the above pattern change doesn't really effect SUSE, I was 
> hoping you could check the output under RedHat and let me know if you'd like 
> '$path: ' removed from my version.

Feel free to remove ^$path. However, for robustness I ditch the leading
^ from your replacement. The difference will be down to a different
version of file included in the libguestfs appliance on SUSE.

> One other item I was hoping you could doublecheck is in the filtering out of 
> xen/xenU in _install_capability. Shouldn't the xen/xenU portion of the release 
> string actually be '-xen/xenU'? In other words, would the inclusion of the 
> hypen in the following code also be applicable for RedHat?
> 
>                         if (defined($kernel_release) &&
>                             $kernel_release =~ /^(\S+?)(-xen)?(U)?$/)
>                         {
>                             $kernel_release = $1;
>                         }

Yes, RH xen kernels also have the hyphen.

> > You can still make $kernel a list, you just need to ensure it's always a
> > list. The updates to the other installation methods should be trivial.
> 
> Rather than doing that, I've added the -base kernel as an app dependency for 
> the kernel. (It seems appropriate anyway.) At the end of _install_config, I 
> catch this condition, and install the packages together. This approach 
> shouldn't impact any non-SUSE environments.

_install_config should already install all dependencies in a single
transaction for exactly this reason. If it doesn't, we should fix that.
I take it zypper just does the right thing?

> > This is because there are 2 names here: the 'libvirt' name, which calls
> > ide devices hdX and is independent of the guest OS because it's at the
> > level of the hypervisor, and the name used by the guest os, which may
> > will be different if the guest uses libata.
> > 
> > The only direct information we have about the guest comes from the
> > hypervisor, so the only names we have to start off with are the names
> > the hypervisor uses. Everything else comes from subsequent inspection.
> > If the guest uses something different we need to handle that, hence this
> > whole complicated and fragile dance.
> 
> Agreed, but I still think there could be environments where hdX devices exist 
> (from the guest perspective) in a libata environment. If that ever is the 
> case, I think any such devices should be included in the rename map.
> 
> I've set all SUSE environments to $libata=0 for now, but I'm still doing 
> research to see if there is ever a condition where we want $prefix set to 'sd' 
> (which would mean that setting will need to be changed).

I'm not convinced. Either IDE devices will be presented as scsi devices
(default libata), or they won't (non-libata, or udev rewriting to
maintain the legacy behaviour). I'd be surprised to find a configuration
where some IDE devices become SCSI devices, but others don't.

Matt