On Tue, Oct 27, 2015 at 04:45:00PM +0300, Roman Kagan wrote:
On Tue, Oct 27, 2015 at 12:02:40PM +0000, Richard W.M. Jones wrote:
> On Tue, Oct 27, 2015 at 02:08:42PM +0300, Roman Kagan wrote:
> > On Tue, Oct 27, 2015 at 09:12:41AM +0000, Richard W.M. Jones wrote:
> > > On Mon, Oct 26, 2015 at 09:00:03PM +0300, Roman Kagan wrote:
> > > > Windows QXL drivers include also qxldd.dll which used to get
filtered
> > > > out and not copied over into the guest. As a result QXL driver
failed
> > > > to install due to a missing file.
> > > > (* Skip files without specific extensions. *)
> > > > - let extensions = ["cat"; "inf";
"pdb"; "sys"] in
> > > > + let extensions = ["cat"; "dll";
"inf"; "pdb"; "sys"] in
> > >
> > > Actually no, this part is (may be) wrong.
> > >
> > > This causes WdfCoInstaller*.dll from the ISO to be copied in. It's
> > > not clear to me whether these files are needed - I suspect not.
> >
> > Yes it is, see the corresponding *.inf where it's mentioned in the
> > corresponding CopyFiles directive (and yes, I just verified that with
> > that file missing the balloon driver installation fails with 'file not
> > found' error).
>
> Maybe we should be looking at the CopyFiles directive? (As you may be
> able to guess, I know next to nothing about how Windows drivers work).
So do I, and parsing the *.inf files is the last thing I'd like to do
here; I'm not sure it can be made reliable (I mean, not the parsing, but
making any sense out of the parsed data).
However I'm now facing a more serious problem: when I actually went
ahead and looked into the virio-win iso packaged in the rhel virtio-win
rpm, I found out that its contents differed significantly from what was
packaged in that very same rpm as a driver directory hierarchy.
Namely,
- there are no qxl drivers on the iso, but they are present in the rpm
- there are no balloon, qemupciserial, viorng, vioserial in the rpm,
but they are present on the iso
- qemupciserial is an inf-only 'driver' which matches all windows
versions; it's just one copy at the sub-toplevel directory, so it
won't pass the virtio_iso_path_matches_guest_os() criteria
- there are a lot of duplicates between files for different windows
flavors
To sum up, the packaging and naming policy of the virtio-win rpm and the
virtio-win iso therein are different and neither is clear. Hardcoding
the policy in v2v without actually knowing it appears risky at best.
We need guidance here from someone who knows how that virtio-win stuff
is packaged and how different it is across distros. Any idea whom to
contact on the matter?
Amnon -- CC'd -- I guess?
I'm aware that there are at least some differences in paths, and the
current virt-v2v code should be able to cope for the two drivers that
we really care about - viostor and virtio-net. Of course it can't
install drivers that don't exist on either the ISO or the rpm.
Rich.
> Anyhow, can you fix up the test at least.
Sure, but I'd like first to figure out how to fix up the code ;)
Roman.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine. Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/