September 2013 - Devel - Ovirt List Archives

[Engine-devel] question related to sysprep and AD

by bigclouds

------=_Part_456523_121567887.1378820657783 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: 7bit hi,all 1. it seems that ovirt has implemented to sysprep a windows. if this feature works and how to take advantage of it. 2.on UI, there are several input places for AD(domain), if its goal is to add a guestvm into a domain? how to use it and add a guest into domain? 3.if there is a way to add a guestvm into domain without reboot? thanks. ------=_Part_456523_121567887.1378820657783 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: 7bit <div style="line-height:1.7;color:#000000;font-size:14px;font-family:arial"><div>hi,all</div><div> 1.</div><div>it seems that ovirt has implemented to sysprep a windows.</div><div>if this feature works and how to <u><font color="#0066cc">take advantage of</font></u> it.</div><div> </div><div>2.on UI, there are several input places for AD(domain), if its goal is to add a guestvm into a domain?</div><div>how to use it and add a guest into domain?</div><div> </div><div>3.if there is a way to add a guestvm into domain without reboot?</div><div> </div><div>thanks.</div></div><br><br><span title="neteasefooter"><span id="netease_mail_footer"></span></span> ------=_Part_456523_121567887.1378820657783--

10 years, 7 months

1
0
0 / 0

[Engine-devel] Question about HotPlug

by Gustavo Frederico Temple Pedrosa

--_000_EF26FC1776F7FF46BFC072393EFD13A29A4E1FSERV070corpeldora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Currently there is an option in the "vdc_options" table which indicates the= operating systems that do not support NIC hotplug. I think it would be a b= etter idea to use the osinfo properties file to enable or disable NIC hotpl= ugging, since in this file an operating system can inherit properties from = another one. The main idea is to disable NIC hotplugging in PPC64 VMs, but = listing explicitly every ppc64 os in "HotPlugUnsupportedOsList" config valu= e does not look like a clean way to do so. Do you agree with this? Should t= his parameter be included in the osinfo properties file? Thanks, Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa --_000_EF26FC1776F7FF46BFC072393EFD13A29A4E1FSERV070corpeldora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"PT-BR" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US">Hi all,<br> <br> Currently there is an option in the "vdc_options" table which ind= icates the operating systems that do not support NIC hotplug. I think it wo= uld be a better idea to use the osinfo properties file to enable or disable= NIC hotplugging, since in this file an operating system can inherit properties from another one. The main idea is to disabl= e NIC hotplugging in PPC64 VMs, but listing explicitly every ppc64 os in &q= uot;HotPlugUnsupportedOsList" config value does not look like a clean = way to do so. Do you agree with this? Should this parameter be included in the osinfo properties file?<o:p></o:p></span= ></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal">Thanks,<o:p></o:p></p> <p class=3D"MsoNormal">Leonardo Bianconi/Vitor de Lima/Gustavo Pedrosa<o:p>= </o:p></p> </div> </body> </html> --_000_EF26FC1776F7FF46BFC072393EFD13A29A4E1FSERV070corpeldora_--

10 years, 7 months

4
4
0 / 0

[Engine-devel] Profiling presentation

by Liran Zelkha

Hi all, For those who attended the profiling session today, or for anyone who wants to run a profiler on ovirt, please see today's presentation at http://www.slideshare.net/lzelkha/jprofiler8-ovirt

10 years, 7 months

1
0
0 / 0

Re: [Engine-devel] Minor question concerning ServerException class

by Michael Pasternak

Hi Ricky, On 09/06/2013 09:31 PM, Hopper, Richard wrote: > Hi Michael, > > While working with the ovirt-engine-sdk-java, > I came across a small issue concerning the ServerException class. I wrote a utility to handle different types of exceptions > (ServerException being one of those) for our plugin and found that ServerException does not meet GWT's specific serialization requirements due to the lack of a no-arg > constructor of any visibility level. Is there an explicit reason for the lack of such a constructor? no, not at all, addressed at [1]. [1] http://gerrit.ovirt.org/#/c/18960/ thanks for reporting this. > I was able to work around this, it's just a minor concern as far as GWT > goes, and it could be useful to others if such types were serializable as well. > > Thanks, > > - Ricky -- Michael Pasternak RedHat, ENG-Virtualization R&D

10 years, 7 months

1
0
0 / 0

[Engine-devel] Storing command parameters

by Sahina Bose

Hi all, As part of the gluster volume asynchronous tasks, we ran into a requirement wherein when we start a command, we need to remember the parameters that the command was started with. Is there any infrastructure available to do this, or should we build something? thanks sahina

10 years, 7 months

3
3
0 / 0

[Engine-devel] Big up Assaf Muller

by Tim Hildred

I just wanted to say what an amazing feature page this is: http://www.ovirt.org/Features/Multiple_Gateways I especially like the "Why do we need this feature" part. It is all so well laid out and presented. Nice work Assaf! Tim Hildred, RHCE, RHCVA Content Author II - Engineering Content Services, Red Hat, Inc. Brisbane, Australia Email: thildred(a)redhat.com Internal: 8588287 Mobile: +61 4 666 25242 IRC: thildred

10 years, 7 months

2
1
0 / 0

[Engine-devel] Question about API REST

by Gustavo Frederico Temple Pedrosa

--_000_EF26FC1776F7FF46BFC072393EFD13A29A40C6SERV070corpeldora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello everyone, I'm adding the architecture meta-field of VMs, Templates and Clusters in RE= ST API (see change #16700 in gerrit). It's a read-only field (like a "final= " in Java), that the administrator cannot change it, but there are some sit= uations where there might be a value for it, such as when an entity is rece= ived from the API, slightly modified and then its update method is called. = So I would like to ask these questions about how to implement it: 1) Should this attribute be mapped both ways (from the REST API to the engi= ne and vice-versa)? 2) How should this field be declared in the rdsl_metadata? Do I have to exp= licitly put it in the optional arguments or should I omit it? 3) How can I make this field strictly immutable (like the ID field is), giv= en that the architecture is a field of the CPU entity, and the methods used= to check for invalid updates can only operate on fields that belong direct= ly to the main entity? Thanks. --_000_EF26FC1776F7FF46BFC072393EFD13A29A40C6SERV070corpeldora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"PT-BR" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US">Hello everyone,<o:p></o:p></spa= n></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">I'm adding the architecture met= a-field of VMs, Templates and Clusters in REST API (see change #16700 in ge= rrit). It's a read-only field (like a “final” in Java), that th= e administrator cannot change it, but there are some situations where there might be a value for it, such as when an entit= y is received from the API, slightly modified and then its update method is= called. So I would like to ask these questions about how to implement it:<= o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">1) Should this attribute be map= ped both ways (from the REST API to the engine and vice-versa)?<o:p></o:p><= /span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">2) How should this field be dec= lared in the rdsl_metadata? Do I have to explicitly put it in the optional = arguments or should I omit it?<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US">3) How can I make this field st= rictly immutable (like the ID field is), given that the architecture is a f= ield of the CPU entity, and the methods used to check for invalid updates c= an only operate on fields that belong directly to the main entity? <o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US"><o:p> </o:p></span></p> <p class=3D"MsoNormal">Thanks.<o:p></o:p></p> <p class=3D"MsoNormal"><o:p> </o:p></p> </div> </body> </html> --_000_EF26FC1776F7FF46BFC072393EFD13A29A40C6SERV070corpeldora_--

10 years, 7 months

2
2
0 / 0

Re: [Engine-devel] Cluster default with empty processor name with PPC64 support

by Leonardo Bianconi

>-----Original Message----- >From: Michal Skrivanek [mailto:mskrivan@redhat.com] >Sent: terça-feira, 3 de setembro de 2013 09:19 >To: Leonardo Bianconi >Cc: engine-devel(a)ovirt.org >Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support > > >On Sep 3, 2013, at 13:49 , Itamar Heim <iheim(a)redhat.com> wrote: > >> On 09/03/2013 02:39 PM, Leonardo Bianconi wrote: >>> >>> >>>> -----Original Message----- >>>> From: Itamar Heim [mailto:iheim@redhat.com] >>>> Sent: segunda-feira, 2 de setembro de 2013 13:46 >>>> To: Leonardo Bianconi >>>> Cc: Roy Golan; engine-devel(a)ovirt.org >>>> Subject: Re: [Engine-devel] Cluster default with empty processor >>>> name with PPC64 support >>>> >>>> On 09/02/2013 06:43 PM, Leonardo Bianconi wrote: >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Itamar Heim [mailto:iheim@redhat.com] >>>>>> Sent: segunda-feira, 2 de setembro de 2013 10:29 >>>>>> To: Leonardo Bianconi >>>>>> Cc: Roy Golan; engine-devel(a)ovirt.org >>>>>> Subject: Re: [Engine-devel] Cluster default with empty processor >>>>>> name with PPC64 support >>>>>> >>>>>> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote: >>>>>>> >>>>>>> >>>>>>>>> From: Roy Golan [mailto:rgolan@redhat.com] >>>>>>>>> Sent: domingo, 1 de setembro de 2013 05:07 >>>>>>>>> To: Leonardo Bianconi >>>>>>>>> Cc: engine-devel(a)ovirt.org >>>>>>>>> Subject: Re: [Engine-devel] Cluster default with empty >>>>>>>>> processor name with PPC64 support >>>>>>>>> >>>>>>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote: >>>>>>>>> Hi everyone! >>>>>>>>> >>>>>>>>> During the development of PPC64 support in the engine, we faced >>>>>>>>> some UX issues regarding the default Cluster (that Cluster with >>>>>> empty processor name). >>>>>>>>> >>>>>>>>> Currently, oVirt engine allows the default Cluster to contain >>>>>>>>> empty processor name, and the administrator can add VMs and/or >>>>>> Templates to it. The processor name can be assigned later, editing the cluster or assigning a valid host to it. >>>>>>>>> >>>>>>>>> During the implementation of PPC64 support on the engine, the >>>>>>>>> field "architecture" was added to Clusters, VMs and Templates >>>>>> entities. >>>>>>>>> herdado >>>>>>>>> So we have the following questions regarding how the UI should behave: >>>>>>>>> >>>>>>>>> - Shall we keep allowing the administrator to assign VMs and >>>>>>>>> Templates to the Cluster with no processor name or assigned >>>>>> architecture ? >>>>>>>>> -> If we have an "yes" for the question above: >>>>>>>>> -- We will have to assign the architecture to >>>>>>>>> the Cluster based on the OS of the first assigned VM, and the >>>>>>>>> processor name >>>>>> could be defined the same way as currently ... editing the Cluster or assigning a compatible Host to it. >>>>>>>>> -- The VM creation popup will >>>>>>>>> have to be able to indicate the architecture of each OS ... >>>>>>>>> some OSes have the same >>>>>> name, and it may get ambiguous since the Cluster architecture is >>>>>> still undefined at that point (before the first VM get already >>>> created). >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> Regards. >>>>>>>>> Leonardo Bianconi >>>>>>>>> >>>>>>>> To add VMs you anyway need a running host in the cluster which means the cpu name and the architecture would be the >host's. >>>>>>>> So we can keep the cluster attributes - "cpu name" and "arch" consistent and allow them to be empty on creation. >>>>>>>> >>>>>>>> >>>>>>> Hi Roy! >>>>>>> >>>>>>> There is a way to add VMs in a cluster with no hosts running. Steps to reproduce: >>>>>>> - Initialize the oVirt engine with a new data base >>>>>>> - Create a new Cluster (I will call it of newCluster) in the Data >>>>>>> Center Default >>>>>>> - Add a host in the newCluster >>>>>>> - Add a Storage >>>>>>> - Create a VM in the Cluster Default >>>>>>> Result: The system allows a VM in a cluster with no Hosts running in it. >>>>>>> >>>>>>> Is it a bug or a system functionality? If it's a functionality, the issue above can happen. >>>>>> >>>>>> while above can happen, is it really an interesting use case to solve? >>>>>> can user edit the arch field of a vm? if so, i'd just block >>>>>> running it on incorrect cluster (just like we block on moving it >>>>>> between incompatible clusters) until user fix the issue >>>>> >>>>> Yes, it's interesting solve, because we use the cluster architecture when creating VMs. >>>>> The user cannot edit the arch field, because there is no field for >>>>> that, it is inherited from the cluster. The arch is important on >>>> creating VMs, because it filters the OS list and defines the VM architecture. >>>>> What should we do? >>>>> >>>>> Thanks!! >>>>> >>>> >>>> so worst case the list is not filtered while creating the VM for that corner case? >>>> >>>> thinking about this some more, with all due respect to PPC and this >>>> corner case, I'd just assume if cluster arch is not yet defined, OS list should be filtered as x86_64. >>>> or, we block creating VMs on clusters which have no arch defined >>>> (I'm specifically not saying no hosts, just in case its useful >>>> somehow) >>> >>> I think both are good solutions, but looking the system behavior, I think the first solution will be weird for new users and the >second has problems when upgrading the data base. >>> I would suggest the following behavior: >>> >>> 1. For new data bases: Block the admin to add VMs in the cluster with no processor name (Cluster Default), i. e. no architecture. >>> 2. For upgraded data bases, If the cluster with no processor name (Cluster Default) has: >>> 2.1 - VMs: Set the cluster architecture for x86_64 and allow admin use it as x86_64. > >as an upgrade script, right? Yes. > >>> 2.2 - no VMs: Keep the cluster with no processor name, i. e. no >>> architecture (it will keep the same behavior of the cluster for new >>> data base - item 1) >>> >>> On the item 2.1, when setting the architecture of the cluster (Cluster Default) for x86_64, the processor name will be empty. >Should we set it for the lowest x86_64 level? How about the processor name for this case, Any thoughts? > >sounds good enough > >Thanks, >michal > >>> >>> What do you think? >>> >>> Thanks!! >>> >> >> sounds good to me. roy/omer/michal? >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel

10 years, 7 months

1
0
0 / 0

[Engine-devel] Importing OVF files for x86/PPC64

by Leonardo Bianconi

Hi! We are about to implement and propose changes in VM import UI ... for oVirt PPC64 (multiplatform). Currently it's possible to select more than one item to be imported. This may create a problem since administrators will be able to select items with different architectures (e.g. x86 a PPC64) and import them into the same cluster. We propose to add a column in the tables (VM Import and Template Import) to display the identified architecture of each VM to be imported. The validation will occur by hitting the "Import" button action, that may block the operation in case there were items related to different architectures. We'd like to know your opinion about it, because it will change how the user interacts (UX) with this feature. Regards, Leonardo Bianconi

10 years, 7 months

1
0
0 / 0

[Engine-devel] oVirt 3.3 Release Go/No-Go meeting

by Ofer Schreiber

------=_Part_8326286_1829562358.1378130804020 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit The following is a new meeting request: Subject: oVirt 3.3 Release Go/No-Go meeting Organizer: "Ofer Schreiber" <oschreib(a)redhat.com> Location: #ovirt IRC channel @oftc Time: Tuesday, September 3, 2013, 4:00:00 PM - 4:30:00 PM GMT +02:00 Jerusalem Invitees: board(a)ovirt.org; users(a)ovirt.org; engine-devel(a)ovirt.org *~*~*~*~*~*~*~*~*~* oVirt 3.3 Release Go/No-Go meeting ------=_Part_8326286_1829562358.1378130804020 Content-Type: text/calendar; charset=utf-8; method=REQUEST; name=meeting.ics Content-Transfer-Encoding: 7bit BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Asia/Jerusalem BEGIN:STANDARD DTSTART:16010101T020000 TZOFFSETTO:+0200 TZOFFSETFROM:+0300 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=10;BYDAY=1SU TZNAME:IST END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T020000 TZOFFSETTO:+0300 TZOFFSETFROM:+0200 RRULE:FREQ=YEARLY;WKST=MO;INTERVAL=1;BYMONTH=3;BYDAY=-1FR TZNAME:IDT END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT UID:e4bb4608-7bca-4ed5-a0a3-7abc6a64af7a SUMMARY:oVirt 3.3 Release Go/No-Go meeting LOCATION:#ovirt IRC channel @oftc ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:board@o virt.org ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:users@o virt.org ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE:mailto:engine- devel(a)ovirt.org ORGANIZER;CN=Ofer Schreiber:mailto:oschreib@redhat.com DTSTART;TZID="Asia/Jerusalem":20130903T160000 DTEND;TZID="Asia/Jerusalem":20130903T163000 STATUS:CONFIRMED CLASS:PUBLIC X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY TRANSP:OPAQUE LAST-MODIFIED:20130902T140644Z DTSTAMP:20130902T140644Z SEQUENCE:0 DESCRIPTION:The following is a new meeting request:\n\nSubject: oVirt 3.3 Re lease Go/No-Go meeting \nOrganizer: "Ofer Schreiber" <oschreib(a)redhat.com> \ n\nLocation: #ovirt IRC channel @oftc \nTime: Tuesday\, September 3\, 2013\, 4:00:00 PM - 4:30:00 PM GMT +02:00 Jerusalem\n \nInvitees: board(a)ovirt.org\ ; users(a)ovirt.org\; engine-devel(a)ovirt.org \n\n\n*~*~*~*~*~*~*~*~*~*\n\noVir t 3.3 Release Go/No-Go meeting BEGIN:VALARM ACTION:DISPLAY TRIGGER;RELATED=START:-PT5M DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR ------=_Part_8326286_1829562358.1378130804020--

10 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

Devel September 2013