- Devel - oVirt List Archives

Re: [ovirt-devel] [ovirt-users] HA not working 3.4.2
by mad Engineer 25 Jun '14

25 Jun '14

Thanks, I tried that and now the "!" is gone and from control panel restarted that server and it rebooted but the reboot happened only in Ovirt control panel and actual server hasn't rebooted nor got shutdown its up time still hasn't changed. Any idea whats wrong Thanks On Wed, Jun 25, 2014 at 12:46 AM, Joop <jvdwege(a)xs4all.nl> wrote: > On 24-6-2014 21:02, mad Engineer wrote: > > Thanks Arik, > I think that's the issue,i havent configured any > power management but could you tell me what to specify in power management > > i see Address,Username,Password,SSH port and Type. > > Using HP server with ILO2 so i filled Type as ILO2 but its confusing > what these > > * Address,Username,Password *are > > are these ILO credentials or My hypervisor credentials > > > ILO credentials. > > Joop > > > _______________________________________________ > Users mailing list > Users(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > >

1 0

Annotating internal commands
by Yair Zaslavsky 25 Jun '14

25 Jun '14

Hi, Some of you already got or will get emails from me asking if several commands are only internal or not. I basically check usages at rest-api and ui, but I might have missed something. IMHO, we should continue (until we device not to :) ) to annotate internal commands with the @InternalCommandAttribute Thanks, Yair

3 3

ioprocess on debian
by Yeela Kaplan 25 Jun '14

25 Jun '14

Hi, There's a new dependency for vdsm: python-ioprocess. We also need to build ioprocess for debian. Do you know who can be helping with that or what's the process? Thanks in advance, Yeela

6 12

[QE][ACTION NEEDED] oVirt 3.5.0 Beta status
by Sandro Bonazzola 25 Jun '14

25 Jun '14

Hi, We're going to compose oVirt 3.5.0 Beta on Thu *2014-06-26 08:00 UTC*. Maintainers: - Please be sure that master snapshot allow to create VMs before today *2014-06-25 15:00 UTC* The bug tracker [1] shows the following proposed blockers to be reviewed: Bug ID Whiteboard Status Summary 1073944 integration ASSIGNED Add log gathering for a new ovirt module (External scheduler) 1060198 integration NEW [RFE] add support for Fedora 20 About Add log gathering for a new ovirt module (External scheduler), patch have been merged on upstream sos master branch. For Fedora >= 19 sos-3.1 package includes the fix. For EL 6 patches need to be backported to ovirt-log-collector. Feature freeze is now effective, no more features should be pushed. Features included in 3.5.0 Beta are marked in green on Features Status Table [2] Some more features may be included since they were near to be completed on last sync meeting. The table will be updated on next sync meeting scheduled for today 2014-06-25. There are still 357 bugs [3] targeted to 3.5.0. Excluding node and documentation bugs we still have 294 bugs [4] targeted to 3.5.0. Maintainers / Assignee: - Please remember to rebuild your packages before today *2014-06-25 15:00* if needed, otherwise nightly snapshot will be taken. - Please be sure that master snapshot allow to create VMs before today *2014-06-25 15:00 UTC* - If you find a blocker bug please remember to add it to the tracker [1] - Please start filling release notes, the page has been created here [5] - Please review and add test cases to oVirt 3.5 Test Day [6] Community: - You're welcome to join us testing this beta release and getting involved in oVirt Quality Assurance[7]! [1] http://bugzilla.redhat.com/1073943 [2] http://bit.ly/17qBn6F [3] http://red.ht/1pVEk7H [4] http://red.ht/1rLCJwF [5] http://www.ovirt.org/OVirt_3.5_Release_Notes [6] http://www.ovirt.org/OVirt_3.5_TestDay [7] http://www.ovirt.org/OVirt_Quality_Assurance Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

[QE][ACTION NEEDED] oVirt 3.4.3 RC status
by Sandro Bonazzola 25 Jun '14

25 Jun '14

Hi, We're going to start composing oVirt 3.4.3 RC on *2014-07-10 08:00 UTC* from 3.4 branch. A 3.4.3 branch will be created immediately after using the same hash of the build. The bug tracker [1] shows no blocking bugs for the release There are still 34 bugs [2] targeted to 3.4.3. Excluding node and documentation bugs we still have 12 bugs [3] targeted to 3.4.3. Maintainers / Assignee: - Please add the bugs to the tracker if you think that 3.4.3 should not be released without them fixed. - Please update the target to any next release for bugs that won't be in 3.4.3: it will ease gathering the blocking bugs for next releases. - Please fill release notes, the page has been created here [4] - Please build packages before *2014-07-09 15:00 UTC*. Community: - If you're testing oVirt 3.4 nightly snapshot, please add yourself to the test page [5] [1] bugzilla.redhat.com/1107968 [2] http://red.ht/1lBAw2R [3] http://red.ht/1ly9hfA [4] http://www.ovirt.org/OVirt_3.4.3_Release_Notes [5] http://www.ovirt.org/Testing/oVirt_3.4.3_Testing Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Update on QEMU Snapshot Package in CentOS
by Brian Proffitt 24 Jun '14

24 Jun '14

All: I spoke with KB at CentOS about maintaining the qemu package for the Virt SIG. He has expressed concerns that if oVirt curates the qemu package in order to have the snapshotting flag turned on, then there might arise a situation where each project within the SIG would be getting their own versions of qemu. To help mitigate against such an occurrence, KB suggested that oVirt take ownership of not the RHEL distro-specific version of qemu, but a more upstream version instead. Upon discussion with Douglas Landsgraf and Itamar, it seemed to make more sense to keep downloading from CentOS repo and rebuilding it with flag enabled and either sharing that with the SIG or inside our own oVirt repository. Basically, KB's issue that if oVirt does wish to curate this package on behalf of the SIG, that we as a project would be willing to manage all requests from the rest of the SIG participants (such as the example he raised, which was his personal wish that the vdi and Microsoft vpc formats be turned on as well, so he can build Azure images more easily). If we were willing to take on such a responsibility for the SIG, then this would mitigate multiple versions of qemu appearing. >From my side, I believe this is a reasonable expectation, given that we are going to get what we need within CentOS and still can be a responsible community player within the SIG. I put the question to the developers: is this something we want to undertake, or should we simply maintain our version of qemu within an oVirt-specific repository? Peace, Brian -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

5 11

HA not working 3.4.2
by mad Engineer 24 Jun '14

24 Jun '14

Hi i was testing HA of ovirt,(i am from Xenserver background and trying to use KVM solution in our environment) Have 2 hosts with NFS storage and i tested migration between these two hosts. On Host2 while VM was running on it, i unplugged Power cable and it took long minutes to update that VM is down,okkk now long wait...... .. ..... ....... VM state changed to *unkown *and not booted on second Node ie Host1 its been half an hour and still the VM is not restarted What can be the issue?What should i do it make the VM in real HA so that it will be restarted on the active node. *How HA is enabled* what i did was while creating vm> Advanced option>High Availability>Highly Available I am sure this can be a configuration error,Can some one please help me with enabling HA. Please Help Thanks

2 2

Update: artifactory problem is resolved (incident report)
by Eyal Edri 24 Jun '14

24 Jun '14

Hi, Today jenkins.ovirt.org had suffered a major incident which occured due to bad syncing from maven sonatype. it all started from the jboss commit "core: CDI workaournd jboss 7.1.1 bug", which was fixed later by roy, but for some reason (might be sonatype repo deleting ovirt artifacts), we were left with outdated jars in all jenkins local repos and on artifactory.ovirt.org. roy sent this morning how it should be resolved: - build is failing because ovirt-host-deploy needs refresh using -U . alonbl updates its artifacts just now so it should take a while to refresh but it didn't work. also didn't work: - cleaning cache from artifactory - deleting local maven repos from jenkins jobs what did work finally: - deleting the sonatype from artifactory.ovirt.org and creating it again, plug updating ovirt-mirror virtual as well. - some jobs might need to be updated/deleted local WS manually still - please report to infra on jobs that still fail. we probably need to think how to handle such incidents in the future (if sonatype continues to delete our jars...). any suggestions will be gladly considered. oVirt infra team. ----- Original Message ----- > From: "Sandro Bonazzola" <sbonazzo(a)redhat.com> > To: "Ohad Basan" <obasan(a)redhat.com>, "infra" <infra(a)ovirt.org> > Sent: Tuesday, June 24, 2014 6:22:35 PM > Subject: Re: artifactory problem is resolved > > Il 24/06/2014 17:10, Ohad Basan ha scritto: > > Hello > > > > the artifactory problem we had today (fetching the wrong host deploy) > > should be fixed > > send an email if you hit more problems > > http://jenkins.ovirt.org/job/ovirt-engine_master_create-rpms-quick_gerrit/2… > > > > > thanks, > > > > Ohad > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra >

1 0

oVirt Node Weekly Meeting Minutes - June 24 2014
by Fabian Deutsch 24 Jun '14

24 Jun '14

Minutes: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-06-24-13.11.html Minutes (text): http://ovirt.org/meetings/ovirt/2014/ovirt.2014-06-24-13.11.txt Log: http://ovirt.org/meetings/ovirt/2014/ovirt.2014-06-24-13.11.log.html ================================= #ovirt: oVirt Node Weekly Meeting ================================= Meeting started by fabiand at 13:11:08 UTC. The full logs are available at http://ovirt.org/meetings/ovirt/2014/ovirt.2014-06-24-13.11.log.html . Meeting summary --------------- * Agenda (fabiand, 13:11:46) * Stable Release (3.0.6) (fabiand, 13:12:31) * Next Release (3.1) (fabiand, 13:12:40) * Other Items (fabiand, 13:12:48) * Action Item Review (fabiand, 13:12:54) * LINK: http://resources.ovirt.org/meetings/ovirt/2014/ovirt.2014-06-17-13.01.txt (fabiand, 13:13:01) * LINK: http://gerrit.ovirt.org/#/c/29085/ (fabiand_, 13:18:40) * A patch to ovirt-node was required to fix some vdsm related bug, this bumps the stable release to 3.0.6 (fabiand_, 13:19:07) * Next Release (3.1) (fabiand, 13:22:20) * apuimedo_ is contributing patches to fix some corner cases of the persistence model (fabiand, 13:25:38) * ACTION: Node team once again to do a review sprint (fabiand, 13:28:42) * Other Items (fabiand, 13:32:03) * First TestDay is on July 1st (fabiand, 13:35:46) Meeting ended at 13:39:12 UTC. Action Items ------------ * Node team once again to do a review sprint Action Items, by person ----------------------- * **UNASSIGNED** * Node team once again to do a review sprint People Present (lines said) --------------------------- * fabiand (53) * fabiand_ (23) * apuimedo_ (12) * rbarry (7) * clarkee (6) * ovirtbot (4) * jboggs (3) * ewoud (1) * jboggs` (1) * bkp (1) * eedri (1) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot

1 0

VDSM faqemu default memory change
by Martin Polednik 24 Jun '14

24 Jun '14

Hello I'm writing in order to propose a change to faqemu hook as indicated in [1], modifying the hook's default behavior: There are currently hardcoded x86_64 and PPC memory limits (20480 and 262144), this change would remove these implicit constraints and keep the memory unchanged. A new variable in configuration is introduced, fake_kvm_memory, which allows you to limit the memory for both these platforms to a value (or using unchanged memory by setting it to 0, which is default). This means that running faqemu without modification would consume up to 10x times memory using default VM memory memory size for x86_64 and unchanged for PPC. [1] http://gerrit.ovirt.org/#/c/28320/

2 2