New QEMU package landing on master snapshot
by Sandro Bonazzola
Hi,
qemu-kvm-ev-2.1.2-23 for EL7 from RHOS is landing on ovirt-master-snapshot repository today.
It will obsolete qemu-kvm-rhev-1.5.3-60 currently provided by CentOS.
The package has been requested for fixing
Bug 1199014 - RHEV [RHEL7.1] - Require qemu fix for "Cannot start VMs that have more than 23 snapshots"
The package is also available from CentOS Virt SIG repository: http://cbs.centos.org/repos/virt7-testing/x86_64/os/
Help testing the new rpm is welcome.
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 8 months
Database layout for vm icons
by Jakub Niedermertl
Hi all,
I post a conversation with Eli regarding vm icons (and screenhots) there to find wide agreement on database layout. Requirements are summarized in conversation below.
Based on discussion with Eli and later with Tomas and Michal the current proposal corresponds to option (3) at https://www.lucidchart.com/documents/view/b6dbbcde-d2f5-4594-b265-6c70918... . Mapping to business entities: VmIcon class corresponding to vm_icons table, icon_info and vm_static tables are transparently joined to VmBase class.
Reasoning:
* there are no loop references that developer don't like and my perform badly in case only small (i.e. not directly referenced) icon is required (no for option (2))
* it is clean, easy to maintain, saves number of columns in vm_static table (compared to option (1)), related things are grouped together
* icon_info is joined into VmBase in order to avoid complicated caching and invalidation using timestamps (if it depends on timstamp of vm_static then unnecessary refreshes can happen, if it depends on extra timestamp in vm_static extra column is needed; and besides it brings unnecessary complexity)
I'll be glad for any comments.
Best regards
Jakub
----- Forwarded Message -----
From: "Jakub Niedermertl" <jniederm(a)redhat.com>
To: "Eli Mesika" <emesika(a)redhat.com>
Sent: Wednesday, March 18, 2015 4:44:50 PM
Subject: Re: Database layout for vm icons
I assume, based on your answer, that list of requirements was not complete (sorry for that). Other requirements are:
* if screenshot is not availble: basic userportal list shows large icons of all available VMs
* if screenshot is availble: basic userportal list shows small icons and small screenshots of all available VMS
* each of 'New VM', 'Edit VM', 'Edit Template', 'New Pool', 'Edit Pool' dialog requests one or two large icons during its opening - these dialogs contains (sometimes disabled yet visible) icon editor widget, dialogs can be invoked form extended userportal or webadmin
* icons are large (about 20kB each for png format), hence images (icons and screenshots) are cached using their guid as a key. Each image is requested at most once.
* images are downloaded on demand
* ids of predefined (associated wit operating systems) icons are precached on clients because they can't be changed while engine is running
Plus there are general assumptions:
* queries to server (= engine) are expensive (especially sequence of dependent queries)
* database joins are expensive
So:
* each update of basic userportal requires to resolve large icon ids of all available icons or (small icon ids plus small screenshot ids)
* each update of extended userportal reuqires to resolve all small icon ids
* graphics needs to be downloaded anyway, the problem is how to get ids of images
* the overall performance can depend on what users do: how many VMs have custom id, how many VMs has screenshot
* I'd like to extend my question from db layout to also how db layouts should be mapped to BE.
----- Original Message -----
> From: "Eli Mesika" <emesika(a)redhat.com>
> To: "Jakub Niedermertl" <jniederm(a)redhat.com>
> Cc: "Oved Ourfali" <oourfali(a)redhat.com>
> Sent: Wednesday, March 18, 2015 2:14:05 PM
> Subject: Re: Database layout for vm icons
>
>
>
> ----- Original Message -----
> > From: "Jakub Niedermertl" <jniederm(a)redhat.com>
> > To: "Eli Mesika" <emesika(a)redhat.com>
> > Sent: Tuesday, March 17, 2015 7:28:13 PM
> > Subject: Database layout for vm icons
> >
> > Hi Eli,
> >
> > I'm working on VM icons feature (http://www.ovirt.org/Features/VM_Icons),
> > customizable icons for userportal. This feature should by followed by vm
> > screenshots. I'd like to discuss db layout for storing icons (and
> > screenshots) since you will probably review the db related part.
> >
> > Requirements are approximately following:
> > * there are default icons (provided by us, undeletable) derived from
> > selected
> > operating system (like Tux, Windows, ...) and custom icons (uploaded by
> > users)
> > * all icons are stored in db
> > * there are two sizes for each icon (small and large), small one is
> > generally
> > different image from large one, not just a scale
> > * there are screenshots stored in same table as icons
> > * there are two sizes of each screenshot (small and large) - just scaled
> > image
> > * each vm has exactly one icon pair (small and large): default (derived
> > from
> > os) or custom (uploaded by user)
> > * each vm has at most one screenshot pair (small and large)
> > * data in vm_icons table has to be
> > - either referenced from other table, i.e. used
> > - or marked as default_for_os by operating system identifier
> > i.e. table doesn't contain any library of unused icons
> >
> > What would you suggest as most suitable layout?
> >
> > I prepared three options at
> > https://www.lucidchart.com/documents/view/b6dbbcde-d2f5-4594-b265-6c70918...
> >
> > 1) The most natural one. It consumes many columns in vm_static table.
>
> I don't like adding that which imply adding that to the VM BE and returning
> those fields also from the web admin.
>
This performs best. No need for db joins or additional queries to get image ids.
> >
> > 2) Only large icons (and screenshots) are referenced from vm_static, small
> > versions are referenced from the large version. The advantage is that
> > information about the pair is contained in one table, disadvantage is that
> > many developers doesn't like loop references.
>
> This is a hybrid solution that uses loops as you stated and I am not a hybrid
> not loops (which performs bad) in the database
It performs as (1) i.e. well for opening dialogs, basic userportal without screenshot. For extended userportal or basic userportal with many screenshots it requires one additional bulk query to resolve small icon ids (such query generally can't be cached until assumption that small icon can't be changed without changing large icon is accepted). Or VmBase entity can be mapped using joins to vm_static and vm_icons - no additional query but join for VmBase retireve.
>
> >
> > 3) Optimization of multiple columns used in version 1, it breaks 3. normal
> > form.
>
> I would go for that, only additional field in vm_static that points to the
> info , web admin stayed as is and only in user portal you will pay for
> getting the additional information.
>
If icon_info table has separate BE then there is additional query to resolve image ids all the time. If icon_info table is joined into VmBase entity then there is an additional join all the time.
> >
> > Thanks for advice.
> >
> > Best regards.
> > Jakub
> >
>
Taking into account aforementioned facts, what solution do you consider the best.
Thanks for advice.
Best regards
Jakub
9 years, 8 months
Updates on the oVirt Appliances (installation of engine and node)
by Fabian Deutsch
Hey,
lately I've updated the oVirt Engine appliance image to be based on CentOS 7,
to get away from breakage which came from the fast moving forward Fedora (previously
the appliance was based on Fedora).
Besides of that I've simplified the kickstart and Tolik added support for cloud-init,
which will hopefully help to pave the way for a better integration into hosted-engine.
Another thing I've been working was to simplify the installation of the appliance
in use cases outside of hosted-engine.
Why? Because the Engine appliance image is a good way to start testing and using Engine.
It is an installed OS (CentOS 7) with all the necessary repos set up, and engine installed.
Ready to run `engine-setup --offline --config-append=ovirt-engine-answers` to get engine set up.
So why not simplify the consumption of this nice image for everybody?
This small job [0] builds an ISO [1] with a boot menu, which can be used to install
the Engine appliance [2] directly into a VM or onto a real host.
During the installation you can set a root password which you can then use after
installation to log in.
Please note that all the relevant files (installer + os image) are pulled from Jenkins,
so the time to install heavily depends on your internet connection.
For me it takes ~20min to get from a fresh VM until Engine is running.
When you run the ISO [1] you might also see the option to install Node.
It's not the classical Node, it's rather a Node appliance [3], based on CentOS 7,
containing vdsm, glusterfs and cockpit (all from the upstream sources with the latest bits).
The appliance was simple to create is mainly a way to get the latest upstream bit's in a
clean environment, to test our Node team cockpit move.
For me it took also roughly ~20min to get this appliance up and running.
You can mirror/cache the images locally if you want to speed up this process.
Theoretically that appliance can be used as a host for Engine, but in my initial trials
I failed to attach the node to Engine. But we can probably fix that in future.
This is more research and work in progress. But I am surely interested to make this mature in future.
One important step is to get the anaconda installer images from CentOS 7.1.
The CentOS 7.0 installer images are very outdated [4] and I can not use them. Temporarily I'm using
the Fedora anaconda images, but that has other drawbacks [5].
As a last note I can tell that at least the node appliance has some testing (installation), but
should gain more.
So take all of this with care, but feel free to experiment with the boot iso and roll
out your own Engine instances.
Help to fix the node appliance and feedback in general is welcome.
- fabian
--
[0] http://jenkins.ovirt.org/job/fabiand_boo_build_testing/
[1] http://jenkins.ovirt.org/job/fabiand_boo_build_testing/lastSuccessfulBuil...
[2] http://jenkins.ovirt.org/job/ovirt-appliance_engine-3.5_master_merged/
[3] http://jenkins.ovirt.org/job/ovirt-appliance_node-3.5_master_merged/
[4] http://bugs.centos.org/view.php?id=8239
[5] https://bugzilla.redhat.com/show_bug.cgi?id=1145130
9 years, 8 months
introduce AssetProvider (huge refactor)
by Greg Sheremeta
Hi all,
[1] just landed in master. This patch introduces an AssetManager that
should always be used to get access to messages, constants, templates,
and resources. No more GWT.creating or @Injecting them into
constructors and passing them around.
If you need access to an asset in a class, use one of the following lines
of code to get at the singleton:
(in webadmin and userportal)
private final static ApplicationTemplates templates = AssetProvider.getTemplates();
private final static ApplicationResources resources = AssetProvider.getResources();
private final static ApplicationConstants constants = AssetProvider.getConstants();
private final static ApplicationMessages messages = AssetProvider.getMessages();
(in gwt-common)
private final static CommonApplicationTemplates templates = AssetProvider.getTemplates();
private final static CommonApplicationResources resources = AssetProvider.getResources();
private final static CommonApplicationConstants constants = AssetProvider.getConstants();
private final static CommonApplicationMessages messages = AssetProvider.getMessages();
(Please keep these standard variable names -- i.e., don't name them "TEMPLATES" or
"commonConstants", etc.
If you have a frontend patch pending, your rebase probably won't be clean. This
patch touches over 700 files :)
Thanks!
Greg
[1] https://gerrit.ovirt.org/#/c/38724/ (userportal, webadmin: introduce AssetProvider)
Greg Sheremeta
Red Hat, Inc.
Sr. Software Engineer, RHEV
Cell: 919-807-1086
gshereme(a)redhat.com
9 years, 8 months
[ANN] oVirt 3.5.2 Second Release Candidate is now available for testing
by Sandro Bonazzola
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The oVirt team is pleased to announce that the 3.5.2 Second Release Candidate is now
available for testing as of Mar 18th 2015.
The release candidate is available now for Fedora 20,
Red Hat Enterprise Linux 6.6, CentOS 6.6 (or similar) and
Red Hat Enterprise Linux 7.1, CentOS 7 (or similar).
This release of oVirt includes numerous bug fixes.
See the release notes [1] for a list of the new features and bugs fixed.
Please refer to release notes [1] for Installation / Upgrade instructions.
New oVirt Live and oVirt Node ISO will be available soon as well[2].
Please note that mirrors[3] may need usually one day before being synchronized.
Please refer to the release notes for known issues in this release.
[1] http://www.ovirt.org/OVirt_3.5.2_Release_Notes
[2] http://resources.ovirt.org/pub/ovirt-3.5-pre/iso/
[3] http://www.ovirt.org/Repository_mirrors#Current_mirrors
- --
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAEBAgAGBQJVCZq1AAoJEHw3u57E4QAOmj8P/2Nn3OcRKErMFXJLXeqZHaEi
vhk9MEiaSKMuPSLAfigvhAX5133czXlv1qmcLP8zQ4yqXdbkBXHptFQXWGRsFmH5
zhmy9bqUUlDFIcepMWw5Rm+LZRWKWwUVQUijnpah1l6d6w0YJoqy8hZxgeFtaFna
ytDlVBHpvLCubbjmCWRibOFd80P+z2pSk31/Y4k0vi/UIwMGnXO74vkBU+mzLuZO
mHVLueQjJORe6jEwoBeFFnen1QI/+uCpCCSm+inHoiSGxISnujhoZT1T9DmOPFJT
2i0cd7QnxmMo/aY8EoIEagCGXsIravgSW6NmrAXbJfKQ4NrylaAD/mfDhQy0tZLt
fRnANlDV2aHqdE0Cfw5LjzgOHgLrtG8cSCXL40tQI+/HGh1Av4OjnJQDbWL7dMIR
rxXn4t/hicIYPy17SM/+qo/2/2BSgR1jro17WgIn6nxAsV3YiXbHghRJ+uJRxFCJ
a8fT4vReHExRASdjjw+KMF0O3o4sqjd7ldX4aTDtuaEojYc3ducZVZDIT/L3SFPP
o+S6cWggWL/VZ7Ormts3Fkz6Il/pMAAre7NEuAk8gtARukmrMoBTz88TvvTQlNXg
ttynkryL/bPE6xsQ6nQbR0c7Iks3cYyg1T1VF7rbQyjD56X2wKJPCe+lX7Id0KqT
sJ5UIcdDI5VCHCElWzih
=QuV3
-----END PGP SIGNATURE-----
9 years, 8 months
[ACTION REQUIRED] oVirt 3.5.2 and 3.5.3 status (building RC2 today!)
by Sandro Bonazzola
Hi,
we still have 5 open blockers for 3.5.2[1]:
Bug ID Whiteboard Status Summary
1161012 infra POST task cleaning utility should erase commands that have running tasks
1187244 network POST [RHEL 7.0 + 7.1] Host configure with DHCP is losing connectivity after some time - dhclient is not running
1177220 storage ASSIGNED [BLOCKED] Failed to Delete First snapshot with live merge
1196327 virt ASSIGNED [performance] bad getVMList output creates unnecessary calls from Engine
1202360 virt POST [performance] bad getVMList output creates unnecessary calls from Engine
And 2 dependency on libvirt not yet fixed:
Bug ID Status Summary
1199182 POST 2nd active commit after snapshot triggers qemu failure
1199036 POST Libvirtd was restarted when do active blockcommit while there is a blockpull job running
ACTION: Assignee to provide ETA for the blocker bug.
Despite the blockers bug count, we're going to build RC2 today 2015-03-18 at 12:00 UTC for allowing the verification of fixed bugs and testing on
CentOS 7.1.
If you're going to test this release candidate on CentOS please be sure to have the CR[2] repository enabled and system fully updated to CentOS 7.1.
We still have 7 bugs in MODIFIED and 31 on QA[3]:
MODIFIED ON_QA Total
infra 2 10 12
integration 0 2 2
network 0 2 2
node 0 1 1
sla 2 1 3
storage 3 11 14
virt 0 4 4
Total 7 31 38
ACTION: Testers: you're welcome to verify bugs currently ON_QA.
All remaining bugs not marked as blockers have been moved to 3.5.3.
A release management entry has been added for tracking the schedule of 3.5.3[4]
A bug tracker [5] has been created for 3.5.3.
We have 32 bugs currently targeted to 3.5.3[6]:
Whiteboard NEW ASSIGNED POST Total
docs 2 0 0 2
external 1 0 0 1
gluster 4 0 1 5
infra 2 2 0 4
node 2 0 1 3
ppc 0 0 1 1
sla 4 0 0 4
storage 8 0 0 8
ux 1 0 1 2
virt 1 0 1 2
Total 25 2 5 32
ACTION: Maintainers / Assignee: to review the bugs targeted to 3.5.3 ensuring they're correctly targeted.
ACTION: Maintainers: to fill release notes for 3.5.2, the page has been created and updated here [7]
ACTION: Testers: please add yourself to the test page [8]
7 Patches have been merged for 3.5.3 and not backported to 3.5.2 branch according to Change-Id
commit 6b5a8169093357656d3e638c7018ee516d1f44bd
Author: Maor Lipchuk <mlipchuk(a)redhat.com>
Date: Thu Feb 19 14:40:23 2015 +0200
core: Add validation when Storage Domain is blocked.
Change-Id: I9a7c12609b3780c74396dab6edf26e4deaff490f
commit 7fd4dca0a7fb15d3e9179457f1f2aea6c727d325
Author: Maor Lipchuk <mlipchuk(a)redhat.com>
Date: Sun Mar 1 17:17:16 2015 +0200
restapi: reconfigure values on import data Storage Domain.
Change-Id: I2ef7baa850bd6da08ae27d41ebe9e4ad525fbe9b
commit 4283f755e6b77995247ecb9ddd904139bc8c322c
Author: Maor Lipchuk <mlipchuk(a)redhat.com>
Date: Tue Mar 10 12:05:05 2015 +0200
restapi: Quering FCP unregistered Storage Domains
Change-Id: Iafe2f2afcd0e6e68adbbbb2054c857388acc30a7
commit a3d8b687620817b38a64a3917f4440274831bca3
Author: Maor Lipchuk <mlipchuk(a)redhat.com>
Date: Wed Feb 25 17:00:47 2015 +0200
core: Add fk constraint on vm_interface_statistics
Change-Id: I53cf2737ef91cf967c93990fcb237f6c4e12a8f8
commit c8caaceb6b1678c702961d298b3d6c48183d9390
Author: emesika <emesika(a)redhat.com>
Date: Mon Mar 9 18:01:58 2015 +0200
core: do not use distinct if sort expr have func
Change-Id: I7c036b2b9ee94266b6e3df54f2c50167e454ed6a
commit 4332194e55ad40eee423e8611eceb95fd59dac7e
Author: Vered Volansky <vvolansk(a)redhat.com>
Date: Thu Mar 12 17:38:35 2015 +0200
webadmin: Fix punctuation in threshold warnings
Change-Id: If30f094e52f42b78537e215a2699cf74c248bd83
commit 773f2a108ce18e0029f864c8748d7068b71f8ff3
Author: Maor Lipchuk <mlipchuk(a)redhat.com>
Date: Sat Feb 28 11:37:26 2015 +0200
core: Add managed devices to OVF
Change-Id: Ie0e912c9b2950f1461ae95f4704f18b818b83a3b
ACTION: Authors please verify they're not meant to be targeted to 3.5.2.
[1] https://bugzilla.redhat.com/1186161
[2] http://mirror.centos.org/centos/7/cr/x86_64/
[3] http://goo.gl/UEVTCf
[4] http://www.ovirt.org/OVirt_3.5.z_Release_Management#oVirt_3.5.3
[5] https://bugzilla.redhat.com/1198142
[6] https://bugzilla.redhat.com/buglist.cgi?quicksearch=product%3Aovirt%20tar...
[7] http://www.ovirt.org/OVirt_3.5.2_Release_Notes
[8] http://www.ovirt.org/Testing/oVirt_3.5.2_Testing
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 8 months
