[Engine-devel] Asynchronous tasks for live merge
by Adam Litke
Hi all,
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
plug into?
Thanks in advance for taking the time to think about this flow and for
providing your insights!
--
Adam Litke
10 years, 2 months
[Engine-devel] Install rhevm-guest-agent on SLES guest
by Vikas Kokare
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?
10 years, 2 months
[Engine-devel] oVirt 3.4.0 branch creation
by Sandro Bonazzola
Hi,
we're going to create ovirt-engine-3.4.0 branch tomorrow morning 09:00 UTC.
oVirt 3.4.1 development will continue on ovirt-engine-3.4 branch.
Critical fixes for oVirt 3.4.0 GA will need to be pushed to 3.4.0 branch too starting tomorrow morning 09:00 UTC.
Thanks,
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 2 months
[Engine-devel] Usage of Dynamic Queries
by Liran Zelkha
Hi All,
As part of an ongoing effort to improve oVirt performance, we're trying to
reduce the number of Dynamic Queries usage in the code, and replace it with
Postgres stored procedures. You wouldn't believe the performance gain.
Please consider before making use of the Dynamic Queries feature - it
should ONLY be used for places where users can enter search queries - and
not for any other usage.
Thanks.
Liran
10 years, 2 months
[Engine-devel] [ATN] ovirt-engine dbscritps cleanup (master)
by Alon Bar-Lev
Hello All,
The dbscripts of ovirt-engine master were cleaned up, to match other scripts in tree.
Developer visible changes are:
1. Removal of create_schema.sh, upgrade.sh, cleandb.sh, refreshStoredProcedures.sh in favour of single schema.sh script, note the -c parameter.
Usage: ./schema.sh [options]
-h - This help text.
-v - Turn on verbosity (WARNING: lots of output)
-l LOGFILE - The logfile for capturing output (def. )
-s HOST - The database servername for the database (def. localhost)
-p PORT - The database port for the database (def. 5432)
-u USER - The username for the database (def. engine)
-d DATABASE - The database name (def. engine)
-m MD5FILE - Where to store schema MD5 files (def. )
-c COMMAND - Command: apply|refresh|drop
-t - Force cleaning tasks and compensation info.
2. Introduction of schema-dev.sh as a wrapper to schema.sh with defaults as a utility for developers.
- always enable md5.
- always enable logging.
- apply command as default.
3. Shell upgrade script is not receives entire settings via DBFUNC_* environment variables.
Regards,
Alon Bar-Lev
10 years, 2 months
[Engine-devel] hosted-engine rebooting in the middle of setup (was: [vdsm] [Users] [ANN] oVirt 3.4.0 Release Candidate is now available)
by Yedidyah Bar David
----- Original Message -----
> From: "Darrell Budic" <darrell.budic(a)zenfire.com>
> To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
> Cc: announce(a)ovirt.org, "engine-devel" <engine-devel(a)ovirt.org>, "arch" <arch(a)ovirt.org>, Users(a)ovirt.org, "VDSM
> Project Development" <vdsm-devel(a)lists.fedorahosted.org>
> Sent: Saturday, March 1, 2014 1:56:23 AM
> Subject: Re: [vdsm] [Users] [ANN] oVirt 3.4.0 Release Candidate is now available
>
> Started testing this on two self-hosted clusters, with mixed results. There
> were updates from 3.4.0 beta 3.
>
> On both, got informed the system was going to reboot in 2 minutes while it
> was still installing yum updates.
>
> On the faster system, the whole update process finished before the 2 minutes
> were up, the VM restarted, and all appears normal.
>
> On the other, slower cluster, the 2 minutes hit while the yum updates were
> still being installed, and the system rebooted. It continued rebooting every
> 3 minutes or so, and the engine console web pages are not available because
> the engine doesn’t start. it did this at least 3 times before I went ahead
> and reran engine-setup, which completed successfully. The system stopped
> restarting and the web interface was available again. A quick perusal of
> system logs and engine-setup logs didn’t reveal what requested the reboot.
>
> That was rather impolite of something to do that without warning :) At least
> it was recoverable. Seems like scheduling the reboot while the yum updates
> were still running seems like a poor idea as well.
Can you please post relevant logs?
hosts: /var/log/ovirt-hosted-engine-setup/*, /var/log/ovirt-hosted-engine-ha/*,
/var/log/vdsm/*
engine: /var/log/ovirt-engine/setup/*, /var/log/ovirt-engine/*
You can of course open a bug on bugzilla and attach there logs if you want.
Thanks, and thanks for the report!
--
Didi
10 years, 2 months
