Bug 1264384 - changing disk io limit removes disk
Summary: changing disk io limit removes disk
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-18 10:39 UTC by Dominik Perpeet
Modified: 2015-09-18 15:23 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2015-09-18 13:39:35 UTC
Embargoed:


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

Description Dominik Perpeet 2015-09-18 10:39:04 UTC
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.

Comment 1 Stef Walter 2015-09-18 12:21:52 UTC
This is causing problems with the Cockpit integration tests: https://github.com/cockpit-project/cockpit/pull/2759

Comment 2 Peter Krempa 2015-09-18 13:39:35 UTC
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 14:29:44 UTC
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 15:23:00 UTC
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.