Description of problem:
floppy fail to be accessible(Location is not available) after change from none, this will block users to update the virito-win driver.
Version-Release number of selected component (if applicable):
# uname -r && rpm -q qemu-kvm
Steps to Reproduce:
1.launch a KVM win2012R2 guest.
# /usr/libexec/qemu-kvm -M pc -cpu Westmere -enable-kvm -m 4096 -smp 4,sockets=2,cores=2,threads=1 -no-kvm-pit-reinjection -usb -device usb-tablet,id=input0 -name sluo -uuid 990ea161-6b67-47b2-b803-19fb01d30d30 -rtc base=localtime,clock=host,driftfix=slew -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0,bus=pci.0,addr=0x3 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm.1,bus=virtio-serial0.0,id=port1 -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm.2,bus=virtio-serial0.0,id=port2 -drive file=/mnt/win2012r2-64.qcow2,if=none,id=drive-system-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x4,drive=drive-system-disk,id=system-disk,bootindex=1 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=00:01:02:B6:40:21,bus=pci.0,addr=0x5 -device virtio-balloon-pci,id=ballooning,bus=pci.0,addr=0x6 -k en-us -boot menu=on -vga std -vnc :2 -monitor stdio
2.change a virtio-win floppy to update the virtio-win driever.
# rpm -q virtio-win
# rpm -ql virtio-win | grep win_amd64.vfd
(qemu) info block
drive-system-disk: removable=0 io-status=ok file=/mnt/win2012r2-64.qcow2 ro=0 drv=qcow2 encrypted=0
ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
floppy0: removable=1 locked=0 tray-open=0 [not inserted]
sd0: removable=1 locked=0 tray-open=0 [not inserted]
(qemu) change floppy0 /usr/share/virtio-win/virtio-win_amd64.vfd
after step 2, floppy fail to be accessible(Location is not available) after change from none, i will attach the screen-shot later.
it should can read the floppy file.
Created attachment 1011644 [details]
(In reply to Sibiao Luo from comment #0)
> Description of problem:
> floppy fail to be accessible(Location is not available) after change from
> none, this will block users to update the virito-win driver.
> 2.change a virtio-win floppy to update the virtio-win driever.
> # rpm -q virtio-win
> # rpm -ql virtio-win | grep win_amd64.vfd
> (qemu) info block
> drive-system-disk: removable=0 io-status=ok file=/mnt/win2012r2-64.qcow2
> ro=0 drv=qcow2 encrypted=0
> ide1-cd0: removable=1 locked=0 tray-open=0 io-status=ok [not inserted]
> floppy0: removable=1 locked=0 tray-open=0 [not inserted]
> sd0: removable=1 locked=0 tray-open=0 [not inserted]
> (qemu) change floppy0 /usr/share/virtio-win/virtio-win_amd64.vfd
It still failed to work if you reboot the guest after you change the floppy from none.
But it worked well if boot up a KVM guest with the floopy attached at first.
Reproduced upstream using QEMU 2.3-rc2 and virtio-win-1.7.2-2.el6.noarch.
Interestingly enough, I found an older .vfd (1.2.1?) that works just fine. A newer virtio-win package, 1.7.3, also doesn't work quite right.
Will investigate further next week.
The problem is that QEMU currently decides what kind of floppy drive to emulate based on the type of floppy that is present at boot time. If a floppy is not present, it arbitrarily picks a low-density 3.5" floppy drive type.
SeaBIOS supports floppy disk controllers that report a drive with a lower-density medium inserted, but does not support the concept of a higher-density diskette being added.
and so the problem is thus: the virtio image we have shipped in recent times is a 2.88MB image, whereas virtio-1.2.1 (for instance) shipped in a 1.44MB image.
By booting with a 1.44MB image (or nothing), QEMU is "stuck" with low density drives as SeaBIOS will not let us change this at runtime. By inserting a 2.88MB image at boot time we can change between them as needed.
Workaround: Insert a 2.88 image at boot time. The virtio-win image is a prime choice.
Bumped back to RHEL 6.8 for a few reasons:
(1) This is not a customer reported bug, so I have no reason to believe anyone has been bitten by this.
(2) There is a suitable workaround, as outlined above.
(3) The changes necessary to allow swapping between 1.44 and 2.88 at will without planning ahead may require changes to the machine type to allow cross-version migration, and I am not comfortable making finnicky changes to legacy hardware so close to the snapshot date.
Therefore, though I intend to fix this upstream, it seems unlikely this will make it to 6.7.
Pushing back one last, final time.
A fix has been merged upstream, see: https://github.com/qemu/qemu/commit/1535a6d699487740b490369e44f9ca8d305463cd
However, that fix introduced a regression, and it seems wisest not to hurry the fix through the 6.8 process given that the FDC device is hard to verify correctness for.
As such, I intend to backport this for 6.9, but recommend documenting the workaround for any customer who happens to bump into this:
- high capacity (>1.44MB) floppy images must be inserted at boot time, not inserted via the "change" command later. As long as the floppy is there at boot time, you will be able to use it to install the virtio drivers. Once you have used a high-capacity floppy, you will not be able to switch back to 1.44MB floppy disk images until you reboot.
- If a customer needs the 2.88MB virtio-win floppy disk image to install virtio drivers, advise them to attach the disk in libvirt prior to starting the VM.
I failed to realize exactly *how old* the 6.* product was, and a backport to code this "delicate" does not seem wise.
Recommend a documentation of a workaround, but will fix in the 7.x product and upstream and in RHEV.