Red Hat Bugzilla – Bug 1264384
changing disk io limit removes disk
Last modified: 2015-09-18 11:23:00 EDT
Created attachment 1074781 [details] domain xml description (before adding a disk) Description of problem: Version-Release number of selected component (if applicable): Installed Packages Name : libvirt Arch : x86_64 Epoch : 0 Version : 1.2.13.1 Release : 2.fc22 Name : qemu Arch : x86_64 Epoch : 2 Version : 2.3.1 Release : 1.fc22 How reproducible: always Steps to Reproduce: 1. Add a domain (see attachment) 2. Add a disk device <disk type='file'> <driver name='qemu' type='raw'/> <source file='/home/dev/disk.raw'/> <serial>SLOW</serial> <address type='drive' controller='0' bus='0' target='2' unit='3'/> <target dev='sdb' bus='scsi'/> </disk> 3. Change io limit for the disk, here for vm 5 and sdb: virsh blkdeviotune --current 5 sdb --total-bytes-sec 800 Actual results: Disk isn't accessible in the guest after changing the speed. Expected results: Disk is accessible and has the io limit Additional info: If the disk is added with the <iotune> tag, it isn't even recognized in the guest even though the libvirt call (attachDeviceFlags) succeeds. Also, virsh blkdeviotune will still show info for the device.
This is causing problems with the Cockpit integration tests: https://github.com/cockpit-project/cockpit/pull/2759
So you are trying to limit the speed of the disk to 800 bytes/s. Given that a single sector is 512KiB it'll take ~11 minutes just to read 1 sector. The guest operating system probably isn't happy when it tries to read the partition table.
I'll have to correct myself. Actually, the sector is just 512bytes, so you'll be able to read a bit more than one sector per second. This still doesn't make much sense though as a useful configuration once you try to use a filesystem on top of that. At any rate I've tried the described configuration using a 10MiB image file and the kernel was able to detect the partition table. Creating a 10MiB filesystem took quite long (I actually gave up after 5 minutes and increased the speed) and mounting it took ~45 seconds when I've specified the filesystem type. A 1000MiB filesystem mount attempt failed after 5 minutes and the kernel log was filled with device timeout errors. I think the behavior is expected according to the configuration.
Thanks for thinking this through! We used trickle to limit the rate before... apparently trickle defaults input to KB, so I should have multiplied accordingly. After changing the speed to 512K it works very well!