[vdsm] Cancelled: vdsm call
BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:CANCEL BEGIN:VTIMEZONE TZID:Europe/London BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETTO:- TZOFFSETFROM:+0100 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU TZNAME:GMT/BST END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T01 TZOFFSETTO:+0100 TZOFFSETFROM:- RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU TZNAME:GMT/BST END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:95fbe6ce-3950-4413-b63a-d2c5701bc3a7 SUMMARY:Cancelled: vdsm call COMMENT:A single instance of a recurring meeting has been cancelled. ATTENDEE;CN=vdsm-devel;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE: mailto:vdsm-devel@lists.fedorahosted.org ATTENDEE;CN=Otavio Luiz Ferranti;PARTSTAT=DECLINED:mailto:otavio.ferranti@el dorado.org.br ATTENDEE;CN=Saggi Mizrahi;PARTSTAT=ACCEPTED:mailto:smizr...@redhat.com ATTENDEE;CN=Antoni Segura Puimedon;PARTSTAT=ACCEPTED:mailto:asegurap@redhat. com ATTENDEE;CN=Dima Kuznetsov;PARTSTAT=ACCEPTED:mailto:dkuzn...@redhat.com ATTENDEE;CN=Yaniv Bronheim;PARTSTAT=ACCEPTED:mailto:ybron...@redhat.com ATTENDEE;CN=Barak Azulay;PARTSTAT=TENTATIVE:mailto:bazu...@redhat.com ATTENDEE;CN=Francesco Romani;PARTSTAT=ACCEPTED:mailto:from...@redhat.com ATTENDEE;CN=Federico Simoncelli;PARTSTAT=ACCEPTED:mailto:fsimo...@redhat.com ATTENDEE;CN=Sean Cohen;PARTSTAT=TENTATIVE:mailto:sco...@redhat.com ATTENDEE;CN=Oved Ourfalli;PARTSTAT=TENTATIVE:mailto:ov...@redhat.com ATTENDEE;CN=Piotr Kliczewski;PARTSTAT=ACCEPTED:mailto:pklic...@redhat.com ATTENDEE;CN=Ido Barkan;PARTSTAT=ACCEPTED:mailto:ibar...@redhat.com ATTENDEE;CN=Adam Litke;PARTSTAT=ACCEPTED:mailto:ali...@redhat.com ORGANIZER;CN=Dan Kenigsberg:mailto:dkeni...@redhat.com DTSTART;TZID=Europe/London:20141125T143000 DTEND;TZID=Europe/London:20141125T153000 STATUS:CANCELLED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE RECURRENCE-ID;TZID=Europe/London:20141125T143000 LAST-MODIFIED:20141125T134313Z DTSTAMP:20141125T134313Z SEQUENCE:3 DESCRIPTION:A single instance of the following meeting has been cancelled:\n \nSubject: vdsm call \nOrganizer: Dan Kenigsberg dkeni...@redhat.com \n\ nTime: Tuesday\, November 25\, 2014\, 2:30:00 PM - 3:30:00 PM GMT +00:00 Bri tain\, Ireland\, Portugal\n \nInvitees: vdsm-devel@lists.fedorahosted.org\; otavio.ferra...@eldorado.org.br\; smizr...@redhat.com\; asegu...@redhat.com\ ; dkuzn...@redhat.com\; ybron...@redhat.com\; bazu...@redhat.com\; fromani@r edhat.com\; fsimo...@redhat.com\; sco...@redhat.com\; ov...@redhat.com ... \ n\n\n*~*~*~*~*~*~*~*~*~*\n\nSorry for the late notice\, but I just noticed t hat most of us have a conflicting meeting today. END:VEVENT END:VCALENDAR___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Cancelled: vdsm call
BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:CANCEL BEGIN:VTIMEZONE TZID:Europe/London BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETTO:- TZOFFSETFROM:+0100 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU TZNAME:GMT/BST END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T01 TZOFFSETTO:+0100 TZOFFSETFROM:- RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU TZNAME:GMT/BST END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:95fbe6ce-3950-4413-b63a-d2c5701bc3a7 SUMMARY:Cancelled: vdsm call COMMENT:A single instance of a recurring meeting has been cancelled. ATTENDEE;CN=vdsm-devel;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE: mailto:vdsm-devel@lists.fedorahosted.org ATTENDEE;CN=Otavio Luiz Ferranti;PARTSTAT=DECLINED:mailto:otavio.ferranti@el dorado.org.br ATTENDEE;CN=Saggi Mizrahi;PARTSTAT=ACCEPTED:mailto:smizr...@redhat.com ATTENDEE;CN=Antoni Segura Puimedon;PARTSTAT=ACCEPTED:mailto:asegurap@redhat. com ATTENDEE;CN=Dima Kuznetsov;PARTSTAT=ACCEPTED:mailto:dkuzn...@redhat.com ATTENDEE;CN=Yaniv Bronheim;PARTSTAT=ACCEPTED:mailto:ybron...@redhat.com ATTENDEE;CN=Barak Azulay;PARTSTAT=TENTATIVE:mailto:bazu...@redhat.com ATTENDEE;CN=Francesco Romani;PARTSTAT=ACCEPTED:mailto:from...@redhat.com ATTENDEE;CN=Federico Simoncelli;PARTSTAT=ACCEPTED:mailto:fsimo...@redhat.com ATTENDEE;CN=Sean Cohen;PARTSTAT=TENTATIVE:mailto:sco...@redhat.com ATTENDEE;CN=Oved Ourfalli;PARTSTAT=TENTATIVE:mailto:ov...@redhat.com ATTENDEE;CN=Piotr Kliczewski;PARTSTAT=ACCEPTED:mailto:pklic...@redhat.com ATTENDEE;CN=Ido Barkan;PARTSTAT=ACCEPTED:mailto:ibar...@redhat.com ORGANIZER;CN=Dan Kenigsberg:mailto:dkeni...@redhat.com DTSTART;TZID=Europe/London:20141014T143000 DTEND;TZID=Europe/London:20141014T153000 STATUS:CANCELLED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE RECURRENCE-ID;TZID=Europe/London:20141014T143000 LAST-MODIFIED:20141014T101625Z DTSTAMP:20141014T101625Z SEQUENCE:3 DESCRIPTION:A single instance of the following meeting has been cancelled:\n \nSubject: vdsm call \nOrganizer: Dan Kenigsberg dkeni...@redhat.com \n\ nTime: Tuesday\, October 14\, 2014\, 2:30:00 PM - 3:30:00 PM GMT +00:00 Brit ain\, Ireland\, Portugal\n \nInvitees: vdsm-devel@lists.fedorahosted.org\; o tavio.ferra...@eldorado.org.br\; smizr...@redhat.com\; asegu...@redhat.com\; dkuzn...@redhat.com\; ybron...@redhat.com\; bazu...@redhat.com\; fromani@re dhat.com\; fsimo...@redhat.com\; sco...@redhat.com\; ov...@redhat.com ... \n \n\n*~*~*~*~*~*~*~*~*~*\n\nIf you receive this e-mail\, it means that you ar e invited to the \nbi-weekly phone meeting of Vdsm developers. This is an op portunity \nto discuss design problems\, pending patches\, and persistent bu gs. \n\nEven if you do not join\, you may solicit subjects for discussion on \nthe mailing list or over #v...@irc.freenode.net. \n\nNote the new meeting time and conference code. \n\nConference code: 353-86-075-901. \n\nDial-in information: \nhttps://www.intercallonline.com/listNumbersByCode.action?conf Code=35386075901 X-ALT-DESC;FMTTYPE=text/html:htmlbody id='htmlmode'h3A single instance of the following meeting has been cancelled:/h3\n\np\ntable border='0' \ntrth align=leftSubject:/thtdvdsm call /td/tr\ntrth align=l eftOrganizer:/thtdDan Kenigsberg lt\;dkeni...@redhat.comgt\; /td /tr\n/table\np\ntable border='0'\ntrth align=leftTime:/thtdTu esday\, October 14\, 2014\, 2:30:00 PM - 3:30:00 PM GMT +00:00 Britain\, Ire land\, Portugal\n /td/tr/table\np\ntable border='0'\ntrth align =leftInvitees:/thtdvdsm-devel@lists.fedorahosted.org\; otavio.ferranti@ eldorado.org.br\; smizr...@redhat.com\; asegu...@redhat.com\; dkuznets@redha t.com\; ybron...@redhat.com\; bazu...@redhat.com\; from...@redhat.com\; fsim o...@redhat.com\; sco...@redhat.com\; ov...@redhat.com ... /td/tr\n/tab le\ndiv*~*~*~*~*~*~*~*~*~*/divbrIf you receive this e-mail\, it means that you are invited to the brbi-weekly phone meeting of Vdsm developers. This is an opportunity brto discuss design problems\, pending patches\, a nd persistent bugs. brbrEven if you do not join\, you may solicit subjec ts for discussion on brthe mailing list or over #v...@irc.freenode.net. b rbrNote the new meeting time and conference code. brbrConference code : 353-86-075-901. brbrDial-in information: brhttps://www.intercallonli ne.com/listNumbersByCode.action?confCode=35386075901/body/html END:VEVENT END:VCALENDAR___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [VDSM] cleaning statistics retrieval
On Wed, Apr 09, 2014 at 08:40:24AM -0400, Francesco Romani wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Francesco Romani from...@redhat.com Cc: vdsm-devel vdsm-devel@lists.fedorahosted.org, de...@ovirt.org Sent: Tuesday, April 8, 2014 6:57:15 PM Subject: Re: cleaning statistics retrieval On Tue, Apr 08, 2014 at 06:52:50AM -0400, Francesco Romani wrote: Hello VDSM developers, Please use devel@ovirt, and mention vdsm at the subject. This thread in particular involves Engine as well. Right, I forgot. Sorry about that. I'd like to discuss and explain the plans for cleaning up Vm.getStats() in vdsm/virt/vm.py, and how it affects a bug we have: https://bugzilla.redhat.com/show_bug.cgi?id=1073478 Let's start from the bug. To make a long story short, there is a (small) race in VDSM, probably introduced by commit 8fedf8bde3c28edb07add23c3e9b72681cb48e49 The race can actually be triggered only if the VM is shutting down, so it is not that bad. Fixing the reported issue in the specific case can be done with a trivial if, and that it what I did in my initial http://gerrit.ovirt.org/#/c/25803/1/vdsm/vm.py,cm Could you explain how an AttributeError there moved the VM to Down? This should actually be this bug of engine https://bugzilla.redhat.com/show_bug.cgi?id=1072282 if GetVmStats fails for whatever reason, engine thinks the VM is down. Could you rename the Vdsm bug to exprese the in-vdsm problem, and make clear that it confuses older Engines to think the Vm is Down? And this is the core of the issue. My initial idea is to either return success and a complete, well formed statistics set, or return an error. However current engine seems to not cope properly with this, and we cannot break backward compatibility. Would you be more precise? If getAllVmStats returns an errCode for one of the Vms, what happens? Of course. For GetAllVmStats, AFAIK, but please correct me if I am wrong, because I'm not really expert on engine side, engine simply does not expects anything different from a list of either a RunningVmStats or an ExitedVmStats. So not sure (will verify just after this mail) if engine can cope with mixed content, meaning [ stats, errCode, stats, stats ... ] For GetVmStats, like Michal said, the engine expects the call to succeed otherwise it puts the VM into the Unknown state. Looks like the only way to go is to always return success and to add a field to describe the content of the statistics (partial, complete...). THis is admittedly a far cry from the ideal solution, but it is dictated by the need to preserve the compatibility with current/old engines. I don't think that I understand your suggestion, but it does not sound right to send a partial dictionary and to appologize about its paritiality elsewhere. The dictionary may be partial for engine-4.0 yet complete for engine-3.5. It's not for Vdsm to grade its own output. I see your point (that's one of the reasons I'm not happy about this solution). Please see below for the detauls. please note that I'm not really happy about this solution, but, given the constraint, I don't see better alternatives. Please explain the benefits of describing the partial content, as I do not see them. The root issue here is the getStats must always succeed, because the engine doesn't expect otherwise and thus we guarantee this to cope with old engines; but inside VDSM, getStats can actually fail in a lot of places (like in this case getBalloonInfo) So, in VDSM we can end up with a partial response, and now the question is: what to do with this partial response? And if there are optional fields in the response, how can the engine distinguish between * full response, but with an optional field missing and * partial response (because of an exception inside VDSM), without some field, incidentally including an optional one ? The VDSM 'grading' was an hint from VDSM to help engine to distinguish between those cases. Even if we agree this grading idea is bad, the core issue remains open: what to do if we end up with a partial response? For example, let's say we handle the getBalloonInfo exception (http://gerrit.ovirt.org/#/c/26539/), the stats object to be returned will lack * the (mandatory, expected) balloon stats * the (optional) migration progress - ok, bad example because this makes sense only during migrations, but other optional fields may be added later and the issue remains Again, anyone feel free to correct me if I misunderstood something about engine (or VDSM = engine communication) and to suggest better alternatives :\ Currently, we have way too many try-except-Exception clauses in our code. They swallow everything: from expected libvirt errors to unexpected syntax errors. We should eliminate
Re: [vdsm] cleaning statistics retrieval
On Wed, Apr 09, 2014 at 01:11:22PM +0200, Michal Skrivanek wrote: On Apr 8, 2014, at 18:57 , Dan Kenigsberg dan...@redhat.com wrote: On Tue, Apr 08, 2014 at 06:52:50AM -0400, Francesco Romani wrote: Hello VDSM developers, Please use devel@ovirt, and mention vdsm at the subject. This thread in particular involves Engine as well. I'd like to discuss and explain the plans for cleaning up Vm.getStats() in vdsm/virt/vm.py, and how it affects a bug we have: https://bugzilla.redhat.com/show_bug.cgi?id=1073478 Let's start from the bug. To make a long story short, there is a (small) race in VDSM, probably introduced by commit 8fedf8bde3c28edb07add23c3e9b72681cb48e49 The race can actually be triggered only if the VM is shutting down, so it is not that bad. Fixing the reported issue in the specific case can be done with a trivial if, and that it what I did in my initial http://gerrit.ovirt.org/#/c/25803/1/vdsm/vm.py,cm Could you explain how an AttributeError there moved the VM to Down? However, this is just a bandaid and a proper solution is needed. This is the reason why the following versions of http://gerrit.ovirt.org/#/c/25803 changed direction toward a more comprehensive approach. And this is the core of the issue. My initial idea is to either return success and a complete, well formed statistics set, or return an error. However current engine seems to not cope properly with this, and we cannot break backward compatibility. Would you be more precise? If getAllVmStats returns an errCode for one of the Vms, what happens? VM moves to Unknown after some time Looks like the only way to go is to always return success and to add a field to describe the content of the statistics (partial, complete...). THis is admittedly a far cry from the ideal solution, but it is dictated by the need to preserve the compatibility with current/old engines. I don't think that I understand your suggestion, but it does not sound right to send a partial dictionary and to appologize about its paritiality elsewhere. The dictionary may be partial for engine-4.0 yet complete for engine-3.5. It's not for Vdsm to grade its own output. Moreover, I would like to take the chance and cleanup/refactor the statistics collection. I already started adding the test infrastructure: http://gerrit.ovirt.org/#/c/26536/ To summarize, what I suggest to do is: * fix https://bugzilla.redhat.com/show_bug.cgi?id=1073478 using a simple ugly fix like the original http://gerrit.ovirt.org/#/c/25803/1/vdsm/vm.py,cm (which I'll resubmit as new change) * refactor and clean getStats() and friends * on the cleaner base, properly fix the statistics collection by let getStats() always succeed and return possibly partial stats, with a new field describing the content please note that I'm not really happy about this solution, but, given the constraint, I don't see better alternatives. Please explain the benefits of describing the partial content, as I do not see them. the main reason for me is that currently if we fail to fetch some parts of the stats we still return what we could get. E.g. try: stats.update(self.guestAgent.getGuestInfo()) except Exception: return stats currently in engine we can only tell it's partial by not seeing the missing bits… it makes sense since for lifecycle decisions we care for the VM status, but we don't necessarily care for other stuff Engine knows that the data is partial, since it sees only parts of it. What is the benefit of Vdsm declaring it as partial? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm sync meeting minutes April 1st, 2014
On Wed, Apr 02, 2014 at 09:29:09AM +0100, dan...@redhat.com wrote: - We had a very (too) heated debate about ignoring failures of setDomainRegularRole() in http://gerrit.ovirt.org/24495/ and http://gerrit.ovirt.org/25424. The pain point is that relying on domain role (master/regular) is faulty by design. We cannot avoid the cases where a pool has more than one domain with a master role written in its metadata. One side argued that oVirt should be fixed to handle this unescapable truth, or at least enumerate the places where Vdsm and Engine, both current and old, depend on master role uniqueness. The other side argued that this is not a priority task, and that we should try to garbage-collect known-bad master roles as a courtesy to people digging into domain metadata, and as a means to lessen the problem until we kill the pool concept in the upcoming version. I hope that I present the debate fairly enough. In order to move these two patches forward, how about: - Limit the usage of the catching-all except Exception and replace it with swalling only the expected IO error - Add a comment about setDomainRegularRole() being called only as a courtesy garbage-collection attempt. - Conduct a survey on whether migrateMaster is used by anyone. No supported Engine has it, but I there was a suggestion that it was still expected via the command line. What do you think? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] cleaning statistics retrieval
On Wed, Apr 09, 2014 at 02:32:57PM +0200, Michal Skrivanek wrote: On Apr 9, 2014, at 14:21 , Dan Kenigsberg dan...@redhat.com wrote: On Wed, Apr 09, 2014 at 01:11:22PM +0200, Michal Skrivanek wrote: On Apr 8, 2014, at 18:57 , Dan Kenigsberg dan...@redhat.com wrote: On Tue, Apr 08, 2014 at 06:52:50AM -0400, Francesco Romani wrote: Hello VDSM developers, Please use devel@ovirt, and mention vdsm at the subject. This thread in particular involves Engine as well. I'd like to discuss and explain the plans for cleaning up Vm.getStats() in vdsm/virt/vm.py, and how it affects a bug we have: https://bugzilla.redhat.com/show_bug.cgi?id=1073478 Let's start from the bug. To make a long story short, there is a (small) race in VDSM, probably introduced by commit 8fedf8bde3c28edb07add23c3e9b72681cb48e49 The race can actually be triggered only if the VM is shutting down, so it is not that bad. Fixing the reported issue in the specific case can be done with a trivial if, and that it what I did in my initial http://gerrit.ovirt.org/#/c/25803/1/vdsm/vm.py,cm Could you explain how an AttributeError there moved the VM to Down? However, this is just a bandaid and a proper solution is needed. This is the reason why the following versions of http://gerrit.ovirt.org/#/c/25803 changed direction toward a more comprehensive approach. And this is the core of the issue. My initial idea is to either return success and a complete, well formed statistics set, or return an error. However current engine seems to not cope properly with this, and we cannot break backward compatibility. Would you be more precise? If getAllVmStats returns an errCode for one of the Vms, what happens? VM moves to Unknown after some time Looks like the only way to go is to always return success and to add a field to describe the content of the statistics (partial, complete...). THis is admittedly a far cry from the ideal solution, but it is dictated by the need to preserve the compatibility with current/old engines. I don't think that I understand your suggestion, but it does not sound right to send a partial dictionary and to appologize about its paritiality elsewhere. The dictionary may be partial for engine-4.0 yet complete for engine-3.5. It's not for Vdsm to grade its own output. Moreover, I would like to take the chance and cleanup/refactor the statistics collection. I already started adding the test infrastructure: http://gerrit.ovirt.org/#/c/26536/ To summarize, what I suggest to do is: * fix https://bugzilla.redhat.com/show_bug.cgi?id=1073478 using a simple ugly fix like the original http://gerrit.ovirt.org/#/c/25803/1/vdsm/vm.py,cm (which I'll resubmit as new change) * refactor and clean getStats() and friends * on the cleaner base, properly fix the statistics collection by let getStats() always succeed and return possibly partial stats, with a new field describing the content please note that I'm not really happy about this solution, but, given the constraint, I don't see better alternatives. Please explain the benefits of describing the partial content, as I do not see them. the main reason for me is that currently if we fail to fetch some parts of the stats we still return what we could get. E.g. try: stats.update(self.guestAgent.getGuestInfo()) except Exception: return stats currently in engine we can only tell it's partial by not seeing the missing bits… it makes sense since for lifecycle decisions we care for the VM status, but we don't necessarily care for other stuff Engine knows that the data is partial, since it sees only parts of it. What is the benefit of Vdsm declaring it as partial? there are a lot of variable fields so it's not that easy to say if it's partial or not. It does make sense to let someone know that there is an issue and you're getting partial data, yet you don't want to make any automatic actions... But Vdsm cannot make this decision. Soon, Vdsm is to report the host's boot time. Now assume that Vdsm fails to do so. Is the stats partial? It's partial for engine-3.5, but it's complete for engine-3.4. Vdsm should tell as much of the truth that it knows. We could extend the alerts mechanism to report non-lethal errors in getVmStats (we currently have it only in for storage domain status), where Engine is told what's missing and why. I'm not sure if this is really needed, though. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Help Needed
On Tue, Apr 08, 2014 at 02:02:37AM -0400, Darshan Narayana Murthy wrote: - Original Message - From: Darshan Narayana Murthy dnara...@redhat.com To: vdsm-de...@fedorahosted.org Sent: Tuesday, April 8, 2014 11:21:27 AM Subject: Re: [vdsm] Help Needed - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Darshan Narayana Murthy dnara...@redhat.com Sent: Monday, April 7, 2014 4:53:30 PM Subject: Re: Help Needed On Mon, Apr 07, 2014 at 06:52:36AM -0400, Darshan Narayana Murthy wrote: Hi Dan, I sent a patch for vdsm to get the gluster volume capacity statistics using libgf api ( patch : http://gerrit.ovirt.org/#/c/26343 ), This patch requires glusterfs-devel package for build. It looks like jenkins does not have this package and so the build for this patch is failing. Does jenkins automatically pull the required package or is there anything to be done to get this package in jenkins ?. Can you please help me to resolve this. Generally speaking, if you want a new package installed, you should ask that on in...@ovirt.org. However, I am not at all happy with adding C code into Vdsm. What is it? Python binding for glfs_statvfs ? Could this be implemented elsewhere (such as an independent python-glfs package)? Dan. Hi, We are making use of libgf-api for getting the statistics related to a glusterfs volume, as it is more efficient than we mounting a volume and getting the statistics. libgfapi is a c api. Initially we tried using ctypes to wrap the required functions in libgfapi. But because of a limitation in glusterfs when these functions were invoked through supervdsm it would break. I hope Toni can help out here, he found outr that when using threads, you must declare the function prototype explicitly, but I'm not at all sure this is your issue. Issue with the above approach was: https://lists.fedorahosted.org/pipermail/vdsm-devel/2013-August/002537.html So we thought of having an extension module that makes use of libgfapi and provides the statistics, which can be used in vdsm. what would be the better approach to resolve this ? Please provide us your suggestions. In my opionion, the python module that you suggest makes sense - but it should be part of libgf - it is their's python binding (or part thereof). ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Modeling graphics framebuffer device in VDSM
On Fri, Mar 28, 2014 at 08:06:17AM -0400, Frantisek Kobzik wrote:
Dear VDSM devels,
I've been working on refactoring graphics devices in engine and VDSM for some
time now and I'd like know your opinion of that.
The aim of this refactoring is to model graphics framebuffer (SPICE, VNC) as
device in the engine and VDSM. This which is quite natural since libvirt
treats
graphics as a device and we have some kind of devices infrastructure in both
projects. Another advantage (and actually the main reason for refactoring) is
simplified support for multiple graphics framebuffers on a single vm.
Currently, passing information about graphics from engine to VDSM is done via
'display' param in conf. In the other direction VDSM informs the engine about
graphics parameters ('displayPort', 'displaySecurePort', 'displayIp' and
'displayNetwork') in conf as well.
What I'd like to achieve is to encapsulate all this information in specParams
of the new graphics device and use specParams as a place for transfering data
about graphics device between engine and vdsm. What do you think?
the draft patch is here:
http://gerrit.ovirt.org/#/c/23555/ (it's currently marked with '-1' but it
puts
some light on what the solution looks like so feel free to take a look).
Thanks for the heads up. I'd appreciate if you could split this patch to
smaller ones, and define well-named functions as much as possible. It's
not your fault, but vm.py is in such a shape that adding more complexity
into it should be done with great care.
So even if the patches are interdependent, the review process would be
simpler.
Another high-level note that I have is that you should care for
reporting displayPort on the vm level only for those Engines that care
for that, so if you have multiple graphics devices - you should not.
Regards,
Dan.
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] cleaning statistics retrieval
On Tue, Apr 08, 2014 at 06:52:50AM -0400, Francesco Romani wrote: Hello VDSM developers, Please use devel@ovirt, and mention vdsm at the subject. This thread in particular involves Engine as well. I'd like to discuss and explain the plans for cleaning up Vm.getStats() in vdsm/virt/vm.py, and how it affects a bug we have: https://bugzilla.redhat.com/show_bug.cgi?id=1073478 Let's start from the bug. To make a long story short, there is a (small) race in VDSM, probably introduced by commit 8fedf8bde3c28edb07add23c3e9b72681cb48e49 The race can actually be triggered only if the VM is shutting down, so it is not that bad. Fixing the reported issue in the specific case can be done with a trivial if, and that it what I did in my initial http://gerrit.ovirt.org/#/c/25803/1/vdsm/vm.py,cm Could you explain how an AttributeError there moved the VM to Down? However, this is just a bandaid and a proper solution is needed. This is the reason why the following versions of http://gerrit.ovirt.org/#/c/25803 changed direction toward a more comprehensive approach. And this is the core of the issue. My initial idea is to either return success and a complete, well formed statistics set, or return an error. However current engine seems to not cope properly with this, and we cannot break backward compatibility. Would you be more precise? If getAllVmStats returns an errCode for one of the Vms, what happens? Looks like the only way to go is to always return success and to add a field to describe the content of the statistics (partial, complete...). THis is admittedly a far cry from the ideal solution, but it is dictated by the need to preserve the compatibility with current/old engines. I don't think that I understand your suggestion, but it does not sound right to send a partial dictionary and to appologize about its paritiality elsewhere. The dictionary may be partial for engine-4.0 yet complete for engine-3.5. It's not for Vdsm to grade its own output. Moreover, I would like to take the chance and cleanup/refactor the statistics collection. I already started adding the test infrastructure: http://gerrit.ovirt.org/#/c/26536/ To summarize, what I suggest to do is: * fix https://bugzilla.redhat.com/show_bug.cgi?id=1073478 using a simple ugly fix like the original http://gerrit.ovirt.org/#/c/25803/1/vdsm/vm.py,cm (which I'll resubmit as new change) * refactor and clean getStats() and friends * on the cleaner base, properly fix the statistics collection by let getStats() always succeed and return possibly partial stats, with a new field describing the content please note that I'm not really happy about this solution, but, given the constraint, I don't see better alternatives. Please explain the benefits of describing the partial content, as I do not see them. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Addming whole application profile
On Wed, Mar 26, 2014 at 09:13:16AM -0400, Nir Soffer wrote: Hi all, Please review this patch: http://gerrit.ovirt.org/26113 The short term goal of this patch is to allow debugging of this nasty bug: https://bugzilla.redhat.com/1074097 The long term goal is having an easy way to profile vdsm in the field and during development, initiative started by Francesco. Here are some docs to help you get started with the profiler. Installing yappi To try this patch, you must install yappi: 1. wget http://yappi.googlecode.com/files/yappi-0.82.tar.gz 2. tar xzf yappi-0.82.tar.gz 3. cd yappi-0.82 4. sudo python setup.py install If you want to build an rpm, the quickest way is: 1. Fix MANIFEST.in so it looks like this: include *.h include ez_setup.py 2. Build rpm $ python setup.py bdist_rpm You rpm is located in dist. I built rpm packages for fedora and rhel (looking for a place to share them) How about making it a Fedora package? https://fedoraproject.org/wiki/Join_the_package_collection_maintainers#Create_Your_Review_Request (caveat - it can be a long long process) ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] if ipv6 ready and hot to use it?
On Mon, Mar 24, 2014 at 12:32:50PM +, Sven Kieske wrote: Well would you maybe consider priorising this feature set a bit? Because the world really runs out of IPv4 addresses..fast. The planning phase of ovirt-3.5 is almost done... But it would be nice if you join that ovirt-3.5 planning thread on ovirt-users and explain why it's important to have Engine send ipv6 addresses. And better yet, get someone to send the patches upstream... Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] VDSM profiling results, round 1
On Wed, Mar 19, 2014 at 08:04:18AM -0400, Francesco Romani wrote: another cpickle patch round. http://paste.fedoraproject.org/86653/ The only change is: - DO NOT restart vdsmd between runs (just because it was faster to test) the timings/profile is now much more closer to what I was expecting. The benefits of switching to cPickle are indeed small, but the change is quick easy and safe, so I'm still all for it. I'm confused. What is the numerical benefit? http://paste.fedoraproject.org/86611/ suggests that it's 36/1230=3% of GIL-holding time, but the former pastebin saw a total *worsening*. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] creating ovirtmgmt bridge using tagged vlans
On Wed, Mar 19, 2014 at 08:00:48AM -0400, Antoni Segura Puimedon wrote:
- Original Message -
From: Sandro Bonazzola sbona...@redhat.com
To: VDSM Project Development vdsm-devel@lists.fedorahosted.org
Cc: Antoni Segura Puimedon asegu...@redhat.com
Sent: Wednesday, March 19, 2014 12:54:45 PM
Subject: creating ovirtmgmt bridge using tagged vlans
Hi,
I'm working on: Bug 1072027 - hosted-engine setup fails when using VLAN
tagged interfaces
Provided the following caps:
# vdsClient -s localhost getVdsHardwareInfo
systemFamily = 'Not Specified'
systemManufacturer = 'Dell Inc.'
systemProductName = 'OptiPlex 7010'
systemSerialNumber = 'DYC5YX1'
systemUUID = '4C4C4544-0059-4310-8035-C4C04F595831'
systemVersion = '01'
[root@dellserver network-scripts]# vdsClient -s localhost getVdsCap
getVdsCapabilities getVdsCaps
[root@dellserver network-scripts]# vdsClient -s localhost getVdsCaps
HBAInventory = {'FC': [], 'iSCSI': [{'InitiatorName':
'iqn.1994-05.com.redhat:babababa'}]}
ISCSIInitiatorName = 'iqn.1994-05.com.redhat:babababa'
bondings = {'bond0': {'addr': '',
'cfg': {},
'hwaddr': '5a:46:b1:db:ec:9b',
'ipv6addrs': [],
'mtu': '1500',
'netmask': '',
'slaves': []}}
bridges = {';vdsmdummy;': {'addr': '',
'cfg': {},
'gateway': '',
'ipv6addrs':
['fe80::8c8a:edff:fe92:b332/64'],
'ipv6gateway': '::',
'mtu': '1500',
'netmask': '',
'ports': [],
'stp': 'off'}}
clusterLevels = ['3.0', '3.1', '3.2', '3.3', '3.4']
cpuCores = '4'
cpuFlags =
'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,rdtscp,lm,constant_tsc,arch_perfmon,pebs,bts,rep_good,nopl,xtopology,nonstop_tsc,aperfmperf,eagerfpu,pni,pclmulqdq,dtes64,monitor,ds_cpl,vmx,smx,est,tm2,ssse3,cx16,xtpr,pdcm,pcid,sse4_1,sse4_2,x2apic,popcnt,tsc_deadline_timer,aes,xsave,avx,f16c,rdrand,lahf_lm,ida,arat,epb,xsaveopt,pln,pts,dtherm,tpr_shadow,vnmi,flexpriority,ept,vpid,fsgsbase,smep,erms,model_Nehalem,model_Conroe,model_coreduo,model_core2duo,model_Penryn,model_Westmere,model_n270,model_SandyBridge'
cpuModel = 'Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz'
cpuSockets = '1'
cpuSpeed = '1864.156'
cpuThreads = '8'
emulatedMachines = ['pc',
'pc-q35-1.4',
'pc-q35-1.5',
'q35',
'isapc',
'pc-0.10',
'pc-0.11',
'pc-0.12',
'pc-0.13',
'pc-0.14',
'pc-0.15',
'pc-1.0',
'pc-1.1',
'pc-1.2',
'pc-1.3',
'pc-i440fx-1.4',
'pc-i440fx-1.5',
'none']
guestOverhead = '65'
hooks = {}
kvmEnabled = 'true'
lastClient = '127.0.0.1'
lastClientIface = 'lo'
management_ip = '0.0.0.0'
memSize = '15936'
netConfigDirty = 'False'
networks = {}
nics = {'em1': {'addr': '192.168.1.105',
'cfg': {'DEVICE': 'em1',
'HWADDR': 'b8:ca:3a:76:9a:43',
'MTU': '1500',
'ONBOOT': 'yes'},
'hwaddr': 'b8:ca:3a:76:9a:43',
'ipv6addrs': ['fe80::baca:3aff:fe76:9a43/64'],
'mtu': '1500',
'netmask': '255.255.255.0',
'speed': 1000}}
operatingSystem = {'name': 'Fedora', 'release': '8', 'version': '19'}
packages2 = {'kernel': {'buildtime': 1394207804.0,
'release': '100.fc19.x86_64',
'version': '3.13.6'},
'libvirt': {'buildtime': 1387094943,
'release': '1.fc19',
'version': '1.1.3.2'},
'mom': {'buildtime': 1391183561, 'release': '1.fc19',
'version': '0.4.0'},
'qemu-img': {'buildtime': 1384762225,
'release': '2.fc19',
'version': '1.6.1'},
'qemu-kvm': {'buildtime': 1384762225,
'release': '2.fc19',
'version': '1.6.1'},
[vdsm] Vdsm Coding Guidelines
Hi folks, I've patched up http://www.ovirt.org/Vdsm_Coding_Guidelines. Please keep it in mind when coding and reviewing. If you'd like to amend that suggestion, let's discuss it here. Regards, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] vdsm call
BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/London BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETTO:- TZOFFSETFROM:+0100 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU TZNAME:GMT/BST END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T01 TZOFFSETTO:+0100 TZOFFSETFROM:- RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU TZNAME:GMT/BST END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:95fbe6ce-3950-4413-b63a-d2c5701bc3a7 SUMMARY:vdsm call ATTENDEE;CN=vdsm-devel;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE: mailto:vdsm-devel@lists.fedorahosted.org ORGANIZER;CN=Dan Kenigsberg:mailto:dkeni...@redhat.com DTSTART;TZID=Europe/London:20140318T143000 DTEND;TZID=Europe/London:20140318T153000 STATUS:CONFIRMED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE LAST-MODIFIED:20140318T160917Z DTSTAMP:20140318T160917Z SEQUENCE:1 DESCRIPTION:The following is a new meeting request:\n\nSubject: vdsm call \n Organizer: Dan Kenigsberg dkeni...@redhat.com \n\nTime: Tuesday\, March 18\, 2014\, 2:30:00 PM - 3:30:00 PM GMT +00:00 Britain\, Ireland\, Portugal\ n \nInvitees: vdsm-devel@lists.fedorahosted.org \n\n\n*~*~*~*~*~*~*~*~*~*\n\ nIf you receive this e-mail\, it means that you are invited to the\nbi-weekl y phone meeting of Vdsm developers. This is an opportunity\nto discuss desig n problems\, pending patches\, and persistent bugs.\n\nEven if you do not jo in\, you may solicit subjects for discussion on\nthe mailing list or over #v d...@irc.freenode.net.\n\nNote the new meeting time and conference code.\n\nC onference code: 353-86-075-901.\n\nDial-in information:\nhttps://www.interca llonline.com/listNumbersByCode.action?confCode=35386075901 BEGIN:VALARM ACTION:DISPLAY TRIGGER;RELATED=START:-PT5M DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] vdsm call
BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Europe/London BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETTO:- TZOFFSETFROM:+0100 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=-1SU TZNAME:GMT/BST END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T01 TZOFFSETTO:+0100 TZOFFSETFROM:- RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1SU TZNAME:GMT/BST END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:95fbe6ce-3950-4413-b63a-d2c5701bc3a7 RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=TU SUMMARY:vdsm call ATTENDEE;CN=vdsm-devel;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE: mailto:vdsm-devel@lists.fedorahosted.org ORGANIZER;CN=Dan Kenigsberg:mailto:dkeni...@redhat.com DTSTART;TZID=Europe/London:20140318T143000 DTEND;TZID=Europe/London:20140318T153000 STATUS:CONFIRMED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE LAST-MODIFIED:20140318T161008Z DTSTAMP:20140318T161008Z SEQUENCE:2 DESCRIPTION:The following meeting has been modified:\n\nSubject: vdsm call \ nOrganizer: Dan Kenigsberg dkeni...@redhat.com \n\nTime: 2:30:00 PM - 3: 30:00 PM GMT +00:00 Britain\, Ireland\, Portugal\n Recurrence : Every 2 week (s) on Tuesday No end date Effective Mar 18\, 2014\n\nInvitees: vdsm-devel@l ists.fedorahosted.org \n\n\n*~*~*~*~*~*~*~*~*~*\n\nIf you receive this e-mai l\, it means that you are invited to the \nbi-weekly phone meeting of Vdsm d evelopers. This is an opportunity \nto discuss design problems\, pending pat ches\, and persistent bugs. \n\nEven if you do not join\, you may solicit su bjects for discussion on \nthe mailing list or over #v...@irc.freenode.net. \n\nNote the new meeting time and conference code. \n\nConference code: 353- 86-075-901. \n\nDial-in information: \nhttps://www.intercallonline.com/listN umbersByCode.action?confCode=35386075901 BEGIN:VALARM ACTION:DISPLAY TRIGGER;RELATED=START:-PT5M DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] deepcopy error when saveState
On Thu, Mar 13, 2014 at 03:27:29PM +0800, bigclouds wrote: what is the reason of this error? Thread-20::DEBUG::2014-03-12 19:04:23,191::BindingXMLRPC::161::vds::(wrapper) client [192.168.0.113] Thread-20::DEBUG::2014-03-12 19:04:23,191::task::563::TaskManager.Task::(_updateState) Task=`30301b19-55ba-4152-98fd-0301d1c3975a`::moving from state init - state preparing File /usr/lib64/python2.7/copy.py, line 257, in _deepcopy_dict File /usr/lib64/python2.7/copy.py, line 190, in deepcopy File /usr/lib64/python2.7/copy.py, line 334, in _reconstruct File /usr/lib64/python2.7/copy.py, line 163, in deepcopy File /usr/lib64/python2.7/copy.py, line 257, in _deepcopy_dict File /usr/lib64/python2.7/copy.py, line 190, in deepcopy File /usr/lib64/python2.7/copy.py, line 334, in _reconstruct File /usr/lib64/python2.7/copy.py, line 163, in deepcopy File /usr/lib64/python2.7/copy.py, line 257, in _deepcopy_dict File /usr/lib64/python2.7/copy.py, line 190, in deepcopy File /usr/lib64/python2.7/copy.py, line 329, in _reconstruct File /usr/lib64/python2.7/copy_reg.py, line 93, in __newobj__ TypeError: object.__new__(PyCapsule) is not safe, use PyCapsule.__new__() Thread-13::DEBUG::2014-03-12 19:04:21,526::vm::2226::vm.Vm::(_startUnderlyingVm) vmId=`6d32200d-43ee-48a5-8ee9-fe6beaf2ca9d`::_ongoingCreations released Thread-13::INFO::2014-03-12 19:04:21,550::vm::2250::vm.Vm::(_startUnderlyingVm) vmId=`6d32200d-43ee-48a5-8ee9-fe6beaf2ca9d`::Skipping errors on recovery Could you attach 6d32200d-43ee-48a5-8ee9-fe6beaf2ca9d.recovery file? It might have been corrupted (e.g. due to a filesystem error) which most probably means the untimely death of your VM. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [PATCH] Monkeypatch python's thread.allocate_lock
On Sun, Mar 02, 2014 at 12:01:21PM +0200, Yaniv Bronhaim wrote: In python's thread package implementation thread.allocate_lock is being used in each creation of new thread (python.__bootstrap_inner). Vdsm faced few scenarios where the thread run was stuck in this function. We assume that this lock implementation contains a deadlock bug. Therefore I did not see enough evidence for this assumption, however, using pthreading.Lock everywhere is just cleaner. Could you say we suspect instead? this patch replaces thread.allocate_lock with python-pthreading Lock object (which uses pthread mutex). python-pthreading Lock - pthreading.Lock Other than this - ACK. Please take it into git. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] question about faqemu hook
On Tue, Feb 25, 2014 at 02:51:54PM +0200, ybronhei wrote: Hey, does someone know why do we set memory size value to 20480 (20mb) in before_vm_start hook when using fake qemu? That's the whole point that makes it a *fake* qemu. The hook is intended to be used in cases when you do not care about the guest - you just want it out there, bothering the management stack with its existence. It is not expected to run anything, and it should consume as little resources as possible, so that a quality engineer can condense as many fake VMs on a single host (most porbably a lightweight virtualized host). ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] fedora19 needs the new glusterfs repo for certain CI jobs
On Thu, Feb 13, 2014 at 09:30:21AM -0500, Eyal Edri wrote: - Original Message - From: Ohad Basan oba...@redhat.com To: Vered Volansky ve...@redhat.com Cc: infra in...@ovirt.org Sent: Thursday, February 13, 2014 3:04:13 PM Subject: Re: fedora19 needs the new glusterfs repo for certain CI jobs I think that what has to be done here is that we need to add to puppet the gluster upstream repository. opinions anyone? you're talking about the glusterfs epel repos? fine by me, but adding vdsm devel to confirm. e. - Original Message - From: Vered Volansky ve...@redhat.com To: infra in...@ovirt.org Sent: Thursday, February 13, 2014 3:03:24 PM Subject: fedora19 needs the new glusterfs repo for certain CI jobs Hi, When http://jenkins.ovirt.org/job/vdsm_storage_functional_tests_localfs runs on a fedora19 machine, it seems as though the glusterfs repository is stale. Can it please be updated? Please note the following error in http://jenkins.ovirt.org/job/vdsm_storage_functional_tests_localfs/170/consoleFull . Error: Package: glusterfs-cli-3.4.0-8.fc19.x86_64 (@updates) Requires: glusterfs-libs = 3.4.0-8.fc19 and so on... Ohad, any reason why http://download.fedoraproject.org/pub/fedora/linux/updates/19/x86_64/glusterfs-3.4.2-1.fc19.x86_64.rpm is not installed on the slave? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] pylint in make check-local
On Mon, Feb 17, 2014 at 01:21:11PM +0100, Ewoud Kohl van Wijngaarden wrote: On Mon, Feb 17, 2014 at 11:44:37AM +, Dan Kenigsberg wrote: While I'm waiting for more acks/nacks, could infra add pylint to our Jenkins slaves? Is the version in EL6 recent enough or do we have to ship our own version? (EL6 is 0.21.1) Please review http://gerrit.ovirt.org/24556 Let's take the standard one, and move to something more modern (such as Fedora's 1.0.0) when the need arrises. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] fedora19 needs the new glusterfs repo for certain CI jobs
On Sun, Feb 16, 2014 at 09:59:52AM -0500, Ohad Basan wrote: I see that the only repository that exists there is aarch64 (ARM) which is irrelevant for us. Sorry for misleading you into this. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] VDSM Storage tests @ Jenkins
On Mon, Feb 10, 2014 at 03:10:56PM +0100, Vinzenz Feenstra wrote: Hi, Could we please disable the storage tests until they are really working? These random failures are really creating more noise than being helpful. As much as I think that they are valuable to have, I think Vinzenz is correct - they are not yet dependable. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] suggested patch for python-pthreading
On Tue, Feb 04, 2014 at 04:04:37AM -0500, Yaniv Bronheim wrote: according to coredumps we found in the scope of the bug [1] we opened [2] that suggested to override python's implementation of thread.allocate_lock in each coredump we saw few threads stuck with the bt: #16 0x7fcb69288c93 in PyEval_CallObjectWithKeywords (func=0x2527820, arg=0x7fcb6972f050, kw=value optimized out) at Python/ceval.c:3663 #17 0x7fcb692ba7ba in t_bootstrap (boot_raw=0x250a820) at Modules/threadmodule.c:428 #18 0x7fcb68fa3851 in start_thread (arg=0x7fcb1bfff700) at pthread_create.c:301 #19 0x7fcb6866694d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 in pystack the threads were stuck in /usr/lib64/python2.6/threading.py (513): __bootstrap_inner in bootstrap_inner we use thread.allocate_lock which python-pthreading does not override. we suggest the following commit: From 9d89e9be1a379b3d93b23dd54a381b9ca0973ebc Mon Sep 17 00:00:00 2001 From: Yaniv Bronhaim ybron...@redhat.com Date: Mon, 3 Feb 2014 19:24:30 +0200 Subject: [PATCH] Mocking thread.allocate_lock with Lock imp Signed-off-by: Yaniv Bronhaim ybron...@redhat.com --- pthreading.py | 4 1 file changed, 4 insertions(+) diff --git a/pthreading.py b/pthreading.py index 916ca7f..96df42c 100644 --- a/pthreading.py +++ b/pthreading.py @@ -132,6 +132,10 @@ def monkey_patch(): Thus, Queue and SocketServer can easily enjoy them. +import thread + +thread.allocate_lock = Lock + import threading threading.Condition = Condition -- 1.8.3.1 [1] https://bugzilla.redhat.com/show_bug.cgi?id=1022036 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1060749 It makes sense to use pthreading.Lock for thread.allocate_lock instead of the standard threading.Lock CPU hog. However, I do not understand its relevance to the deadlock sited above: pthreading.Lock fixes performance issues, but not correctness issues, of threading.Lock. Would you explain, in the commit message of the pthreading patch, why you believe that the implementation of thread.allocate_lock() is buggy? Do you know if the bug is fixed in Python 3? Regards, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] mom RPMs for 3.4
On Fri, Jan 31, 2014 at 04:56:12PM -0500, Adam Litke wrote: On 31/01/14 08:36 +0100, Sandro Bonazzola wrote: Il 30/01/2014 19:30, Adam Litke ha scritto: On 30/01/14 18:13 +, Dan Kenigsberg wrote: On Thu, Jan 30, 2014 at 11:49:42AM -0500, Adam Litke wrote: Hi Sandro, After updating the MOM project's build system, I have used jenkins to produce a set of RPMs that I would like to tag into the oVirt 3.4 release. Please see the jenkins job [1] for the relevant artifacts for EL6[2], F19[3], and F20[4]. Dan, should I submit a patch to vdsm to make it require mom = 0.4.0? I want to be careful to not break people's environments this late in the 3.4 release cycle. What is the best way to minimize that damage? Hey, we're during beta. I prefer making this requirement explicit now over having users with supervdsmd.log retate due to log spam. In that case, Sandro, can you let me know when those RPMs hit the ovirt repos (for master and 3.4) and then I will submit a patch to vdsm to require the new version. mom 0.4.0 has been built in last night nightly job [1] and published to nightly by publisher job [2] so it's already available on nightly [3] For 3.4.0, it has been planned [4] a beta 2 release on 2014-02-06 so we'll include your builds in that release. I presume the scripting for 3.4 release rpms will produce a version without the git-rev based suffix: ie. mom-0.4.0-1.rpm? I need to figure out how to handle a problem that might be a bit unique to mom. MOM is used by non-oVirt users who install it from the main Fedora repository. I think it's fine that we are producing our own rpms in oVirt (that may have additional patches applied and may resync to upstream mom code more frequently than would be desired for the main Fedora repository). Given this, I think it makes sense to tag the oVirt RPMs with a special version suffix to indicate that these are oVirt produced and not upstream Fedora. For example: The next Fedora update will be mom-0.4.0-1.f20.rpm. The next oVirt update will be mom-0.4.0-1ovirt.f20.rpm. Is this the best practice for accomplishing my goals? One other thing I'd like to have the option of doing is to make vdsm depend on an ovirt distribution of mom so that the upstream Fedora version will not satisfy the dependency for vdsm. What is the motivation for this? You would not like to bother Fedora users with updates that are required only for oVirt? Vdsm itself is built, signed, and distributed via Fedora. It is also copied into the ovirt repo, for completeness sake. Could MoM do the same? Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] ovirt-3.3.3 release postponed due to blockers
On Fri, Jan 31, 2014 at 04:16:54PM -0500, Douglas Schilling Landgraf wrote: On 01/31/2014 05:17 AM, Dan Kenigsberg wrote: On Fri, Jan 31, 2014 at 09:36:48AM +0100, Sandro Bonazzola wrote: Il 30/01/2014 22:38, Robert Story ha scritto: Can we revert these packages to previous versions in the 3.3.2 stable repo so those of us who want/need to install new hosts in our clusters aren't dead in the water waiting for 3.3.3? Hi Robert, I think you can still install 3.3.2 on your clusters with the requirement of adding manually oython-cpopen before trying to install vdsm. About 3.3.3, I think vdsm should really drop dependency on vdsm-python-cpopen: it's a package obsoleted by python-cpopen so there's no point in still requiring it especially if keeping that requirement still break dependency resolution. I really wanted to avoid eliminating a subpackage during a micro release. That's impolite and surprising. But given the awkward yum bug, persistent dependency problems, and the current release delay, I give up. Let's eliminate vdsm-python-cpopen from ovirt-3.3 branch, and require python-cpopen. Yaniv, Douglas: could you handle it? Sure. Done: http://gerrit.ovirt.org/#/c/23942/ Acked. Could you cherry-pick it into dist-git and rebuild the ovirt-3.3.3 candidate (and without other changes that can wait for ovirt-3.3.4). ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] ovirt-3.3.3 release postponed due to blockers
On Fri, Jan 31, 2014 at 09:36:48AM +0100, Sandro Bonazzola wrote: Il 30/01/2014 22:38, Robert Story ha scritto: Can we revert these packages to previous versions in the 3.3.2 stable repo so those of us who want/need to install new hosts in our clusters aren't dead in the water waiting for 3.3.3? Hi Robert, I think you can still install 3.3.2 on your clusters with the requirement of adding manually oython-cpopen before trying to install vdsm. About 3.3.3, I think vdsm should really drop dependency on vdsm-python-cpopen: it's a package obsoleted by python-cpopen so there's no point in still requiring it especially if keeping that requirement still break dependency resolution. I really wanted to avoid eliminating a subpackage during a micro release. That's impolite and surprising. But given the awkward yum bug, persistent dependency problems, and the current release delay, I give up. Let's eliminate vdsm-python-cpopen from ovirt-3.3 branch, and require python-cpopen. Yaniv, Douglas: could you handle it? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] ovirt-3.3.3 release postponed due to blockers
On Thu, Jan 30, 2014 at 08:52:36AM +, Sven Kieske wrote: Hi, any news regarding my questions? Am 29.01.2014 09:23, schrieb Sandro Bonazzola: Il 29/01/2014 09:21, Sven Kieske ha scritto: Hi, I wanted to try it the other way around, installing vdsm-python-cpopen and check if it runs without python-cpopen . But that leads me to a question: Is there any difference between these packages beside their different name? If yes, what is the difference and which package should be installed? I no, why is there a packet vdsm-python-cpopen ? CCing VDSM python-cpopen includes some improvements and bug fixes, that are going to be needed in ovirt-3.4. vdsm-python-cpopen is shipped by ovirt-3.3. python-cpopen wast intended to deprecate and replace vdsm-python-cpopen, but we have had way too many issues trying to do that properly in rpm/yum. Most of the bugs are ours, at least one is yum's. At the moment, the existence of python-cpopen in Fedora confuses `yum install vdsm`. To avoid this unfortunate delay, we can either include python-cpopen in ovirt-stable or exclude vdsm-python-cpopen from there. Both options are unfavorable, but so is continuing to wait. Regards, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] ovirt-3.3.3 release postponed due to blockers
On Thu, Jan 30, 2014 at 10:27:34AM +0100, Sandro Bonazzola wrote: Il 30/01/2014 10:20, Dan Kenigsberg ha scritto: On Thu, Jan 30, 2014 at 08:52:36AM +, Sven Kieske wrote: Hi, any news regarding my questions? Am 29.01.2014 09:23, schrieb Sandro Bonazzola: Il 29/01/2014 09:21, Sven Kieske ha scritto: Hi, I wanted to try it the other way around, installing vdsm-python-cpopen and check if it runs without python-cpopen . But that leads me to a question: Is there any difference between these packages beside their different name? If yes, what is the difference and which package should be installed? I no, why is there a packet vdsm-python-cpopen ? CCing VDSM python-cpopen includes some improvements and bug fixes, that are going to be needed in ovirt-3.4. vdsm-python-cpopen is shipped by ovirt-3.3. python-cpopen wast intended to deprecate and replace vdsm-python-cpopen, but we have had way too many issues trying to do that properly in rpm/yum. Most of the bugs are ours, at least one is yum's. At the moment, the existence of python-cpopen in Fedora confuses `yum install vdsm`. To avoid this unfortunate delay, we can either include python-cpopen in ovirt-stable or exclude vdsm-python-cpopen from there. Both options are unfavorable, but so is continuing to wait. If it's enough just to add python-cpopen to ovirt-stable, I'm fine with that. I just need the link to the build to be included there. Yaniv, have you tried if shipping python-cpopen hides this issue? http://kojipkgs.fedoraproject.org//packages/python-cpopen/1.3/1.fc20/x86_64/python-cpopen-1.3-1.fc20.x86_64.rpm http://kojipkgs.fedoraproject.org//packages/python-cpopen/1.3/1.fc19/x86_64/python-cpopen-1.3-1.fc19.x86_64.rpm http://kojipkgs.fedoraproject.org//packages/python-cpopen/1.3/1.el6/ppc64/python-cpopen-1.3-1.el6.ppc64.rpm Dropping vdsm-python-cpopen from a stable version seems impolite, but should work, too. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] mom RPMs for 3.4
On Thu, Jan 30, 2014 at 11:49:42AM -0500, Adam Litke wrote: Hi Sandro, After updating the MOM project's build system, I have used jenkins to produce a set of RPMs that I would like to tag into the oVirt 3.4 release. Please see the jenkins job [1] for the relevant artifacts for EL6[2], F19[3], and F20[4]. Dan, should I submit a patch to vdsm to make it require mom = 0.4.0? I want to be careful to not break people's environments this late in the 3.4 release cycle. What is the best way to minimize that damage? Hey, we're during beta. I prefer making this requirement explicit now over having users with supervdsmd.log retate due to log spam. [1] http://jenkins.ovirt.org/view/All/job/manual-build-tarball/179/ [2] http://jenkins.ovirt.org/view/All/job/manual-build-tarball/179/label=centos6-host/artifact/exported-artifacts/mom-0.4.0-1.el6.noarch.rpm [3] http://jenkins.ovirt.org/view/All/job/manual-build-tarball/179/label=fedora19-host/artifact/exported-artifacts/mom-0.4.0-1.fc19.noarch.rpm [4] http://jenkins.ovirt.org/view/All/job/manual-build-tarball/179/label=fedora20-host/artifact/exported-artifacts/mom-0.4.0-1.fc20.noarch.rpm ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] ovirtmgmt vanishes after reboot
On Wed, Jan 29, 2014 at 11:07:08AM +0100, Fabian Deutsch wrote:
Am Mittwoch, den 29.01.2014, 05:02 -0500 schrieb Antoni Segura Puimedon:
Right.
I believe the bug you are seeing is:
http://gerrit.ovirt.org/#/c/20068/
This has been merged into out stable branch, but the release of a new
oVirt Node ISO for 3.3 is pending because of the vdsm-python-cpopen
dependency problem.
Would you agree to patch `yum` on your build machine? I do not fully
understand the issue, but with the following patch, the dependency
problem is resolved for me:
diff --git a/yum/depsolve.py b/yum/depsolve.py
index 95c21bc..57cf379 100644
--- a/yum/depsolve.py
+++ b/yum/depsolve.py
@@ -720,7 +720,7 @@ class Depsolve(object):
else:
self.verbose_logger.debug(_('TSINFO: Marking %s as install for
%s'), best,
requiringPo)
-reqtuple = misc.string_to_prco_tuple(needname + str(needflags) +
needversion)
+reqtuple = misc.string_to_prco_tuple(requirement)
txmbrs = self.install(best, provides_for=reqtuple)
for txmbr in txmbrs:
txmbr.setAsDep(po=requiringPo)
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Introduction of VDSM - Guest Agent API Versioning
On Wed, Jan 22, 2014 at 12:12:53PM +0100, Vinzenz Feenstra wrote: Hi, With the increasing complexity on different version of the guest agent and vdsm I have proposed a patchset for each the guest agent and vdsm to implement it on top of the current protocol, in a way that it will not affect the existing protocol. This patchset has created some controversy about its implementation and design and I was asked to kick off a discussion to design a better implementation or validate the suggested approach. My goals for the API versioning: === - Make VDSM and the Guest Agent both aware of what the other side understands (which messages) to avoid logging errors - The used version of the API should be automatically and immediately be agreed upon in case any change happened. And in case one end doesn't support it but the other does, the supporting end must revert back to a compatible state. Possible scenarios: - a VM gets migrated from a VDSM version with API version support to a VDSM without API version support (or lower version) - VDSM gets downgraded or upgraded and the API version changed or is no longer supported - The ovirt-guest-agent gets up or downgraded and Vdsm upgrade, too. - Make use of existing messages which allow extending without generating errors or would result in VDSM API changes due to direct export of the message, to be backwards compatible on both ends From my side not considered as goals for the API Versioning: == (sorry, I do not understand this section and its title. are these things you need? nice-to-have? would like to avoid?) - Deprecation of messages, because you can send alternatives if the other side supports it - Raising the lowest supported API version, as this would actually break backwards compatibility The proposed solution: == VDSM: - Add a field to the 'refresh' message reporting the highest API version supported by VDSM - Upon receiving the 'heartbeat' message check for the `apiVersion` field to know if the guest agent supports api versioning. - If the fields is not present: The guest agent won't support api versioning. And it needs to be disabled on the VDSM side and the version 0 has to be assumed. That simply means only messages can be sent which were supported before the API versioning was introduced. - If the field is present: The value of the field is supposed to represent the maximum version supported by the guest agent. VDSM then makes a `min(vdsmMaxApiVersion, guestAgentMaxApiVersion)` to determine the highest common value and uses this value as supported API version. When the value has changed since the last time a heartbeat was received. VDSM will send a message 'api-version' to update the guest agent about the determined value. And sets the internally stored apiVersion value to this new value. Guest Agent: - Adds the field `apiVersion` to the heartbeat containing the highest API version supported by the guest agent - Upon receiving the `refresh` message without a `apiVersion` field, the guest agent immediately will revert immediately fall back to version 0 To avoid sending any messages which are not yet supported. - Upon receiving the `api-version` message, the guest agent will verify the value received and sets the value to min(received, maxAgentApiVersion) which should, of course, result in setting the received value (this is just an additional step to ensure it does not send more than supported by VDSM. Once having the API version, we can use some lookup table for the messages before sending and check which version is required to send it. And we would even be able to give some feedback if we support a feature or not on the guest side. Please let me know your opinion and I would be welcoming suggestions or any other comment related to this. I find this reasonable solution - despite several comments that I had regarding the implementation's clarity. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Introduction of VDSM - Guest Agent API Versioning
On Mon, Jan 27, 2014 at 03:00:55PM +0100, Vinzenz Feenstra wrote: On 01/27/2014 02:57 PM, Dan Kenigsberg wrote: On Wed, Jan 22, 2014 at 12:12:53PM +0100, Vinzenz Feenstra wrote: Possible scenarios: - a VM gets migrated from a VDSM version with API version support to a VDSM without API version support (or lower version) - VDSM gets downgraded or upgraded and the API version changed or is no longer supported - The ovirt-guest-agent gets up or downgraded and Vdsm upgrade, too. Second point VDSM gets downgraded or upgraded... oops, dunno how I've missed it. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Find reviewers for codes of Numa feature
On Sun, Jan 26, 2014 at 06:51:50AM +, Shi, Xiao-Lei (Bruce, HP Servers-PSC-CQ) wrote: Hi all, I have submitted a draft patch about Features/NUMA and Virtual NUMAhttp://www.ovirt.org/Features/NUMA_and_Virtual_NUMA. Here is the gerrit request: http://gerrit.ovirt.org/#/c/23703/ Please help me to review the codes. Thanks for your contrinution! I see that Francesco gave it a preliminary review. Since this patch borders virt and sla, I think that Martin could be of help, too. When you introduce new API functionality, you most usually need to document it in vdsm_api/vdsmapi-schema.json and explain in the commit message, how would the new response to this verb would look like. Unit tests serve as a good example of how to use the new code. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Vdsm network functional tests taking slave offline
On Thu, Jan 23, 2014 at 01:17:21PM +0100, David Caro wrote: Hi! We have been seeing the slave that is used for the network tests getting offline from time to time, it was dues to vdsm_functional_tests not cleaning up properly, as removing all the *dummy* interface configurations from /etc/sysconfig/network-scripts and restarting the network brings it back again. Can you take a look on why it would not have been cleaning up properly? the last job that made the host go offline is: http://jenkins.ovirt.org/job/vdsm_network_functional_tests/1173/console The number of the dummy interface that was left over was 6 (not sure it's reelevant, but just in case). It seems that Jenkins killed the job forcefully, before it had the chance to clean after itself: testIPv6ConfigNetwork FATAL: Unable to delete script file /home/jenkins/workspace/tmp/hudson6940503892814963275.sh hudson.util.IOException2: remote file operation failed: /home/jenkins/workspace/tmp/hudson6940503892814963275.sh at hudson.remoting.Channel@67a91450:fedora19-vm01 at hudson.FilePath.act(FilePath.java:906) at hudson.FilePath.act(FilePath.java:883) at hudson.FilePath.delete(FilePath.java:1268) ... Does jenkins have the ability to add a job-specific cleanup script, to be excuted on such occasions? I'm sure Toni could populate it witha couple of lines to remove remainders? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [gerrit 23138] VM responsiveness and libvirt timeouts
On Wed, Jan 22, 2014 at 05:49:11AM -0500, Francesco Romani wrote: Hi everyone, I'd like to gather some thoughts about this change http://gerrit.ovirt.org/#/c/23138/5 Sorry for the long mail, but the scenario is not trivial to explain and I tried to achieve a decent compromise between terseness and completeness. Context --- Everything starts from the bugzilla https://bugzilla.redhat.com/866484 . Summary of the bug: when a blockInfo call to libvirt goes in timeout, the status of the affected VM start to bounce in the engine between 'Non Responsive' and 'Up'. This is because the responsiveness of a VM is tracked using a single flag, updated each after libvirt call, and the flag could be overwritten behind the back of the engine (between two getStats). In a nutshell, the responsiveness of a VM could observed in a different way depending on the time sequence of the updates. It is worth to mention that, I *cannot* yet reproduce in the terms described in the bug description. Part of the reason why I failed to reproduce it is a particular event sequence is required to achieve the bouncing effect described in the bug. The event sequence is in turn determined by the timing of the block storage timeout and by the time the engine queries the affected VDSM. Pardon my skeptism, but a bug that was opened with How reproducible: 100% and now cannot be reproduced at all smells like a misunderstood bug. However, my understanding is that the scenario which emerges from the bug description and the analysis of the logs attached to the bug is still relevant, although somewhat unlikely. This is the reason why I submitted the change http://gerrit.ovirt.org/#/c/23138/5 The issue with the new patch The new code determines the responsiveness of the monitor -and thus of the VM- in a `pessimistic` way, meaning that now as long as at least one call to libvirt fails, the VM is deemed unresponsive. On the other hand, with the current code, if an attribute is unresponsive but if the sequence of events is good enough, the not responsive time interval could be hidden from the engine's sight. Or, of course, the engine could see the bouncing we're discussing. In a nutshell, the new code could be too pessimistic in reporting the state. A VM could be reported not responsive longer and more often (again it all depends on the event sequence) than before. Indeed, this issue is crippling. For example, if you fire up migration, and due to a transient hickup, libvirt times out, we would get into a dead end. The attribute for migrate would be set to -1, the VM would be reported as non-responsive, and no future migrate command would ever be sent to free it. It that is the case, the problem is: how to fix the reporting in a more optimistic way? Possible solution - While reviewing the change with Michal, we found that partitioning the set of the calls to be monitored in critical/not critical could be a way: * critical libvirt calls: if at least one fails for timeout, and while it fails for timeout, the VM is considered Unresponsive. * not critical: a timeout is logged but ignored to decide the responsiveness of the VM Would that be an improvement with respect to the current state and, possible, a viable long-term solution? I like the idea of partitioning, but criticality is not a clear indicator imo. monitorResponse was introduced as a heuristical answer to the question would qemu accept an upcoming command and act upon it in a timely manner? A libvirt.virDomain method that succeeds despite its qemu process being SIGSTOPped, should not be considered when setting monitorResponse. I we undestand what has reset monitorResponse in Dafna's scenerio, we could avoid wrapping it with _timeoutExperienced. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Engine-devel] Copy reviewer scores on trivial rebase/commit msg changes
On Sat, Jan 18, 2014 at 01:48:52AM +0200, Itamar Heim wrote: I'd like to enable these - comments welcome: 1. label.Label-Name.copyAllScoresOnTrivialRebase If true, all scores for the label are copied forward when a new patch set is uploaded that is a trivial rebase. A new patch set is considered as trivial rebase if the commit message is the same as in the previous patch set and if it has the same code delta as the previous patch set. This is the case if the change was rebased onto a different parent. This can be used to enable sticky approvals, reducing turn-around for trivial rebases prior to submitting a change. Defaults to false. 2. label.Label-Name.copyAllScoresIfNoCodeChange If true, all scores for the label are copied forward when a new patch set is uploaded that has the same parent commit as the previous patch set and the same code delta as the previous patch set. This means only the commit message is different. This can be used to enable sticky approvals on labels that only depend on the code, reducing turn-around if only the commit message is changed prior to submitting a change. Defaults to false. https://gerrit-review.googlesource.com/Documentation/config-labels.html I think that the time saved by these copying is worth the dangers. But is there a way to tell a human ack from an ack auto-copied by these options? It's not so fair to blame X for X approved this patch when he only approved a very similar version thereof. Assuming that a clean rebase can do no wrong is sometimes wrong (a recent example is detailed by Nir's http://gerrit.ovirt.org/21649/ ) Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Engine-devel] Gerrit NEW Change Screen
On Thu, Jan 16, 2014 at 08:16:17AM -0500, Adam Litke wrote: On 16/01/14 00:08 +0200, Itamar Heim wrote: with gerrit 2.8, there is a new change screen. its not enabled by default (yet), please use and see what you think. to enable, go to settings (click the top-right arrow next to your name, and choose settings). select preferences and set Change View: to New Screen. Thanks Itamar. For me, this new screen is much better. Things are more compact and for most patches all of the important information fits easily on one screen. I also like the easy to find gitweb link and the ability to edit the commit message right from the interface. On my narrow lcd, though, the new look makes comments in diff to be seen only partially. I failed to find a configurable to make the comment windows narrower, so my only solution is to reduce the font (which is bad for my poor old eyes). ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] [QE] 3.4.0 Release tracker
On Mon, Jan 13, 2014 at 11:05:05AM +0100, Sander Grendelman wrote: On Mon, Jan 13, 2014 at 12:32 AM, Dan Kenigsberg dan...@redhat.com wrote: On Fri, Jan 10, 2014 at 04:55:18PM +0200, Itamar Heim wrote: On 01/10/2014 01:52 PM, Sander Grendelman wrote: Can I propose BZ#1035314 for 3.3.3 or 3.4.0, simple, trivial fix to a hook. Hi Sander, please use bug summary so folks won't have to go and look what the number means just to see if relevant to them. this is about: Bug 1035314 - vdsm-hook-nestedvt uses kvm_intel-only syntax OK, I'll keep that in mind! i see you posted a patch in the bug - can you post the patch to gerrit as well? I've done that alraedy: http://gerrit.ovirt.org/#/c/23164/ Sander (and others), could you review and formally verify it? Looks fine to me, should I also do/confirm something in gerrit? Yes, it would be great if you tick the patch as verified, as I did not try it myself. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] [QE] 3.4.0 Release tracker
On Fri, Jan 10, 2014 at 04:55:18PM +0200, Itamar Heim wrote: On 01/10/2014 01:52 PM, Sander Grendelman wrote: Can I propose BZ#1035314 for 3.3.3 or 3.4.0, simple, trivial fix to a hook. Hi Sander, please use bug summary so folks won't have to go and look what the number means just to see if relevant to them. this is about: Bug 1035314 - vdsm-hook-nestedvt uses kvm_intel-only syntax i see you posted a patch in the bug - can you post the patch to gerrit as well? I've done that alraedy: http://gerrit.ovirt.org/#/c/23164/ Sander (and others), could you review and formally verify it? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Smarter network_setup hooks
On Wed, Jan 08, 2014 at 03:34:24PM +0100, Miguel Angel wrote: Hi Assaf, Thank you very much for the summary, Just a few questions, there are things I don't understand yet: 2014/1/8 Assaf Muller amul...@redhat.com Mid-thread summary: First some terminology so we're all on the same page: 'request' - The setupNetworks that just arrived 'running config' - If unified persistence is being used - All networking on the host as VDSM sees it 'expected' - If unified persistence is being used - The running config after the effects of the request, but before the hook is ran correct I think we all agree that we have to expose the 'request' to the hook. However, there's two different approaches: 1) Allow the hook to rewrite parts of the request (For example, if two networks were sent, and the hook handled one of them, it could then delete that network from the request, so VDSM will only continue to configure the 2nd network). In this case ,if the hook deleted the 2nd network, VDSM couldn't handle the network config persistence anymore, right?, Right. If the before_network_setup hook decides to drop an item from the 'request', it means that neither following hooks, nor Vdsm proper, would see it. I find it as a useful and simple sematics: the hook practically says I'm taking it from here, and from then on, it is repsonsible for everything. Implementation and persistence alike. I didn't expect this use case, I only expected tweaks, etc (before or after network setup), for example, setting special hardware capabilities using ethtool or those kind of things. Neither have I expected this. But it's a powerful tool that's relatively easy to implement. 2) Toni's idea with marking devices as hook-configured. So if a network is over a bridge over a VLAN over a bond over three NICs, hooks could configure only the NICs (For example) and VDSM would configure the rest, whereas the first idea means that the hook would have to configure the entire network (Bridge, VLANs, bonds, and all 3 NICs) and then remove that network from the request. The disadvantage of this method is that it would be harder to implement, and have references to the hooks flag throughout all of VDSM. You mean that if the hook marked a certain device as hook handled then, VDSM would just keep this information along with the network config, etc... and won't do any setup, just config-keeping, right? That's my understanding, too. And I share the feeling that this is error prone: Vdsm sees the config, but must remember that it should not touch it or act upon it. Then there's the matter of IF to expose the 'running config' and 'expected'. My main argument is that it's very easy to expose to the hooks (But then why not expose other 'random' data that is easy for VDSM to calculate?), and that we don't understand all usages for the setupNetworks hooks. I'd rather we expose too much information than not enough and screw over hook writers. We have something important here, the hooks don't need to be python-written, they could be bash scripts, or any other thing... that means that they wouldn't have access to get running config, but they could calculate expected. So, my vote here goes for request + running config. The running config is accessible to any process, albeit not in its Vdsm representation. All the information is available if you do `ip a` and `virsh net-list`. I do not imagine why a hook would need the running config; If it does end up needing it, it could re-calculate it just as Vdsm does. Passing this as argument to each hook script is a premature optimization imho. If I end up wrong, it would not be hard to add the running config to the Vdsm/hook API. Removing something from an API is a much harder task. My vote goes to only request. Either way, let's get some votes in a timely manner so we could manage to implement this for 3.4. Thanks Assaf! ;) ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Smarter network_setup hooks
On Sun, Jan 05, 2014 at 05:05:59AM -0500, Assaf Muller wrote: Whichever way we decide to do this, I think the important bit is documentation - We have to make sure to update the oVirt wiki hooks pages. If users aren't aware of how to retrieve the networking config then we might as well not implement it. That being said, I'd expose three dictionaries: What's currently configure, the current request, as well as the proposed end result. I do not see why current is a good idea to pass from Vdsm to the hook - if the hook needs it, it could compute the current state on its own. What do you mean by the proposed end result? setupNetwork API works in allows diffs relative to the current state. The end result, however, may even be unexpressable within the scope of our API (that's exactly what hooks are for!). And again, if Vdsm is able to calculate the end result based on the current state + diff, so can the hook itself. It's easy to add and I see how it would be useful to hook writers. And just to state the obvious, just like how traditional hooks can change the VM or device XML, the hook should be able to rewrite the current request contents. For example, if a user would like to take over host networking configuration, he could just write a before_setup_networks hook that would configure networking however he wants, then writes the empty dictionary to the current request, meaning that VDSM wouldn't do anything further with the current setup networks request. This would be a very good additions. Cascaded scripts would then be able to drop parts of the command, which they have implemented themselves. Regards, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Smarter network_setup hooks
On Sun, Jan 05, 2014 at 08:58:07PM -0500, Antoni Segura Puimedon wrote: - Original Message - From: Miguel Angel miguelan...@ajo.es To: Livnat Peer lp...@redhat.com Cc: dsull...@redhat.com, vdsm-de...@fedorahosted.org, a...@ovirt.org Sent: Sunday, January 5, 2014 11:41:44 PM Subject: Re: [vdsm] Smarter network_setup hooks 2014/1/5 Livnat Peer lp...@redhat.com On 01/05/2014 12:05 PM, Assaf Muller wrote: Whichever way we decide to do this, I think the important bit is documentation - We have to make sure to update the oVirt wiki hooks pages. If users aren't aware of how to retrieve the networking config then we might as well not implement it. That being said, I'd expose three dictionaries: What's currently configure, the current request, as well as the proposed end result. It's easy to add and I see how it would be useful to hook writers. And just to state the obvious, just like how traditional hooks can change the VM or device XML, the hook should be able to rewrite the current request contents. For example, if a user would like to take over host networking configuration, he could just write a before_setup_networks hook that would configure networking however he wants, then writes the empty dictionary to the current request, meaning that VDSM wouldn't do anything further with the current setup networks request. My original thought on this was that the hook would be able to mark a device as configured by it adding a key value like 'hooked': X. This was in order that if, for example a bond is to be configured by the hook, it would still stay in the config passed to objectivize but the configurator configure method for it would be short circuited and X would have the data that is to be put in the running config by vdsm for that device. I didn't mature this thought much though... (holidays have kept me a bit busy) Oh, few seconds ago I noted about the idea that hooks scripts would be able to remove parts of the configuration which they have already implemented, so that Vdsm proper is left unaware of them. It's not as flexible as your hooked=True suggestion, as it does not alow to implement only part of a network, but I think that it is as-powerful and with clearer atomicity. I'm not sure if it's easy to get the final state without actually applying it, it's easy to get an approximate final state (just aggregating dictionaries to networks and bondings, and erasing the removed ones), but I suppose that'd be good enough :-) May be it's good if you can provide a use case for this third expected final state, I can't come up with one. :-) For this reason I thought of the 'hooked' value, to make the hook writer own the task of filling in the missing piece of state. Sorry, Toni, I do not understaed how hooked=True is related to the expected dictionary suggested by Assaf. One final consideration that I didn't see arise is the need for having caps hooks. As soon as we allow setupNetworks hooks it is very necessary that we enable vdsm caps. One very easy example. Let us say that I write a hook that makes setupNetworks specified bondings be configured in the system by libteam/teamd. In order for the changes to be made visible to the engine we need to fake that team link aggregation as a bond so that the engine can, in the future, change/delete/use it. Correct. The same json-based framework devised by Miguel (as well as Adam's getContext) would come up hand when implementing it. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] what does custom option mean when vmcreate ?
On Fri, Jan 03, 2014 at 11:25:04AM +0100, Michal Skrivanek wrote:
On 26 Dec 2013, at 07:32, bigclouds wrote:
the paramters received when vmCreate has a long part called custom,
do we use custom infomation? what does the long key
device_* means?
custom properties for devices
see the UI Custom Properties tab in Edit VM
I think that bigclouds meant the bizarre-looking properties that are
sent by Engine automatically, with no human interventions, per VmDevice that is
reported by Vdsm but not managed by Engine:
'device_82934f8e-7470-4c46-b9ed-d1c73fb17477device_87f6330a-278d-4b2a-9674-db58eb0e7023device_a19855be-70a9-49d0-9ea4-ee746b2d9739':
'VmDevice {vmId=46914913-8bcf-4fa0-b1fb-3680ca8b6c16,
deviceId=a19855be-70a9-49d0-9ea4-ee746b2d9739, device=virtio-serial,
type=CONTROLLER, bootOrder=0, specParams={}, address={bus=0x00, domain=0x,
type=pci, slot=0x06, function=0x0}, managed=false, plugged=true,
readOnly=false, deviceAlias=virtio-serial0, customProperties={},
snapshotId=null}'
It was an attempt for future-compatibility, by (ab)using the custom properties
interface. Certainly Eli or Igor can explain the motivation better.
Dan.
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] Trouble Upgrading (Fedora)
On Fri, Dec 06, 2013 at 03:35:22PM -0500, Eyal Edri wrote: we only have 2 jobs (that i'm aware of) that installs vdsm: http://jenkins.ovirt.org/view/vdsm/job/vdsm_3.3_install_rpm_sanity_gerrit/ http://jenkins.ovirt.org/view/vdsm/job/vdsm_master_install_rpm_sanity_gerrit/ i changed 3.3 to remove python-cpopen at the start of the test. Thanks, but do you understand why http://jenkins.ovirt.org/job/vdsm_3.3_install_rpm_sanity_gerrit/315/ (triggered after you've send this email) still fails? Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] Trouble Upgrading (Fedora)
On Thu, Dec 05, 2013 at 09:13:02PM -0500, Douglas Schilling Landgraf wrote: On 12/05/2013 08:45 AM, Vinzenz Feenstra wrote: On 12/05/2013 01:49 PM, Dan Kenigsberg wrote: Joining two threads on that subject On Sun, Nov 24, 2013 at 11:32:55AM -0500, Yaniv Bronheim wrote: Hey, - Original Message - From: Nicholas Kesick cybertimber2...@hotmail.com To: oVirt Mailing List us...@ovirt.org Sent: Friday, November 22, 2013 6:55:23 PM Subject: [Users] Trouble Upgrading (Fedora) I am having trouble upgrading on Fedora 19 to 3.3.1. Two observations: 1) I can't find ovirt-engine-3.3.1, even after a yum clear all; yum update. 2) There is a dependency update circle involving python-cpopen-1.2.3-4.fc19.x86_64 and dsm-python-cpopen.x86_64 0:4.13.0-11.fc19 This issue is fine. Not so smoothly but we had to do that. cpopen package is published as part of vdsm code in ovirt-3.3 and before, On master branch we require python-cpopen formal package that is shipped with fedora\rhel currently . Each time you'll switch between newer version of current master (3.4) to ovirt-3.3 or older you will notice this report We should break this vicious cycle. I think it was intended to simplify upgrade from ovirt-3.4 to ovirt-3.3 on Jenkins slaves. But that's plain wrong on a wider context. The Jenkins issue should be solved explicitly by removing python-cpopen when vdsm-python-cpopen has to be installed. python-cpopen should obsolete vdsm-python-cpopen, solving OUR jenkins issues in the released rpms. I see this loop too. python-cpopen spec obsoletes vdsm-python-cpopen, so vdsm.spec don't need to obsolete python-cpopen. Otherwise, it will generate an infinity loop during the yum update between these packages. http://gerrit.ovirt.org/#/c/22113/ Therefore +1 for solving that on jenkins +1 Douglas, before taking your patch to the ovirt-3.3 branch, would you work with infra@ to get all their ovirt-3.3 vdsm jobs remove python-cpopen before attempting to install vdsm? Regards, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm sync meeting December 2th
On Mon, Dec 02, 2013 at 01:40:24PM -0500, Douglas Schilling Landgraf wrote: VDSM sync meeting Monday December 2th 2013 = - Douglas going to make tests between VDSM and Fedora 20 - Antoni will rework on the 'make dist check' patches. - Dan raised to have virt functional tests for checking vdsm failure/disconnect versus reconnect. Antoni going to check with Martin. - Federico going to review: tests: Add simple mocking library http://gerrit.ovirt.org/#/c/21155/ - Antoni raised the thread: seobject vdsm master install https://lists.fedorahosted.org/pipermail/vdsm-devel/2013-November/002773.html - Yaniv going to check with Federico the ovirt-host-deploy/libvirt fallback problem. - Dan raised that we are going to increase the version of iscsi (rpm dependency) - Federico to review Douglas's doc about building new release: http://www.ovirt.org/Vdsm_Developers#Building_new_releases_for_Fedora_or_EPEL_with_fedpkg - tarball release - Yaniv is going to talk with infra team to check the best way to provide the vdsm tarball and patches. We never done it before, until now only provided the srpm/rpm builds. I've filed https://fedorahosted.org/ovirt/ticket/99 to track this issue. - The below patch going to be verified: Removing hack for stopping libvirt-guests as conflict service http://gerrit.ovirt.org/#/c/21205/1 - Fedora rpm branches and vdsm beta/stable builds. Yaniv and Douglas to push new beta 3.3.2 vdsm rpm into master branch. -- Cheers Douglas ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] VDSM and Fedora 20 test
On Tue, Dec 03, 2013 at 02:31:16PM +0100, Sandro Bonazzola wrote: Il 03/12/2013 17:20, Douglas Schilling Landgraf ha scritto: Hi, Below the initial tests that I have executed with vdsm version (4.13.0-11 and 4.13.0-12) on Fedora 20. Faced an 'iscsiadm: Error while adding record: no available memory' trying to connect to iscsi storage and opened a bugzilla [1] for it. Thanks, Douglas! Engine and otopi = oVirt Engine Version: 3.4.0-0.2.master.20131129131413.git3f58634.fc19 otopi-1.1.2-1.fc19 Testing this part of the project with f20 makes sense, too (but is less likely to break). Hosts === # cat /etc/fedora-release Fedora release 20 (Heisenbug) # getenforce Enforcing vdsm 4.13.0-11 (current stable) - Host deployed NFS: - Added NFS DATA and ISO [OK] have you tried to populate using iso-uploader / image-uploader? is log-collector able to collect logs for the traceback you've reported down here? snip ISCSI: Thread-498::ERROR::2013-12-03 00:33:29,199::hsm::2369::Storage.HSM::(connectStorageServer) Could not connect to storageServer Traceback (most recent call last): File /usr/share/vdsm/storage/hsm.py, line 2366, in connectStorageServer conObj.connect() File /usr/share/vdsm/storage/storageServer.py, line 359, in connect iscsi.addIscsiNode(self._iface, self._target, self._cred) File /usr/share/vdsm/storage/iscsi.py, line 150, in addIscsiNode iscsiadm.node_new(iface.name, portalStr, targetName) File /usr/share/vdsm/storage/iscsiadm.py, line 239, in node_new raise IscsiNodeError(rc, out, err) IscsiNodeError: (3, [], ['iscsiadm: Error while adding record: no available memory']) [1] F20: iscsiadm: Error while adding record: no available memory https://bugzilla.redhat.com/show_bug.cgi?id=1037602 To move ahead with block storage testing, could you try to rebuild iscsiadm or run Vdsm with fibre channel? Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] VDSM and Fedora 20 test
On Tue, Dec 03, 2013 at 05:03:26PM -0500, Douglas Schilling Landgraf wrote: I have found that iscsi-initiator-utils-6.2.0.873-11.fc20.x86_64 (or higher) introduces this error. I was able to create and run a virtual machine with the last build before the above one (iscsi-initiator-utils-6.2.0.873-9.fc20.x86_64). Also did manual tests with below versions and it worked as well: iscsi-initiator-utils-6.2.0.873-5.fc20.x86_64 iscsi-initiator-utils-6.2.0.873-7.fc20.x86_64 iscsi-initiator-utils-6.2.0.873-9.fc20.x86_64 Finally, I have talked with iscsi-initiator-utils package maintainer and he is aware of the problem. So, have you managed to fire up VMs with one of those installed? A basic migration/hibernation test would be interesting to conduct, too. Thanks Douglas! ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Fedora 20 seobject vdsm master install
On Tue, Nov 26, 2013 at 09:24:00AM -0500, Antoni Segura Puimedon wrote: Hi List, I just built master with some gerrit patch and when installing in Fedora20 I get the following: Installing : vdsm-python-4.13.0-179.gite51bbc3.fc20.x86_64 1/7 Installing : vdsm-xmlrpc-4.13.0-179.gite51bbc3.fc20.noarch 2/7 Installing : vdsm-python-zombiereaper-4.13.0-179.gite51bbc3.fc20.noarch 3/7 Installing : vdsm-4.13.0-179.gite51bbc3.fc20.x86_64 4/7 Traceback (most recent call last): File /usr/bin/vdsm-tool, line 145, in module sys.exit(main()) File /usr/bin/vdsm-tool, line 142, in main return tool_command[cmd][command](*args[1:]) File /usr/lib64/python2.7/site-packages/vdsm/tool/seboolsetup.py, line 59, in sebool_config setup_booleans(True) File /usr/lib64/python2.7/site-packages/vdsm/tool/seboolsetup.py, line 41, in setup_booleans sebool_obj = seobject.booleanRecords() File /usr/lib/python2.7/site-packages/seobject/__init__.py, line 2070, in __init__ semanageRecords.__init__(self, store) File /usr/lib/python2.7/site-packages/seobject/__init__.py, line 205, in __init__ self.mylog = logger() File /usr/lib/python2.7/site-packages/seobject/__init__.py, line 90, in __init__ self.audit_fd = audit.audit_open() OSError: [Errno 93] Protocol not supported OSError: Protocol not supported Installing : vdsm-debug-plugin-4.13.0-179.gite51bbc3.fc20.noarch 5/7 Installing : vdsm-reg-4.13.0-179.gite51bbc3.fc20.noarch 6/7 Installing : vdsm-cli-4.13.0-179.gite51bbc3.fc20.noarch 7/7 Verifying : vdsm-debug-plugin-4.13.0-179.gite51bbc3.fc20.noarch 1/7 Verifying : vdsm-reg-4.13.0-179.gite51bbc3.fc20.noarch 2/7 Verifying : vdsm-python-zombiereaper-4.13.0-179.gite51bbc3.fc20.noarch 3/7 Verifying : vdsm-cli-4.13.0-179.gite51bbc3.fc20.noarch 4/7 Verifying : vdsm-4.13.0-179.gite51bbc3.fc20.x86_64 5/7 Verifying : vdsm-xmlrpc-4.13.0-179.gite51bbc3.fc20.noarch 6/7 Verifying : vdsm-python-4.13.0-179.gite51bbc3.fc20.x86_64 Shouldn't the auditing be optional (I have audit=0 in the kernel cmdline). We've discussed this issue today in the vdsm sync meeting. If make this optional, we must check for the flag existence on every startup of vdsm. Presumably, this is not a long ardious task. It would be good to check the flags even if we choose to keep the ugly install-time errors: an admin should be warned that his VMs are not going to start due to future selinux errors, and should be notified with which vdsm-tool action (sebool-config) he should fix the issue. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] addNetwork to use existing nic conf
On Wed, Nov 27, 2013 at 04:38:54AM -0500, Yedidyah Bar David wrote: Hi all, While looking at [1], and reading the source of bridge.py of ovirt-hosted-engine-setup and of ovirt-host-deploy, I think the correct thing will be for addNetwork to not require either bootproto=dhcp or ipaddr/netmask/etc., but to take this from the existing conf of the nics to be put inside the bridge. Does this make sense? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1013666 I do not think it does: addNetwork was designed to set up a network accroding to a complete definition thereof. The current state and the configuration of the underlying devices is intentionally overridden. addNetwork's default for bootproto is not to set it in the ifcfg file (which initscript translates to none, i.e. static). Other users of addNetwork may already rely on that, and forcing them to change is not realistic (particularly given our willingness to deprecate addNetwork/delNetwork/editNetwork in favor of setupNetworks). The suggested logic is particularly fuzzy if we consider the fact that addNetwork may set multiple ifcfg files. Which bootproto should it select as a default if it is building a bond on top of 3 nics? I assume that hosted-engine-setup has an argument for selecting the management interface. I see no way around having it receive --ipaddr/--netmask/--gateway/--bootproto too, or doing the guestwork itself. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] addNetwork to use existing nic conf
On Wed, Nov 27, 2013 at 06:55:26AM -0500, Antoni Segura Puimedon wrote: - Original Message - From: Yedidyah Bar David d...@redhat.com To: Antoni Segura Puimedon asegu...@redhat.com Cc: vdsm-devel vdsm-de...@fedorahosted.org, Alon Bar-Lev alo...@redhat.com, Sandro Bonazzola sbona...@redhat.com Sent: Wednesday, November 27, 2013 11:18:39 AM Subject: Re: addNetwork to use existing nic conf - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: Yedidyah Bar David d...@redhat.com Cc: vdsm-devel vdsm-de...@fedorahosted.org, Alon Bar-Lev alo...@redhat.com, Sandro Bonazzola sbona...@redhat.com Sent: Wednesday, November 27, 2013 11:52:51 AM Subject: Re: addNetwork to use existing nic conf - Original Message - From: Yedidyah Bar David d...@redhat.com To: vdsm-devel vdsm-de...@fedorahosted.org Cc: Alon Bar-Lev alo...@redhat.com, Sandro Bonazzola sbona...@redhat.com, Antoni Segura Puimedon asegu...@redhat.com Sent: Wednesday, November 27, 2013 10:38:54 AM Subject: addNetwork to use existing nic conf Hi all, While looking at [1], and reading the source of bridge.py of ovirt-hosted-engine-setup and of ovirt-host-deploy, I think the correct thing will be for addNetwork to not require either bootproto=dhcp or ipaddr/netmask/etc., but to take this from the existing conf of the nics to be put inside the bridge. You mean the addNetwork in vdsm/vdsm/configNetwork.py? We currently use vdsClient - 'vdsClient addNetwork'. If that is the case I would very much prefer not to make such change, since that would make addNetwork even farther from referential transparency. What I propose is that the calling code will use the new getBootProto introduced in: http://gerrit.ovirt.org/18484 (already merged). Does vdsClient support that? Well, vdsClient getVdsCaps returns the cfg information for all the devices, part of that will be the bootproto if it is defined on the ifcfg file of the device. We'd very much like to drop the 'cfg' element reported per nic (it breaks Vdsm's network abrstraction and would be anoying to maintain with iproute2 when we move to it. BOOTPROTO is there, and would have to stay there (for backward compatibility with Engine), but please avoid using any other data. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] addNetwork to use existing nic conf
On Wed, Nov 27, 2013 at 07:28:23AM -0500, Antoni Segura Puimedon wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Antoni Segura Puimedon asegu...@redhat.com Cc: Yedidyah Bar David d...@redhat.com, vdsm-devel vdsm-de...@fedorahosted.org Sent: Wednesday, November 27, 2013 1:22:47 PM Subject: Re: [vdsm] addNetwork to use existing nic conf On Wed, Nov 27, 2013 at 06:55:26AM -0500, Antoni Segura Puimedon wrote: - Original Message - From: Yedidyah Bar David d...@redhat.com To: Antoni Segura Puimedon asegu...@redhat.com Cc: vdsm-devel vdsm-de...@fedorahosted.org, Alon Bar-Lev alo...@redhat.com, Sandro Bonazzola sbona...@redhat.com Sent: Wednesday, November 27, 2013 11:18:39 AM Subject: Re: addNetwork to use existing nic conf - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: Yedidyah Bar David d...@redhat.com Cc: vdsm-devel vdsm-de...@fedorahosted.org, Alon Bar-Lev alo...@redhat.com, Sandro Bonazzola sbona...@redhat.com Sent: Wednesday, November 27, 2013 11:52:51 AM Subject: Re: addNetwork to use existing nic conf - Original Message - From: Yedidyah Bar David d...@redhat.com To: vdsm-devel vdsm-de...@fedorahosted.org Cc: Alon Bar-Lev alo...@redhat.com, Sandro Bonazzola sbona...@redhat.com, Antoni Segura Puimedon asegu...@redhat.com Sent: Wednesday, November 27, 2013 10:38:54 AM Subject: addNetwork to use existing nic conf Hi all, While looking at [1], and reading the source of bridge.py of ovirt-hosted-engine-setup and of ovirt-host-deploy, I think the correct thing will be for addNetwork to not require either bootproto=dhcp or ipaddr/netmask/etc., but to take this from the existing conf of the nics to be put inside the bridge. You mean the addNetwork in vdsm/vdsm/configNetwork.py? We currently use vdsClient - 'vdsClient addNetwork'. If that is the case I would very much prefer not to make such change, since that would make addNetwork even farther from referential transparency. What I propose is that the calling code will use the new getBootProto introduced in: http://gerrit.ovirt.org/18484 (already merged). Does vdsClient support that? Well, vdsClient getVdsCaps returns the cfg information for all the devices, part of that will be the bootproto if it is defined on the ifcfg file of the device. We'd very much like to drop the 'cfg' element reported per nic (it breaks Vdsm's network abrstraction and would be anoying to maintain with iproute2 when we move to it. BOOTPROTO is there, and would have to stay there (for backward compatibility with Engine), but please avoid using any other data. Well, for installation time, there must be something (not necessarily part of vdsm proper that is able to get the ip configuration of the device we connect through. Since it could be ifcfg info (el6), NM (newer distros), /etc/network/interfaces (debian derived) I would really make a separate solution to vdsm. No doubt about that: Bug 987813 - [RFE] report BOOTPROTO and BONDING_OPTS independent of netdevice.cfg ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Pending Self-Hosted-Engine Patches in ovirt-3.3.2
On Tue, Nov 26, 2013 at 05:18:49AM -0500, Yaniv Bronheim wrote: - Original Message - From: Sandro Bonazzola sbona...@redhat.com To: Dan Kenigsberg dan...@redhat.com, vdsm-de...@fedorahosted.org Cc: hat...@redhat.com Sent: Tuesday, November 26, 2013 8:50:38 AM Subject: Re: [vdsm] Pending Self-Hosted-Engine Patches in ovirt-3.3.2 Il 25/11/2013 22:16, Dan Kenigsberg ha scritto: An important feature of ovirt-3.3 has not made it to the ovirt-3.3.0 deadline: http://www.ovirt.org/Features/Self_Hosted_Engine. It would allow to run Engine as a VM on top one of the hosts controlled by itself, saving resources and allowing high availablity out-of-the-box. The feature was not ready on time for the ovirt-3.3.0 release but now its Engine-side patches are merged, and its Vdsm-side patches are pending aproval for entry into Vdsm's stable branch. http://gerrit.ovirt.org/20189 http://gerrit.ovirt.org/20190 http://gerrit.ovirt.org/20191 http://gerrit.ovirt.org/20192 http://gerrit.ovirt.org/20193 http://gerrit.ovirt.org/20194 http://gerrit.ovirt.org/20209 http://gerrit.ovirt.org/20300 http://gerrit.ovirt.org/21357 I suggest to take the pending patches into the ovirt-3.3 branch, and ship ovirt-3.3.2 with this feature enabled. +1 We shall not release ovirt-3.3.2 before we are assured by quality engineering that we have no regression to main Vdsm code. If we do not receive this green light, and there's urgency to release ovirt-3.3.2, we'd fork and ship 3.3.2 only with the urgent fixes. Any objections? not from my side. waiting for the green light I'm suggesting not to wait with merging. A CR+2 V+1 should be enough for those patches. The release of ovirt-3.3.2 should wait, though. are there more pending urgent fixes that I'm not aware of? You may be aware of http://gerrit.ovirt.org/#/c/21700/ but I'm sure there would be more. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] Pending Self-Hosted-Engine Patches in ovirt-3.3.2
An important feature of ovirt-3.3 has not made it to the ovirt-3.3.0 deadline: http://www.ovirt.org/Features/Self_Hosted_Engine. It would allow to run Engine as a VM on top one of the hosts controlled by itself, saving resources and allowing high availablity out-of-the-box. The feature was not ready on time for the ovirt-3.3.0 release but now its Engine-side patches are merged, and its Vdsm-side patches are pending aproval for entry into Vdsm's stable branch. http://gerrit.ovirt.org/20189 http://gerrit.ovirt.org/20190 http://gerrit.ovirt.org/20191 http://gerrit.ovirt.org/20192 http://gerrit.ovirt.org/20193 http://gerrit.ovirt.org/20194 http://gerrit.ovirt.org/20209 http://gerrit.ovirt.org/20300 http://gerrit.ovirt.org/21357 I suggest to take the pending patches into the ovirt-3.3 branch, and ship ovirt-3.3.2 with this feature enabled. We shall not release ovirt-3.3.2 before we are assured by quality engineering that we have no regression to main Vdsm code. If we do not receive this green light, and there's urgency to release ovirt-3.3.2, we'd fork and ship 3.3.2 only with the urgent fixes. Any objections? Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Engine-devel] oVirt 3.3.2 beta status
On Mon, Nov 18, 2013 at 10:12:02AM +0100, Sandro Bonazzola wrote: Hi, we're going to branch and build oVirt 3.3.2 beta on Nov 27th. A bug tracker is available at [1] and it shows only 2 bugs blocking the release: Bug 1029792 - VDSM does not report the qemu version in capabilities, if qemu-kvm-rhev is used Backported http://gerrit.ovirt.org/21363 http://gerrit.ovirt.org/21364 to ovirt-3.3 branch to address this request. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] vdsm sync meeting minutes - Nov 18
Things we've discussed - pending iscsi dependency (fixed master branch since meeting) http://gerrit.ovirt.org/21385 - We should strive to keep master usable by el6 (and other supported platforms). We forgot to discuss the issue blocking our spec-checking jenkins job: cpopen collision. Yaniv, are there any updates on that? - function storage/virt tests needs a parent and extension. Ayal says that A storage developer was assigned to that task, expect improvement within weeks. - Vdsm is asked to report information about various VM-related long processes: VM migration, live storage migration, live merge. There was a universal agreement that getAllVmStats is a reasonable place to add those. Michal, Saggi, would it be fine? - failing `make distcheck`: Toni to try monkey-patching the constants module when the schema is built. - Nir's mock module needs review, and later - a decision. There was a disagreement regarding its necessity/helpfulness. See ya! ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] Low quality of el6 vdsm rpms
On Tue, Nov 12, 2013 at 11:31:04AM +0100, Sandro Bonazzola wrote: Il 12/11/2013 10:34, Patrick Hurrelmann ha scritto: Hi all, sorry for this rant, but... Thanks for ranting. Community testing and ranting are to be cherished. We must improve in the points you have raised. I now tried several times to test the beta 3.3.1 rpms, but they can't even be installed in the most times. I'm glad to read you're testing 3.3.1. May I ask you to add yourself to http://www.ovirt.org/Testing/Ovirt_3.3.1_testing ? One time it required a future selinux-policy, although the needed selinux fix was delivered in a much lower version. Now the rpms have broken requirements. It requires hostname instead of /bin/hostname. This broken requirement is not included in the vdsm 3.3 branch, so I wonder where it comes from? Anyway. So I proceeded and tried to build vdsm myself once again. Currently the build fails with (but worked fine some days ago): /usr/bin/pep8 --exclude=config.py,constants.py --filename '*.py,*.py.in' \ client lib/cpopen/*.py lib/vdsm/*.py lib/vdsm/*.py.in tests vds_bootstrap vdsm-tool vdsm/*.py vdsm/*.py.in vdsm/netconf vdsm/sos/vdsm.py.in vdsm/storage vdsm/vdsm vdsm_api vdsm_hooks vdsm_reg vdsm/storage/imageRepository/formatConverter.py:280:29: E128 continuation line under-indented for visual indent - How can the quality of the vdsm builds be increased? It is frustrating to spend time on testing and then the hosts cannot even be installed to broken vdsm rpms. I suspect you are not interested in excuses for each of the failures, let us look forwards. My conclusions are: - Do not require non-yet-existing rpms. If we require a feature that is not yet in Fedora/Centos, we must wait. This is already in effect, see for example http://gerrit.ovirt.org/#/c/20248/ and http://gerrit.ovirt.org/19545 - There's a Jenkins job to enforce the former requirement of spec requirement. David, Sandro, any idea why it is not running these days? - Keep the docs updated. Our Jenkins slaves have pep8-1.4.6, so we should update http://www.ovirt.org/Vdsm_Developers#Installing_required_packages accordingly - and more importantly, make that version available. Sandro, who built the python-pep8-1.4.6 that sits on the el6 Jenkins slave? Could you make it publicly available? (I can volunteer http://danken.fedorapeople.org again) - How are the builds prepared? Is there a Jenkins job that prepares stable rpms in addition to the nightly job? Or is this totally handcrafted? - How can it be that the rpm spec differs between the 3.3 branch and released rpms? What is the source/branch for el6 vdsm rpms? Maybe I'm just tracking on the wrong source tree... Based on your reports, you are tracking the correct tree; but please describe which differences do you see (and between what releases exactly). Regards, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] Low quality of el6 vdsm rpms
On Tue, Nov 12, 2013 at 10:31:24AM -0500, Eyal Edri wrote: snip - There's a Jenkins job to enforce the former requirement of spec requirement. David, Sandro, any idea why it is not running these days? it does run, but we can't enable it since it's still failing: http://jenkins.ovirt.org/job/vdsm_3.3_install_rpm_sanity_gerrit/label=fedora19/282/console once that's fixed, the job will be enabled and run per patch. Yaniv, any idea why we still have file /usr/lib64/python2.7/site-packages/cpopen/__init__.py from install of vdsm-python-cpopen-4.12.1-4.fc19.x86_64 conflicts with file from package python-cpopen-1.2.3-2.fc19.x86_64 ? - Keep the docs updated. Our Jenkins slaves have pep8-1.4.6, so we should update http://www.ovirt.org/Vdsm_Developers#Installing_required_packages accordingly - and more importantly, make that version available. Sandro, who built the python-pep8-1.4.6 that sits on the el6 Jenkins slave? Could you make it publicly available? (I can volunteer http://danken.fedorapeople.org again) i tend to agree here with patrick on using non released pep8 packages, that are not available via rpms, but only via python-pip. the jenkins slaves were updated via pyhon-pip and not via yum upgrade. Eyal, I do not understand your opinion here... In any case, I've added http://danken.fedorapeople.org/python-pep8-1.4.5-2.el6.noarch.rpm if anyone find this unsigned unsupported hardly tested package useful. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] Low quality of el6 vdsm rpms
On Tue, Nov 12, 2013 at 04:41:53PM +, Dan Kenigsberg wrote: On Tue, Nov 12, 2013 at 10:31:24AM -0500, Eyal Edri wrote: snip - Keep the docs updated. Our Jenkins slaves have pep8-1.4.6, so we should update http://www.ovirt.org/Vdsm_Developers#Installing_required_packages accordingly - and more importantly, make that version available. Sandro, who built the python-pep8-1.4.6 that sits on the el6 Jenkins slave? Could you make it publicly available? (I can volunteer http://danken.fedorapeople.org again) i tend to agree here with patrick on using non released pep8 packages, that are not available via rpms, but only via python-pip. the jenkins slaves were updated via pyhon-pip and not via yum upgrade. Eyal, I do not understand your opinion here... In any case, I've added http://danken.fedorapeople.org/python-pep8-1.4.5-2.el6.noarch.rpm if anyone find this unsigned unsupported hardly tested package useful. A concerned user just asked me how did I build this. I just took the source from koji, http://kojipkgs.fedoraproject.org//packages/python-pep8/1.4.5/2.fc20/src/python-pep8-1.4.5-2.fc20.src.rpm and built it on an el6 host with http://kojipkgs.fedoraproject.org//packages/python-sphinx/1.0.8/1.el6/noarch/python-sphinx-1.0.8-1.el6.noarch.rpm installed. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] Low quality of el6 vdsm rpms
On Tue, Nov 12, 2013 at 03:51:36PM -0500, Douglas Schilling Landgraf wrote: Indeed, that's bad. It has been included from a patch only on Fedora koji build rawhide. The others points here already have been answered by others developers. Anyway, we have updated the build. We would appreciate if you could continue the tests with the new test build: F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172359 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172521 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6172612 This last update includes the following patches: - The require hostname fix (http://gerrit.ovirt.org/#/c/21194/ should have been sent to gerrit long ago, I suppose) ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Engine-devel] daily oVirt 3.3.1 blocker status
On Mon, Nov 11, 2013 at 10:26:19AM +0100, Sandro Bonazzola wrote: Il 08/11/2013 01:28, Dan Kenigsberg ha scritto: On Wed, Nov 06, 2013 at 02:36:08AM -0500, Eduardo Warszawski wrote: Hi, only one bloker remains to be fixed: Bug 1022961 - Running a VM from a gluster domain uses mount instead of gluster URI I don't see any activity about it. Can anybody join Eduardo for fixing it ASAP? I'm working on it. Hope soon we will have a fix. Don't panic! :) It's not the /real thing/ that Eduardo wanted, but it's something and it's working. Please review and verify http://gerrit.ovirt.org/#/c/21059/ gluster prepareImage: return gluster-sepecific information Hi, Bug 1022961 - Running a VM from a gluster domain uses mount instead of gluster URI is the only bug blocking 3.3.1 and is on POST. the related patch http://gerrit.ovirt.org/21059 is marked as verified and has two +1. Can you merge the patch and build VDSM for having it under testing so we can try to release 3.3.1 this week? I'd love to merge this in, but given this being my own code, I prefer another core developer ack it, even though no one really likes it. Eduardo dislikes the fact that this patch maintains the awkward API of prepareImage returning this 'info' dictionary on top of the simple 'path' it used to return before the glusterSD effort. Federico dislikes the fact that this patch adds gluster-specific code into our top-level class HSM. To relieve this, I am now suggesting three other cleanup patches http://gerrit.ovirt.org/21122 http://gerrit.ovirt.org/21123 http://gerrit.ovirt.org/21124 but I would like to take the simple fix first. Unbreaking a major feature in master and ovirt-3.3.1 should have precedence over architectural debates. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Host local_host running without virtualization hardware acceleration
On Tue, Nov 05, 2013 at 09:08:33AM +0100, Sandro Bonazzola wrote: Hi, I had to reinstall ovirt yesterday and now it seems that it doesn't work anymore. I'm running nightly on Fedora 18. kernel-3.11.4-101.fc18.x86_64 sanlock-2.8-1.fc18.x86_64 libvirt-1.1.4-1.fc18.x86_64 qemu-1.5.1-1.fc18.x86_64 vdsm-4.13.0-93.gitea8c8f0.fc18.x86_64 ovirt-engine-3.4.0-0.2.master.20131104192919.git3b65870.fc18.noarch engine-setup with all-in-one detects hardware virtualization and allow me to configure the system. (it fails detecting engine health status due probably to recent changes in its URL, I'm already looking into it) Once added localhost to the engine, it has been moved to non operational mode saying I don't have virtualization hardware acceleration anymore. I've found that: # modinfo kvm filename: /lib/modules/3.11.4-101.fc18.x86_64/kernel/arch/x86/kvm/kvm.ko license:GPL author: Qumranet depends: intree: Y vermagic: 3.11.4-101.fc18.x86_64 SMP mod_unload parm: min_timer_period_us:uint parm: ignore_msrs:bool parm: tsc_tolerance_ppm:uint parm: allow_unsafe_assigned_interrupts:Enable device assignment on platforms without interrupt remapping support. (bool) # /usr/bin/qemu-kvm Could not access KVM kernel module: No such file or directory failed to initialize KVM: No such file or directory looking at strace: open(/dev/kvm, O_RDWR|O_CLOEXEC) = -1 ENOENT (No such file or directory) Any clue on what may be happened? What's your `lsmod | grep kvm` ? If empty, does `modprobe kvm_intel` trigger tail-telling lines on /var/log/message? Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Engine-devel] daily oVirt 3.3.1 blocker status
On Mon, Nov 04, 2013 at 09:05:19AM +0100, Sandro Bonazzola wrote: Il 31/10/2013 08:49, Sandro Bonazzola ha scritto: Hi, The following blockers are still not fixed: VDSM: Bug 1022961 - Running a VM from a gluster domain uses mount instead of gluster URI Bug 1022975 - [vdsm] storage domain upgrade fails with attributeError Federico, Eduardo, can you provide an ETA for those? Still not fixed with no ETA. WWIW, Bug 1022975 is solved by http://gerrit.ovirt.org/20721; waiting only for a formal verification. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Problem building master on rhel-6.4 according ovirt.org
On Thu, Oct 31, 2013 at 07:07:08AM -0400, Mooli Tayer wrote: While building master on a rhel-6.4 according to instructions at ovirt.org [1] I encountered several issues: 1.)This line: yum install --enablerepo=ovirt-beta x86_64/* noarch/vdsm-xml* noarch/vdsm-cli Is missing: noarch/vdsm-python-zombiereaper* Is that correct? I'll fix it if so 2.) we need the gluster 3.4.1 repos which we get, but we also get 3.4.0 (from resources.ovirt.org) so after following instructions we end up with glusterfs-epel.repo.1 with 3.4.1 and glusterfs-epel.repo with 3.4.0 Is this a problem? are newer versions considered? Thanks for fixing the wiki for 1 and 2. 3.) selinux-policy-targeted = 3.7.19-195.el6.13 is missing (known issue I believe) It also can be found on-line, can we still build somehow? This package has been released by Red Hat recently, coming Centos way anytime soon. You can take my http://gerrit.ovirt.org/#/c/20313/ hack if you do not want to use --force when installing vdsm. 4.) this issue, which I don't get: Error: Package: libvirt-lock-sanlock-0.10.2-18.el6.x86_64 (RHEL-6.4-optional) Requires: libvirt = 0.10.2-18.el6 Available: libvirt-0.10.2-18.el6.x86_64 (RHEL-6.4) libvirt = 0.10.2-18.el6 Installing: libvirt-0.10.2-18.el6_4.14.x86_64 (RHEL-6-updates) libvirt = 0.10.2-18.el6_4.14 Red Hat ships libvirt-lock-sanlock in the EL optional channel, not in the basic platform one. You have an old libvirt-lock-sanlock installed on your host (from optional), and a newer libvirt is available on your platform channel. However, their versions must match. So you can either wait for a newer libvirt-lock-sanlock, or ignore the error and keep the older libvirt. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm Requires: selinux-policy-targeted = 3.7.19-213
On Mon, Oct 28, 2013 at 10:36:17AM +0100, Fabian Deutsch wrote: Am Montag, den 28.10.2013, 01:23 + schrieb Dan Kenigsberg: On Sun, Oct 27, 2013 at 02:45:43PM +0100, Fabian Deutsch wrote: Hey, when I try to install vdsm, I get: Would you be so kind to verify my fix for this http://gerrit.ovirt.org/#/c/20313/ on ovirt node? Dan, I've done a draft build and your basically works (the policy wihtin the image is modified), only restorceon needs to be run on /var/run/vdsm . Oh, right. Thanks. Could you have another look? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm sync meeting - October 21th 2013
On Mon, Oct 21, 2013 at 11:48:45AM -0400, Yaniv Bronheim wrote: Vdsm Sync Meeting - October 21th 2013 * Functional unit tests fail due to an old python-noise version on EL6: * Tony submitted clean up script before tests as workaround. * Old noise version is missing noise_xml, which is still a mystery how it worked before. Seems that old python-noise ignores xunit file and does not produce it at all (correct me if I missed or wrong on the details here) * Kiril should update python-noise on slaves. Thanks Kiril and infra in general. The issue was that EPEL6's python-nose does not support xml output, hence a newer version was installed via pip on top of the rpm. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Recent changes in vdsmd startup
On Sat, Oct 12, 2013 at 05:26:53PM -0400, Yaniv Bronheim wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Antoni Segura Puimedon asegu...@redhat.com Cc: arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 11:51:30 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On Thu, Oct 10, 2013 at 04:40:36PM -0400, Antoni Segura Puimedon wrote: Is this what happened with the network functional testing? After these last changes, before the yum install of the new vdsm and the yum erase of the old I had to add the vdsm-tool libvirt reconfigure and start. Otherwise vdsm would not be able to reply to VdsGetCaps (on f19, on el6 somehow it didn't happen). IMO what you've experienced is the intended change that Yaniv has reported in this thread. Fresh installation of vdsm now requires more-than-just `service vdsmd start`. I'm trying to understand our action on the unattended upgrade path. Interesting point. Thanks for raising that up, raising such issues was part of this mail goals You are right that after an upgrade we will need to restart libvirt service manually to start working with new configuration, But, AFAIK we don't force vdsmd restart after upgrading. Actually, we have to restart (you cannot expect the old process to keep on running porperly after its data/code files have changed underneath) and we do, by virtue of /sbin/service vdsmd condrestart in the %post script. If the user updated the package and still wants the new configuration, manual vdsmd restart will be required anyway. So the print to restart also related service is just enough. I'm afraid we're ain't so lucky... Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] Resizing disks destroys contents
On Sat, Oct 12, 2013 at 11:07:07PM +0330, Mohsen Saeedi wrote: We should update both of vdsm and ovirt-engine or vdsm is enough? I check ovirt el repo and it does not have new version for vdsm. On 10/12/2013 02:11 AM, Dan Kenigsberg wrote: Only a vdsm update is required for resolving this issue. Apparently, vdsm-4.12.1-4 is still in testing stage http://resources.ovirt.org/releases/updates-testing/rpm/EL/6/x86_64/ Please try it out! On Sat, Oct 12, 2013 at 12:27:02AM +0330, Mohsen Saeedi wrote: I have same problem too.  I have one node as ovirt engine and as hypervisor too. I successfully upgrade our engine from 3.1 to 3.2 and then from 3.2 to 3.3 and everything is ok. then i upgrade our cluster version to 3.3 and then our datacenter to 3.3. I increase 1GB on virtual machine with 20GB thin disk and I receive success message on event and our disk increase to 21GB but after host reboot, i saw message that contains no bootable disk is available!!!  then i try to install new os on that disk (Centos 6.4 minimal) and anaconda show the error on screen : No usable disks have found. I think disk corrupt after resizing. it was test VM but it's very if occur for real and functional VMs. Yes, this is indeed a bad bad bug. It was inadvertantly fixed on the master branch a while ago. Yesterday, we've backported the fix to 3.3.0.1 http://lists.ovirt.org/pipermail/users/2013-October/017018.html Please avoid trying ovirt-3.3.0's new disk resize feature on file-based storage, unless you upgrade to vdsm vdsm-4.12.1-4 first. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] Resizing disks destroys contents
On Sat, Oct 12, 2013 at 12:27:02AM +0330, Mohsen Saeedi wrote: I have same problem too.  I have one node as ovirt engine and as hypervisor too. I successfully upgrade our engine from 3.1 to 3.2 and then from 3.2 to 3.3 and everything is ok. then i upgrade our cluster version to 3.3 and then our datacenter to 3.3. I increase 1GB on virtual machine with 20GB thin disk and I receive success message on event and our disk increase to 21GB but after host reboot, i saw message that contains no bootable disk is available!!!  then i try to install new os on that disk (Centos 6.4 minimal) and anaconda show the error on screen : No usable disks have found. I think disk corrupt after resizing. it was test VM but it's very if occur for real and functional VMs. Yes, this is indeed a bad bad bug. It was inadvertantly fixed on the master branch a while ago. Yesterday, we've backported the fix to 3.3.0.1 http://lists.ovirt.org/pipermail/users/2013-October/017018.html Please avoid trying ovirt-3.3.0's new disk resize feature on file-based storage, unless you upgrade to vdsm vdsm-4.12.1-4 first. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm rpm sanity test is failing
On Thu, Oct 10, 2013 at 08:48:00AM -0400, Eyal Edri wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Aravinda avish...@redhat.com Cc: vdsm-devel@lists.fedorahosted.org, ee...@redhat.com, ybron...@redhat.com Sent: Thursday, October 10, 2013 3:43:29 PM Subject: Re: [vdsm] vdsm rpm sanity test is failing On Thu, Oct 10, 2013 at 11:39:51AM +0530, Aravinda wrote: Hi, I sent a patch to vdsm in gerrit, but rpm sanity test is failing. Please suggest how to fix this. patch: http://gerrit.ovirt.org/#/c/17822/6 sanity test: http://jenkins.ovirt.org/job/vdsm_install_rpm_sanity_gerrit/148/ Can we install glusterfs-3.4.1-2.el6 from https://koji.fedoraproject.org/koji/buildinfo?buildID=468826 on our el6 slave? i rather have a stable repo to use constantly and not specific pkg in koji. I think that we should take the glusterfs straight from Fedora EPEL6, as I would like to avoid shipping our own glusterfs in the ovirt repo. My request for a manaual fix is only to unbreak current situation. It is important to do that in order to ubreak the new rpm sanity test, which is going to save us this trouble in the future. Regards, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Recent changes in vdsmd startup
On Thu, Oct 10, 2013 at 01:51:00PM -0400, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Yaniv Bronheim ybron...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 8:33:39 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On 10/10/2013 07:47 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Yaniv Bronheim ybron...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 7:45:36 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On 10/10/2013 07:43 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Yaniv Bronheim ybron...@redhat.com, arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 7:39:35 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On 10/10/2013 07:38 PM, Alon Bar-Lev wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: arch a...@ovirt.org, VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Thursday, October 10, 2013 7:37:14 PM Subject: Re: [vdsm] Recent changes in vdsmd startup On 10/10/2013 05:38 PM, Yaniv Bronheim wrote: - Original Message - From: Itamar Heim ih...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org, arch a...@ovirt.org Sent: Thursday, October 10, 2013 5:24:40 PM Subject: Re: Recent changes in vdsmd startup On 10/10/2013 04:32 PM, Yaniv Bronheim wrote: Hey Everybody, FYI, Recently we merged a fix that changes the way vdsmd starts. Before that service vdsmd start command performed its main logic in addition to related services manipulation, as configure libvirt service and restart it for example. Now we are trying to avoid that and only alert the user if restart or other operations on related services are required. So now when you perform vdsmd start after clear installation you will see: ~$ sudo service vdsmd restart Shutting down vdsm daemon: vdsm watchdog stop [ OK ] vdsm: not running [FAILED] vdsm: Running run_final_hooks vdsm stop [ OK ] supervdsm start[ OK ] vdsm: Running run_init_hooks vdsm: Running gencerts hostname: Unknown host vdsm: Running check_libvirt_configure libvirt is not configured for vdsm yet Perform 'vdsm-tool libvirt-configure' before starting vdsmd vdsm: failed to execute check_libvirt_configure, error code 1 vdsm start [FAILED] This asks you to run vdsm-tool libvirt-configure After running it you should see: ~$ sudo vdsm-tool libvirt-configure Stopping libvirtd daemon: [ OK ] libvirt is not configured for vdsm yet Reconfiguration of libvirt is done. To start working with the new configuration, execute: 'vdsm-tool libvirt-configure-services-restart' This will manage restarting of the following services: libvirtd, supervdsmd After performing: 'vdsm-tool libvirt-configure-services-restart' you are ready to start vdsmd again as usual. All those vdsm-tool commands require root privileges, otherwise it'll alert and stop the operation. Over systemd the errors\output can be watched in /var/log/messages Thanks, Yaniv Bronhaim. ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch how will this affect the following use cases: 1. i added a new host to the system via the engine. at the end of the installation i expect the host to work without admin having to do any operation on the host. 2. i update a host to latest vdsm version via the engine. at the end of the update i expect the host to be updated without admin having to do any operation on the host I think we've quite neglected a third case, of unattended `yum upgrade -y`. If and when we need to update BY_VDSM_VERS, this would result in a failure to restart vdsm. How should we handle that? I do not see a way other than adding libvirt-configure and libvirt condrestart to vdsm %postin. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org
Re: [vdsm] vdsm-4.12.1-4
On Thu, Oct 10, 2013 at 10:13:33AM -0400, Mike Burns wrote: On 10/10/2013 10:12 AM, Mike Burns wrote: On 10/10/2013 10:20 AM, Douglas Schilling Landgraf wrote: Changes: = - remoteFileHandler: Add create exclusive option for truncateFile (BZ#979193) - oop: improve safety for truncateFile F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6046682 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6046573 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6046734 Done Done as in they're uploaded to updates-testing on ovirt.org Thanks! As Federico reported earlier, they are quite important. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Recent changes in vdsmd startup
On Thu, Oct 10, 2013 at 04:40:36PM -0400, Antoni Segura Puimedon wrote: Is this what happened with the network functional testing? After these last changes, before the yum install of the new vdsm and the yum erase of the old I had to add the vdsm-tool libvirt reconfigure and start. Otherwise vdsm would not be able to reply to VdsGetCaps (on f19, on el6 somehow it didn't happen). IMO what you've experienced is the intended change that Yaniv has reported in this thread. Fresh installation of vdsm now requires more-than-just `service vdsmd start`. I'm trying to understand our action on the unattended upgrade path. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm sync meeting - October 7th 2013
On Wed, Oct 09, 2013 at 08:27:58AM -0400, Mike Burns wrote: On 10/08/2013 04:52 PM, Douglas Schilling Landgraf wrote: On 10/08/2013 05:08 AM, Dan Kenigsberg wrote: On Mon, Oct 07, 2013 at 03:25:22PM +0100, Dan Kenigsberg wrote: We had an unpleasant talk, hampered by statics and disconnection on danken's side. Beyond the noises I've managed to recognize Yaniv, Toni, Douglas, Danken, Ayal, Timothy, Yeela and Mooli. We've managed to discuss: I've forgot to mention the resolution of Bug 1007980 - Failed to run VM with gluster drives: internal error unexpected address type for ide disk by http://gerrit.ovirt.org/19949 . Due to its being a serious painpoint to users. I've backport this fix to both ovirt-3.3 and ovirt-3.3.0 branches. Douglas, would you issue a Fedora build from the ovirt-3.3.0 branch? I think this deserves an async build and an update of the ovirt-3.3 reporsitory. Sure. F19: http://koji.fedoraproject.org/koji/taskinfo?taskID=6037496 F20: http://koji.fedoraproject.org/koji/taskinfo?taskID=6037437 EL6: http://koji.fedoraproject.org/koji/taskinfo?taskID=6037527 Changes included into vdsm 4.12.1-3: - vm.Vm._getUnderlyingDriveInfo: extract path of gluster disks (BZ#1007980) - Require libvirt that allows vmUpdateDevice (BZ#1001001) - imageSharing: return proper size in httpGetSize - vdsmd.init: Add service-is-managed in shutdown_conflicting_srv (BZ#1006842) Adding in CC mburns for ovirt.org stuff. Builds posted to ovirt.org updates-testing repo. They'll be pushed live with 3.3.0.1 release Thanks! ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm sync meeting - October 7th 2013
On Mon, Oct 07, 2013 at 03:25:22PM +0100, Dan Kenigsberg wrote: We had an unpleasant talk, hampered by statics and disconnection on danken's side. Beyond the noises I've managed to recognize Yaniv, Toni, Douglas, Danken, Ayal, Timothy, Yeela and Mooli. We've managed to discuss: I've forgot to mention the resolution of Bug 1007980 - Failed to run VM with gluster drives: internal error unexpected address type for ide disk by http://gerrit.ovirt.org/19949 . Due to its being a serious painpoint to users. I've backport this fix to both ovirt-3.3 and ovirt-3.3.0 branches. Douglas, would you issue a Fedora build from the ovirt-3.3.0 branch? I think this deserves an async build and an update of the ovirt-3.3 reporsitory. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] vdsm sync meeting - October 7th 2013
We had an unpleasant talk, hampered by statics and disconnection on danken's side. Beyond the noises I've managed to recognize Yaniv, Toni, Douglas, Danken, Ayal, Timothy, Yeela and Mooli. We've managed to discuss: - vdsm-4.13.0 is tagged, with a know selinux issue on el6. Expect a new seliux-policy solving it any time soon. - All bugfixes should be backported to ovirt-3.3, so that we have a stable and comfortable vdsm in ovirt-3.3.1. Risky changes and new features should remain in master IMO. - We incorporated a glusterfs requirement breaking rpm installaiton for people. We should avoid that by posters notifying reviewers more prominently and by having http://jenkins.ovirt.org/job/vdsm_install_rpm_sanity_gerrit/ run on every patch that touches vdsm.spec.in. David, could you make the adjustment to the job? - We discussed feature negotiation: Toni and Dan liked the idea of having vdsm expose a feature flags, to make it easier on Engine to check if a certain feature is supported. Ayal argues that this is useful only for capabilities that depend on existence on lower level components. Sees little value in fine feature granularity on vdsm side - versions is enough. So the disputed question is only how many feature flags we should have, and when to set them: statically or based on negotiation with kernel/libvirt/gluster/what not. - Unified network persistence patches are being merged into master - Timothy is working on fixing http://jenkins.ovirt.org/job/vdsm_verify_error_codes/lastBuild/console (hopefully by introducing the new error codes to Engine) I was dropped from the call, so please append with stuff that I've missed. Sorry for the noise! Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] vdsm sync meeting - September 23th 2013
On Tue, Sep 24, 2013 at 10:23:21AM +0100, Dan Kenigsberg wrote: On Mon, Sep 23, 2013 at 04:34:29PM -0400, Douglas Schilling Landgraf wrote: - Heads up about 3.3.1/stable branch http://lists.ovirt.org/pipermail/engine-devel/2013-September/005601.html Our intention is to rename the current ovirt-3.3 branch to ovirt-3.3.0, and create a new ovirt-3.3 branch for following ovirt-3.3.z releases, based on current master. Please help in testing the tip of master branch for bugs and other surprises! After fighting several more surprises, v4.13.0 has been tagged. Note that the ovirt-3.3 branch has been rebased as stated above. We have a pending SELinux issue on el6: v4.13.0 requires a yet-unpublished selinux-policy-targeted package that would allow it to use /var/run/vdsm/storage for its storage repository. Until it is published, you would need to something like sudo semanage fcontext -a -s system_u -t virt_var_run_t -r s0 '/var/run/vdsm(/.*)?' and --force install your vdsm.rpm. Regards, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] supervdsmServer: Enable logging from multiprocessing library
On Wed, Oct 02, 2013 at 03:59:58PM +1000, David Gibson wrote: On Tue, 01 Oct 2013 20:25:21 +0100 Lee Yarwood lyarw...@redhat.com wrote: On 10/01/2013 06:35 PM, Dan Kenigsberg wrote: On Tue, Oct 01, 2013 at 02:33:00PM +0100, Lee Yarwood wrote: On 10/01/2013 09:00 AM, Dan Kenigsberg wrote: It is prefered to post patches to gerrit.ovirt.org. Apologies for jumping in David but I've pushed this here for now : http://gerrit.ovirt.org/19741 Thanks! Thanks, I'm new to ovirt development and gerrit, so I'm going to need to work that out. On Tue, Oct 01, 2013 at 01:18:25PM +1000, David Gibson wrote: At present, if the super vdsm server dies with an exception inside Python's multiprocessing module, then it will not usually produce any useful debugging output. For our context - when do you notice such supervdsm deaths? Is it frequent? What is the cause? BZ#1011661 BZ#1010030 downstream. Ok, I can see them, dig into them and find an answer to my question. But it's not fair to the wider community of users and partner to cite private bugs. https://www.berrange.com/posts/2012/06/27/thoughts-on-improving-openstack-git-commit-practicehistory/ Apologies Dan, I believe David was referring to the public BZ#1011661. I believe that has been attributed to the following change merged upstream in May : http://gerrit.ovirt.org/#/c/14998 Uh, the problem's not attributed to that, rather that patch fixes it. The problem was that the process ctimes were changing, leading vdsm to erroneously think that supervdsm had died and restarting it. That lead to several complications, including the supervdsm servers failing silently due to lack of logging from multiprocessing. As much as I hate restarting supervdsmd service, I'm so glad that these issues are solved in ovirt-3.3. We don't yet know why the ctimes were changing in this particular customer environment. a longshot: maybe a system date change managed to confuse vdsm? Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] supervdsmServer: Enable logging from multiprocessing library
It is prefered to post patches to gerrit.ovirt.org. On Tue, Oct 01, 2013 at 01:18:25PM +1000, David Gibson wrote: At present, if the super vdsm server dies with an exception inside Python's multiprocessing module, then it will not usually produce any useful debugging output. For our context - when do you notice such supervdsm deaths? Is it frequent? What is the cause? The multiprocessing module includes error logging using Python's logging module, but it is not enabled by default. This patch enables the logging and sets it to propagate to the supervdsmServer's root logger, so it now defaults to producing logging and can be configured easily from /etc/vdsm/svdsm.logger.conf. Signed-off-by: David Gibson da...@gibson.dropbear.id.au --- vdsm/supervdsmServer | 4 1 file changed, 4 insertions(+) diff --git a/vdsm/supervdsmServer b/vdsm/supervdsmServer index 40ec9df..43a408f 100755 --- a/vdsm/supervdsmServer +++ b/vdsm/supervdsmServer @@ -42,6 +42,7 @@ except: log.warn(Could not init proper logging, exc_info=True) from storage import fuser +import multiprocessing from multiprocessing import Pipe, Process from gluster import listPublicFunctions import storage.misc as misc @@ -356,6 +357,9 @@ class _SuperVdsm(object): def main(sockfile, pidfile=None): log = logging.getLogger(SuperVdsm.Server) +# Wire up the multiprocessing logger +mlog = multiprocessing.get_logger() +mlog.propagate = 1 The code seems fine, though I'd avoid the variable multiprocessing.get_logger().propagate = 1 Thanks. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] supervdsmServer: Enable logging from multiprocessing library
On Tue, Oct 01, 2013 at 02:33:00PM +0100, Lee Yarwood wrote: On 10/01/2013 09:00 AM, Dan Kenigsberg wrote: It is prefered to post patches to gerrit.ovirt.org. Apologies for jumping in David but I've pushed this here for now : http://gerrit.ovirt.org/19741 Thanks! On Tue, Oct 01, 2013 at 01:18:25PM +1000, David Gibson wrote: At present, if the super vdsm server dies with an exception inside Python's multiprocessing module, then it will not usually produce any useful debugging output. For our context - when do you notice such supervdsm deaths? Is it frequent? What is the cause? BZ#1011661 BZ#1010030 downstream. Ok, I can see them, dig into them and find an answer to my question. But it's not fair to the wider community of users and partner to cite private bugs. https://www.berrange.com/posts/2012/06/27/thoughts-on-improving-openstack-git-commit-practicehistory/ ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [ATN] vdsm yum install is missing pkg for centos f18
On Mon, Sep 30, 2013 at 04:11:56AM -0400, Eyal Edri wrote: fyi, as part of adding more verification jobs on vdsm, infra recently added a new job [1] that installs vdsm. currently that job is working only on f19 and fails on f18 and centos64[2]: Are there any plans to fix this soon? how users are supposed to install vdsm if those pkg are missing? Eyal. [1]http://jenkins.ovirt.org/job/vdsm_install_rpm_sanity_gerrit/label=fedora18/117/console [2] centos: Error: Package: vdsm-4.12.0-149.git44993c6.el6.x86_64 (/vdsm-4.12.0-149.git44993c6.el6.x86_64) Requires: selinux-policy-targeted = 3.7.19-213 Installed: selinux-policy-targeted-3.7.19-195.el6_4.12.noarch (@updates) Thanks for reporting this issue. We must revert this part of http://gerrit.ovirt.org/4220 (One shot prepare) The selinux requirement came since that patch moves the storage reprository to a new location (/var/run/vdsm/storage) instead of the trademark-offensive non-standard /rhev/data-center. EL6.4 would not be able to use the new location with selinux enabled. We have a much bigger issue with this change, as it breaks migration to and from ovirt-3.3; solving this is in the works. f18: -- Running transaction check --- Package dracut.x86_64 0:024-18.git20130102.fc18 will be updated --- Package dracut.x86_64 0:024-25.git20130205.fc18 will be an update --- Package vdsm.x86_64 0:4.12.0-149.git44993c6.fc18 will be installed -- Processing Dependency: libvirt-daemon = 1.0.2-1 for package: vdsm-4.12.0-149.git44993c6.fc18.x86_64 -- Finished Dependency Resolution Error: Package: vdsm-4.12.0-149.git44993c6.fc18.x86_64 (/vdsm-4.12.0-149.git44993c6.fc18.x86_64) Requires: libvirt-daemon = 1.0.2-1 Installed: libvirt-daemon-0.10.2.7-1.fc18.x86_64 (@updates) libvirt-daemon = 0.10.2.7-1.fc18 Available: libvirt-daemon-0.10.2.2-3.fc18.x86_64 (fedora) libvirt-daemon = 0.10.2.2-3.fc18 This is a known and unavoidable issue (since http://gerrit.ovirt.org/11709 of Mar 28 2013). oVirt users on F18 would have to obtain libvirt from virt-preview or compile it themselves. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [ATN] vdsm yum install is missing pkg for centos f18
On Mon, Sep 30, 2013 at 01:01:43PM -0400, Mike Burns wrote: On 09/30/2013 11:53 AM, Dan Kenigsberg wrote: On Mon, Sep 30, 2013 at 04:11:56AM -0400, Eyal Edri wrote: fyi, as part of adding more verification jobs on vdsm, infra recently added a new job [1] that installs vdsm. currently that job is working only on f19 and fails on f18 and centos64[2]: Are there any plans to fix this soon? how users are supposed to install vdsm if those pkg are missing? Eyal. [1]http://jenkins.ovirt.org/job/vdsm_install_rpm_sanity_gerrit/label=fedora18/117/console [2] centos: Error: Package: vdsm-4.12.0-149.git44993c6.el6.x86_64 (/vdsm-4.12.0-149.git44993c6.el6.x86_64) Requires: selinux-policy-targeted = 3.7.19-213 Installed: selinux-policy-targeted-3.7.19-195.el6_4.12.noarch (@updates) Thanks for reporting this issue. We must revert this part of http://gerrit.ovirt.org/4220 (One shot prepare) The selinux requirement came since that patch moves the storage reprository to a new location (/var/run/vdsm/storage) instead of the trademark-offensive non-standard /rhev/data-center. EL6.4 would not be able to use the new location with selinux enabled. We have a much bigger issue with this change, as it breaks migration to and from ovirt-3.3; solving this is in the works. f18: -- Running transaction check --- Package dracut.x86_64 0:024-18.git20130102.fc18 will be updated --- Package dracut.x86_64 0:024-25.git20130205.fc18 will be an update --- Package vdsm.x86_64 0:4.12.0-149.git44993c6.fc18 will be installed -- Processing Dependency: libvirt-daemon = 1.0.2-1 for package: vdsm-4.12.0-149.git44993c6.fc18.x86_64 -- Finished Dependency Resolution Error: Package: vdsm-4.12.0-149.git44993c6.fc18.x86_64 (/vdsm-4.12.0-149.git44993c6.fc18.x86_64) Requires: libvirt-daemon = 1.0.2-1 Installed: libvirt-daemon-0.10.2.7-1.fc18.x86_64 (@updates) libvirt-daemon = 0.10.2.7-1.fc18 Available: libvirt-daemon-0.10.2.2-3.fc18.x86_64 (fedora) libvirt-daemon = 0.10.2.2-3.fc18 This is a known and unavoidable issue (since http://gerrit.ovirt.org/11709 of Mar 28 2013). oVirt users on F18 would have to obtain libvirt from virt-preview or compile it themselves. We should simply disable the job on Fedora 18. Or install Fedora 20 alpha on the slave! ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] vdsm live migration errors in latest master
On Thu, Sep 26, 2013 at 12:14:06PM -0400, Federico Simoncelli wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: Dead Horse deadhorseconsult...@gmail.com, users us...@ovirt.org, vdsm-de...@fedorahosted.org, aba...@redhat.com Sent: Thursday, September 26, 2013 2:09:15 PM Subject: Re: [Users] vdsm live migration errors in latest master On Thu, Sep 26, 2013 at 05:35:46AM -0400, Federico Simoncelli wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: Dead Horse deadhorseconsult...@gmail.com, users us...@ovirt.org, vdsm-de...@fedorahosted.org, aba...@redhat.com Sent: Thursday, September 26, 2013 1:38:15 AM Subject: Re: [Users] vdsm live migration errors in latest master On Tue, Sep 24, 2013 at 12:04:14PM -0400, Federico Simoncelli wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Dead Horse deadhorseconsult...@gmail.com Cc: us...@ovirt.org us...@ovirt.org, vdsm-de...@fedorahosted.org, fsimo...@redhat.com, aba...@redhat.com Sent: Tuesday, September 24, 2013 11:44:48 AM Subject: Re: [Users] vdsm live migration errors in latest master On Mon, Sep 23, 2013 at 04:05:34PM -0500, Dead Horse wrote: Seeing failed live migrations and these errors in the vdsm logs with latest VDSM/Engine master. Hosts are EL6.4 Thanks for posting this report. The log is from the source of migration, right? Could you trace the history of the hosts of this VM? Could it be that it was started on an older version of vdsm (say ovirt-3.3.0) and then (due to migration or vdsm upgrade) got into a host with a much newer vdsm? Would you share the vmCreate (or vmMigrationCreate) line for this Vm in your log? I smells like an unintended regression of http://gerrit.ovirt.org/17714 vm: extend shared property to support locking solving it may not be trivial, as we should not call _normalizeDriveSharedAttribute() automatically on migration destination, as it may well still be apart of a 3.3 clusterLevel. Also, migration from vdsm with extended shared property, to an ovirt 3.3 vdsm is going to explode (in a different way), since the destination does not expect the extended values. Federico, do we have a choice but to revert that patch, and use something like shared3 property instead? I filed a bug at: https://bugzilla.redhat.com/show_bug.cgi?id=1011608 A possible fix could be: http://gerrit.ovirt.org/#/c/19509 Beyond this, we must make sure that on Engine side, the extended shared values would be used only for clusterLevel 3.4 and above. Are the extended shared values already used by Engine? Yes. That's the idea. Actually to be fair, the second case you mentioned (migrating from extended shared property to old vdsm) it wouldn't have been possible I suppose (the issue here is that Dead Horse has one or more hosts running on master instead of 3.3). The extended shared property would have appeared only in 3.4 and to allow the migration you would have had to upgrade all the nodes. But anyway since we were also talking about a new 3.3.1 barnch I just went ahead and covered all cases. I do not see how the 3.3.1 branch is relevant to the discussion, as its Vdsm is NOT going to support clusterLevel 3.4. That is what I was referring to. If 3.3.1 was 3.3.0 + backported patches then we just wouldn't backport the extended shared attributes patch and that's it. But from what I understood 3.3.1 will be rebased on master (where instead we have the extended shared attributes) and that is why we have to cover both migration direction cases (instead of just the simple getattr one). Pardon my slowliness, but would you confirm that this feature is to be used only on clusterLevel 3.4 and above? If so, I'm +2ing your patch. Yes, the extended attributes will be used in the hosted engine and cluster level 3.4. But what the engine does is not relevant to +2ing correct vdsm patches. IMHO the patch is correct only if all clients understned that this is a clusterLevel 3.4 feature. Now that that's clear to me. Ack by me. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] vdsm live migration errors in latest master
On Thu, Sep 26, 2013 at 05:35:46AM -0400, Federico Simoncelli wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Federico Simoncelli fsimo...@redhat.com Cc: Dead Horse deadhorseconsult...@gmail.com, users us...@ovirt.org, vdsm-de...@fedorahosted.org, aba...@redhat.com Sent: Thursday, September 26, 2013 1:38:15 AM Subject: Re: [Users] vdsm live migration errors in latest master On Tue, Sep 24, 2013 at 12:04:14PM -0400, Federico Simoncelli wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Dead Horse deadhorseconsult...@gmail.com Cc: us...@ovirt.org us...@ovirt.org, vdsm-de...@fedorahosted.org, fsimo...@redhat.com, aba...@redhat.com Sent: Tuesday, September 24, 2013 11:44:48 AM Subject: Re: [Users] vdsm live migration errors in latest master On Mon, Sep 23, 2013 at 04:05:34PM -0500, Dead Horse wrote: Seeing failed live migrations and these errors in the vdsm logs with latest VDSM/Engine master. Hosts are EL6.4 Thanks for posting this report. The log is from the source of migration, right? Could you trace the history of the hosts of this VM? Could it be that it was started on an older version of vdsm (say ovirt-3.3.0) and then (due to migration or vdsm upgrade) got into a host with a much newer vdsm? Would you share the vmCreate (or vmMigrationCreate) line for this Vm in your log? I smells like an unintended regression of http://gerrit.ovirt.org/17714 vm: extend shared property to support locking solving it may not be trivial, as we should not call _normalizeDriveSharedAttribute() automatically on migration destination, as it may well still be apart of a 3.3 clusterLevel. Also, migration from vdsm with extended shared property, to an ovirt 3.3 vdsm is going to explode (in a different way), since the destination does not expect the extended values. Federico, do we have a choice but to revert that patch, and use something like shared3 property instead? I filed a bug at: https://bugzilla.redhat.com/show_bug.cgi?id=1011608 A possible fix could be: http://gerrit.ovirt.org/#/c/19509 Beyond this, we must make sure that on Engine side, the extended shared values would be used only for clusterLevel 3.4 and above. Are the extended shared values already used by Engine? Yes. That's the idea. Actually to be fair, the second case you mentioned (migrating from extended shared property to old vdsm) it wouldn't have been possible I suppose (the issue here is that Dead Horse has one or more hosts running on master instead of 3.3). The extended shared property would have appeared only in 3.4 and to allow the migration you would have had to upgrade all the nodes. But anyway since we were also talking about a new 3.3.1 barnch I just went ahead and covered all cases. I do not see how the 3.3.1 branch is relevant to the discussion, as its Vdsm is NOT going to support clusterLevel 3.4. Pardon my slowliness, but would you confirm that this feature is to be used only on clusterLevel 3.4 and above? If so, I'm +2ing your patch. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] vdsm live migration errors in latest master
On Tue, Sep 24, 2013 at 12:04:14PM -0400, Federico Simoncelli wrote: - Original Message - From: Dan Kenigsberg dan...@redhat.com To: Dead Horse deadhorseconsult...@gmail.com Cc: us...@ovirt.org us...@ovirt.org, vdsm-de...@fedorahosted.org, fsimo...@redhat.com, aba...@redhat.com Sent: Tuesday, September 24, 2013 11:44:48 AM Subject: Re: [Users] vdsm live migration errors in latest master On Mon, Sep 23, 2013 at 04:05:34PM -0500, Dead Horse wrote: Seeing failed live migrations and these errors in the vdsm logs with latest VDSM/Engine master. Hosts are EL6.4 Thanks for posting this report. The log is from the source of migration, right? Could you trace the history of the hosts of this VM? Could it be that it was started on an older version of vdsm (say ovirt-3.3.0) and then (due to migration or vdsm upgrade) got into a host with a much newer vdsm? Would you share the vmCreate (or vmMigrationCreate) line for this Vm in your log? I smells like an unintended regression of http://gerrit.ovirt.org/17714 vm: extend shared property to support locking solving it may not be trivial, as we should not call _normalizeDriveSharedAttribute() automatically on migration destination, as it may well still be apart of a 3.3 clusterLevel. Also, migration from vdsm with extended shared property, to an ovirt 3.3 vdsm is going to explode (in a different way), since the destination does not expect the extended values. Federico, do we have a choice but to revert that patch, and use something like shared3 property instead? I filed a bug at: https://bugzilla.redhat.com/show_bug.cgi?id=1011608 A possible fix could be: http://gerrit.ovirt.org/#/c/19509 Beyond this, we must make sure that on Engine side, the extended shared values would be used only for clusterLevel 3.4 and above. Are the extended shared values already used by Engine? ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] HELP NEEDED: vdsm sync meeting - September 23th 2013
On Mon, Sep 23, 2013 at 04:34:29PM -0400, Douglas Schilling Landgraf wrote: - Heads up about 3.3.1/stable branch http://lists.ovirt.org/pipermail/engine-devel/2013-September/005601.html Our intention is to rename the current ovirt-3.3 branch to ovirt-3.3.0, and create a new ovirt-3.3 branch for following ovirt-3.3.z releases, based on current master. Please help in testing the tip of master branch for bugs and other surprises! - New VDSM release for this week (please raise any urgent/blockers bugs) - Patch pending to be included (status: review): glusterSD: BZ 988299: Deduce gluster volume name from domain metadata http://gerrit.ovirt.org/#/c/19219/1 -- Cheers Douglas ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] vdsm live migration errors in latest master
On Mon, Sep 23, 2013 at 04:05:34PM -0500, Dead Horse wrote:
Seeing failed live migrations and these errors in the vdsm logs with latest
VDSM/Engine master.
Hosts are EL6.4
Thanks for posting this report.
The log is from the source of migration, right?
Could you trace the history of the hosts of this VM? Could it be that it
was started on an older version of vdsm (say ovirt-3.3.0) and then (due
to migration or vdsm upgrade) got into a host with a much newer vdsm?
Would you share the vmCreate (or vmMigrationCreate) line for this Vm in
your log? I smells like an unintended regression of
http://gerrit.ovirt.org/17714
vm: extend shared property to support locking
solving it may not be trivial, as we should not call
_normalizeDriveSharedAttribute() automatically on migration destination,
as it may well still be apart of a 3.3 clusterLevel.
Also, migration from vdsm with extended shared property, to an ovirt 3.3
vdsm is going to explode (in a different way), since the destination
does not expect the extended values.
Federico, do we have a choice but to revert that patch, and use
something like shared3 property instead?
Thread-1306::ERROR::2013-09-23
16:02:42,422::BindingXMLRPC::993::vds::(wrapper) unexpected error
Traceback (most recent call last):
File /usr/share/vdsm/BindingXMLRPC.py, line 979, in wrapper
res = f(*args, **kwargs)
File /usr/share/vdsm/BindingXMLRPC.py, line 211, in vmDestroy
return vm.destroy()
File /usr/share/vdsm/API.py, line 323, in destroy
res = v.destroy()
File /usr/share/vdsm/vm.py, line 4326, in destroy
response = self.releaseVm()
File /usr/share/vdsm/vm.py, line 4292, in releaseVm
self._cleanup()
File /usr/share/vdsm/vm.py, line 2750, in _cleanup
self._cleanupDrives()
File /usr/share/vdsm/vm.py, line 2482, in _cleanupDrives
drive, exc_info=True)
File /usr/lib64/python2.6/logging/__init__.py, line 1329, in error
self.logger.error(msg, *args, **kwargs)
File /usr/lib64/python2.6/logging/__init__.py, line 1082, in error
self._log(ERROR, msg, args, **kwargs)
File /usr/lib64/python2.6/logging/__init__.py, line 1082, in error
self._log(ERROR, msg, args, **kwargs)
File /usr/lib64/python2.6/logging/__init__.py, line 1173, in _log
self.handle(record)
File /usr/lib64/python2.6/logging/__init__.py, line 1183, in handle
self.callHandlers(record)
File /usr/lib64/python2.6/logging/__init__.py, line 1220, in
callHandlers
hdlr.handle(record)
File /usr/lib64/python2.6/logging/__init__.py, line 679, in handle
self.emit(record)
File /usr/lib64/python2.6/logging/handlers.py, line 780, in emit
msg = self.format(record)
File /usr/lib64/python2.6/logging/__init__.py, line 654, in format
return fmt.format(record)
File /usr/lib64/python2.6/logging/__init__.py, line 436, in format
record.message = record.getMessage()
File /usr/lib64/python2.6/logging/__init__.py, line 306, in getMessage
msg = msg % self.args
File /usr/share/vdsm/vm.py, line 107, in __str__
if not a.startswith('__')]
File /usr/share/vdsm/vm.py, line 1344, in hasVolumeLeases
if self.shared != DRIVE_SHARED_TYPE.EXCLUSIVE:
AttributeError: 'Drive' object has no attribute 'shared'
- DHC
___
Users mailing list
us...@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] VDSM RPM Build failed with error SecureXMLRPCServer.py:143:1: E303 too many blank lines
On Fri, Sep 20, 2013 at 05:31:59AM -0400, Timothy Asir Jeyasingh wrote: Hi All, The vdsm (master branch) rpm build failed with the following error: find . -path './.git' -prune -type f -o \ -name '*.py' -o -name '*.py.in' | xargs /usr/bin/pyflakes | \ grep -w -v \./vdsm/storage/lvm\.py.*: list comprehension redefines 'lv' from line .* | \ while read LINE; do echo $LINE; false; done /usr/bin/pep8 --version 1.4.6 /usr/bin/pep8 --exclude=config.py,constants.py --filename '*.py,*.py.in' \ client lib/cpopen/*.py lib/vdsm/*.py lib/vdsm/*.py.in tests vds_bootstrap vdsm-tool vdsm/*.py vdsm/*.py.in vdsm/netconf vdsm/sos/vdsm.py.in vdsm/storage vdsm/vdsm vdsm_api vdsm_hooks vdsm_reg lib/vdsm/SecureXMLRPCServer.py:143:1: E303 too many blank lines (3) make[3]: *** [check-local] Error 1 make[3]: Leaving directory `/home/timothy/rpmbuild/BUILD/vdsm-4.12.0' make[2]: *** [check-am] Error 2 make[2]: Leaving directory `/home/timothy/rpmbuild/BUILD/vdsm-4.12.0' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/timothy/rpmbuild/BUILD/vdsm-4.12.0' error: Bad exit status from /var/tmp/rpm-tmp.PcZNhb (%check) Sorry about that. The pep8 failure was masked by another failure of apiTests.JsonRawTest.testBadMethod http://jenkins.ovirt.org/job/vdsm_unit_tests_gerrit/4499/testReport/junit/apiTests/JsonRawTest/testBadMethod/ Saggi, could you look into these recurring breakage? As David Caro explains in a comment to http://gerrit.ovirt.org/#/c/19332/ , I carelessly ignored the pep8 failure in Juan's patch. Problem solved by Juan's http://gerrit.ovirt.org/19408 . Thanks, and sorry for the noise. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] start vm which in pool failed
On Wed, Sep 18, 2013 at 01:03:08PM +0800, bigclouds wrote:
when starting a vm of a pool fails.in the process of hooks, i modify
guestvm hostname, and modify the path of backing file of chain. do nothing
else.
i can munually define a xml(after hooks), and start it without error.
Could you compare (or share) the manual domxml and the one produced by
your hook? It might be easier to spot the bug that way.
env:
libvirt-0.10.2-18.el6_4.5.x86_64
2.6.32-358.6.2.el6.x86_64
centos6.4
1.where does this error message come from ?
Storage.StorageDomain WARNING Could not find mapping for lv
d028d521-d4a9-4dd7-a0fe-3e9b60e7c4e4/cae1bb2d-0529-4287-95a3-13dcb14f082f
2.
Thread-6291::ERROR::2013-09-18
12:44:21,205::vm::683::vm.Vm::(_startUnderlyingVm)
vmId=`24f7e975-9aa5-4a14-b0f0-590add14c8b5`::The vm start process failed
Traceback (most recent call last):
File /usr/share/vdsm/vm.py, line 645, in _startUnderlyingVm
self._run()
File /usr/share/vdsm/libvirtvm.py, line 1529, in _run
self._connection.createXML(domxml, flags),
File /usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py, line
83, in wrapper
ret = f(*args, **kwargs)
File /usr/lib64/python2.6/site-packages/libvirt.py, line 2645, in
createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed',
conn=self)
libvirtError: internal error Process exited while reading console log output:
char device redirected to /dev/pts/4
qemu-kvm: -drive
file=/rhev/data-center/7828f2ae-955e-4e4b-a4bb-43807629dc52/d028d521-d4a9-4dd7-a0fe-3e9b60e7c4e4/images/ac025dc1-4e25-4b71-8c56-88dcb61b9f09/cae1bb2d-0529-4287-95a3-13dcb14f082f,if=none,id=drive-ide0-0-0,format=qcow2,serial=ac025dc1-4e25-4b71-8c56-88dcb61b9f09,cache=none,werror=stop,rerror=stop,aio=native:
could not open disk image
/rhev/data-center/7828f2ae-955e-4e4b-a4bb-43807629dc52/d028d521-d4a9-4dd7-a0fe-3e9b60e7c4e4/images/ac025dc1-4e25-4b71-8c56-88dcb61b9f09/cae1bb2d-0529-4287-95a3-13dcb14f082f:
Operation not permitted
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
___
vdsm-devel mailing list
vdsm-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] rebasing for oVirt 3.3.1?
On Mon, Sep 09, 2013 at 03:17:35PM +0300, Itamar Heim wrote: with 3.3.0 coming soon, one of the questions I heard is what about 3.3.1 considering the number of patches fox bugs that went into master branch since since we branched to stabilize 3.3.0. i.e., most of the work in master branch has been focused on bug fixes) so my suggestion is for 3.3.1 that we rebase from master, then move to backporting patches to that branch for the rest of 3.3 time frame. while this poses a small risk, i believe its the best course forward to making ovirt 3.3 a more robust and stable version going forward. this is mostly about ovirt-engine, and probably vdsm. for the other projects, its up to the maintainer, based on risk/benefit. To make this happen for Vdsm, we need to slow things down a bit, stabilize what we have, and test it out. Most of our work since ovirt-3.3 was bug fixing (23 patches), but some of the 101 patches we've got are related to refactoring (19), cleanups (27), test improvements (21), behind-the-scenes features (6), and visible features (5). Refactoring included Zhou Zheng Sheng's Ubuntu-readiness patches, which may still incur surprises to sysV/systemd/upstart service framework, and changes to how network configurators are to be used. Behind-the-scenes features include speedup to block-based storage: - One shot teardown. - Avoid Img and Vol produces in fileVolume.getV*Size - Make lvm.listPVNames() be based on vgs information. - One shot prepare. - Introduce lvm short filters. Visible features are few, and only one of them: - clientIF: automatically unpause vms in EIO when SD becomes active carries some kind of a risk to a timely release. The rest of them are: - Support for multiple heads for Qxl display device - Add support for direct setting of cpu_shares when creating a VM - Introducing hidden_vlans configurable. - macspoof hooks: new hook script to enable macspoof filtering per vnic. I think we can release vdsm-4.13.0 within a week if we put a hold on new features and big changes, and put enough effort into testing the mostly-changed areas: - service framework - VM lifecycle over block storage (including auto unpause) - network configuration Then, we could release vdsm-4.13.z without risking the stability of ovirt-3.3.1. Let's do it! Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] VDSM sync meeting September 9th 2013
On Tue, Sep 10, 2013 at 08:34:42AM +0200, Sandro Bonazzola wrote: Il 09/09/2013 16:09, Dan Kenigsberg ha scritto: - Master branch is broken for EL6 since we've taken Id8e514df1ca88500f746242134ddb24c31588046 with its daemonAdapter Yaniv Bronheim is working with Zhou and Alon Bar Lev to mend this. Please review http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:error-handling-daemonAdapter,n,z - Another breakage of master is the libvirt requirement introduced by me in http://gerrit.ovirt.org/18937. libvirt-0.10.2-18.el6_4.10 is not yet public. Current workaround is to take a newer libvirt from virt-preview, or ignore this dependency (which makes you unable to re-wire networks for a running VM). - We now require gluster-3.4.0 which is not yet availabled from koji for EL6. That's why we ship it in http://resources.ovirt.org/releases/3.3/rpm/EL/6/x86_64/ However, it is missing from the nightly repos. Can we softlink to them from the nightly repo, Eyal? - Timothy reports that the gluster team is working on geo-replication. One of the patches under review is http://gerrit.ovirt.org/#/c/17766/ Have I missed something? Please report it as a response! Master branch is also broken for Fedora 18, missing selinux-policy-targeted = 3.12.1-71 Eduardo, this has been introduced by your one shot prepare http://gerrit.ovirt.org/4220 . Once Bug 1005950 - Current selinux policy prevents running a VM with volumes under /var/run/vdsm/storage is solved in Fedora 18, we should require the proper version of selinux in our spec. Untill then, Vdsm cannot work with and enforcing F18's selinux. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] VDSM sync meeting September 9th 2013
- Master branch is broken for EL6 since we've taken Id8e514df1ca88500f746242134ddb24c31588046 with its daemonAdapter Yaniv Bronheim is working with Zhou and Alon Bar Lev to mend this. Please review http://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:error-handling-daemonAdapter,n,z - Another breakage of master is the libvirt requirement introduced by me in http://gerrit.ovirt.org/18937. libvirt-0.10.2-18.el6_4.10 is not yet public. Current workaround is to take a newer libvirt from virt-preview, or ignore this dependency (which makes you unable to re-wire networks for a running VM). - We now require gluster-3.4.0 which is not yet availabled from koji for EL6. That's why we ship it in http://resources.ovirt.org/releases/3.3/rpm/EL/6/x86_64/ However, it is missing from the nightly repos. Can we softlink to them from the nightly repo, Eyal? - Timothy reports that the gluster team is working on geo-replication. One of the patches under review is http://gerrit.ovirt.org/#/c/17766/ Have I missed something? Please report it as a response! Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] glusterfs-client and el6
They are here: http://resources.ovirt.org/releases/3.3/rpm/EL/6/x86_64/glusterfs-cli-3.4.0-8.el6.x86_64.rpm posting top we are why? On Tue, Aug 27, 2013 at 02:41:54PM -0400, Yaniv Bronheim wrote: Any estimation when the packages will be added to 6.4? If it'll take long we should revert the dependencies on those packages till then - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: Yaniv Bronheim ybron...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, August 27, 2013 10:35:13 AM Subject: Re: [vdsm] glusterfs-client and el6 Gluster 3.4 pkgs are not available in epel for el6 (6.4, they will be, I think for 6.5). However, as I put yesterday in the notes, Federico said that those packages will be added to the ovirt.org repository for 6.4. At the moment I'm using the gluster repo for them. - Original Message - From: Yaniv Bronheim ybron...@redhat.com To: Antoni Segura Puimedon asegu...@redhat.com Cc: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Tuesday, August 27, 2013 8:43:01 AM Subject: Re: [vdsm] glusterfs-client and el6 Before merging such patches that adds new requirements please verify that the required packages are available. Such issues raised more than few times before.. As I understood in yesterday's vdsm call the gluster packages are already available, so this issue is not relevant anymore. right? Yaniv Bronhaim. - Original Message - From: Antoni Segura Puimedon asegu...@redhat.com To: VDSM Project Development vdsm-devel@lists.fedorahosted.org Sent: Friday, August 23, 2013 2:15:33 PM Subject: [vdsm] glusterfs-client and el6 Hi list, This patch http://gerrit.ovirt.org/#/c/17994/ made vdsm on el6 and Fedora18+ depend, among others, on glusterfs-cli, which is on the epel candidates but not yet on epel stable (at least this morning it was not in http://dl.fedoraproject.org/pub/epel/6/x86_64/repoview/letter_g.group.html ). To be able to install vdsm on el6, then, it is necessary to get the packages in: http://koji.fedoraproject.org/koji/buildinfo?buildID=454492 which are labeled at the moment as epel-testing-candidate. In the future we should strive delay such changes until the packages hit epel stable, I'd propose. Best regards, Toni ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] suggesting new Vdsm maintaniner(s)
On Thu, Aug 01, 2013 at 04:55:07PM +0300, Dan Kenigsberg wrote: Nominating Toni Puimedon and/or Mark Wu as maintainers == During their recent year-or-two of participation in Vdsm development, both Toni and Mark has demonstrated a genuine care for the health and evolution of the the project. They both carry this hard-to-quantify quality of serious-mindedness when reviewing patches. Toni's 73 committed patches touch everything that is related to network configuration and reporting 27 vdsm/configNetwork.py 11 lib/vdsm/netinfo.py 8 vdsm/API.py 8 tests/configNetworkTests.py 7 vdsm/netinfo.py 7 vdsm/netconf/ifcfg.py 5 vdsm/libvirtvm.py 4 vdsm/netmodels.py ... similar to Mark's 80: 16 vdsm/configNetwork.py 12 vdsm/netconf/ifcfg.py 12 vdsm/libvirtvm.py 7 vdsm/clientIF.py 6 lib/vdsm/netinfo.py 5 vdsm/caps.py 5 vdsm/API.py 4 vdsm/vm.py 4 vdsm/netmodels.py 4 vdsm/Makefile.am I suggest that both of them obtain +2/-2 rights, in the understanding that they are to be used on net-related parts of the code. This is particularly important given my nearing, relatively long, vacation. What do you say? We've got no objectation, but neither an overwhelming support. Maybe it's due to the summer season. To me, it is important to tell whether Toni/Mark only reviewed a patch (+1) or are completely standing behind it, and going to fix bugs in it if the author is run over by a bus (God forbid). Itamar and other board members: if there is no objection within, say, one week, would you grant the duo +2 rights? Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] Error while rebooting VM
On Fri, Aug 02, 2013 at 03:15:46PM +0200, Sandro Bonazzola wrote: Pushed a patch for the issue here: http://gerrit.ovirt.org/#/c/17599/ Now I see the following traceback in the logs: Traceback (most recent call last): File /usr/share/vdsm/clientIF.py, line 382, in teardownVolumePath res = self.irs.teardownImage(drive['domainID'], File /usr/share/vdsm/vm.py, line 1343, in __getitem__ raise KeyError(key) KeyError: 'domainID' I do not understand what it is, but I've seen that before. It's unrelated to Yeela's latest patch, and unlike it, it affects ovirt-3.3 branch) https://bugzilla.redhat.com/show_bug.cgi?id=987965#c2 ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] vdsm v4.12.0 dependencies for el6 hosts
On Wed, Jul 31, 2013 at 04:36:00PM -0500, Dead Horse wrote: vdsm v4.12.0 for engine 3.3 has some unsatisfied dependencies on el6 hosts: -- Finished Dependency Resolution Error: Package: vdsm-hook-sriov-4.12.0-10.el6.noarch (el6v-test) Requires: libvirt-daemon-driver-nodedev Error: Package: vdsm-4.12.0-10.el6.x86_64 (el6v-test) Requires: mom = 0.3.2-3 Removing: mom-0.3.0-1.el6.noarch (@epel) mom = 0.3.0-1.el6 Updated By: mom-0.3.2-2.el6.noarch (el6v-test) mom = 0.3.2-2.el6 mom can be built from http://gerrit.ovirt.org/gitweb?p=mom.git but libvirt-daemon-driver-nodedev would require a newer libvirt. (https://apps.fedoraproject.org/packages/libvirt-daemon-driver-nodedev) That's my bad. Would you verify http://gerrit.ovirt.org/#/c/17554/ ? Regrads, Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
[vdsm] suggesting new Vdsm maintaniner(s)
Nominating Toni Puimedon and/or Mark Wu as maintainers == During their recent year-or-two of participation in Vdsm development, both Toni and Mark has demonstrated a genuine care for the health and evolution of the the project. They both carry this hard-to-quantify quality of serious-mindedness when reviewing patches. Toni's 73 committed patches touch everything that is related to network configuration and reporting 27 vdsm/configNetwork.py 11 lib/vdsm/netinfo.py 8 vdsm/API.py 8 tests/configNetworkTests.py 7 vdsm/netinfo.py 7 vdsm/netconf/ifcfg.py 5 vdsm/libvirtvm.py 4 vdsm/netmodels.py ... similar to Mark's 80: 16 vdsm/configNetwork.py 12 vdsm/netconf/ifcfg.py 12 vdsm/libvirtvm.py 7 vdsm/clientIF.py 6 lib/vdsm/netinfo.py 5 vdsm/caps.py 5 vdsm/API.py 4 vdsm/vm.py 4 vdsm/netmodels.py 4 vdsm/Makefile.am I suggest that both of them obtain +2/-2 rights, in the understanding that they are to be used on net-related parts of the code. This is particularly important given my nearing, relatively long, vacation. What do you say? Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] [Users] [ATN] oVirt 3.3 release, moving to RC [3.3 branching, blockers review]
On Tue, Jul 30, 2013 at 06:05:46PM +0300, Moran Goldboim wrote: We would like to go a head on oVirt 3.3 release process and issue an RC for tomorrow meeting: Maintainers/ Package owners == -branch your git repo (master) with 3.3 branch (making master ready for 3.4) -for tomorrow meeting, overview [1], see if you have any changes to it -if you don't have any blockers under your component, please branch 3.3 with RC1 branch | -master | -engine_3.3 | -RC1 | -engine_3.2 ... Users with your experience from test day and with nightlies, if you feel there are additional candidates to block this version for please add it to the tracker bug [1]. Suggested Schedule Wed Jul 31st - review of blockers for the version and component readiness Mon Aug 5th - RC1 release Wed Aug 7th - Release readiness review (in case of blockers an RC2 will be issued) Thanks. [1]*Bug 918494* https://bugzilla.redhat.com/show_bug.cgi?id=918494 -Tracker: oVirt 3.3 release I've just tagged vdsm-4.12.0 and branched ovirt-3.3 branch for the vdsm repository starting at git has 620343d6317c849fc985a5083cebb68c995f7c15. Expect a deluge of non-ovirt-3.3 merges to the master branch soon. Future ovirt-3.3 fixes would have to be backported and cherry-picked. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
Re: [vdsm] migration progress feature
On Sun, Jul 21, 2013 at 10:29:03PM +0300, Itamar Heim wrote: On 07/21/2013 12:14 PM, Dan Kenigsberg wrote: Introducing a new verb, getMigrationStatuses(), would allow Engine to collect this piece of statistics in the exact frequency that it needs it. Coupling this data with the frequently-polled state of VM begs for future complaints that getVMList(full=False) is too heavy, and that we must introduce getVMList(full=False, veryveryskinny=True). so the most likely outcome is engine would be calling this every time it calls getAllVmStats? Having two different verbs allows the client to play with the frequency of polling. Last word I've heard was that getAllVmStats is too heavy to be called in the frequency that getMigrationStatuses is needed. If Engine is happy to lock the frequency of getMigrationStatuses to that of getAllVmStats, we can include migrateStatus within getAllVmStats. I already conceded to this earlier in this thread. Dan. ___ vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
