Created attachment 1274921 [details] timeline , engine & vdsm logs Description of problem: After VM import of VM from DC+cluster on version 4.0 to upgraded DC + cluster 4.1 -> VM Can not activated, error issued: "Cannot run VM. Random Number Generator device is not supported in cluster" Version-Release number of selected component (if applicable): engine: ovirt-engine-4.1.2-0.1.el7.noarch VDSM: 4.19.10.1-1 How reproducible: 100% (tried 4 times) Steps to Reproduce: 1. Create DC + cluster on v3 2. Create a VM with thin disk and create 5 snapshots 3. Create export domain on v3 DC 4. Export VM to export domain 5. Upgrade cluster &DC to version 4 6. Import the VM and verify snapshot images version 1.0 7. Create a new snapshot and verify that the images are version 1.0 8. Start the VM Actual results: VM Can not activate, error issued: "Cannot run VM. Random Number Generator device is not supported in cluster" Expected results: VM should be activated Additional info: 1) Full timeline (automation run ) attached at timeline.txt file. 2) VM name = vm_TestCase18338_REST_ISCS_2814391936 3) After the issue occurred I also tried the following: - I tried to remove & recreate same VM name on same cluster & activation worked. - I exported VM from the same cluster(4.1) then imported it back & activation worked.
- what is "on v3"? Can you please clarify exact compatibility levels for both DC and Cluster. - did this pass id 4.1.1? - I don't see the timeline.txt in attachment
(In reply to Michal Skrivanek from comment #1) > - what is "on v3"? Can you please clarify exact compatibility levels for > both DC and Cluster. v3 DC & cluster means they are at compatibility level 4.0. v4 DC & cluster means they are at compatibility level 4.1. > - did this pass id 4.1.1? This was block due to other bug solved in 4.1.2 > - I don't see the timeline.txt in attachment Added to attachment timeline.txt
Created attachment 1274942 [details] timeline , engine & vdsm logs
2017-04-28 13:44:37,162+03 WARN [org.ovirt.engine.core.bll.validator.VirtIoRngValidator] (DefaultQuartzScheduler10) [1f45555e] Random number source URANDOM is not supported in cluster 'cluster_upgrade_4_0_to_4_1' compatibility version 4.0. in AddVmTemplateCommand Is the template created in 4.0 or 4.1 compatibility?
(In reply to Michal Skrivanek from comment #4) > 2017-04-28 13:44:37,162+03 WARN > [org.ovirt.engine.core.bll.validator.VirtIoRngValidator] > (DefaultQuartzScheduler10) [1f45555e] Random number source URANDOM is not > supported in cluster 'cluster_upgrade_4_0_to_4_1' compatibility version 4.0. > > in AddVmTemplateCommand > > Is the template created in 4.0 or 4.1 compatibility? The initial template that the first VM was created was on 4.0 , I located the time in engine log : 2017-04-28 14:39:11,617+03 INFO [org.ovirt.engine.core.bll.storage.disk.CreateAllTemplateDisksCommand] (DefaultQuartzScheduler10) [73d8138d] Running command: CreateAllTemplateDisksCommand internal: true. 2017-04-28 14:39:11,814+03 WARN [org.ovirt.engine.core.bll.validator.VirtIoRngValidator] (DefaultQuartzScheduler10) [73d8138d] Random number source URANDOM is not supported in cluster 'cluster_upgrade_4_0_to_4_1' compatibility version 4. 0. This VM convention name is not URANDOM but partry psudo random : "vm_TestCase<#>_REST_<storage_type>_<mangled_time>
The first template was imported from glance, it's naming convention is similar to the VM nameing convention : templ_TestCase<#>_REST_<storage_type>_<mangled_time> in our case : templ_TestCase18340_REST_ISCS_2818065299. Anyhow, I do not get it, if this naming convention is prohibited, why let the user use it & create template & VM only to not activate VM ?
Also , please remember that when I activate the VM , DC&cluster are in v4.1. So even if this was not supported on 4.0 (which I wonder why its not blocked completly in 4.0) it should work on 4.1, right ?
BTW, if a VM is created in 4.1, it cannot be imported to 4.0, just because of the random/urandom issue?
(In reply to Yaniv Kaul from comment #8) > BTW, if a VM is created in 4.1, it cannot be imported to 4.0, just because > of the random/urandom issue? In general you can't import a VM from future versions. There is no compatibility code for any field to "downgrade" automatically. If that is requested now this would need to be a non-trivial RFE. We need to understand why would it be needed now.
Avihai, I have no idea what are you talking about in comment #5, #6 and #7. But it doesn't seem relevant. I'm asking where was the template "templ_TestCase18338_REST_ISCS_2814374392" created, in which cluster compatibility version. Can you please get the exported VM's OVF? It would be interesting to see what was exactly exported. Yaniv, I do not think this is the issue here. Supposedly the flow is ok, 4.0 VM exported and imported to 4.1 - that should work. I suspect it's not running the "upgrade".
(In reply to Michal Skrivanek from comment #10) > Avihai, I have no idea what are you talking about in comment #5, #6 and #7. > But it doesn't seem relevant. > I'm asking where was the template "templ_TestCase18338_REST_ISCS_2814374392" > created, in which cluster compatibility version. As I answered in comment #5 this template was created with cluster compatibility version v4.0 right at the beginning of the test See in timeline.txt : -> Cluster 4.0 created : 2017-04-28 14:35:15,511 - MainThread - art.rhevm_api.tests_lib.low_level.clusters - INFO - Create cluster cluster_upgrade_4_0_to_4_1 with {'data_center': 'dc_upgrade_4_0_to_4_1', 'name': 'cluster_upgrade_4_0_to_4_1', 'version': '4.0', 'cpu': 'Intel Conroe Family'} 2017-04-28 14:35:15,771 - MainThread - clusters - INFO - Using Correlation-Id: clusters_create_59798c66-0539-423c 2017-04-28 14:35:16,616 - MainThread - clusters - INFO - New entity was added 2017-04-28 14:35:16,627 - MainThread - clusters - INFO - Property 'cluster->data_center->id' has correct value: c1202922-db23-4c80-ae79-a04ba7115ee7 2017-04-28 14:35:16,629 - MainThread - clusters - INFO - Property 'cluster->name' has correct value: cluster_upgrade_4_0_to_4_1 2017-04-28 14:35:16,630 - MainThread - clusters - INFO - Property 'cluster->version->major' has correct value: 4 2017-04-28 14:35:16,630 - MainThread - clusters - INFO - Property 'cluster->version->minor' has correct value: 0 ............................................................................. -> Template imported from glance which created template 'templ_TestCase18338_REST_ISCS_2814374392' : 2017-04-28 14:37:43,930 - MainThread - storagedomains - INFO - Importing glance image from rhevm-qe-infra-glance 2017-04-28 14:37:45,749 - MainThread - storagedomains - INFO - Using Correlation-Id: storagedomains_syncAction_f04604c1-9311-43d8 2017-04-28 14:37:48,084 - MainThread - art.ll_lib.disks - INFO - Waiting for status ok on disks ['disk_TestCase18338_REST_ISCS_2814374392'] 2017-04-28 14:39:17,018 - MainThread - storagedomains - INFO - Disk disk_TestCase18338_REST_ISCS_2814374392 have been imported successfully 2017-04-28 14:39:17,018 - MainThread - art.ll_lib.jobs - INFO - Waiting for jobs ['Importing Disk .* to domain .*'] 2017-04-28 14:39:17,280 - MainThread - art.ll_lib.jobs - INFO - Active jobs: []2017-04-28 14:37:43,930 - MainThread - storagedomains - INFO - Importing glance image from rhevm-qe-infra-glance 2017-04-28 14:39:17,553 - MainThread - art.ll_lib.jobs - INFO - JOB 'Importing Disk disk_TestCase18338_REST_ISCS_2814374392 to domain upgrade_4_0_to_4_1iscsi0' TOOK 85.756 seconds 2017-04-28 14:39:17,554 - MainThread - art.ll_lib.jobs - INFO - All jobs are gone 2017-04-28 14:39:17,554 - MainThread - root - INFO - Getting all templates in cluster cluster_upgrade_4_0_to_4_1 2017-04-28 14:39:18,126 - MainThread - root - INFO - Templates in cluster: ['templ_TestCase18338_REST_ISCS_2814374392' -> Upgrade to 4.1 : 2017-04-28 14:43:56,103 - MainThread - root - INFO - Update cluster cluster_upgrade_4_0_to_4_1 with {'version': '4.1'} in comment #6& #7 I provided more information I thought was relevant (sorry it wasn't) . > Can you please get the exported VM's OVF? It would be interesting to see > what was exactly exported. Setup moved on to other tests, if this is critical I will rerun & extract. > Yaniv, I do not think this is the issue here. Supposedly the flow is ok, 4.0 > VM exported and imported to 4.1 - that should work. I suspect it's not > running the "upgrade".
Same issue occurs in another more simpler scenario without an export domain: 1. Create DC + cluster with compatibility version 4.0. 2. Create a VM with thin disk & start VM. 3. Create snapshot "snap1" . 4. Upgrade the cluster+DC to v4.1. 5. Preview the snapshot "snap1". 6. Commit the Previewed snapshot 7. Start the VM -> VM Can not activate, error issued: "Cannot run VM. Random Number Generator device is not supported in cluster" VM started at 2017-04-30 20:14:21, Logs attached.
Created attachment 1275358 [details] engine & vdsm logs scenario2
Also in scenario2 the VM name was not random at all but a simple "vm1"
This happens only when you preview the snapshot without memory. The workaround is to open the edit VM dialog and save it (with no changes). The fix will be to do call the update VM command automatically.
verified on 4.1.3.2