Created attachment 849313 [details] src_vdsm_log Description of problem: Have two host with different CPU flags, migration vm with enabled 'Use Host CPU'(it also mean that you need to change migration options to 'Allow manual migration only') from host with high CPU to low CPU failed with libvirt error: libvirtError: unsupported configuration: guest and host CPU are not compatible: Host CPU does not provide required features: est. Version-Release number of selected component (if applicable): is31 How reproducible: Always(may give another flag in error) Steps to Reproduce: 1. Add two hosts with different CPU's, hosts with higher CPU host_high, host with lower host_low 2. Set vm "Allow manual migration only" and check "Use Host CPU" 3. Run vm on host_high and migrate it without specify destination host Actual results: Migration Failed and in vdsm log appear libvirt error. Expected results: Or give possibility to choose 'Use Host Cpu' flag only when migration option is 'Do not allow migration' or failed migration and give appropriate message in engine events. Additional info: Bug opened first as cluster policies bug https://bugzilla.redhat.com/show_bug.cgi?id=1051370#c0, but after discussion with Doron, I decide to close bug and open new bug connect to migration.
andrew - i have a vague recollection you specifically asked to not block this?
According to libvirt docs [1]- " host-passthrough ... Though the downside of this mode is that the guest environment cannot be reproduced on different hardware. Thus, if you hit any bugs, you are on your own. " So my last recollection of this was we allow the vm to start anywhere, but then it will not migrate. See: https://bugzilla.redhat.com/show_bug.cgi?id=838469#c10 And [2] that says: " Label should be "Pass through host CPU". When this is set the VM should be marked as non-migratable " [1] http://libvirt.org/formatdomain.html#elementsCPU [2] http://www.ovirt.org/Features/Cpu-host_Support#Detailed_Description
@Doron Should new/edit/other VM commands be blocked in case the VM is not pinned and pass through is on? Thanks.
(In reply to Gilad Chaplik from comment #4) > @Doron > > Should new/edit/other VM commands be blocked in case the VM is not pinned > and pass through is on? > > Thanks. What do you mean by 'new'? As for the others, shouldn't be an issue. The important thing is locking the migration options, once pass through is being used.
Check on rhevm-3.5.0-0.23.beta.el6ev.noarch Still have libvirt error and migration failed: Thread-334139::ERROR::2014-12-14 09:53:20,262::migration::260::vm.Vm::(run) vmId=`ffb6cc41-be24-4479-b7a9-3d0c714ea8fc`::Failed to migrate Traceback (most recent call last): File "/usr/share/vdsm/virt/migration.py", line 246, in run self._startUnderlyingMigration(time.time()) File "/usr/share/vdsm/virt/migration.py", line 325, in _startUnderlyingMigration None, maxBandwidth) File "/usr/share/vdsm/virt/vm.py", line 689, in f ret = attr(*args, **kwargs) File "/usr/lib/python2.6/site-packages/vdsm/libvirtconnection.py", line 111, in wrapper ret = f(*args, **kwargs) File "/usr/lib64/python2.6/site-packages/libvirt.py", line 1210, in migrateToURI2 if ret == -1: raise libvirtError ('virDomainMigrateToURI2() failed', dom=self) libvirtError: Requested operation is not valid: domain has CPU feature: invtsc
Missed patches added to the 3.5.0 branch.
Verified on rhevm-3.5.0-0.25.el6ev.noarch
rhev 3.5.0 was released. closing.