Roman Kagan
2015-Oct-27 13:45 UTC
Re: [Libguestfs] [PATCH] v2v: virtio-win: include *.dll too
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?> 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 W.M. Jones
2015-Oct-27 14:11 UTC
Re: [Libguestfs] [PATCH] v2v: virtio-win: include *.dll too
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/
Vadim Rozenfeld
2015-Oct-28 01:10 UTC
Re: [Libguestfs] Fwd: [PATCH] v2v: virtio-win: include *.dll too
On Tue, 2015-10-27 at 11:00 -0400, Amnon Ilan wrote:> Hi Jeff, > > There were some questions on the libguestfs mailing list regarding virtio-win iso an packaging (see below). > Could you answer it on the list? (just send it to libguestfs@redhat.com , no need to register, keep us CCed) > The people asking are from Virtuozzo, they are not customers or official partners, just good contributors upstream. > Note that this mailing list is public. > > Thanks, > Amnon > > > > ----- Forwarded Message ----- > > From: "Richard W.M. Jones" <rjones@redhat.com> > > To: "Roman Kagan" <rkagan@virtuozzo.com>, libguestfs@redhat.com, "Denis Lunev" <den@virtuozzo.com> > > Cc: "Amnon Ilan" <ailan@redhat.com> > > Sent: Tuesday, October 27, 2015 4:11:10 PM > > Subject: Re: [PATCH] v2v: virtio-win: include *.dll too > > > > 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. > > > > >Having WdfCoInstaller* is absolutely necessary for successful installation any of our WDF based drivers (serial, balloon, and rng).> > > > > 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 > > > flavorsIt's due to historical reasons mostly. The best way would be having a set of separate distribution images packaged on per-platform base. Vadim.> > > > > > 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/ > >
Roman Kagan
2015-Oct-28 11:53 UTC
Re: [Libguestfs] Fwd: [PATCH] v2v: virtio-win: include *.dll too
On Wed, Oct 28, 2015 at 12:10:19PM +1100, Vadim Rozenfeld wrote:> > > > 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. > > It's due to historical reasons mostly. The best way would be having a set of separate > distribution images packaged on per-platform base.Let me try to get the libguestfs requirements straight: given a set of Windows drivers, it should be able to identify the ones appropriate for the particular Windows flavor, in order to 1) tell which devices can be configured 2) offline-"install" the storage driver and thus enable the guest too boot 3) copy over the matching drivers into the guest and allow it to pick them up on the first boot Obviously virtio-win driver packaging and libguestfs must agree on how to deal with this. Could you please provide any guidance on how to address this problem? Thanks, Roman.