search for: qemupciserial

...nto 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...

...However, do I get it right that this is just a convention currently followed in virtio-win drivers? I.e. there's nothing in the Windows driver specifications mandating this versioning scheme? I'm trying to figure out how dependable it is. Besides, ATM there's at least one driver -- qemupciserial -- which doesn't fit in this scheme (or any scheme at all :). There are other peculiarities which we don't know what to do: - the netkvm driver directory on virtio-win.iso contains netkvmco.dll (I'm assuming it's coinstaller dll). However, netkvm.inf doesn't mention it, a...

...cantly 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 > > > wo...

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. *)

...rer] >> %RHEL% = RHEL,NTAMD64 >> >> but the contents are not very consistent across all the .inf files I >> have access to. > > Hi Richard, > > It should be consistent. We do specify target architecture (amd64 or > x86) when stamping inf/inx files. IIRC, qemupciserial.inf is the only > exception, but it goes without binaries. In any case, if you are going > to use existing distribution media, you can rely on the media layout - > for example, if "amd64" is a part of your current path - you are in > 64-bit directory. >> >> (2) I...

...t the contents are not very consistent across all the .inf files I > > >> have access to. > > > > > > Hi Richard, > > > > > > It should be consistent. We do specify target architecture (amd64 or > > > x86) when stamping inf/inx files. IIRC, qemupciserial.inf is the only > > > exception, but it goes without binaries. In any case, if you are going > > > to use existing distribution media, you can rely on the media layout - > > > for example, if "amd64" is a part of your current path - you are in > > > 64-...

On Thu, Oct 29, 2015 at 11:05:42AM +1100, Vadim Rozenfeld wrote: > On Wed, 2015-10-28 at 14:53 +0300, Roman Kagan wrote: > > 1) tell which devices can be configured > Not sure that I fully understated your question. but if you are going to > create some sort of off-line automatic virtio-win drivers update > utility, then it shouldn't be too complicated. Firs of all you will

...oks hopeful, eg: > > [Manufacturer] > %RHEL% = RHEL,NTAMD64 > > but the contents are not very consistent across all the .inf files I > have access to. Hi Richard, It should be consistent. We do specify target architecture (amd64 or x86) when stamping inf/inx files. IIRC, qemupciserial.inf is the only exception, but it goes without binaries. In any case, if you are going to use existing distribution media, you can rely on the media layout - for example, if "amd64" is a part of your current path - you are in 64-bit directory. > > (2) If we have a directory contai...

...gt; >> > >> but the contents are not very consistent across all the .inf files I > >> have access to. > > > > Hi Richard, > > > > It should be consistent. We do specify target architecture (amd64 or > > x86) when stamping inf/inx files. IIRC, qemupciserial.inf is the only > > exception, but it goes without binaries. In any case, if you are going > > to use existing distribution media, you can rely on the media layout - > > for example, if "amd64" is a part of your current path - you are in > > 64-bit directory. >...

On Thu, Oct 29, 2015 at 11:05:42AM +1100, Vadim Rozenfeld wrote: > > 1) tell which devices can be configured > Not sure that I fully understated your question. but if you are going to > create some sort of off-line automatic virtio-win drivers update > utility, then it shouldn't be too complicated. Roman is talking about what virt-v2v already does. This is good information:

...winxp_32; - "NetKVM/xp/x86/netkvm.inf", Some winxp_32; - "NetKVM/xp/x86/netkvm.pdb", Some winxp_32; - "NetKVM/xp/x86/netkvm.sys", Some winxp_32; - "guest-agent/qemu-ga-x64.msi", None; - "guest-agent/qemu-ga-x86.msi", None; - "qemupciserial/qemupciserial.inf", None; - "viorng/2k12/amd64/WdfCoInstaller01011.dll", None; - "viorng/2k12/amd64/viorng.cat", Some win2k12_64; - "viorng/2k12/amd64/viorng.inf", Some win2k12_64; - "viorng/2k12/amd64/viorng.pdb", Some win2k12_64; - &quot...

v2 -> v3 - Don't make a special case for WdfCoInstaller* files. There is a difference of opinion about whether copying these is necessary, but it seems like it is not harmful. Rich.

https://github.com/rwmjones/libguestfs/tree/rewrite-virtio-copy-drivers Instead of trying to split and parse elements from virtio-win paths, use the '*.inf' files supplied with the drivers to control how Windows drivers are installed. The following emails best explain how this works: https://www.redhat.com/archives/libguestfs/2015-October/msg00352.html

..."NetKVM/xp/x86/netkvm.inf", Some winxp_32; "NetKVM/xp/x86/netkvm.pdb", Some winxp_32; @@ -343,83 +343,83 @@ let test_virtio_iso_path_matches_guest_os ctx = "guest-agent/qemu-ga-x64.msi", None; "guest-agent/qemu-ga-x86.msi", None; "qemupciserial/qemupciserial.inf", None; - "viorng/2k12/amd64/WdfCoInstaller01011.dll", None; + "viorng/2k12/amd64/WdfCoInstaller01011.dll", Some win2k12_64; "viorng/2k12/amd64/viorng.cat", Some win2k12_64; "viorng/2k12/amd64/viorng.inf", Some win2k12_6...

Patch 1 moves the v2v/fake-virtio-win and v2v/fake-virt-tools directories to the recently created test-data/ hierarchy. This is just refactoring with no functional change at all. Patches 2-4 then extend the available (fake) virtio-win drivers: - Patch 2 adds all of the drivers from the virtio-win RPM. - Patch 3 adds all of the drivers from the virtio-win ISO (which are different from the

If the connection is not local, paths of disks will refer to the remote host, which were mistakenly handled as local paths (in the best case failing to open a non-existing disk, and in the worst case opening a different disk!). In case the disks are remote resources like ssh or ceph, nothing guarantees that the hostname can be reached from the local machine, or even that it is actually the same on

Hopefully this time ...