Created attachment 981806 [details] logs Description of problem: Importing an "old" Export Domain to a new setup fails. engine logs: 2015-01-20 13:24:53,012 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp-/127.0.0.1:8702-2) [43534a79] Correlation ID: 43534a79, Job ID: f9314558-51e7-49f4-a4de-ecafbb6da7db, Call Stack: null, Custom Event ID: -1, Message: Failed to attach Storage Domain export to Data Center Default. (User: admin) 2015-01-20 13:24:53,016 INFO [org.ovirt.engine.core.bll.storage.AttachStorageDomainToPoolCommand] (ajp-/127.0.0.1:8702-2) [43534a79] Lock freed to object EngineLock [exclusiveLocks= key: 866ed921-b706-4852-b36c-bb5c16974694 value: STORAGE , sharedLocks= ] vdsm logs: operation mutex Thread-4795::ERROR::2015-01-20 13:24:52,393::dispatcher::76::Storage.Dispatcher::(wrapper) {'status': {'message': "Storage domain already attached to pool: u'domain=866ed921-b706-4852-b36c-bb5c16974694, pool=00000002-0002-0002-0002-000000000089'", 'code': 380}} Thread-4814::DEBUG::2015-01-20 13:24:52,394::lvm::502::Storage.OperationMutex::(_invalidateAllVgs) Operation 'lvm invalidate operation' released the operation mutex Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
export domain is not supported on multiple storage pools.
(In reply to Maor from comment #2) > export domain is not supported on multiple storage pools. Maor, thanx for the quick reply, first of all, as you well know, every Import operation is performed on multiple storage pools, so what you are basically saying is Export domain cannot be imported(or ImportDomain feature does not support NFS Export domain). Well, according to import domain documentation this operation is very well supported and it's mentioned several times. http://www.ovirt.org/Features/ImportStorageDomain#General_Functionality "The user flow for importing NFS Storage Domain, will be similar to importing Export/ISO domain. The user will enter the path of the storage domain and will start the import process." "General Functionality * The feature should be fully supported from oVirt 3.5. ... * Attach of a Storage domain from a disaster environment, which its meta data still indicates it is attached to another Data Center, is supported for 3.5 Data Center. " and I can go on, please do not close this as "NOTABUG" as it is on any case a bug, or RFE, professionally I believe it's the first option.
(In reply to Ori Gofen from comment #3) > (In reply to Maor from comment #2) > > export domain is not supported on multiple storage pools. > > Maor, thanx for the quick reply, first of all, as you well know, every > Import operation is performed on multiple storage pools What? I think we have our wires crossed somewhere. The only SD that can be attached to several pools AT ONCE is an ISO domain.
Allon, not at once, the flow consist from one pool which have been destroyed and one which is active, a regular ImportDomain operation nothing special.
So this is the flow we had since 3.1. I agree it's worth considering having feature parity between data and export domains, but this was not the requirement for 3.5.0. Pushing out to 3.6.0 to reconsider. Maor - can you please link the kbase article for the manual procedure?
Export Domain is not related to the Import Storage Domain feature. The ImportStorageDomain is only related to Data Storage Domains as described in the summary of the bug, http://www.ovirt.org/Features/ImportStorageDomain#Summary. Since we want eventually to get rid of the export Storage Domain, I dont think there is a reason to make it an RFE. (see https://bugzilla.redhat.com/show_bug.cgi?id=924834#c11) maybe an appropriate RFE might be to change export domain to be a Data Storage Domain to make it compatible with the ImportStorageDomain feature, but this is a whole different bug IMHO.
Well I respect you'r humble opinion Maor, please take into consideration that a lot of our major costumers use export domain to implement CloudForms with Rhevm, as well documented at https://access.redhat.com/documentation/en-US/CloudForms/3.1/html/Installing_CloudForms_on_Red_Hat_Enterprise_Virtualization/sect-Installing_CloudForms.html , uploading an image to export domain is the default way to do it today and while OvfStore provides solutions to most "ExportDomain functionalities", this flow can only be executed with ExportDomain.
Update to this RFE, after a discussion with Maor, about the desired flow that handles this issue, it was agreed that importing an export domain operation should turn the export domain to data domain before importing. the result will be an Nfs data domain that contains all it's recovered entities.
(In reply to Ori Gofen from comment #9) > Update to this RFE, after a discussion with Maor, about the desired flow > that handles this issue, it was agreed that importing an export domain > operation should turn the export domain to data domain before importing. > the result will be an Nfs data domain that contains all it's recovered > entities. It should be OPTIONAL to do so. We definitely don't want to "blindly" convert domain types.
*** This bug has been marked as a duplicate of bug 1130991 ***