I got the following error message when I tried to run a VM:
"VM's swap percentage is above the threshold. (check your configuration
parameters for Host Swap Percentage)."
After increasing the parameter BlockMigrationOnSwapUsagePercentage, the
But I don't understand the logic here:
return ((swap_total - swap_free - mem_available) * 100 /
physical_mem_mb) <= Config
So anyone can help me explain it? Thanks a lot!
If you're using settings.xml as published in Building the oVirt Engine page, you'd see we're forking for every test, in every subproject.
This behaviour was introduced to handle memory leaks in PowerMock we use in some subprojects, but is redundant in others.
Over the past month or so I've been working on removing PowerMock from as many places as possible (many thanks to mkolesni and lhornyak!), and we've got to the stage that forking is only needed in to subprojects - bll and resttypes.
The forking was defined explicitly in those two projects, so if you want to speed up your tests, just take the latest version of settings.xml from http://ovirt.org/wiki/Building_oVirt_engine#Maven_personal_settings.
I believe we should save the REST API behavior and keep using status object instead of <active>true</active> for vm nics.
We should use:
Many rest frameworks works around that <status> object in order to verify element state and we shouldn't change that behavior.
This is true also for hotplug disk
Red Hat tlv
Yesterday I encountered a situation that even though I performed local
build on my environment and deployed , engine application over JBOSS
acted as if it does not contain the changed code (upon deployment).
In the past I encountered such issues with tomcat.
I came (thanks to Juan Hernandez) with some instructions in what do do
in such a situation,
You can find them at http://ovirt.org/wiki/Building_oVirt_engine under
the Troubleshooting section
> -------- Original Message --------
> Subject: [Engine-devel] Advanced Nfs Options + NFSv4 GUI mockup
> Date: Mon, 21 May 2012 06:34:32 -0400 (EDT)
> From: Einav Cohen <ecohen(a)redhat.com>
> To: Ayal Baron <abaron(a)redhat.com>, Eldan Hildesheim
> <ehildesh(a)redhat.com>, Eldan Hildesheim <info(a)eldanet.com>,
> Miki Kenneth <mkenneth(a)redhat.com>, Andrew Cathrow
> <acathrow(a)redhat.com>, Simon Grinberg <sgrinber(a)redhat.com>,
> Alexey Chub <achub(a)redhat.com>
> CC: engine-devel(a)ovirt.org
> Please review the mock-up on the feature page:
Sorry, I just saw this.
The advanced features should be in an advanced tab (not easily accessible) in general I'd like to discourage users from changing these params.
not sure what mount options is as it is not supported for NFS.
> Comments are welcome.
> Engine-devel mailing list
IIUC originally this collection was suppose to keep all disks
that can be shared between different vms and/or available to be
attached to certain vm.
At the moment this collection contains all disks in system while
engine does not provide any search capabilities for it,
in my view it not really useful, till we add search capabilities
for being able:
1. locate <shareable>true</shareable> disks
2. distinguish between <shareable>true|false</shareable> and <active>true|false</active>
3. maybe even worth taking <active>false</active>&&<shareable>false</shareable>
out of this collection and place them under api/clusters/xxx/disks (or under DC).
this way /api/disks will only have disks that can be shared.
RedHat, ENG-Virtualization R&D
on the quantum-ovirt call today the question of live migration between
multiple technologies was raised.
iirc, you implemented the abstraction in libvirt between what the guest
sees and the actual host networking implementation for live migration.
can you please share if there are any considerations around live
migrations across different network implementations (bridge, sr-iov,
ovs, qbg, openflow, etc.)
I think the fact that when updating (PUT), we may send only the updated
xml elements violates following.
Figure 5-2: The client-server style
We next add a constraint to the client-server interaction: communication
must be stateless in nature, as in the client-stateless-server (CSS)
style of Section 3.4.3 (Figure 5-3), such that each request from client
to server must contain all of the information necessary to understand
the request, and cannot take advantage of any stored context on the
server. Session state is therefore kept entirely on the client.
Am I right? If so, this is quite huge violation. Much much bigger than
some state of SESSION_ID/TOKEN. Would caches/proxies work well with