Bug 1123836 - oVirt-guest-tools installer hangs on vioscsi installation
Summary: oVirt-guest-tools installer hangs on vioscsi installation
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: virtio-win
Version: 19
Hardware: x86_64
OS: Windows
medium
medium
Target Milestone: ---
Assignee: Vadim Rozenfeld
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-28 11:49 UTC by Sander
Modified: 2018-03-12 12:20 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-01-10 04:23:15 UTC


Attachments (Terms of Use)

Description Sander 2014-07-28 11:49:25 UTC
Description of problem:

The oVirt-guest-tools installer hangs on vioscsi installation, on the next reboot (after killing the installer process) windows won't start.

Problem only occurs when virtio-scsi support is enabled for the guest (default in oVirt).

Version-Release number of selected component (if applicable):
3.5_5

How reproducible:
always

Steps to Reproduce:
1. Create windows 2012 guest in oVirt.
2. Install windows guest (tested with 2012 and 2012 R2)
3. Start oVirt Guest Tools Installer
4. Ignore a couple of scary unsigned driver warnings
5. Installer hangs on "Installing the vioscsi driver..."
6. Kill the installer process
7. Reboot the guest

Actual results:
Installer hangs on "Installing the vioscsi driver..." and guest hangs on next boot.

Expected results:
Installer completes succesfully and guest boots without problems.

Additional info:
After disabling virtio-scsi support in the guest configuration the installer completes succesfully and the guest boots without problems.

Comment 1 Lev Veyde 2014-07-28 12:20:20 UTC
(In reply to Sander from comment #0)
> Description of problem:
> 
> The oVirt-guest-tools installer hangs on vioscsi installation, on the next
> reboot (after killing the installer process) windows won't start.
> 
> Problem only occurs when virtio-scsi support is enabled for the guest
> (default in oVirt).
> 
> Version-Release number of selected component (if applicable):
> 3.5_5
> 
> How reproducible:
> always
> 
> Steps to Reproduce:
> 1. Create windows 2012 guest in oVirt.
> 2. Install windows guest (tested with 2012 and 2012 R2)
> 3. Start oVirt Guest Tools Installer
> 4. Ignore a couple of scary unsigned driver warnings
> 5. Installer hangs on "Installing the vioscsi driver..."
> 6. Kill the installer process
> 7. Reboot the guest
> 
> Actual results:
> Installer hangs on "Installing the vioscsi driver..." and guest hangs on
> next boot.
> 
> Expected results:
> Installer completes succesfully and guest boots without problems.
> 
> Additional info:
> After disabling virtio-scsi support in the guest configuration the installer
> completes succesfully and the guest boots without problems.

What storage you use for installation?
(Do you use VirtIO-Block in both cases, or is it VirtIO-SCSI in the first case?)

How you install the drivers for the storage during the OS installation?

Comment 2 Sander 2014-07-28 12:34:12 UTC
(In reply to Lev Veyde from comment #1)
> What storage you use for installation?
> (Do you use VirtIO-Block in both cases, or is it VirtIO-SCSI in the first
> case?)

VirtIO-Block in both cases.

> 
> How you install the drivers for the storage during the OS installation?

I've used both the driver floppy (virtio-win-1.7.1_amd64.vfd) and slip streamed drivers, the result was the same in both cases.

Comment 3 Lev Veyde 2014-07-28 13:53:02 UTC
(In reply to Sander from comment #2)
> (In reply to Lev Veyde from comment #1)
> > What storage you use for installation?
> > (Do you use VirtIO-Block in both cases, or is it VirtIO-SCSI in the first
> > case?)
> 
> VirtIO-Block in both cases.
> 
> > 
> > How you install the drivers for the storage during the OS installation?
> 
> I've used both the driver floppy (virtio-win-1.7.1_amd64.vfd) and slip
> streamed drivers, the result was the same in both cases.

And what you are using for host (RHEL 6.x/7, Fedora etc.)?

Comment 4 Ronen Hod 2014-07-28 14:01:42 UTC
Vadim, what do you think is going on?

Comment 5 Sander 2014-07-28 14:04:13 UTC
(In reply to Lev Veyde from comment #3)
> (In reply to Sander from comment #2)
> > (In reply to Lev Veyde from comment #1)
> > > What storage you use for installation?
> > > (Do you use VirtIO-Block in both cases, or is it VirtIO-SCSI in the first
> > > case?)
> > 
> > VirtIO-Block in both cases.
> > 
> > > 
> > > How you install the drivers for the storage during the OS installation?
> > 
> > I've used both the driver floppy (virtio-win-1.7.1_amd64.vfd) and slip
> > streamed drivers, the result was the same in both cases.
> 
> And what you are using for host (RHEL 6.x/7, Fedora etc.)?

Hosts (and engine) are CentOS 6.5.
oVirt versions:
* Engine 3.4.2
* Hosts are on a lower version (vdsm version is vdsm-4.13.3-4.el6.x86_64, cluster version is 3.3)

Comment 7 Lev Veyde 2014-07-28 15:36:21 UTC
(In reply to Sander from comment #5)
> (In reply to Lev Veyde from comment #3)
> > (In reply to Sander from comment #2)
> > > (In reply to Lev Veyde from comment #1)
> > > > What storage you use for installation?
> > > > (Do you use VirtIO-Block in both cases, or is it VirtIO-SCSI in the first
> > > > case?)
> > > 
> > > VirtIO-Block in both cases.
> > > 
> > > > 
> > > > How you install the drivers for the storage during the OS installation?
> > > 
> > > I've used both the driver floppy (virtio-win-1.7.1_amd64.vfd) and slip
> > > streamed drivers, the result was the same in both cases.
> > 
> > And what you are using for host (RHEL 6.x/7, Fedora etc.)?
> 
> Hosts (and engine) are CentOS 6.5.
> oVirt versions:
> * Engine 3.4.2
> * Hosts are on a lower version (vdsm version is vdsm-4.13.3-4.el6.x86_64,
> cluster version is 3.3)

What is the source of virtio-win-1.7.1_amd64.vfd ?

Can you send me the info about the package you took this VFD from ?

Comment 9 Vadim Rozenfeld 2014-07-29 02:58:27 UTC
(In reply to Ronen Hod from comment #4)
> Vadim, what do you think is going on?

I don't know, but if it's virtio-blk in both cases (as mentioned in comment #2)
viostor driver should be used instead of vioscsi.

Comment 10 Mike Cao 2014-07-29 03:40:23 UTC
(In reply to Vadim Rozenfeld from comment #9)
> (In reply to Ronen Hod from comment #4)
> > Vadim, what do you think is going on?
> 
> I don't know, but if it's virtio-blk in both cases (as mentioned in comment
> #2)
> viostor driver should be used instead of vioscsi.

There is no way to choose vioscsi driver is only specify virtio-blk in CLI

I tested following 3 scenarios ,all can not hit this issue 

Packages
2.6.32-486.el6.x86_64
qemu-kvm-0.12.1.2-2.430.el6.x86_64
virtio-win-1.7.1-1.el7.noarch
seabios-0.6.1.2-28.el6.x86_64


1.Start Guest w/ virtio-blk-pci
/usr/libexec/qemu-kvm -name 086RNGBLUE64NQB -enable-kvm -m 6G -smp 4 -uuid d58093ff-d9da-4f75-a648-922e78eac32f -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/tmp/086RNGBLUE64NQB,server,nowait -mon chardev=charmonitor,id=monitor1,mode=control -rtc base=localtime,driftfix=slew -boot order=cd,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=test.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,serial=mike_cao,cache=none -device virtio-blk-pci,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=en_windows_server_2012_x64_dvd_915478.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/usr/share/virtio-win/virtio-win_amd64.vfd,if=none,id=drive-fdc0-0-0,format=raw,cache=none -global isa-fdc.driveA=drive-fdc0-0-0 -netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=00:52:42:0f:05:69,bus=pci.0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=isa_serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -vga cirrus  -monitor stdio

2.Start guest w/ virtio-scsi-pci
/usr/libexec/qemu-kvm -name 086RNGBLUE64NQB -enable-kvm -m 6G -smp 4 -uuid d58093ff-d9da-4f75-a648-922e78eac32f -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/tmp/086RNGBLUE64NQB,server,nowait -mon chardev=charmonitor,id=monitor1,mode=control -rtc base=localtime,driftfix=slew -boot order=cd,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=en_windows_server_2012_x64_dvd_915478.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/usr/share/virtio-win/virtio-win_amd64.vfd,if=none,id=drive-fdc0-0-0,format=raw,cache=none -global isa-fdc.driveA=drive-fdc0-0-0 -netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=00:52:42:0f:05:69,bus=pci.0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=isa_serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -vga cirrus  -monitor stdio -device virtio-scsi-pci,id=scsi0 -drive file=test_scsi.qcow2,if=none,format=qcow2,cache=none,werror=stop,rerror=stop,id=drive-scsi -device scsi-hd,bus=scsi0.0,id=scsi,drive=drive-scsi


3.start guest w/ virtio-blk-pci and virtio-scsi-pci both
/usr/libexec/qemu-kvm -name 086RNGBLUE64NQB -enable-kvm -m 6G -smp 4 -uuid d58093ff-d9da-4f75-a648-922e78eac32f -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/tmp/086RNGBLUE64NQB,server,nowait -mon chardev=charmonitor,id=monitor1,mode=control -rtc base=localtime,driftfix=slew -boot order=cd,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=test.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,serial=mike_cao,cache=none -device virtio-blk-pci,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=en_windows_server_2012_x64_dvd_915478.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/usr/share/virtio-win/virtio-win_amd64.vfd,if=none,id=drive-fdc0-0-0,format=raw,cache=none -global isa-fdc.driveA=drive-fdc0-0-0 -netdev tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=00:52:42:0f:05:69,bus=pci.0 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=isa_serial0 -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -vga cirrus  -monitor stdio -device virtio-scsi-pci,id=scsi0 -drive file=test_scsi.qcow2,if=none,format=qcow2,cache=none,werror=stop,rerror=stop,id=drive-scsi -device scsi-hd,bus=scsi0.0,id=scsi,drive=drive-scsi 

Actual Results:
All guests can running w/o hang 

Mike

Comment 11 Sander 2014-07-29 07:33:26 UTC
(In reply to Lev Veyde from comment #7)
> What is the source of virtio-win-1.7.1_amd64.vfd ?
> 
> Can you send me the info about the package you took this VFD from ?

That one is from the (RHEL6) virtio-win package.

I've just retested with the following scenarios:
(both win2012 r2 and using the drivers from ovirt-guest-tools-3.5_5 )

VM1) guest with vioscsi enabled but viostor drive.
VM2) guest with vioscsi enabled and vioscsi drive.

Results:

VM1) Windows installation works, after that oVirt Guest Tools Installer hangs on "Installing the vioscsi driver".
VM2) Windows installation hangs after choosing the vioscsi driver from the ovirt-guest-tools-3.5_5 iso.

Comment 12 Sander 2014-07-29 07:40:50 UTC
(In reply to Mike Cao from comment #10)
> (In reply to Vadim Rozenfeld from comment #9)
> > (In reply to Ronen Hod from comment #4)
> > > Vadim, what do you think is going on?
> > 
> > I don't know, but if it's virtio-blk in both cases (as mentioned in comment
> > #2)
> > viostor driver should be used instead of vioscsi.
> 
> There is no way to choose vioscsi driver is only specify virtio-blk in CLI
> 
> I tested following 3 scenarios ,all can not hit this issue 
> 
> Packages
> 2.6.32-486.el6.x86_64
> qemu-kvm-0.12.1.2-2.430.el6.x86_64
> virtio-win-1.7.1-1.el7.noarch
> seabios-0.6.1.2-28.el6.x86_64
> 
> 
> 1.Start Guest w/ virtio-blk-pci
> /usr/libexec/qemu-kvm -name 086RNGBLUE64NQB -enable-kvm -m 6G -smp 4 -uuid
> d58093ff-d9da-4f75-a648-922e78eac32f -nodefconfig -nodefaults -chardev
> socket,id=charmonitor,path=/tmp/086RNGBLUE64NQB,server,nowait -mon
> chardev=charmonitor,id=monitor1,mode=control -rtc
> base=localtime,driftfix=slew -boot order=cd,menu=on -device
> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
> file=test.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,serial=mike_cao,
> cache=none -device virtio-blk-pci,drive=drive-ide0-0-0,id=ide0-0-0 -drive
> file=en_windows_server_2012_x64_dvd_915478.iso,if=none,media=cdrom,id=drive-
> ide0-1-0,readonly=on,format=raw -device
> ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive
> file=/usr/share/virtio-win/virtio-win_amd64.vfd,if=none,id=drive-fdc0-0-0,
> format=raw,cache=none -global isa-fdc.driveA=drive-fdc0-0-0 -netdev
> tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device
> rtl8139,netdev=hostnet0,id=net0,mac=00:52:42:0f:05:69,bus=pci.0 -chardev
> pty,id=charserial0 -device isa-serial,chardev=charserial0,id=isa_serial0
> -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -vga cirrus  -monitor stdio
> 
> 2.Start guest w/ virtio-scsi-pci
> /usr/libexec/qemu-kvm -name 086RNGBLUE64NQB -enable-kvm -m 6G -smp 4 -uuid
> d58093ff-d9da-4f75-a648-922e78eac32f -nodefconfig -nodefaults -chardev
> socket,id=charmonitor,path=/tmp/086RNGBLUE64NQB,server,nowait -mon
> chardev=charmonitor,id=monitor1,mode=control -rtc
> base=localtime,driftfix=slew -boot order=cd,menu=on -device
> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
> file=en_windows_server_2012_x64_dvd_915478.iso,if=none,media=cdrom,id=drive-
> ide0-1-0,readonly=on,format=raw -device
> ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive
> file=/usr/share/virtio-win/virtio-win_amd64.vfd,if=none,id=drive-fdc0-0-0,
> format=raw,cache=none -global isa-fdc.driveA=drive-fdc0-0-0 -netdev
> tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device
> rtl8139,netdev=hostnet0,id=net0,mac=00:52:42:0f:05:69,bus=pci.0 -chardev
> pty,id=charserial0 -device isa-serial,chardev=charserial0,id=isa_serial0
> -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -vga cirrus  -monitor stdio
> -device virtio-scsi-pci,id=scsi0 -drive
> file=test_scsi.qcow2,if=none,format=qcow2,cache=none,werror=stop,rerror=stop,
> id=drive-scsi -device scsi-hd,bus=scsi0.0,id=scsi,drive=drive-scsi
> 
> 
> 3.start guest w/ virtio-blk-pci and virtio-scsi-pci both
> /usr/libexec/qemu-kvm -name 086RNGBLUE64NQB -enable-kvm -m 6G -smp 4 -uuid
> d58093ff-d9da-4f75-a648-922e78eac32f -nodefconfig -nodefaults -chardev
> socket,id=charmonitor,path=/tmp/086RNGBLUE64NQB,server,nowait -mon
> chardev=charmonitor,id=monitor1,mode=control -rtc
> base=localtime,driftfix=slew -boot order=cd,menu=on -device
> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
> file=test.qcow2,if=none,id=drive-ide0-0-0,format=qcow2,serial=mike_cao,
> cache=none -device virtio-blk-pci,drive=drive-ide0-0-0,id=ide0-0-0 -drive
> file=en_windows_server_2012_x64_dvd_915478.iso,if=none,media=cdrom,id=drive-
> ide0-1-0,readonly=on,format=raw -device
> ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive
> file=/usr/share/virtio-win/virtio-win_amd64.vfd,if=none,id=drive-fdc0-0-0,
> format=raw,cache=none -global isa-fdc.driveA=drive-fdc0-0-0 -netdev
> tap,script=/etc/qemu-ifup,downscript=no,id=hostnet0 -device
> rtl8139,netdev=hostnet0,id=net0,mac=00:52:42:0f:05:69,bus=pci.0 -chardev
> pty,id=charserial0 -device isa-serial,chardev=charserial0,id=isa_serial0
> -device usb-tablet,id=input0 -vnc 0.0.0.0:0 -vga cirrus  -monitor stdio
> -device virtio-scsi-pci,id=scsi0 -drive
> file=test_scsi.qcow2,if=none,format=qcow2,cache=none,werror=stop,rerror=stop,
> id=drive-scsi -device scsi-hd,bus=scsi0.0,id=scsi,drive=drive-scsi 
> 
> Actual Results:
> All guests can running w/o hang 
> 
> Mike

Maybe it's something specific in our setup/hardware?

Packages:

2.6.32-431.11.2.el6.x86_64
qemu-kvm-rhev-0.12.1.2-2.415.el6.8.x86_64 ( built from http://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/RHEV/SRPMS/qemu-kvm-rhev-0.12.1.2-2.415.el6_5.8.src.rpm )
virtio-win-1.7.1-1.el6_5.noarch and ovirt-guest-tools-3.5_5.iso
seabios-0.6.1.2-28.el6.x86_64


CLI for VM1 (see comment 11):
/usr/libexec/qemu-kvm -name sg2k12test_odrv -S -M rhel6.4.0 -cpu Opteron_G3 -enable-kvm -m 8192 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 88af997a-72ed-4257-a255-93b83b744557 -smbios type=1,manufacturer=oVirt,product=oVirt Node,version=6-5.el6.centos.11.2,serial=35373434-3039-4742-3830-30314544524B,uuid=88af997a-72ed-4257-a255-93b83b744557 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/sg2k12test_odrv.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2014-07-29T08:17:26,driftfix=slew -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/rhev/data-center/mnt/gnovirt01.plusine.intern:_var_iso_/99fa6d36-8254-4cba-9ee0-f86e580a1bec/images/11111111-1111-1111-1111-111111111111/SW_DVD9_Windows_Svr_Std_and_DataCtr_2012_R2_64Bit_English_-2_Core_MLF_X19-31419.ISO,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=2 -drive file=/rhev/data-center/mnt/blockSD/7b95244c-0935-44f5-a304-3c81ab1cec7b/images/0a6f9d37-46ed-4855-ba21-0eb7dab12c75/98865dcd-f990-44ff-a6d4-175a89d580c9,if=none,id=drive-virtio-disk0,format=raw,serial=0a6f9d37-46ed-4855-ba21-0eb7dab12c75,cache=none,werror=stop,rerror=stop,aio=native -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=53,id=hostnet0,vhost=on,vhostfd=54 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:01:a4:ad:12:9f,bus=pci.0,addr=0x3,bootindex=3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/88af997a-72ed-4257-a255-93b83b744557.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/88af997a-72ed-4257-a255-93b83b744557.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -vnc 0:17,password -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7

CLI for VM2 (see comment 11):

/usr/libexec/qemu-kvm -name sg2k12t_odrv_sc -S -M rhel6.4.0 -cpu Opteron_G3 -enable-kvm -m 8192 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 30b01570-9133-487e-b361-4fbde26d4379 -smbios type=1,manufacturer=oVirt,product=oVirt Node,version=6-5.el6.centos.11.2,serial=34343831-3837-4742-3838-3337324B3450,uuid=30b01570-9133-487e-b361-4fbde26d4379 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/sg2k12t_odrv_sc.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2014-07-29T08:17:50,driftfix=slew -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-scsi-pci,id=scsi0,bus=pci.0,addr=0x4 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/rhev/data-center/mnt/gnovirt01.plusine.intern:_var_iso_/99fa6d36-8254-4cba-9ee0-f86e580a1bec/images/11111111-1111-1111-1111-111111111111/SW_DVD9_Windows_Svr_Std_and_DataCtr_2012_R2_64Bit_English_-2_Core_MLF_X19-31419.ISO,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=2 -drive file=/rhev/data-center/mnt/blockSD/7b95244c-0935-44f5-a304-3c81ab1cec7b/images/62fa08e3-3d15-4bd7-89db-b702160feefc/01442e9f-7a68-4d1d-84f5-2f8a8e000629,if=none,id=drive-scsi0-0-0-0,format=raw,serial=62fa08e3-3d15-4bd7-89db-b702160feefc,cache=none,werror=stop,rerror=stop,aio=native -device scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 -netdev tap,fd=33,id=hostnet0,vhost=on,vhostfd=34 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:01:a4:ad:12:9d,bus=pci.0,addr=0x3,bootindex=3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/30b01570-9133-487e-b361-4fbde26d4379.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev socket,id=charchannel1,path=/var/lib/libvirt/qemu/channels/30b01570-9133-487e-b361-4fbde26d4379.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=org.qemu.guest_agent.0 -device usb-tablet,id=input0 -vnc 0:4,password -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6

Comment 13 Mike Cao 2014-07-29 07:54:49 UTC
(In reply to Sander from comment #11)
> (In reply to Lev Veyde from comment #7)
> > What is the source of virtio-win-1.7.1_amd64.vfd ?
> > 
> > Can you send me the info about the package you took this VFD from ?
> 
> That one is from the (RHEL6) virtio-win package.
> 
> I've just retested with the following scenarios:
> (both win2012 r2 and using the drivers from ovirt-guest-tools-3.5_5 )
> 
> VM1) guest with vioscsi enabled but viostor drive.
> VM2) guest with vioscsi enabled and vioscsi drive.
> 
> Results:
> 
> VM1) Windows installation works, after that oVirt Guest Tools Installer
> hangs on "Installing the vioscsi driver".
So you means it only happened when you adding virtio-block and virtio-scsi device at the same time during guest startup ,right ?

> VM2) Windows installation hangs after choosing the vioscsi driver from the
> ovirt-guest-tools-3.5_5 iso.

I have two questions:
1.When do you choose to installing driver ,after guest finishing installation ,or during guest installation before format disk ?
2.in comment #0 ,you said you install driver via virtio-win-1.7.1_amd64.vfd ,when you use ovirt-guest-tools and why you use it ?

Thanks,
Mike

Comment 14 Sander 2014-07-29 08:18:02 UTC
(In reply to Mike Cao from comment #13)
> (In reply to Sander from comment #11)
> > (In reply to Lev Veyde from comment #7)
> > > What is the source of virtio-win-1.7.1_amd64.vfd ?
> > > 
> > > Can you send me the info about the package you took this VFD from ?
> > 
> > That one is from the (RHEL6) virtio-win package.
> > 
> > I've just retested with the following scenarios:
> > (both win2012 r2 and using the drivers from ovirt-guest-tools-3.5_5 )
> > 
> > VM1) guest with vioscsi enabled but viostor drive.
> > VM2) guest with vioscsi enabled and vioscsi drive.
> > 
> > Results:
> > 
> > VM1) Windows installation works, after that oVirt Guest Tools Installer
> > hangs on "Installing the vioscsi driver".
> So you means it only happened when you adding virtio-block and virtio-scsi
> device at the same time during guest startup ,right ?
With this VM yes, with VM2 there was no virtio-block disk added at all.
> 
> > VM2) Windows installation hangs after choosing the vioscsi driver from the
> > ovirt-guest-tools-3.5_5 iso.
> 
> I have two questions:
> 1.When do you choose to installing driver ,after guest finishing
> installation ,or during guest installation before format disk ?
During guest installation before format disk (windows installer does not see the disk otherwise).

> 2.in comment #0 ,you said you install driver via virtio-win-1.7.1_amd64.vfd
> ,when you use ovirt-guest-tools?

I install ovirt-guest-tools after guest installation, (have also tried without virt-win-1.7.1 but with drivers from ovirt-guest-tools).

> and why you use it ?
Several reasons:
- To cleanly and easily install the ovirt guest agent (for ip info, guest shutdown etc.)
- To cleanly and easily install the other drivers/tools (network, serial, balloon).
- To test this new oVirt service/feature.
- To be able to use oVirt fully without RHEL packages (virtio-win is RHEL only AFAIK).


> 
> Thanks,
> Mike

Comment 15 Sander 2014-07-29 08:56:52 UTC
I've done one additional test:

Install a VM with a vioscsi disk and virtio-win-1.7.1 drivers, this _ALSO_ hangs.
Retry with virtio-win-1.6.8 _WORKS_

So the ovirt-guest-tools hang is probably a red herring and something else regarding vioscsi 1.7.1 + windows is broken in my setup.

ovirt-guest-tools only triggers the problem by explicitly installing the vioscsi driver.

Comment 16 Mike Cao 2014-07-29 10:17:24 UTC
(In reply to Sander from comment #15)
> I've done one additional test:
> 
> Install a VM with a vioscsi disk and virtio-win-1.7.1 drivers, this _ALSO_
> hangs.
> Retry with virtio-win-1.6.8 _WORKS_
> 
> So the ovirt-guest-tools hang is probably a red herring and something else
> regarding vioscsi 1.7.1 + windows is broken in my setup.
> 
> ovirt-guest-tools only triggers the problem by explicitly installing the
> vioscsi driver.

Can you reproduce it w/o ovirt-guest-tools used (only install driver from virtio-win-1.7.1_amd64.vfd)?

Thanks,
Mike

Comment 17 Sander 2014-07-29 10:25:03 UTC
(In reply to Mike Cao from comment #16)
> (In reply to Sander from comment #15)
> > I've done one additional test:
> > 
> > Install a VM with a vioscsi disk and virtio-win-1.7.1 drivers, this _ALSO_
> > hangs.
> > Retry with virtio-win-1.6.8 _WORKS_
> > 
> > So the ovirt-guest-tools hang is probably a red herring and something else
> > regarding vioscsi 1.7.1 + windows is broken in my setup.
> > 
> > ovirt-guest-tools only triggers the problem by explicitly installing the
> > vioscsi driver.
> 
> Can you reproduce it w/o ovirt-guest-tools used (only install driver from
> virtio-win-1.7.1_amd64.vfd)?
> 
> Thanks,
> Mike

Yes, that is exactly what I did in comment 15.

Comment 18 Doron Fediuck 2014-09-04 08:54:37 UTC
Based on comment 17, this has nothing to do with the installer.
Updating to a relevant component.

Comment 19 Vadim Rozenfeld 2014-11-25 08:04:09 UTC
Hi Sander,
Could you please post SetupAPI.dev.log file?

Thanks,
Vadim

Comment 20 Fedora End Of Life 2015-01-09 21:28:07 UTC
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 21 Sander 2018-03-12 12:20:35 UTC
I'm unable to reproduce this bug because we no longer have this setup running.
Bug can be closed.


Note You need to log in before you can comment on or make changes to this bug.