search for: netkvmco

Since v1: - Fix a bug in the calculation of lc_basename. By luck this doesn't affect anything given the contents of the current ISO. - Don't copy the WdfCoInstaller*.dll files. Rich.

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.

...Some winxp_32; "NetKVM/2k12/amd64/netkvm.cat", Some win2k12_64; "NetKVM/2k12/amd64/netkvm.inf", Some win2k12_64; "NetKVM/2k12/amd64/netkvm.pdb", Some win2k12_64; "NetKVM/2k12/amd64/netkvm.sys", Some win2k12_64; - "NetKVM/2k12/amd64/netkvmco.dll", None; - "NetKVM/2k12/amd64/readme.doc", None; + "NetKVM/2k12/amd64/netkvmco.dll", Some win2k12_64; + "NetKVM/2k12/amd64/readme.doc", Some win2k12_64; "NetKVM/2k12R2/amd64/netkvm.cat", Some win2k12r2_64; "NetKVM/2k12R2/amd64/...

...;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, and the driver installs just fine without it. - the balloon driver directory on virtio-win.iso contains blnsvr.exe (and .pdb) which is apparently a usermode service to report memory stats to host...

On Tue, Jun 23, 2015 at 09:18:01AM +0300, Shahar Havivi wrote: > On 22.06.15 15:33, Richard W.M. Jones wrote: > > This makes several changes to the handling of virtio-win drivers: > > > > The VIRTIO_WIN_DIR environment variable has been renamed > > VIRTIO_WIN (but you can still use the old name). > > > > You can point the VIRTIO_WIN either at a RHEL

...Some winxp_32; - "NetKVM/2k12/amd64/netkvm.cat", Some win2k12_64; - "NetKVM/2k12/amd64/netkvm.inf", Some win2k12_64; - "NetKVM/2k12/amd64/netkvm.pdb", Some win2k12_64; - "NetKVM/2k12/amd64/netkvm.sys", Some win2k12_64; - "NetKVM/2k12/amd64/netkvmco.dll", None; - "NetKVM/2k12/amd64/readme.doc", None; - "NetKVM/2k12R2/amd64/netkvm.cat", Some win2k12r2_64; - "NetKVM/2k12R2/amd64/netkvm.inf", Some win2k12r2_64; - "NetKVM/2k12R2/amd64/netkvm.pdb", Some win2k12r2_64; - "NetKVM/2k12R2/...

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

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

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:

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