Previously, VDSM did not extend thin-provisioned disks on block domains if the pool type had been "file" and the VDSM cache had not been cleared. This resulted in situations in which virtual machines failed to set up, and a "no space error" appeared.
Now, VDSM extends thin-provisioned disks on block domains even if the pool type had been "file" and the VDSM cache had not been cleared.
Created attachment 884574[details]
vdsm+engine logs
Description of problem:
The error seems to results due to something dirty in vdsm's cache.
When creating a DC with pool type,file,restarting vdsm service,and then migrating master domain to block,vdsm won't extend thin provision block disk,an OS installation will pause with error:
** VM NAME has paused due to no Storage space error **
From vdsm logs we see that it keeps looping through extend requests:
Thread-79::INFO::2014-04-09 19:14:19,299::logUtils::47::dispatcher::(wrapper) Run and protect: sendExtendMsg, Return response: None
Version-Release number of selected component (if applicable):
Release:
Red Hat Enterprise Linux Server release 6.5 (Santiago)
Version:
vdsm-4.14.6-0.1.beta3.el6ev.x86_64
rhevm-3.4.0-0.13.beta3.el6ev.noarch
rhevm-webadmin-portal-3.4.0-0.13.beta3.el6ev.noarch
How reproducible:
100%
Steps to Reproduce:
1.create shared DC
2.Create NFS SD
3.restart vdsm service (/etc/init.d/vdsmd restart)
4.Create ISCSI SD
5.disable NFS(master) and activate it
6.create a VM with thin provision ISCSI disk and try to install OS
Actual results:
Installation process stops with "no space error" (2014-Apr-09, 19:01)
Expected results:
Installation should succeed
Additional info:
**After step 6:
**When restarting vsdm's service the installation process continues and **finishes successfully.
Zac, the doc text added is not accurate.
To quote:
> Previously, VDSM did not extend thin-provisioned disks on block domains if the
> pool type had been "file" and the VDSM cache had not been cleared.
This is a bug we encountered during 3.4's development cycle, which was never released to customers/partners, and there's no point in adding a doctext for it.
In 3.3 (and previous versions, AFAIK, since 3.0), the SPM was used to extend thinly provishioned disks on block domains via notifications in the mailbox. The change in 3.4 is that we create and monitor mailboxes on file domains too, since there MIGHT be block domains in the same DC as block domains.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
http://rhn.redhat.com/errata/RHBA-2014-0504.html
Created attachment 884574 [details] vdsm+engine logs Description of problem: The error seems to results due to something dirty in vdsm's cache. When creating a DC with pool type,file,restarting vdsm service,and then migrating master domain to block,vdsm won't extend thin provision block disk,an OS installation will pause with error: ** VM NAME has paused due to no Storage space error ** From vdsm logs we see that it keeps looping through extend requests: Thread-79::INFO::2014-04-09 19:14:19,299::logUtils::47::dispatcher::(wrapper) Run and protect: sendExtendMsg, Return response: None Version-Release number of selected component (if applicable): Release: Red Hat Enterprise Linux Server release 6.5 (Santiago) Version: vdsm-4.14.6-0.1.beta3.el6ev.x86_64 rhevm-3.4.0-0.13.beta3.el6ev.noarch rhevm-webadmin-portal-3.4.0-0.13.beta3.el6ev.noarch How reproducible: 100% Steps to Reproduce: 1.create shared DC 2.Create NFS SD 3.restart vdsm service (/etc/init.d/vdsmd restart) 4.Create ISCSI SD 5.disable NFS(master) and activate it 6.create a VM with thin provision ISCSI disk and try to install OS Actual results: Installation process stops with "no space error" (2014-Apr-09, 19:01) Expected results: Installation should succeed Additional info: **After step 6: **When restarting vsdm's service the installation process continues and **finishes successfully.