search for: driververs

> On 06 Nov 2015, at 08:51, Vadim Rozenfeld <vrozenfe@redhat.com> wrote: > > On Thu, 2015-11-05 at 21:46 +0000, Richard W.M. Jones wrote: >> 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

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

On Mon, 2015-11-09 at 18:08 +0300, Roman Kagan wrote: > On Sun, Nov 08, 2015 at 10:15:31AM +0200, Yan Vugenfirer wrote: > > > > > On 06 Nov 2015, at 08:51, Vadim Rozenfeld <vrozenfe@redhat.com> wrote: > > > > > > On Thu, 2015-11-05 at 21:46 +0000, Richard W.M. Jones wrote: > > >> On Thu, Oct 29, 2015 at 11:05:42AM +1100, Vadim Rozenfeld

On Thu, 2015-11-05 at 21:46 +0000, Richard W.M. Jones wrote: > 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

On Sun, Nov 08, 2015 at 10:15:31AM +0200, Yan Vugenfirer wrote: > > > On 06 Nov 2015, at 08:51, Vadim Rozenfeld <vrozenfe@redhat.com> wrote: > > > > On Thu, 2015-11-05 at 21:46 +0000, Richard W.M. Jones wrote: > >> 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: >

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

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:

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 29 Oct 2015, at 10:28, Richard W.M. Jones <rjones@redhat.com> wrote: > > 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

On Wed, 2015-10-28 at 14:53 +0300, Roman Kagan wrote: > 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

I got a new USB ethernet adapter from ebay, the ad said RealTek chipset, so I thought I would chance it. Well, my 5.2 system does not recognize the USB device. At all. What do I need to do? I checked the driver CD and the XP driver directory's .inf file has the following: ; ASIX AX88172 USB2 to Fast Ethernet Adapter * ; * ; Copyright 2001-2003,

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

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 https://www.redhat.com/archives/libguestfs/2015-November/msg00065.html Currently the product variant (eg.

This simple parser has (limited) understanding of the Windows '*.inf' file format. This is a Windows config file with some peculiarities. This commit also has a unit test. --- po/POTFILES-ml | 1 + v2v/Makefile.am | 5 +- v2v/v2v_unit_tests.ml | 104 +++++++++++++++++++++++++++++++++++- v2v/windows_inf.ml | 143 ++++++++++++++++++++++++++++++++++++++++++++++++++

Add a copy of the libvirt-ocaml library, currently available at: https://libvirt.org/git/?p=libvirt-ocaml.git;a=summary This is a snapshot at commit d3ed8dcf1b0a6a8a855ceecbe0bb97f21e6665e3, which has all the features we need (and that builds fine). It is expected to stay synchronized with upstream, until there is a new upstream release, and it will be widespread enough. --- .gitignore

libvirt-ocaml is used only by virt-v2v, so move it to this repository, instead of having it around in the common submodule. The removal from common will happen later. Pino Toscano (2): common: Bundle the libvirt-ocaml library for use by virt-v2v build: switch embedded copy of libvirt-ocaml .gitignore | 2 + 3rdparty/libvirt-ocaml/Makefile.am |

Hi, this is a mostly done attempt to switch to ocaml-libvirt, embedding the latest version of it from git. This way, it is possible to improve the way v2v connects to libvirt for both input, and output modules, and interacts with libvirt (e.g. no more virsh calls needed in virt-v2v). As side effect, virt-v2v now requires libvirt, as keeping it optional would create too much burden. I could not

Hi, this is a mostly done attempt to switch to ocaml-libvirt, embedding the latest version of it from git. This way, it is possible to improve the way v2v connects to libvirt for both input, and output modules, and interacts with libvirt (e.g. no more virsh calls needed in virt-v2v). As side effect, virt-v2v now requires libvirt, as keeping it optional would create too much burden. I could not

Hi, this is a mostly done attempt to switch to ocaml-libvirt, embedding the latest version of it from git. This way, it is possible to improve the way v2v connects to libvirt for both input, and output modules, and interacts with libvirt (e.g. no more virsh calls needed in virt-v2v). As side effect, virt-v2v now requires libvirt, as keeping it optional would create too much burden. I could not

Hi, this series switches virt-2v to ocaml-libvirt, embedding the latest version of it from git. This way, it is possible to improve the way v2v connects to libvirt for both input, and output modules, and interacts with libvirt (e.g. no more virsh calls needed in virt-v2v). As side effect, virt-v2v now requires libvirt, as keeping it optional would create too much burden. I could not test all