search for: viostore

I think one - maybe final? - problem. How can I tell the difference between drivers for "client" versions of Windows (eg. Windows 7) and server versions of Windows (eg. Windows 2008 Server)? It seems in many or most cases the drivers are identical, eg: $ md5sum viostor/2k12/amd64/* viostor/w8/amd64/* bbe250c13bf891fd7292ccab9908a63a viostor/2k12/amd64/viostor.cat

On Tue, Nov 17, 2015 at 08:49:54PM +0000, Richard W.M. Jones wrote: > There was a copy and paste error. It should have read: > > $ md5sum viostor/2k8/amd64/* viostor/w7/amd64/* > d1132fbd27c98f25ea71a6eb4037b2f8 viostor/2k8/amd64/viostor.cat > defccbe48aca1cd97fee4d7b16053b72 viostor/2k8/amd64/viostor.inf > 6da6120368c097806e4ac7fc6b940810 viostor/2k8/amd64/viostor.pdb >

On Tue, 2015-11-17 at 19:44 +0000, Richard W.M. Jones wrote: > I think one - maybe final? - problem. How can I tell the difference > between drivers for "client" versions of Windows (eg. Windows 7) > and server versions of Windows (eg. Windows 2008 Server)? > > It seems in many or most cases the drivers are identical, eg: > > $ md5sum viostor/2k12/amd64/*

+Li Jin ----- Original Message ----- > From: "Vadim Rozenfeld" <vrozenfe@redhat.com> > To: "Richard W.M. Jones" <rjones@redhat.com> > Cc: "Roman Kagan" <rkagan@virtuozzo.com>, libguestfs@redhat.com, "Amnon Ilan" <ailan@redhat.com>, "Jeff Nelson" > <jenelson@redhat.com>, "Yan Vugenfirer"

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.

----- Original Message ----- > From: "Amnon Ilan" <ailan@redhat.com> > To: "Vadim Rozenfeld" <vrozenfe@redhat.com>, "Li Jin" <lijin@redhat.com> > Cc: "Richard W.M. Jones" <rjones@redhat.com>, "Roman Kagan" <rkagan@virtuozzo.com>, libguestfs@redhat.com, "Jeff > Nelson" <jenelson@redhat.com>,

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

There was a copy and paste error. It should have read: $ md5sum viostor/2k8/amd64/* viostor/w7/amd64/* d1132fbd27c98f25ea71a6eb4037b2f8 viostor/2k8/amd64/viostor.cat defccbe48aca1cd97fee4d7b16053b72 viostor/2k8/amd64/viostor.inf 6da6120368c097806e4ac7fc6b940810 viostor/2k8/amd64/viostor.pdb 63b05edfb75d9dc60e82ab3c0bfee701 viostor/2k8/amd64/viostor.sys af0cca02244fcfedf3209aef56610464

If a Windows boot fails and the user boots the last known good configuration, ControlSet001 will be marked as failed and no longer used. However, virt-v2v would only install viostor to ControlSet001, meaning it will fail to boot this guest after conversion. This patch looks up the current controlset and always installs registry keys to the correct one. Fixes RHBZ#644254 ---

if it works thank god for notepad2 (If it's not then be patience, I am just a windows user). Amos. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-use-single-registry-change-for-all-supported-windows.patch Type: application/octet-stream Size: 10635 bytes Desc: not available URL:

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

...ame='firstbootapp'> > > + <path>windows/rhev-apt.exe</path> > > </app> > > This seems fine. Do we have separate versions of viostor for all the > versions of Windows, or are all those just the same file? In the build system we have separate viostore for each, I have taken them from rhev-m build. > > To what extent have you tested and proven this works? I did test from first boot to complete tools installation on windows xp-sp3, 2k3-r2 32bit, 2k8-r2 64bit and 7. > > Rich. > > -- > Richard Jones, Virtualization Group,...

There are registry entries that are needed to add some other drivers. Extracting them into a function will help adding SUSE VMDP support. --- v2v/windows_virtio.ml | 311 ++++++++++++++++++++++++++++---------------------- 1 file changed, 176 insertions(+), 135 deletions(-) diff --git a/v2v/windows_virtio.ml b/v2v/windows_virtio.ml index 14ffc51..8a0b529 100644 --- a/v2v/windows_virtio.ml +++

[Partly using the mailing list as a backup again ...] This commit changes virt-v2v to make registry changes to all ControlSets, not just the CurrentControlSet. Not sure what difference if any this would make. Rich.

Hi, I am running virt-v2v under CentOS 7, I use the new libguestfs-1.27.48-1.1, and when I try to import my Windows 2008 (running perfectly using virt-manager) in my cloud oVirt, I encounter this issue : ........ libguestfs: trace: mkdir_p = 0 libguestfs: trace: case_sensitive_path "/Windows/system32/drivers/viostor.sys" libguestfs: trace: case_sensitive_path =

This patch allows paths in virt-v2v.conf to be either relative or absolute. If relative, they are relative to software-root. This allows virt-v2v.conf to use files provided by packages independent of virt-v2v. --- lib/Sys/VirtV2V/Config.pm | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/lib/Sys/VirtV2V/Config.pm b/lib/Sys/VirtV2V/Config.pm index f703152..121e774

This is my lightly tested patch which allows pre-conversion of Windows guests. You also need to supply rhsrvany.exe and firstboot scripts. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc.

Windows 7 (version 6.1) doesn't require a different driver to Windows 2008 (version 6.0), Windows Vista (version 6.0) or Windows 2008 R2 (version 6.1). They're all version 6, so we can just match on that. --- v2v/virt-v2v.conf | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/v2v/virt-v2v.conf b/v2v/virt-v2v.conf index 9fbb1cc..c3dfd30 100644 ---

The way we patch the Windows registry in order to allow it to boot off a virtio-blk drive was initially conceived by comparing the state with virtio-blk driver properly installed, to that without. However, we don't want to replicate the Windows PnP system; rather we need to apply just enough edits to make the system boot, and then let the Windows PnP manager figure out the rest. This series