Description of problem: Migration fails instantly ---vdsm--- Thread-1032286::DEBUG::2014-06-27 09:01:56,303::vm::378::vm.Vm::(_startUnderlyingMigration) vmId=`27de6235-941c-4e3f-a2bb-dd596a3c381c`::starting migration to qemu+tls://130.59.114.142/system with miguri tcp ://130.59.114.142 Thread-1032287::DEBUG::2014-06-27 09:01:56,304::vm::742::vm.Vm::(run) vmId=`27de6235-941c-4e3f-a2bb-dd596a3c381c`::migration downtime thread started Thread-1032288::DEBUG::2014-06-27 09:01:56,305::vm::781::vm.Vm::(run) vmId=`27de6235-941c-4e3f-a2bb-dd596a3c381c`::starting migration monitor thread Thread-1032286::DEBUG::2014-06-27 09:01:56,388::libvirtconnection::108::libvirtconnection::(wrapper) Unknown libvirterror: ecode: 67 edom: 24 level: 2 message: unsupported configuration: Unable to find security driver for label selinux Thread-1032286::DEBUG::2014-06-27 09:01:56,388::vm::757::vm.Vm::(cancel) vmId=`27de6235-941c-4e3f-a2bb-dd596a3c381c`::canceling migration downtime thread Thread-1032286::DEBUG::2014-06-27 09:01:56,388::vm::845::vm.Vm::(stop) vmId=`27de6235-941c-4e3f-a2bb-dd596a3c381c`::stopping migration monitor thread Thread-1032287::DEBUG::2014-06-27 09:01:56,389::vm::754::vm.Vm::(run) vmId=`27de6235-941c-4e3f-a2bb-dd596a3c381c`::migration downtime thread exiting Thread-1032286::ERROR::2014-06-27 09:01:56,391::vm::239::vm.Vm::(_recover) vmId=`27de6235-941c-4e3f-a2bb-dd596a3c381c`::unsupported configuration: Unable to find security driver for label selinux Thread-1032286::ERROR::2014-06-27 09:01:56,475::vm::340::vm.Vm::(run) vmId=`27de6235-941c-4e3f-a2bb-dd596a3c381c`::Failed to migrate Traceback (most recent call last): File "/usr/share/vdsm/vm.py", line 326, in run File "/usr/share/vdsm/vm.py", line 409, in _startUnderlyingMigration File "/usr/share/vdsm/vm.py", line 868, in f File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py", line 76, in wrapper File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1178, in migrateToURI2 libvirtError: unsupported configuration: Unable to find security driver for label selinux --- Version-Release number of selected component (if applicable): From selinux enabled host with vdsm-4.13.2-0.17.el6ev to selinux disabled host with vdsm-4.13.2-0.13.el6ev How reproducible: Additional info: Seems like regression from BZ 1013617
what is the selinux configuration on both hosts?
Hi. first comment >>From selinux enabled host with vdsm-4.13.2-0.17.el6ev to selinux disabled host with vdsm-4.13.2-0.13.el6ev sosreport from latest(destination host) is attached to the BZ. sestatus from first: ]$ cat sestatus_-b SELinux status: enabled SELinuxfs mount: /selinux Current mode: enforcing Mode from config file: enforcing Policy version: 24 Policy from config file: targeted What is the "configuration" you want to examine further?
sorry, i missed this info from the first comment. in this case, this is not a bug, as the error state, migration is not supported in this configuration, where selinux policy is different on the source and migration hosts. in 3.5 the UI reports the selinux policy for the hosts, for more info please look at bug 894084
Hello Omer, It seems rather strange that BZ 1013617 was taken care of and fixed, and this is not a bug now. Until RFE (894084) is implemented, i would consider it as a bug. Furthermore, from BZ about enforcing SELinux: 1086374 "When a host changes SELinux Enforcing to SELinux permissive, host will be considered as compromised, an alert should be generated and the host should change status to non-responsive, Admin should be able to configure sVirt policy to migrate running VMs from compromised hosts before changing status to non-operational." How is the proposed RFE pattern to migrate VMs from "compromised" host should work in real life, if customers are facing the bug of not being able to migrate VMs?
I'm not sure about the details of bug 1013617 Michal, is it the same scenario? iirc, migration can work if migrating from permissive to enabled so bug 1086374 can work. but migrating from enabled to disabled doesn't work. Michal, what do you think?
(In reply to Omer Frenkel from comment #8) correct Alex, your case is from enabled->disabled; that's not supported.
(In reply to akotov from comment #7) > It seems rather strange that BZ 1013617 was taken care of and fixed well not that strange since that bug was about something else:) it was an issue on selinux enabled environment, effectively breaking VM startup on any host