yappi rpm
by Saggi Mizrahi
As those of you that have been developing VDSM might know
some time ago yappi profiling support was added to VDSM.
This was a good idea but yappi has no fedora\el RPMs
which forced each developer to find and download yappi
from around the internet.
Also, I personally don't like using disutils as there is
no clean uninstall options (oddly enough).
I am currently in the process of getting yappi into fedora.
There are f21 RPMs (should work with older fedora and el)
for you downloading/testing pleasure [1]
Also, if you can, please help the package review process [2]
[1] https://smizrahi.fedorapeople.org/yappi/
[2] https://bugzilla.redhat.com/1155495
9 years, 5 months
Re: [ovirt-devel] [ovirt-users] Beginner
by Sven Kieske
On 24/10/14 16:37, navya sri nizamkari wrote:
> Hello, i am looking for bugs I can fix.I am new to this. Can somebody help
> me out?
>
> Thank you.
I guess devel list can help you more :)
write to devel(a)ovirt.org (cc'ed)
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
9 years, 6 months
Using libgfapi on Gluster Storage Domains
by Federico Simoncelli
Hi everyone, if you want to try and use the libgfapi support included
in qemu when accessing volumes on gluster storage domains you can try
to apply this patch:
http://gerrit.ovirt.org/33768
As far as I know Jason Brooks already tried it and he reported a
positive feedback.
What has been tested so far is:
- qemu uses libgfapi to access the disks on gluster storage domains
- hotplug of disks on gluster storage domains works as expected (libgfapi)
- hotunplug works as expected (no failure when removing a disk that is
using libgfapi)
- live snpashots work as expected
- disks of vms started before this patch are not affected (they won't
use libgfapi since there's no way to do an hot swap)
One major flow that is yet untested is live storage migration.
Remember that you may need to do some special configuration on your
gluster volumes (most notably the allow-insecure ports option) as
described here:
http://www.ovirt.org/Features/GlusterFS_Storage_Domain
Please try and test the patch if you're interested and report your
feedback.
Thanks,
--
Federico
9 years, 6 months
how (inefficient) does vdsm import sparse disks in local storage(file based) data domain?
by Sven Kieske
Hi,
I might be totally mistaken, so please tell me first if I understand
the process:
when vdsm imports a template from an export domain to local storage,
according to my "ps" output, vdsm copies sparse templates using "dd":
vdsm 14378 0.3 0.0 59032 4424 ? S<l 14:43 0:05 \_
/usr/bin/qemu-img convert -t none -f raw
/rhev/data-center/d6ec1bb0-43ce-4e09-9a7a-e54f9779af64/4ed22092-e961-4e04-b77b-2648ad21f83a/image
vdsm 17291 0.0 0.0 8344 608 ? D< 15:14 0:00 \_
/bin/dd iflag=direct
if=/rhev/data-center/mnt/$REDACTED:_home_iso/e7b8f2e2-b9f7-493c-96b5-33bfb091d0ba/dom_md/metadata
bs=4096 count=1
If this is correct I have some questions regarding this behaviour:
I understand that "dd" is "rock solid" works everywhere and for maybe
every storage/format combination and thus was maybe chosen to do the
work.
But if I'm right and I have a 100 GB sparse disk which actually
uses just 1 GB "dd" will copy the whole 100 GB over network, which
is really not efficient at all.
So here's my proposal (if I do not have any mistakes in the above):
at least make a:
tar -cpSvf disk.tar /path/to/disk
and than "dd" this over the network, because tar _can_ handle sparse
files.
Of course any other more efficient mechanism would be okay too.
If my observation is right, and the project think it's worth
to implement such a thing I would create an RFE for this
and I also would like to help code this (in my leisure time).
PS: I did observe this behaviour on ancient
ovirt 3.3 with vdsm version: vdsm-4.13.4-0.el6.x86_64
but I didn't see anything in release notes which
changed this behaviour.
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
9 years, 6 months
DAO tests are failing on master
by Idan Shaby
Hi,
Two tests are failing on class VmNumaNodeDAOTest:
- testGetAllPinnedVmNumaNodeByVdsNumaNodeId
- testGetAllVmNumaNodeByVdsNumaNodeId
The relevant part of the output:
Failed tests:
testGetAllPinnedVmNumaNodeByVdsNumaNodeId(org.ovirt.engine.core.dao.VmNumaNodeDAOTest): expected:<3c2b81e6-5080-4ad1-86a1-cf513b15b515> but was:<3c2b81e6-5080-4ad1-86a1-cf513b15b516>
testGetAllVmNumaNodeByVdsNumaNodeId(org.ovirt.engine.core.dao.VmNumaNodeDAOTest): expected:<3c2b81e6-5080-4ad1-86a1-cf513b15b515> but was:<3c2b81e6-5080-4ad1-86a1-cf513b15b516>
Tests run: 1386, Failures: 2, Errors: 0, Skipped: 0
My "mvn -version" output:
Apache Maven 3.1.1 (NON-CANONICAL_2013-11-08_14-32_mockbuild; 2013-11-08 16:32:41+0200)
Maven home: /usr/share/maven
Java version: 1.7.0_45, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.3.0.fc20.x86_64/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "3.15.10-200.fc20.x86_64", arch: "amd64", family: "unix"
Anyone knows something about this?
Thanks,
Idan
9 years, 6 months
[ATN] [ovirt-engine] engine master logging
by Alon Bar-Lev
Hello All,
Thanks to Martin Perina efforts[1] the ovirt-engine logging was cleaned up significantly throughout the engine.
1. Logging Facade is slf4j.
2. Logging backend is jboss logging at jboss and java.util.logging at standalone.
3. No more commons-logging, log4j, combinations nor proprietary loggers.
The org.ovirt.engine.core.utils.log.LogFactory and org.ovirt.engine.core.utils.log.Log are depreciated now, the correlation id is managed using logging MDC, so no need to use wrapper, and correlation has much wider effect, as also 3rd parties log records are attached with correlation id.
We will start to push changes to remove the usage of these classes in favor of plain slf4j loggers.
Quick lineup...
1. Usage:
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
class x {
private static final Logger log = LoggerFactory.getLogger(x.class);
}
2. slf4j logger javadoc is here[2].
3. Crash course:
// simple string
log.info("string");
// string with exception and stack trace
log.info("string", exception);
// string with vars, logger will call argN.toString() for each {}.
log.info("string {} {} {}", arg1, arg2, arg3);
4. *NOTICE* Major difference than what we had:
Exception arguments are not "magically" detected.
// previous (utils Log): "exception" magically detected.
log.infoFormat("string {0}", arg1, exception);
// new (slf4j):
log.info("string {}", arg1);
log.info("Exception", exception);
// better new (slf4j):
log.info("string {}", arg1);
log.debug("Exception", exception);
Please do not hesitate to raise any related issue you may find.
Regards,
Alon Bar-Lev.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1109871
[2] http://www.slf4j.org/api/org/slf4j/Logger.html
9 years, 6 months
Updated Event Invitation: Deep Dive 3.5.0 - SLA Resource Capping
by rgolan＠redhat.com
BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:Asia/Jerusalem
X-LIC-LOCATION:Asia/Jerusalem
BEGIN:DAYLIGHT
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
TZNAME:IDT
DTSTART:20130329T020000
RRULE:FREQ=YEARLY;BYDAY=FR;BYMONTHDAY=23,24,25,26,27,28,29;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
TZNAME:IST
DTSTART:20131027T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:+022054
TZOFFSETTO:+022040
TZNAME:JMT
DTSTART:18800101T000000
RDATE;VALUE=DATE-TIME:18800101T000000
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:+022040
TZOFFSETTO:+0200
TZNAME:IST
DTSTART:19180101T000000
RDATE;VALUE=DATE-TIME:19180101T000000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
TZNAME:IDT
DTSTART:19400601T000000
RDATE;VALUE=DATE-TIME:19400601T000000
RDATE;VALUE=DATE-TIME:19430401T020000
RDATE;VALUE=DATE-TIME:19440401T000000
RDATE;VALUE=DATE-TIME:19450416T000000
RDATE;VALUE=DATE-TIME:19460416T020000
RDATE;VALUE=DATE-TIME:19490501T000000
RDATE;VALUE=DATE-TIME:19500416T000000
RDATE;VALUE=DATE-TIME:19510401T000000
RDATE;VALUE=DATE-TIME:19520420T020000
RDATE;VALUE=DATE-TIME:19530412T020000
RDATE;VALUE=DATE-TIME:19540613T000000
RDATE;VALUE=DATE-TIME:19550611T020000
RDATE;VALUE=DATE-TIME:19560603T000000
RDATE;VALUE=DATE-TIME:19570429T020000
RDATE;VALUE=DATE-TIME:19740707T000000
RDATE;VALUE=DATE-TIME:19750420T000000
RDATE;VALUE=DATE-TIME:19850414T000000
RDATE;VALUE=DATE-TIME:19860518T000000
RDATE;VALUE=DATE-TIME:19870415T000000
RDATE;VALUE=DATE-TIME:19880410T000000
RDATE;VALUE=DATE-TIME:19890430T000000
RDATE;VALUE=DATE-TIME:19900325T000000
RDATE;VALUE=DATE-TIME:19910324T000000
RDATE;VALUE=DATE-TIME:19920329T000000
RDATE;VALUE=DATE-TIME:19930402T000000
RDATE;VALUE=DATE-TIME:19940401T000000
RDATE;VALUE=DATE-TIME:19950331T000000
RDATE;VALUE=DATE-TIME:19960315T000000
RDATE;VALUE=DATE-TIME:19970321T000000
RDATE;VALUE=DATE-TIME:19980320T000000
RDATE;VALUE=DATE-TIME:19990402T020000
RDATE;VALUE=DATE-TIME:20000414T020000
RDATE;VALUE=DATE-TIME:20010409T010000
RDATE;VALUE=DATE-TIME:20020329T010000
RDATE;VALUE=DATE-TIME:20030328T010000
RDATE;VALUE=DATE-TIME:20040407T010000
RDATE;VALUE=DATE-TIME:20050401T020000
RDATE;VALUE=DATE-TIME:20060331T020000
RDATE;VALUE=DATE-TIME:20070330T020000
RDATE;VALUE=DATE-TIME:20080328T020000
RDATE;VALUE=DATE-TIME:20090327T020000
RDATE;VALUE=DATE-TIME:20100326T020000
RDATE;VALUE=DATE-TIME:20110401T020000
RDATE;VALUE=DATE-TIME:20120330T020000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
TZNAME:IST
DTSTART:19421101T000000
RDATE;VALUE=DATE-TIME:19421101T000000
RDATE;VALUE=DATE-TIME:19431101T000000
RDATE;VALUE=DATE-TIME:19441101T000000
RDATE;VALUE=DATE-TIME:19451101T020000
RDATE;VALUE=DATE-TIME:19461101T000000
RDATE;VALUE=DATE-TIME:19481101T020000
RDATE;VALUE=DATE-TIME:19491101T020000
RDATE;VALUE=DATE-TIME:19500915T030000
RDATE;VALUE=DATE-TIME:19511111T030000
RDATE;VALUE=DATE-TIME:19521019T030000
RDATE;VALUE=DATE-TIME:19530913T030000
RDATE;VALUE=DATE-TIME:19540912T000000
RDATE;VALUE=DATE-TIME:19550911T000000
RDATE;VALUE=DATE-TIME:19560930T030000
RDATE;VALUE=DATE-TIME:19570922T000000
RDATE;VALUE=DATE-TIME:19741013T000000
RDATE;VALUE=DATE-TIME:19750831T000000
RDATE;VALUE=DATE-TIME:19850915T000000
RDATE;VALUE=DATE-TIME:19860907T000000
RDATE;VALUE=DATE-TIME:19870913T000000
RDATE;VALUE=DATE-TIME:19880904T000000
RDATE;VALUE=DATE-TIME:19890903T000000
RDATE;VALUE=DATE-TIME:19900826T000000
RDATE;VALUE=DATE-TIME:19910901T000000
RDATE;VALUE=DATE-TIME:19920906T000000
RDATE;VALUE=DATE-TIME:19930905T000000
RDATE;VALUE=DATE-TIME:19940828T000000
RDATE;VALUE=DATE-TIME:19950903T000000
RDATE;VALUE=DATE-TIME:19960916T000000
RDATE;VALUE=DATE-TIME:19970914T000000
RDATE;VALUE=DATE-TIME:19980906T000000
RDATE;VALUE=DATE-TIME:19990903T020000
RDATE;VALUE=DATE-TIME:20001006T010000
RDATE;VALUE=DATE-TIME:20010924T010000
RDATE;VALUE=DATE-TIME:20021007T010000
RDATE;VALUE=DATE-TIME:20031003T010000
RDATE;VALUE=DATE-TIME:20040922T010000
RDATE;VALUE=DATE-TIME:20051009T020000
RDATE;VALUE=DATE-TIME:20061001T020000
RDATE;VALUE=DATE-TIME:20070916T020000
RDATE;VALUE=DATE-TIME:20081005T020000
RDATE;VALUE=DATE-TIME:20090927T020000
RDATE;VALUE=DATE-TIME:20100912T020000
RDATE;VALUE=DATE-TIME:20111002T020000
RDATE;VALUE=DATE-TIME:20120923T020000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0200
TZOFFSETTO:+0400
TZNAME:IDDT
DTSTART:19480523T000000
RDATE;VALUE=DATE-TIME:19480523T000000
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETFROM:+0400
TZOFFSETTO:+0300
TZNAME:IDT
DTSTART:19480901T000000
RDATE;VALUE=DATE-TIME:19480901T000000
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
LAST-MODIFIED:20141022T123338Z
DTSTAMP:20141022T123338Z
UID:b622ce76-3a58-4862-81ca-17a23bb1e4d2
SUMMARY:Deep Dive 3.5.0 - SLA Resource Capping
STATUS:CONFIRMED
ORGANIZER;CN=Roy Golan;SENT-BY="mailto:rgolan@redhat.com":mailto:rgolan@re
dhat.com
ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT:mailto:devel
@ovirt.org
ATTENDEE;RSVP=TRUE;CN=users(a)ovirt.org;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTI
CIPANT:mailto:users@ovirt.org
ATTENDEE;RSVP=FALSE;CN=Peter Portante;PARTSTAT=DECLINED:mailto:pportant@re
dhat.com
ATTENDEE;RSVP=FALSE;CN=Omer Frenkel;PARTSTAT=ACCEPTED:mailto:ofrenkel@redh
at.com
ATTENDEE;RSVP=FALSE;CN=Keith Robertson;PARTSTAT=DECLINED:mailto:kroberts@r
edhat.com
ATTENDEE;RSVP=FALSE;CN=Doron Fediuck;PARTSTAT=ACCEPTED:mailto:dfediuck@red
hat.com
ATTENDEE;RSVP=FALSE;CN=j.kappert(a)geotax.nl;PARTSTAT=TENTATIVE;CUTYPE=INDIV
IDUAL:mailto:j.kappert@geotax.nl
ATTENDEE;RSVP=FALSE;CN=Leaboy;PARTSTAT=ACCEPTED;ROLE=OPT-PARTICIPANT:mailt
o:wlbleaboy@126.com
ATTENDEE;RSVP=FALSE;CN=James Labocki;PARTSTAT=ACCEPTED:mailto:jlabocki@red
hat.com
ATTENDEE;RSVP=FALSE;CN=Pavel Stehlik;PARTSTAT=DECLINED:mailto:pstehlik@red
hat.com
DTSTART;TZID=Asia/Jerusalem:20141022T160000
DTEND;TZID=Asia/Jerusalem:20141022T170000
DESCRIPTION:Agenda:\n\n* Overview of the engine's compute resources and a
general overview of the additions in 3.5\n* deep dive into I/O (Storage)\n
* deep dive into CPU\n\n\nHangout session:\nhttps://plus.google.com/events
/cgpkia6825en6lnavhhc2kbr40g\n\nYouTube:\nhttp://www.youtube.com/watch?v=R
G66UGT-NZU\n\n\nThanks\,\nRoy\n
X-MS-OLK-SENDER:mailto:rgolan@redhat.com
CLASS:PUBLIC
TRANSP:OPAQUE
SEQUENCE:1
END:VEVENT
END:VCALENDAR
9 years, 6 months
[QE] oVirt 3.5.1 status
by Sandro Bonazzola
Hi,
now that oVirt 3.5.0 has been released is time to start planning for 3.5.1.
Release management for 3.5.z has been created [1]
Suggested schedule for 3.5.1, following the 1 month schedule we had in 3.4.z, are:
General availability: 2014-12-02
RC Build: 2014-11-25
A tracker bug for 3.5.1 has been created [2] and shows currently one blocker:
Bug ID Whiteboard Status Summary
1145977 infra POST [events] Host memory usage exceeded defined threshold cha...
There are 199 bugs [3] targeted to 3.5.1.
Excluding node and documentation bugs we still have 170 bugs [4] targeted to 3.5.1.
Maintainers / Assignee:
- Please add the bugs to the tracker if you think that 3.5.1 should not be released without them fixed.
- Please update the target to 3.5.2 or later for bugs that won't be in 3.5.1:
it will ease gathering the blocking bugs for next releases.
- Please fill release notes, the page has been created here [5]
Community:
- If you're testing oVirt 3.5 nightly snapshot, please add yourself to the test page [6]
[1] http://www.ovirt.org/OVirt_3.5.z_Release_Management
[2] http://bugzilla.redhat.com/1155170
[3] http://goo.gl/7G0PDV
[4] http://goo.gl/6gUbVr
[5] http://www.ovirt.org/OVirt_3.5.1_Release_Notes
[6] http://www.ovirt.org/Testing/oVirt_3.5.1_Testing
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
9 years, 6 months
(no subject)
by czg sai
ovirt 3.5beta
export disk to ovirt-image-repository. How to delete images from
ovirt-image-repository ?
9 years, 6 months
