Bug 1267123 - SmartState Analysis failed with [No root filesystem found] error
SmartState Analysis failed with [No root filesystem found] error
Status: CLOSED WORKSFORME
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: SmartState Analysis (Show other bugs)
5.4.0
Unspecified Unspecified
high Severity high
: GA
: 5.6.0
Assigned To: Hui Song
Vadim Rutkovsky
rhev:smartstate:retest
:
Depends On:
Blocks: 1267595 1290167
  Show dependency treegraph
 
Reported: 2015-09-28 23:45 EDT by Chen
Modified: 2016-02-09 10:16 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1267595 1290167 (view as bug list)
Environment:
Last Closed: 2016-02-09 10:16:07 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
evm.log (3.74 MB, application/x-gzip)
2015-09-28 23:45 EDT, Chen
no flags Details
disk format of lrlwks01 (7.93 KB, text/plain)
2015-10-27 21:55 EDT, Chen
no flags Details
bd154b8e-5da5-4e6d-8e54-e7df4c757681 disk format (4.04 KB, text/plain)
2015-10-30 03:20 EDT, Chen
no flags Details
4d2a8a61-202b-496b-acb4-620933417f12 disk format (4.20 KB, text/plain)
2015-10-30 03:20 EDT, Chen
no flags Details

  None (edit)
Description Chen 2015-09-28 23:45:23 EDT
Created attachment 1078158 [details]
evm.log

Description of problem:

SmartState Analysis failed with [No root filesystem found] error

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

CFME 5.4

Two data centres in RHEV and one is FC the other one is NFS. The only one CFME appliance resides in the FC storage domain.

The problematic VM is in NFS storage domain.


How reproducible:

100%

Actual results:

[----] E, [2015-09-29T10:08:26.615502 #30126:377e90] ERROR -- : Q-task_id([ff90ea7c-6624-11e5-8e1a-001a4a405620]) Unable to mount filesystem.  Reason:[No root filesystem found.] for VM [/mnt/vm/ff90ea7c-6624-11e5-8e1a-001a4a405620/rhev/data-center/da3dee7f-2099-4dfc-8820-f348627166c1/mastersd/master/vms/bd154b8e-5da5-4e6d-8e54-e7df4c757681/bd154b8e-5da5-4e6d-8e54-e7df4c757681.ovf]

Expected results:

The SmartState Analysis should succeed

Additional info:
Comment 2 Chen 2015-09-28 23:45:48 EDT
The database of RHEVM has been collected as log collector and it has been uploaded to dropbox. 

Filename: sosreport-LogCollector-20150928094340.tar.xz
Comment 5 Chen 2015-10-07 22:12:39 EDT
Hi,

Do we have any update on this error message ? What kind of additional information do we need to provide ?

Chen
Comment 6 Rich Oliveri 2015-10-09 14:16:10 EDT
Can you scan anything in the NFS domain? I would think any attempt to scan those VMs will fail.

For RHEV, appliances scan VMs that reside in the same datacenter as the appliance, so you'll need an appliance in the NFS datacenter in order to scan those VMs. However, I would expect it to fail with a "no available proxy" error.
Comment 7 Chen 2015-10-09 23:10:49 EDT
Hi Rich,

>Can you scan anything in the NFS domain? I would think any attempt to scan those VMs will fail.

The customer could scan the VMs but only some of them came to an error.

>For RHEV, appliances scan VMs that reside in the same datacenter as the appliance, so you'll need an appliance in the NFS datacenter in order to scan those VMs. However, I would expect it to fail with a "no available proxy" error.

So for the customer's environment, we need two appliances to do the scan and one is for NFS while the other one is for FC. Otherwise no available proxy error would be encountered ?

According to our doc, only FC needs one appliance residing in the same DC but NFS doesn't have this restriction.

Best Regards,
Chen
Comment 8 Rich Oliveri 2015-10-12 11:46:08 EDT
Pre 5.5 versions of the code assume one storage type per-datacenter, and one appliance per-datacenter. So, proxy selection is done by datacenter. For FC, the requirement is a hard one - it's the only way the lun can be mapped to the appliance. The criteria for NFS should be based on network connectivity, but we don't have enough information to do that reliably - so we just base it on the datacenter as well. I find the fact that some of the NFS scans succeed, confusing.
Comment 9 Chen 2015-10-12 21:59:09 EDT
Hi Rich,

Thank you for your information about one appliance per datacenter.

Yes now the problem is that some of the VMs are succeeding the scans. I hope Hui could give his valuable opinions.

Chen
Comment 14 Chen 2015-10-23 01:35:01 EDT
Hi Hui,

Would you please let me know which debug option you want to enable for further investigation and which log file you want to collect ?

Chen
Comment 16 Chen 2015-10-26 22:24:57 EDT
Hi Hui,

Here is the feedback from the customer.

~~~
There appears to be an issue there.

This is the output i get:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<disks/>


For other servers I get a lot more information.
~~~

It seems that no disk info is found by api call. This is the RHEV side problem ?

Best Regards,
Chen
Comment 18 Chen 2015-10-27 21:54:58 EDT
Hi Hui,

Sorry that the customer provided wrong information. Here is the newest information I got from the customer I will attach it. 

Best Regards,
Chen
Comment 19 Chen 2015-10-27 21:55 EDT
Created attachment 1087131 [details]
disk format of lrlwks01
Comment 22 Chen 2015-10-30 03:20 EDT
Created attachment 1087824 [details]
bd154b8e-5da5-4e6d-8e54-e7df4c757681 disk format
Comment 23 Chen 2015-10-30 03:20 EDT
Created attachment 1087825 [details]
4d2a8a61-202b-496b-acb4-620933417f12 disk format
Comment 24 Chen 2015-10-30 03:22:03 EDT
Hi Hui,

I uploaded the disk format requested. 

Best Regards,
Chen
Comment 32 Hui Song 2016-02-09 10:16:07 EST
Cannot be reproduced neither in 5.4 and 5.5. Issue closed.

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