Bug 1209362 - floppy fail to be accessible(Location is not available) after change from none
Summary: floppy fail to be accessible(Location is not available) after change from none
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.7
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: John Snow
QA Contact: Virtualization Bugs
Jiri Herrmann
URL:
Whiteboard:
Depends On:
Blocks: 1209707 1209708
TreeView+ depends on / blocked
 
Reported: 2015-04-07 08:02 UTC by Sibiao Luo
Modified: 2017-01-13 14:33 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
Guests cannot access floppy disks larger than 1.44 MB Guest virtual machines are currently unable to access floppy drive images larger than 1.44 MB if they are inserted while the guest is running. To work around the problem, insert the floppy drive image prior to booting the guest.
Clone Of:
: 1209707 (view as bug list)
Environment:
Last Closed: 2016-05-12 22:55:52 UTC


Attachments (Terms of Use)
floppy_fail_to_access_screenshot. (63.02 KB, image/png)
2015-04-07 08:10 UTC, Sibiao Luo
no flags Details

Description Sibiao Luo 2015-04-07 08:02:52 UTC
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):
host info:
# uname -r && rpm -q qemu-kvm
2.6.32-548.el6.x86_64
qemu-kvm-0.12.1.2-2.462.el6.x86_64
guest info:
win2012R2

How reproducible:
100%

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
virtio-win-1.7.2-2.el6.noarch
# rpm -ql virtio-win | grep win_amd64.vfd
/usr/share/virtio-win/virtio-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

Actual results:
after step 2, floppy fail to be accessible(Location is not available) after change from none, i will attach the screen-shot later.

Expected results:
it should can read the floppy file.

Additional info:

Comment 1 Sibiao Luo 2015-04-07 08:10:16 UTC
Created attachment 1011644 [details]
floppy_fail_to_access_screenshot.

Comment 2 Sibiao Luo 2015-04-07 10:03:05 UTC
(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
> virtio-win-1.7.2-2.el6.noarch
> # rpm -ql virtio-win | grep win_amd64.vfd
> /usr/share/virtio-win/virtio-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.

Best Regards,
sluo

Comment 6 John Snow 2015-04-10 22:59:46 UTC
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.

Comment 7 John Snow 2015-04-22 22:37:26 UTC
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.

Comment 10 John Snow 2016-02-01 17:19:51 UTC
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.

Comment 11 John Snow 2016-05-12 22:55:52 UTC
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.


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