Bug 1155566 - [PPC] Qcow sparse doesn't grow on demand due to VdsBrokerObjectsBuilder ERROR
Summary: [PPC] Qcow sparse doesn't grow on demand due to VdsBrokerObjectsBuilder ERROR
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.4.3
Hardware: ppc64
OS: Unspecified
urgent
urgent
Target Milestone: ---
: 3.5.0
Assignee: Nir Soffer
QA Contact: Aharon Canan
URL:
Whiteboard: storage
Depends On: 1150015
Blocks: 1122979
TreeView+ depends on / blocked
 
Reported: 2014-10-22 11:52 UTC by Ori Gofen
Modified: 2016-02-10 16:45 UTC (History)
15 users (show)

Fixed In Version: 3.4.3-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-16 19:10:27 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
logs (1.01 MB, application/x-bzip)
2014-10-22 11:52 UTC, Ori Gofen
no flags Details

Description Ori Gofen 2014-10-22 11:52:05 UTC
Created attachment 949356 [details]
logs

Description of problem:

The Creation of a new Vm + qcow sparse block image fails during OS installation,
it seems that the image "refuses" to grow.

2014-10-22 13:34:29,573 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-85) Correlation ID: 313f94d
a, Job ID: 55e34983-d107-4357-a3dc-1c9659b1d165, Call Stack: null, Custom Event ID: -1, Message: VM vm_virtio_thin started on Host ibm-03-ppc
2014-10-22 13:35:49,900 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerObjectsBuilder] (DefaultQuartzScheduler_Worker-39) Error in parsing vm pause status. Setting value to NONE
2014-10-22 13:35:49,903 INFO  [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-39) VM vm_virtio_thin 087891ff-eb61-401d-a50a-0665cb43207d moved from Up --> Paused



Version-Release number of selected component (if applicable):
ppc-ibm

How reproducible:
100%

Steps to Reproduce:
1.create Vm+block thin provision disk
2.install OS

Actual results:
The operation fails

Expected results:
The operation should be successful sparse image should grow

Additional info:

Comment 1 Michal Skrivanek 2014-10-22 14:06:54 UTC
I suppose libvirt and qemu logs would be needed too?

Comment 2 Michal Skrivanek 2014-10-22 14:17:56 UTC
it also doesn't look like necessarily related to qcow expansion….it's just 70s after the VM was started…

Nir, may it be the missing pause code (as I see none is reported in the vdsm log)?

Comment 3 Nir Soffer 2014-10-22 15:41:52 UTC
This looks like a duplicate of bug 1127460, so this depends on 1150015.

On rhel7 you cannot use thin provisioning without fixing the udev rules. Since I did not backport the fixes to 3.4, it is expected to fail when installing an os - although not in 70 seconds.

Ori, to verify that this is the issue:
1. Start a vm with one disk
2. Find the lv name - should appear in vdsm log in the createVolume log
3. Find the device mapper device backing up the lv /dev/dm-xxx
4. Check the selinux label of the device:
   ls -Z /dev/dm-xxx
   Should be something like:
   system_r:object_r:svirt_image_t:s0:cxxx,cyyy
5. Now start os installation
6. Watch the selinux label during installation
7. When the first disk extend is performed, and the disk size
   changes from 1G to 2G, the vm will pause
8. The selinux label would be:
   system_r:object_r:fixed_disk_device_t:s0

Comment 6 Nir Soffer 2014-10-23 10:06:27 UTC
Add back needinfo for Ori (thanks bugzilla).

Comment 8 Ori Gofen 2014-10-23 12:59:48 UTC
note,this bug is dependent on BZ #1156038, VM's fail to start, hence, couldn't verify the behavior described in #3

Comment 9 Michal Skrivanek 2014-10-23 19:36:41 UTC
Ori, there's a workaround documented in that bug. You cam continue with verification of this bug

Comment 11 Ori Gofen 2014-10-28 10:25:17 UTC
Guys, sorry for the long interval :)
I've checked several block thin provision disk growth via command line and I confirm that the observed behavior is as noted at comment #3, hence, this is a duplicate of bz #1150015.

Michal, However I strongly suggest to verify this bug on powerKVM environment, it is too important to fall between the cracks, your decision.

Comment 12 Allon Mureinik 2014-10-29 10:28:06 UTC
(In reply to Ori from comment #11)
> Guys, sorry for the long interval :)
> I've checked several block thin provision disk growth via command line and I
> confirm that the observed behavior is as noted at comment #3, hence, this is
> a duplicate of bz #1150015.
> 
> Michal, However I strongly suggest to verify this bug on powerKVM
> environment, it is too important to fall between the cracks, your decision.
Agreed. Moving to QA to verify on PPC.

Comment 14 Elad 2014-10-30 14:42:45 UTC
VM installation went fine using a thin-provision disk located on block storage. Disk size grows on writing to it.



verified with latest build_39

Comment 15 Allon Mureinik 2015-02-16 19:10:27 UTC
RHEV-M 3.5.0 has been released, closing this bug.


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