Description of problem: VMPool size update not working via REST Version-Release number of selected component (if applicable): rhevm-3.4.2-0.0.2.20140825gita78caee.root.el6ev.noarch How reproducible: Always Steps to Reproduce: 1. Create vm pool with two vms 2. Update vm pool size via REST: on link ovirt-engine/api/vmpools/vm_pool_id run <vmpool> <size>3</size> </vmpool> 3. Actual results: <fault> <reason>Operation Failed</reason> <detail> [Cannot edit VM-Pool. Selected operating system is not supported by the architecture.] </detail> </fault> Expected results: Update success Additional info: if I run with description <vmpool> <description>Some new description</description> <size>3</size> </vmpool> Rest also show error, but description updated
We already had this problem when creating VMs directly, and it was fixed by the following patch: core, webadmin, restapi: Fix VM creation with blank template http://gerrit.ovirt.org/20667 But this didn't covered the flows where VM creation is triggered internally. This means that when VMs are created for a pool the OS isn't selected correctly. I think that the right way to solve this issue is to change the backend so that it will always automatically select the OS according to the architecture, changing the default value of VmStatic.osId to OsRepository.AUTO_SELECT_OS. We should also remove the special treatment from the REST API. I'm attaching a patch, but I can't verify it as I don't have a PPC system to test.
Created attachment 943345 [details] Proposed patch to fix the issue
pending 3.5 backport
We have ppc build for 3.5?
I think it would be better to use the fake ppc64 mode in the x86 builds. Install the faqemu hook add the following attributes to the vdsm.conf: fake_kvm_support = true fake_kvm_architecture = ppc64 Restart VDSM and the host will behave like a ppc64 host (remember to not do it if the host is inside a x86 cluster already).
Hi I did all steps that you described above, but I have error: 2014-10-20 12:34:00,730 ERROR [org.ovirt.engine.core.bll.HandleVdsCpuFlagsOrClusterChangedCommand] (DefaultQuartzScheduler_Worker-82) [6edeb7d0] Could not find server cpu for server 4ae674db-1cd0-4750-8934-40e94b0eea86:alma07.qa.lab.tlv.redhat.com, flags: powernv,model_POWER7_v2.3 2014-10-20 12:34:00,744 INFO [org.ovirt.engine.core.bll.SetNonOperationalVdsCommand] (DefaultQuartzScheduler_Worker-82) [1227b88b] Running command: SetNonOperationalVdsCommand internal: true. Entities affected : ID: 4ae674db-1cd0-4750-8934-40e94b0eea86 Type: VDS 2014-10-20 12:34:00,746 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (DefaultQuartzScheduler_Worker-82) [1227b88b] START, SetVdsStatusVDSCommand(HostName = alma07.qa.lab.tlv.redhat.com, HostId = 4ae674db-1cd0-4750-8934-40e94b0eea86, status=NonOperational, nonOperationalReason=CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER, stopSpmFailureLogged=false), log id: 2f71becb 2014-10-20 12:34:00,750 INFO [org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand] (DefaultQuartzScheduler_Worker-82) [1227b88b] FINISH, SetVdsStatusVDSCommand, log id: 2f71becb 2014-10-20 12:34:00,763 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (DefaultQuartzScheduler_Worker-82) [1227b88b] Correlation ID: 6edeb7d0, Call Stack: null, Custom Event ID: -1, Message: Host alma07.qa.lab.tlv.redhat.com moved to Non-Operational state as host CPU type is not supported in this cluster compatibility version or is not supported at all 2014-10-20 12:34:00,767 INFO [org.ovirt.engine.core.bll.HandleVdsVersionCommand] (DefaultQuartzScheduler_Worker-82) [682273c3] Running command: HandleVdsVersionCommand internal: true. Entities affected : ID: 4ae674db-1cd0-4750-8934-40e94b0eea86 Type: VDS 2014-10-20 12:34:00,768 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-82) [682273c3] Host 4ae674db-1cd0-4750-8934-40e94b0eea86 : alma07.qa.lab.tlv.redhat.com is already in NonOperational status for reason CPU_TYPE_INCOMPATIBLE_WITH_CLUSTER. SetNonOperationalVds command is skipped. I see that my host have flags: powernv,model_POWER7_v2.3, but minimum cluster cpu is POWER8, so if I have any possibility to change fake emulation cpu from POWER7_v2.3 to POWER8?
Sure, there is a way (sorry, I thought that this patch was already applied in the VDSM version you are using). Find the caps.py in /usr/share/vdsm and change the following lines from: elif targetArch == Architecture.PPC64: caps['cpuModel'] = 'POWER 7 (fake)' caps['cpuFlags'] = 'powernv,model_POWER7_v2.3' else: raise RuntimeError('Unsupported architecture: %s' % targetArch) into this: elif targetArch == Architecture.PPC64: caps['cpuModel'] = 'POWER 8 (fake)' caps['cpuFlags'] = 'powernv,model_power8' else: raise RuntimeError('Unsupported architecture: %s' % targetArch)
Verified on rhevm-3.5.0-0.15.beta.el6ev.noarch
RHEV-M 3.5.0 has been released