Bug 1264384 - changing disk io limit removes disk
changing disk io limit removes disk
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
Depends On:
  Show dependency treegraph
Reported: 2015-09-18 06:39 EDT by Dominik Perpeet
Modified: 2015-09-18 11:23 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-09-18 09:39:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
domain xml description (before adding a disk) (2.53 KB, text/plain)
2015-09-18 06:39 EDT, Dominik Perpeet
no flags Details

  None (edit)
Description Dominik Perpeet 2015-09-18 06:39:04 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     :
Release     : 2.fc22

Name        : qemu
Arch        : x86_64
Epoch       : 2
Version     : 2.3.1
Release     : 1.fc22

How reproducible:

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'/>
  <address type='drive' controller='0' bus='0' target='2' unit='3'/>
  <target dev='sdb' bus='scsi'/>
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.
Comment 1 Stef Walter 2015-09-18 08:21:52 EDT
This is causing problems with the Cockpit integration tests: https://github.com/cockpit-project/cockpit/pull/2759
Comment 2 Peter Krempa 2015-09-18 09:39:35 EDT
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.
Comment 3 Peter Krempa 2015-09-18 10:29:44 EDT
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.
Comment 4 Dominik Perpeet 2015-09-18 11:23:00 EDT
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!

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