Bug 1123836
Summary: | oVirt-guest-tools installer hangs on vioscsi installation | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Sander <bugzilla> |
Component: | virtio-win | Assignee: | Vadim Rozenfeld <vrozenfe> |
Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 19 | CC: | bcao, bugs, bugzilla, dfediuck, ecohen, ghammer, knoel, sbonazzo, virt-maint, vrozenfe, yvugenfi |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Windows | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-01-10 04:23:15 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Sander
2014-07-28 11:49:25 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? (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. (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.)? Vadim, what do you think is going on? (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) (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 ? (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. (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 (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. (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 (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 (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 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. (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 (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. Based on comment 17, this has nothing to do with the installer. Updating to a relevant component. Hi Sander, Could you please post SetupAPI.dev.log file? Thanks, Vadim 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. I'm unable to reproduce this bug because we no longer have this setup running. Bug can be closed. |