Has anyone else noticed that GWT Dev Mode is unbearably slow for WebAdmin? On my machine, it's to the point where I might as well rebuild the entire application for every change and not bother with Dev Mode. Pages take 4 or 5 minutes to render. Sometimes after 5 minutes, I just give up, close everything, and rebuild the app.
For now, I want to see if others have this issue. If we confirm that it's widespread, we can discuss ways to mitigate.
Red Hat, Inc.
Sr. Software Engineer, RHEV
As part of our plan to support live merging of VM disk snapshots it
seems we will need a new form of asynchronous task in ovirt-engine. I
am aware of AsyncTaskManager but it seems to be limited to managing
SPM tasks. For live merge, we are going to need something called
VmTasks since the async command can be run only on the host that
currently runs the VM.
The way I see this working from an engine perspective is:
1. RemoveSnapshotCommand in bll is invoked as usual but since the VM is
found to be up, we activate an alternative live merge flow.
2. We submit a LiveMerge VDS Command for each impacted disk. This is
an asynchronous command which we need to monitor for completion.
3. A VmJob is inserted into the DB so we'll remember to handle it.
4. The VDS Broker monitors the operation via an extension to the
already collected VmStatistics data. Vdsm will report active Block
Jobs only. Once the job stops (in error or success) it will cease
to be reported by vdsm and engine will know to proceed.
5. When the job has completed, VDS Broker raises an event up to bll.
Maybe this could be done via VmJobDAO on the stored VmJob?
6. Bll receives the event and issues a series of VDS commands to
complete the operation:
a) Verify the new image chain matches our expectations (the snap is
no longer present in the chain).
b) Delete the snapshot volume
c) Remove the VmJob from the DB
Could you guys review this proposed flow for sanity? The main
conceptual gaps I am left with concern #5 and #6. What is the
appropriate way for VDSBroker to communicate with BLL? Is there an
event mechanism I can explore or should I use the database? I am
leaning toward the database because it is persistent and will ensure
#6 gets completed even if engine is restarted somewhere in the middle.
For #6, is there an existing polling / event loop in bll that I can
Thanks in advance for taking the time to think about this flow and for
providing your insights!
We want to install the rhevm-guest-agent package on a virtual machine with
Suse Linux as the guest OS. The RHEVM 3.2 documentation provides install
instructions for RHEL and Windows guests but not for Suse Linux. This agent
is important to monitor virtual resources on guest machines, hence the need.
How can this be done?
The oVirt team is pleased to announce that the 3.4.0 Release Candidate is now available for testing.
Release notes and information on the changes for this update are still being worked on and will be available soon on the wiki.
Please ensure to follow install instruction from release notes if you're going to test it.
The existing repository ovirt-3.4.0-prerelease has been updated for delivering this release candidate and future refreshes until final release.
An oVirt Node iso is already available, unchanged from third beta.
You're welcome to join us testing this release candidate in next week test day  scheduled for 2014-03-06!
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
There is very limited documentation (ReST API)about the search query
"criteria" for searching objects. The general format is
(criteria) [sortby (elem ent) asc|desc]
I was looking for detailed information on what the criteria can or can't
support. Please guide to the appropriate source.