Created attachment 839072 [details] engine, vdsm, libvirt and qemu logs Description of problem: Engine allows user to allocate a value of guaranteed RAM memory to VM which is higher than the actually memory size. Version-Release number of selected component (if applicable): is27 rhevm-3.3.0-0.40.rc.el6ev.noarch How reproducible: 100% Steps to Reproduce: 1. create a VM with 1G of RAM memory size and install OS 2. power off the VM and edit its guaranteed memory size to 2GB without changing the actual memory size Actual results: Engine doesn't block user from setting a higher value of guaranteed RAM memory size than the actual RAM memory size. Expected results: The operation should be blocked by engine Additional info: engine, vdsm, libvirt and qemu logs
I wouldn't even fix this....why block it, it does no harm. Wontfix?
well, we can, i thought it might be confusing, setting guaranteed mem will use the host memory, although the vm wouldnt be able to use it, no?
(In reply to Omer Frenkel from comment #2) > well, we can, i thought it might be confusing, setting guaranteed mem will > use the host memory, although the vm wouldnt be able to use it, no? Actually guaranteed is being used for scheduling. So it may fail scheduling in some scenarios. From SLA perspective it should be fixed.
I know it doesn't seems to make a real sense to have more, but exactly for scheduling purposes I don't see a reason why block it. There might be various reasons why someone would want to do that, to trigger a specific scheduler behavior. Whereas blocking it doesn't really help anything
(In reply to Michal Skrivanek from comment #4) > I know it doesn't seems to make a real sense to have more, but exactly for > scheduling purposes I don't see a reason why block it. There might be > various reasons why someone would want to do that, to trigger a specific > scheduler behavior. Whereas blocking it doesn't really help anything so any objection to close it as won't-fix?
(In reply to Arik from comment #5) > (In reply to Michal Skrivanek from comment #4) > > I know it doesn't seems to make a real sense to have more, but exactly for > > scheduling purposes I don't see a reason why block it. There might be > > various reasons why someone would want to do that, to trigger a specific > > scheduler behavior. Whereas blocking it doesn't really help anything > > so any objection to close it as won't-fix? Yes. Currently mom is enforcing a minimum of "Guaranteed RAM" for each vm. If this is more than the maximum allowed we're getting into useless error-flows. So if you feel like changing mom and all relevant logic to the new behavior this issue reveals, please let us know. If not, this issue /has/ to be fixed.
(In reply to Doron Fediuck from comment #6) alright, then it contradicts my assumption of "no harm":-) mom error-flows should be fixed regardless, but fixing this bug makes sense as well then. Do you want to take ownership of this one perhaps?
http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commit;h=6da12e2e038c14ba13752630e49c789b3c035f15
Not fixed, checked following exactly the same steps as described by Elad. Used repos and rhevm version: rhevm-3.4.0-0.5.master.el6ev.noarch [root@dhcp163-99 ~]# rpm -qa rhevm rhevm-3.4.0-0.5.master.el6ev.noarch [root@dhcp163-99 ~]# cat /etc/yum.repos.d/rhev.repo [qa-latest] name=QA Latest build baseurl=http://bob.eng.lab.tlv.redhat.com/builds/av5/el6/ enabled=1 gpgcheck=0 [rhel-65] name=RHEL_65 baseurl=http://globalsync.qa.lab.tlv.redhat.com/pub/rhel/released/RHEL-6/6.5/Server/x86_64/os/ enabled=1 gpgcheck=0 [rhel-65-optional] name=RHEL_65_OPTIONAL baseurl=http://globalsync.qa.lab.tlv.redhat.com/pub/rhel/released/RHEL-6/6.5/Server/optional/x86_64/os/ enabled=1 gpgcheck=0 [rhel-65-zstream] name=RHEL_65_Z baseurl=http://download.eng.bos.redhat.com/rel-eng/repos/RHEL-6.5-Z/x86_64/ enabled=1 gpgcheck=0 [JBoss_latest] name=jboss_latest baseurl=http://download.devel.redhat.com/devel/candidates/JBEAP/JBEAP-6.2.2.CP.CR2/rpms/jbappplatform-6.2-x86_64-server-6-rpm/ enabled=1 gpgcheck=0 [JBoss_stable] name=jboss_stable baseurl=http://download.eng.rdu2.redhat.com/released/JBEAP-6/6.2.1/puddle/x86_64/os/ enabled=1 gpgcheck=0
av5 should be tested with rhevm-3.4.0-0.12 (instead of rhevm-3.4.0-0.5)
Please provide the link for latest repo as I'm using this one: [qa-latest] name=QA Latest build baseurl=http://bob.eng.lab.tlv.redhat.com/builds/av5/el6/ enabled=1 gpgcheck=0 root@dhcp163-99 ~]# yum info rhevm Loaded plugins: product-id, rhnplugin, security, subscription-manager, versionlock This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register. This system is receiving updates from RHN Classic or RHN Satellite. Installed Packages Name : rhevm Arch : noarch Version : 3.4.0 Release : 0.5.master.el6ev Size : 1.5 M Repo : installed From repo : qa-latest Summary : Management server for Open Virtualization URL : http://www.redhat.com/products/virtualization License : ASL 2.0 Description : Red Hat Enterprise Virtualization is a feature-rich server virtualization management : system that provides advanced capabilities for managing Red Hat : virtualization infrastructure for Servers and Desktops.
My misconfiguration issues, didn't knew that I should run "rhevm-setup" after "yum update rhevm-setup". Now after getting to right version, test flow gives results as expected. System returns an error and blocks user from the action as follows: Error while executing action: RHEL6_5_VM3: Cannot edit VM. Physical Memory Guaranteed cannot exceed Memory Size.
*** Bug 1102664 has been marked as a duplicate of this bug. ***
Closing as part of 3.4.0