Re: [ovirt-users] [ANN] oVirt 4.1.0 First Release Candidate is now available

[Yedidyah Bar David]

On Mon, Jan 23, 2017 at 2:35 PM, Sandro Bonazzola  wrote:
> The oVirt Project is pleased to announce the availability of the First
> Release candidate of oVirt 4.1.0 for testing, as of January 23rd, 2016
>
> This is pre-release software. Please take a look at our community page[1]
> to know how to ask questions and interact with developers and users.
> All issues or bugs should be reported via oVirt Bugzilla[2].
> This pre-release should not to be used in production.
>
> This update is the first release candidate of the 4.1 release series.
> 4.1.0 brings more than 250 enhancements and more than 700 bugfixes,
> including more than 300 high or urgent
> severity fixes, on top of oVirt 4.0 series
> See the release notes [3] for installation / upgrade instructions and a
> list of new features and bugs fixed.
>
>
> This release is available now for:
> * Fedora 24 (tech preview)
> * Red Hat Enterprise Linux 7.3 or later
> * CentOS Linux (or similar) 7.3 or later
>
> This release supports Hypervisor Hosts running:
> * Red Hat Enterprise Linux 7.3 or later
> * CentOS Linux (or similar) 7.3 or later
> * Fedora 24 (tech preview)
> * oVirt Node 4.1
>
> See the release notes draft [3] for installation / upgrade instructions and
> a list of new features and bugs fixed.
>
> Notes:
> - oVirt Live iso is already available[5]
> - oVirt Node NG iso is already available[5]
> - Hosted Engine appliance is already available

An updated Windows Guest Tools ISO is now available as well, from:

http://resources.ovirt.org/pub/ovirt-4.1-pre/iso/oVirt-toolsSetup/4.1-1.fc24/

An RPM package wrapping it is in the 4.1-pre repositories.

Changes compared to the 4.0 version:
- Uninstall fixes
- Correct path to QEMU GA MSI files
- Add Display Version as a postfix to the Display Name
- Add Windows 10 support
- Update to latest virtio-win/vdagent releases
- Install virtio-rng driver

Best,

>
> A release management page including planned schedule is also available[4]
>
>
> Additional Resources:
> * Read more about the oVirt 4.1.0 release
> highlights:http://www.ovirt.org/release/4.1.0/
> * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt
> * Check out the latest project news on the oVirt
> blog:http://www.ovirt.org/blog/
>
> [1] https://www.ovirt.org/community/
> [2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt
> [3] http://www.ovirt.org/release/4.1.0/
> [4]
> http://www.ovirt.org/develop/release-management/releases/4.1/release-management/
> [5] http://resources.ovirt.org/pub/ovirt-4.1-pre/iso/
>
>
> --
> Sandro Bonazzola
> Better technology. Faster innovation. Powered by community collaboration.
> See how it works at redhat.com
>
> ___
> Infra mailing list
> in...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>



-- 
Didi
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Invitation: DeepDive: SPDM shared storage management (infrastructure/... @ Wed Feb 15, 2017 6pm - 7pm (IST) (users@ovirt.org)

[laravot]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20170215T16Z
DTEND:20170215T17Z
DTSTAMP:20170125T061216Z
ORGANIZER;CN=lara...@redhat.com:mailto:lara...@redhat.com
UID:bodk6rducn7cg9vpff24rko...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=lara...@redhat.com;X-NUM-GUESTS=0:mailto:lara...@redhat.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=de...@ovirt.org;X-NUM-GUESTS=0:mailto:de...@ovirt.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=users@ovirt.org;X-NUM-GUESTS=0:mailto:users@ovirt.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=rhevm-qe-dept;X-NUM-GUESTS=0:mailto:rhevm-qe-d...@redhat.com
CREATED:20170125T061214Z
DESCRIPTION:View your event at https://www.google.com/calendar/event?action
 =VIEW&eid=Ym9kazZyZHVjbjdjZzl2cGZmMjRya283YXMgdXNlcnNAb3ZpcnQub3Jn&tok=MTgj
 bGFyYXZvdEByZWRoYXQuY29tNDhhYzg0YjcyYzI2ODRiYmVmNmJiZjAwNjExM2ZlZWU1NWJhNTV
 iOA&ctz=Asia/Jerusalem&hl=en.
LAST-MODIFIED:20170125T061216Z
LOCATION:https://redhat.bluejeans.com/laravot
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:DeepDive: SPDM shared storage management (infrastructure/copy scale
  out/progress reporting)
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] How to resume hosted-engine --vm-start-paused

[Matt .]

I'm trying to resume a pause started HostedEngine but I'm failing and
I see lots of topics about some option --vm-resume being needed.

"virsh resume HostedEngine" asks me for a username which is not set,
so I'm wondering how to get this working.

Thanks!

Matt
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Connect to Hosted-Engine using ----add-console-password --password=

[Matt .]

Oops, I was connecting using Spice and needed VNC. Maybe it's nice to
put this in the output or the help for the console command.

2017-01-25 4:48 GMT+01:00 Matt . :
> I'm figuring out how to connect to the hosted engine using virt-viewer
> on a client, is there any more information about this ? You set the
> console password but then ? on what port do we connect, and I assume
> we connect the normal way for normal VM's Consoles ?
>
> Any info would be nice.
>
> Thanks.
>
> Matt
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Connect to Hosted-Engine using ----add-console-password --password=

[Matt .]

I'm figuring out how to connect to the hosted engine using virt-viewer
on a client, is there any more information about this ? You set the
console password but then ? on what port do we connect, and I assume
we connect the normal way for normal VM's Consoles ?

Any info would be nice.

Thanks.

Matt
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] oVIRT / GlusterFS / Data (HA)

[David Gossage]

On Tue, Jan 24, 2017 at 4:56 PM, Devin Acosta 
wrote:

>
> I have created an oVIRT 4.0.6 Cluster, it has 2 Compute nodes, and 3
> Dedicated Gluster nodes. The Gluster nodes are configured correctly and
> they have the replica set to 3. I'm trying to figure out when I go to
> attach the Data (Master) domain to the oVIRT manager what is the best
> method to do so in the configuration?  I initially set the mount point to
> be like: gluster01-int:/data, then set in the mount options
> "backup-volfile-servers=gluster02-int:/data,gluster03-int:/data", so I
> understand that will choose another host if the 1st one is down but if i
> was to reboot the 1st Gluster node would that provide HA for my Data
> domain?
>

If you are mounting with gluster fuse then gluster itself will take care of
making sure mount is available still if one node goes down.  The
backup-volfile settings are so that if the main host in config, here being
gluster01-int, is down when it initially tries to mount on a host it has 2
other hosts in the cluster it can try to connect to which otherwise it
wouldn't know about until after the intial mount was made and it became
aware of the other nodes.


> I also configured ctdb with a floating-ip address that floats between all
> 3 Gluster nodes, and I am wondering if I should be pointing the mount to
> that VIP? What is the best solution with dealing with Gluster and keeping
> your mount HA?
>

If you use gluster-fuse I don't think that you need the floating IP.  I
think that would be more used if you mounted via nfs.


>
> --
>
> Devin Acosta
> Red Hat Certified Architect, LinuxStack
> 602-354-1220 <(602)%20354-1220> || de...@linuxguru.co
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] oVIRT / GlusterFS / Data (HA)

[Devin Acosta]

I have created an oVIRT 4.0.6 Cluster, it has 2 Compute nodes, and 3
Dedicated Gluster nodes. The Gluster nodes are configured correctly and
they have the replica set to 3. I'm trying to figure out when I go to
attach the Data (Master) domain to the oVIRT manager what is the best
method to do so in the configuration?  I initially set the mount point to
be like: gluster01-int:/data, then set in the mount options
"backup-volfile-servers=gluster02-int:/data,gluster03-int:/data", so I
understand that will choose another host if the 1st one is down but if i
was to reboot the 1st Gluster node would that provide HA for my Data
domain?

I also configured ctdb with a floating-ip address that floats between all 3
Gluster nodes, and I am wondering if I should be pointing the mount to that
VIP? What is the best solution with dealing with Gluster and keeping your
mount HA?

-- 

Devin Acosta
Red Hat Certified Architect, LinuxStack
602-354-1220 || de...@linuxguru.co
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] oVirt installs 3.6 repos for 4.0 compat cluster

[James]

Yep,

This was 100% my fault here sorry. Turns out we add the repo as part of
our bootstrap process and I just missed the line.

Sorry for the confusion!

Cheers,
James

On Tue, 24 Jan 2017, at 06:24 PM, Yedidyah Bar David wrote:
> On Tue, Jan 24, 2017 at 7:00 AM, James  wrote:
> > Hi guys,
> >
> > I'm trying to servers to a new oVirt 4.0 cluster. I've upgraded the
> > engine (not hosted, standalone) to version 4.0.6.3 and run engine-setup
> > and everything seemed to go fine.
> >
> > When reinstalling oVirt on a host after removing it from the 3.6 compat
> > cluster into a 4.0 compat cluster causes issues when reinstalling and
> > setting up the management network for some reason. I haven't been able
> > to track this issue down fully yet.
> >
> > Whats weird is that even when a fresh new host is installed and added to
> > the grid for some reason oVirt installs the repos for oVirt 3.6 on the
> 
> AFAIK nothing in oVirt installs repos. It's up to the admin to add the
> correct repos, usually by installing a suitable ovirt-release*.rpm
> package.
> 
> Please check all of /etc/yum.repos.d before you (re)install such a host.
> 
> > host. I'm sure this is done by oVirt itself since they aren't there
> > before I install the host and we don't manage these outside of that. It
> 
> Can you please verify that somehow? E.g. 'yum search vdsm', 'yum info
> vdsm'?
> 
> Also, which OS are you using?
> 
> > also just stalls at "Activating" the host and I can't do anything with
> > them after that.
> >
> > Shouldn't it be installing version 4.0 for this cluster? I've triple
> > checked its set to version 4.0 compatibility and the data center its in
> > is also set to this level.
> >
> > Unsure what logs I can provide but any help would be greatly
> > appreciated!
> 
> Generally speaking, you should check:
> On engine machine - /var/log/ovirt-engine/* ,
> /var/log/ovirt-engine/host-deploy/*
> On host - /var/log/vdsm/* , during install also /tmp/*
> 
> But first check your repos.
> 
> Best,
> -- 
> Didi
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] 4.0 x 4.1

[Yedidyah Bar David]

On Tue, Jan 24, 2017 at 7:37 PM, Pavel Gashev  wrote:
> Karli,
>
> You’re right. Actually, when I did encounter the bugs in 4.0.5, all of them 
> had been already found and fixed.

Actually, you can do that proactively - if you consider upgrading to
some version, you can search bugzilla for bugs targetted to the next
one, and if any of them look serious, wait.

> No doubt that developers do their hard job well. Unfortunately, due to the 
> holydays there was a two-month gap between releases. 4.0.6-pre had another 
> issue. I personally had to build my own hot-fix oVirt release with all the 
> fixes and without changes under development. I can only guess what other 
> users experienced.

See my earlier reply in this thread about the risks you take by doing that.

That said, if that's what you want, you can also use the 4.0 nightly snapshot:

https://www.ovirt.org/develop/dev-process/install-nightly-snapshot/

Was using this significantly different than what you built yourself?

Best,

>
> -Original Message-
> From: Karli Sjöberg 
> Reply-To: Karli Sjöberg 
> Date: Tuesday 24 January 2017 at 15:24
> To: "fernando.fredi...@upx.com.br" , Pavel 
> Gashev , "users@ovirt.org" 
> Subject: Re: [ovirt-users] 4.0 x 4.1
>
> On Tue, 2017-01-24 at 11:06 +, Pavel Gashev wrote:
>> I'd like to apologize for 'ugly' word. From my own personal
>> experience 4.0.5 had some bugs which spoiled my impression from 4.0.
>> Fortunately most of them are fixed in 4.0.6.
>
> I should really not throwing stone in glass houses here, since we´re
> still running 3.6 (I know, I know), but...
>
> If everyone thought like that, no one would have tested and gotten
> those bugs fixed in 4.0.6 either, see what I´m saying?
>
> So if people hadn´t tested and bug-reported those things, your
> impression of 4.0.6 would probably have been just as bad.
>
> Just my two cents.
>
> /K
>
>>
>> -Original Message-
>> From:  on behalf of Pavel Gashev > s.com>
>> Date: Tuesday 24 January 2017 at 13:38
>> To: Fernando Frediani , "us...@ovirt.or
>> g" 
>> Subject: Re: [ovirt-users] 4.0 x 4.1
>>
>> I started with oVirt 3.6. It became stable since 3.6.7 just when 4.0
>> is released. Also I use 4.0. The previous 4.0.5 was ugly, 4.0.6 can
>> be considered more or less stable, and 4.1 is going to be released
>> soon. Thus, I’d start with 4.0 and upgrade to 4.1 when 4.2 is
>> released.
>>
>> -Original Message-
>> From:  on behalf of Fernando Frediani > ndo.fredi...@upx.com.br>
>> Date: Monday 23 January 2017 at 22:36
>> To: "users@ovirt.org" 
>> Subject: [ovirt-users] 4.0 x 4.1
>>
>> I am deploying a oVirt environment which will not get production
>> data
>> immediately.
>>
>> Obviously I would rather use 4.1 RC due the many changes and fixes
>> present. Later when 4.1 becomes stable then upgrade to it.
>> Does anyone see any problem in doing that way or would it be more
>> advisable to start with 4.0.6 and upgrade to 4.1 stable when time
>> comes ?
>>
>> My concern are the issue people related they had when upgrading from
>> one
>> major version to another in the past.
>>
>> Thanks
>>
>> Fernando
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users



-- 
Didi
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Missing Cloud-Init parameters when creating VM from template in User Portal

[Jan Siml]

Hello,

we are running oVirt Engine in version 4.0.6.3-1. While preparing 
templates I came across the following problem. The virtual machine 
created with the template should be configured via Cloud-Init on initial 
run. The checkbox 'Use Cloud-Init/Sysprep' is ticked and the necessary 
fields for provisioning via Cloud-Init are filled. When viewing/editing 
the template in Administration Portal and User Portal the checkbox is 
still ticked and fields are filled, also when creating a VM via 'VM/ New 
VM' inside Administration Portal. But not when a VM is created via 'VM/ 
New VM' inside User Portal. Checkbox is unticked and when it is 
activated all fields are unfilled.


Is this a bug or a feature? Seems to unrelated to permissions of the 
user who creates the VM, because we can reproduce it even with Super 
User permissions.


Kind regards

Jan
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] 4.0 x 4.1

[Pavel Gashev]

Karli,

You’re right. Actually, when I did encounter the bugs in 4.0.5, all of them had 
been already found and fixed. No doubt that developers do their hard job well. 
Unfortunately, due to the holydays there was a two-month gap between releases. 
4.0.6-pre had another issue. I personally had to build my own hot-fix oVirt 
release with all the fixes and without changes under development. I can only 
guess what other users experienced.

-Original Message-
From: Karli Sjöberg 
Reply-To: Karli Sjöberg 
Date: Tuesday 24 January 2017 at 15:24
To: "fernando.fredi...@upx.com.br" , Pavel Gashev 
, "users@ovirt.org" 
Subject: Re: [ovirt-users] 4.0 x 4.1

On Tue, 2017-01-24 at 11:06 +, Pavel Gashev wrote:
> I'd like to apologize for 'ugly' word. From my own personal
> experience 4.0.5 had some bugs which spoiled my impression from 4.0.
> Fortunately most of them are fixed in 4.0.6. 

I should really not throwing stone in glass houses here, since we´re
still running 3.6 (I know, I know), but...

If everyone thought like that, no one would have tested and gotten
those bugs fixed in 4.0.6 either, see what I´m saying?

So if people hadn´t tested and bug-reported those things, your
impression of 4.0.6 would probably have been just as bad.

Just my two cents.

/K

> 
> -Original Message-
> From:  on behalf of Pavel Gashev  s.com>
> Date: Tuesday 24 January 2017 at 13:38
> To: Fernando Frediani , "us...@ovirt.or
> g" 
> Subject: Re: [ovirt-users] 4.0 x 4.1
> 
> I started with oVirt 3.6. It became stable since 3.6.7 just when 4.0
> is released. Also I use 4.0. The previous 4.0.5 was ugly, 4.0.6 can
> be considered more or less stable, and 4.1 is going to be released
> soon. Thus, I’d start with 4.0 and upgrade to 4.1 when 4.2 is
> released.
> 
> -Original Message-
> From:  on behalf of Fernando Frediani  ndo.fredi...@upx.com.br>
> Date: Monday 23 January 2017 at 22:36
> To: "users@ovirt.org" 
> Subject: [ovirt-users] 4.0 x 4.1
> 
> I am deploying a oVirt environment which will not get production
> data 
> immediately.
> 
> Obviously I would rather use 4.1 RC due the many changes and fixes 
> present. Later when 4.1 becomes stable then upgrade to it.
> Does anyone see any problem in doing that way or would it be more 
> advisable to start with 4.0.6 and upgrade to 4.1 stable when time
> comes ?
> 
> My concern are the issue people related they had when upgrading from
> one 
> major version to another in the past.
> 
> Thanks
> 
> Fernando
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Updated Invitation: Next-generation Node package persistence for oVirt 4.1 @ Thu Jan 26, 2017 9am - 10am (MST) (users@ovirt.org)

[rbarry]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20170126T16Z
DTEND:20170126T17Z
DTSTAMP:20170124T154401Z
ORGANIZER;CN=rba...@redhat.com:mailto:rba...@redhat.com
UID:uleimk2b40rrlvl9o222p75...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=users@ovirt.org;X-NUM-GUESTS=0:mailto:users@ovirt.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=de...@ovirt.org;X-NUM-GUESTS=0:mailto:de...@ovirt.org
CREATED:20170117T201117Z
DESCRIPTION:oVirt Node is a composed hypervisor image which can be used to 
 provision virtualization hosts for use with oVirt out of the box\, with no 
 additional package installation necessary.\n\noVirt Node is upgraded via yu
 m in an A/B fashion\, but the installation of a completely new image means 
 that packages which have been installed on a previous version of the hyperv
 isor were lost on upgrades\, or required reinstallation.\n\nWith oVIrt 4.1\
 , oVirt Node will cache and reinstall packages installed with yum or dnf on
 to the new image\, ensuring that customizations made by users or administra
 tors are kept.\n\nThe advantages of keeping packages across upgrades:\n- ab
 ility to persistently modify oVirt Node with additions for tooling or suppo
 rt\n- removes the need to build a brand-new image with a modified kickstart
  to modify oVirt Node\n- simplified management\n\nSession outline:\n- Next-
 generation oVirt Node overview\n- yum API overview\n- oVIrt Node integratio
 n with yum/dnf to persist RPMs across upgrades\n\nSession link:\nhttps://ww
 w.youtube.com/watch?v=VAznsxvZpuk\n\nFeature Page:\nhttps://www.ovirt.org/d
 evelop/release-management/features/node/node-next-persistence\nView your ev
 ent at https://www.google.com/calendar/event?action=VIEW&eid=dWxlaW1rMmI0MH
 JybHZsOW8yMjJwNzVvODQgdXNlcnNAb3ZpcnQub3Jn&tok=MTcjcmJhcnJ5QHJlZGhhdC5jb201
 N2MwMGE3ODhhMTAyZjFjYWY2NjQ5YWEyYzMzYTQyZjA3MTBmNzdl&ctz=America/Phoenix&hl
 =en.
LAST-MODIFIED:20170124T154401Z
LOCATION:https://www.youtube.com/watch?v=tpAVkBEDdVg
SEQUENCE:2
STATUS:CONFIRMED
SUMMARY:Next-generation Node package persistence for oVirt 4.1
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Updated Invitation: Next-generation Node package persistence for oVirt 4.1 @ Thu Jan 26, 2017 8am - 9am (MST) (users@ovirt.org)

[rbarry]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20170126T15Z
DTEND:20170126T16Z
DTSTAMP:20170124T151831Z
ORGANIZER;CN=rba...@redhat.com:mailto:rba...@redhat.com
UID:uleimk2b40rrlvl9o222p75...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=users@ovirt.org;X-NUM-GUESTS=0:mailto:users@ovirt.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=de...@ovirt.org;X-NUM-GUESTS=0:mailto:de...@ovirt.org
CREATED:20170117T201117Z
DESCRIPTION:oVirt Node is a composed hypervisor image which can be used to 
 provision virtualization hosts for use with oVirt out of the box\, with no 
 additional package installation necessary.\n\noVirt Node is upgraded via yu
 m in an A/B fashion\, but the installation of a completely new image means 
 that packages which have been installed on a previous version of the hyperv
 isor were lost on upgrades\, or required reinstallation.\n\nWith oVIrt 4.1\
 , oVirt Node will cache and reinstall packages installed with yum or dnf on
 to the new image\, ensuring that customizations made by users or administra
 tors are kept.\n\nThe advantages of keeping packages across upgrades:\n- ab
 ility to persistently modify oVirt Node with additions for tooling or suppo
 rt\n- removes the need to build a brand-new image with a modified kickstart
  to modify oVirt Node\n- simplified management\n\nSession outline:\n- Next-
 generation oVirt Node overview\n- yum API overview\n- oVIrt Node integratio
 n with yum/dnf to persist RPMs across upgrades\n\nSession link:\nhttps://ww
 w.youtube.com/watch?v=VAznsxvZpuk\n\nFeature Page:\nhttps://www.ovirt.org/d
 evelop/release-management/features/node/node-next-persistence\nView your ev
 ent at https://www.google.com/calendar/event?action=VIEW&eid=dWxlaW1rMmI0MH
 JybHZsOW8yMjJwNzVvODQgdXNlcnNAb3ZpcnQub3Jn&tok=MTcjcmJhcnJ5QHJlZGhhdC5jb201
 N2MwMGE3ODhhMTAyZjFjYWY2NjQ5YWEyYzMzYTQyZjA3MTBmNzdl&ctz=America/Phoenix&hl
 =en.
LAST-MODIFIED:20170124T151831Z
LOCATION:https://www.youtube.com/watch?v=tpAVkBEDdVg
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:Next-generation Node package persistence for oVirt 4.1
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [ovirt-devel] Invitation: Next-generation Node package persistence for oVirt 4.1 @ Tue Jan 24, 2017 8am - 9am (MST) (de...@ovirt.org)

[Ryan Barry]

Sorry everyone -- accidentally created this with the wrong account, and I
can't start the stream (thanks Youtube).

I'll reschedule for Thursday. New invite to follow

On Thu, Jan 19, 2017 at 6:21 AM,  wrote:

> more details »
> 
> Next-generation Node package persistence for oVirt 4.1
> oVirt Node is a composed hypervisor image which can be used to provision
> virtualization hosts for use with oVirt out of the box, with no additional
> package installation necessary.
>
> oVirt Node is upgraded via yum in an A/B fashion, but the installation of
> a completely new image means that packages which have been installed on a
> previous version of the hypervisor were lost on upgrades, or required
> reinstallation.
>
> With oVIrt 4.1, oVirt Node will cache and reinstall packages installed
> with yum or dnf onto the new image, ensuring that customizations made by
> users or administrators are kept.
>
> The advantages of keeping packages across upgrades:
> - ability to persistently modify oVirt Node with additions for tooling or
> support
> - removes the need to build a brand-new image with a modified kickstart to
> modify oVirt Node
> - simplified management
>
> Session outline:
> - Next-generation oVirt Node overview
> - yum API overview
> - oVIrt Node integration with yum/dnf to persist RPMs across upgrades
>
> Session link:
> https://www.youtube.com/watch?v=VAznsxvZpuk
>
> Feature Page:
> https://www.ovirt.org/develop/release-management/features/
> node/node-next-persistence
> 
>
> *When*
> Tue Jan 24, 2017 8am – 9am Mountain Time - Arizona
>
> *Where*
> https://www.youtube.com/watch?v=VAznsxvZpuk (map
> 
> )
>
> *Calendar*
> de...@ovirt.org
>
> *Who*
> •
> rba...@redhat.com - organizer
> •
> users@ovirt.org
> •
> de...@ovirt.org
>
> Going?   *Yes
> 
> - Maybe
> 
> - No
> *
> more options »
> 
>
> Invitation from Google Calendar 
>
> You are receiving this courtesy email at the account de...@ovirt.org
> because you are an attendee of this event.
>
> To stop receiving future updates for this event, decline this event.
> Alternatively you can sign up for a Google account at
> https://www.google.com/calendar/ and control your notification settings
> for your entire calendar.
>
> Forwarding this invitation could allow any recipient to modify your RSVP
> response. Learn More
> .
>
> ___
> Devel mailing list
> de...@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Antwort: Re: get UI working throug ALIAS and real hostname

[emanuel . santosvarina]

GREAT! THANKS a lot ..



Von:Juan Hernández 
An: emanuel.santosvar...@mahle.com, users@ovirt.org, 
Datum:  24.01.2017 15:41
Betreff:Re: [ovirt-users] get UI working throug ALIAS and real 
hostname



On 01/24/2017 03:15 PM, emanuel.santosvar...@mahle.com wrote:
> If I access the UI via "ALIAS" I get the Error-Page "The client is not
> authorized to request an authorization. It's required to access the
> system using FQDN.
> 
> What can I do to get UI working through ALIAS and real hostname?
> 
> Thx,
> Emanuel
> 

Create a 99-whatever-you-like.conf file in
/etc/ovirt-engine/engine.conf.d with the following content:

  SSO_ALTERNATE_ENGINE_FQDNS="thealias"

Then restart the engine:

  systemctl restart ovirt-engine

This setting is documented here:


https://github.com/oVirt/ovirt-engine/blob/master/packaging/services/ovirt-engine/ovirt-engine.conf.in#L363-L366



___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] get UI working throug ALIAS and real hostname

[Doug Ingham]

On 24 January 2017 at 15:15, emanuel.santosvar...@mahle.com wrote:

> If I access the UI via "ALIAS" I get the Error-Page "The client is not
> authorized to request an authorization. It's required to access the system
> using FQDN.
>
> What can I do to get UI working through ALIAS and real hostname?
>

The Hosted-Engine should be installed & configured with the correct FQDN to
begin with. Changing it post install is currently unsupported & can cause a
whole host of problems. There are a couple of documented cases where people
have attempted to do so with varying success, but non have come out problem
free.

I'm currently in the same situation after a company domain change and have
decided that the risk of unforeseen issues & potential problems down the
line, are far greater than the pain of redeploying & migrating to a new
environment.

A really hacky hack, without interfering with the engine, would be to try &
put a reverse proxy in front, but that'll require a load of dynamic
rewriting filters to work.


On 24 January 2017 at 11:41, Juan Hernández  wrote:

> Create a 99-whatever-you-like.conf file in
> /etc/ovirt-engine/engine.conf.d with the following content:
>
>   SSO_ALTERNATE_ENGINE_FQDNS="thealias"
>
> Then restart the engine:
>
>   systemctl restart ovirt-engine
>
> This setting is documented here:
>
>
> https://github.com/oVirt/ovirt-engine/blob/master/
> packaging/services/ovirt-engine/ovirt-engine.conf.in#L363-L366
>

AFAIK, the SSL certificates will still need updating & I've read of people
still having other issues due to differing FQDNs. Being able to update the
HE's FQDN would be of big interest to me, but I've not yet seen one case
where it didn't end with anomalies...


-- 
Doug
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] get UI working throug ALIAS and real hostname

[Juan Hernández]

On 01/24/2017 03:49 PM, Doug Ingham wrote:
> On 24 January 2017 at 15:15, emanuel.santosvar...@mahle.com
>  wrote:
> 
> If I access the UI via "ALIAS" I get the Error-Page "The client is
> not authorized to request an authorization. It's required to access
> the system using FQDN.
> 
> What can I do to get UI working through ALIAS and real hostname?
> 
> 
> The Hosted-Engine should be installed & configured with the correct FQDN
> to begin with. Changing it post install is currently unsupported & can
> cause a whole host of problems. There are a couple of documented cases
> where people have attempted to do so with varying success, but non have
> come out problem free.
> 
> I'm currently in the same situation after a company domain change and
> have decided that the risk of unforeseen issues & potential problems
> down the line, are far greater than the pain of redeploying & migrating
> to a new environment.
> 
> A really hacky hack, without interfering with the engine, would be to
> try & put a reverse proxy in front, but that'll require a load of
> dynamic rewriting filters to work.
> 
> 
> On 24 January 2017 at 11:41, Juan Hernández  > wrote:
> 
> Create a 99-whatever-you-like.conf file in
> /etc/ovirt-engine/engine.conf.d with the following content:
> 
>   SSO_ALTERNATE_ENGINE_FQDNS="thealias"
> 
> Then restart the engine:
> 
>   systemctl restart ovirt-engine
> 
> This setting is documented here:
> 
> 
> 
> https://github.com/oVirt/ovirt-engine/blob/master/packaging/services/ovirt-engine/ovirt-engine.conf.in#L363-L366
> 
> 
> 
> 
> AFAIK, the SSL certificates will still need updating & I've read of
> people still having other issues due to differing FQDNs. Being able to
> update the HE's FQDN would be of big interest to me, but I've not yet
> seen one case where it didn't end with anomalies...
> 

Correct, if the FQDN of the engine changes it is a completely different
story. But in this case my understanding is that the objective is
accessing the engine using an alternative name, probably a DNS CNAME. In
that case changing the configuration as proposed should work.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] get UI working throug ALIAS and real hostname

[Juan Hernández]

On 01/24/2017 03:15 PM, emanuel.santosvar...@mahle.com wrote:
> If I access the UI via "ALIAS" I get the Error-Page "The client is not
> authorized to request an authorization. It's required to access the
> system using FQDN.
> 
> What can I do to get UI working through ALIAS and real hostname?
> 
> Thx,
> Emanuel
> 

Create a 99-whatever-you-like.conf file in
/etc/ovirt-engine/engine.conf.d with the following content:

  SSO_ALTERNATE_ENGINE_FQDNS="thealias"

Then restart the engine:

  systemctl restart ovirt-engine

This setting is documented here:


https://github.com/oVirt/ovirt-engine/blob/master/packaging/services/ovirt-engine/ovirt-engine.conf.in#L363-L366

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Problems upgrading ovirt from 3.5.6 to 3.6.7

[gflwqs gflwqs]

Hi list!
We have a problem upgrading hosted engine nodes (hypervisors) from 3.5.6 to
3.6.7 we get these errors:

from agent.log:
MainThread::ERROR::2017-01-24
15:17:58,981::upgrade::207::ovirt_hosted_engine_ha.lib.upgrade.StorageServer::(_is_conf_volume_there)
Unable to find HE conf volume
MainThread::INFO::2017-01-24
15:17:58,981::upgrade::262::ovirt_hosted_engine_ha.lib.upgrade.StorageServer::(_create_shared_conf_volume)
Creating hosted-engine configuration volume on the shared storage domain
MainThread::DEBUG::2017-01-24
15:17:59,079::heconflib::358::ovirt_hosted_engine_ha.lib.upgrade.StorageServer::(create_and_prepare_image)
{'status': {'message': 'OK', 'code': 0}, 'uuid':
'df95e3fd-3715-4525-8955-abcc8cb24865'}
MainThread::DEBUG::2017-01-24
15:17:59,080::heconflib::372::ovirt_hosted_engine_ha.lib.upgrade.StorageServer::(create_and_prepare_image)
Created configuration volume OK, request was:
- image: e4d09ccf-5d9b-4f90-9eda-1ebd4f55ecbc
- volume: 9636163f-d634-4c28-b2bc-f84b5a90a17e
MainThread::DEBUG::2017-01-24
15:17:59,080::heconflib::283::ovirt_hosted_engine_ha.lib.upgrade.StorageServer::(task_wait)
Waiting for existing tasks to complete
MainThread::DEBUG::2017-01-24
15:18:00,137::heconflib::283::ovirt_hosted_engine_ha.lib.upgrade.StorageServer::(task_wait)
Waiting for existing tasks to complete
MainThread::DEBUG::2017-01-24
15:18:00,278::heconflib::379::ovirt_hosted_engine_ha.lib.upgrade.StorageServer::(create_and_prepare_image)
configuration volume: prepareImage
MainThread::DEBUG::2017-01-24
15:18:00,350::heconflib::387::ovirt_hosted_engine_ha.lib.upgrade.StorageServer::(create_and_prepare_image)
{'status': {'message': "Volume does not exist:
('9636163f-d634-4c28-b2bc-f84b5a90a17e',)", 'code': 201}

from vdsm.log:
df95e3fd-3715-4525-8955-abcc8cb24865::DEBUG::2017-01-24
15:17:59,187::task::752::Storage.TaskManager.Task::(_save)
Task=`df95e3fd-3715-4525-8955-abcc8cb24865`::_save: orig
/rhev/data-center/c202d58c-afc7-4848-8501-228d9bccb15d/mastersd/master/tasks/df95e3fd-3715-4525-8955-

abcc8cb24865 temp
/rhev/data-center/c202d58c-afc7-4848-8501-228d9bccb15d/mastersd/master/tasks/df95e3fd-3715-4525-8955-abcc8cb24865.temp

df95e3fd-3715-4525-8955-abcc8cb24865::DEBUG::2017-01-24
15:17:59,201::task::752::Storage.TaskManager.Task::(_save)
Task=`df95e3fd-3715-4525-8955-abcc8cb24865`::_save: orig
/rhev/data-center/c202d58c-afc7-4848-8501-228d9bccb15d/mastersd/master/tasks/df95e3fd-3715-4525-8955-

abcc8cb24865 temp
/rhev/data-center/c202d58c-afc7-4848-8501-228d9bccb15d/mastersd/master/tasks/df95e3fd-3715-4525-8955-abcc8cb24865.temp

df95e3fd-3715-4525-8955-abcc8cb24865::DEBUG::2017-01-24
15:17:59,217::lvm::290::Storage.Misc.excCmd::(cmd) /usr/bin/taskset
--cpu-list 0-79 /usr/bin/sudo -n /usr/sbin/lvm lvcreate --config ' devices
{ preferred_names = ["^*/dev/mapper/*"] ignore_suspended_devices=1
write_cac
he_state=0 disable_after_error_count=3 filter = [
'\''a|/dev/mapper/2347b42194dacd3656c9ce900aea3dee2|'\'', '\''r|.*|'\'' ]
}  global {  locking_type=1 prioritise_write_locks=1  wait_for_locks=1
use_lvmetad=0 }  backup {  retain_min = 50  retain_days = 0 } '
--autobackup
 n --contiguous n --size 1024m --addtag OVIRT_VOL_INITIALIZING --name
9636163f-d634-4c28-b2bc-f84b5a90a17e 8fa5a242-fcb4-454d-aaa1-23f8dd92373b
(cwd None)
Thread-28556::DEBUG::2017-01-24 15:17:59,289::utils::671::root::(execCmd)
/usr/bin/taskset --cpu-list 0-79 /usr/sbin/tc qdisc show (cwd None)
df95e3fd-3715-4525-8955-abcc8cb24865::DEBUG::2017-01-24
15:17:59,301::lvm::290::Storage.Misc.excCmd::(cmd) FAILED:  = '
WARNING: Not using lvmetad because config setting use_lvmetad=0.\n
WARNING: To avoid corruption, rescan devices to make changes visible
(pvscan --
cache).\n  Volume group "8fa5a242-fcb4-454d-aaa1-23f8dd92373b" has
insufficient free space (4 extents): 8 required.\n';  = 5
df95e3fd-3715-4525-8955-abcc8cb24865::ERROR::2017-01-24
15:17:59,303::volume::485::Storage.Volume::(create) Failed to create volume
/rhev/data-center/c202d58c-afc7-4848-8501-228d9bccb15d/8fa5a242-fcb4-454d-aaa1-23f8dd92373b/images/e4d09ccf-5d9b-4f90-9eda-1ebd4f55ecbc/96361

63f-d634-4c28-b2bc-f84b5a90a17e: Cannot create Logical Volume:
('8fa5a242-fcb4-454d-aaa1-23f8dd92373b',
'9636163f-d634-4c28-b2bc-f84b5a90a17e')
df95e3fd-3715-4525-8955-abcc8cb24865::ERROR::2017-01-24
15:17:59,304::volume::521::Storage.Volume::(create) Unexpected error
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/volume.py", line 482, in create
initialSize=initialSize)
  File "/usr/share/vdsm/storage/blockVolume.py", line 133, in _create
initialTag=TAG_VOL_UNINIT)
  File "/usr/share/vdsm/storage/lvm.py", line 1096, in createLV
raise se.CannotCreateLogicalVolume(vgName, lvName)
CannotCreateLogicalVolume: Cannot create Logical Volume:
('8fa5a242-fcb4-454d-aaa1-23f8dd92373b',
'9636163f-d634-4c28-b2bc-f84b5a90a17e')
df95e3fd-3715-4525-8955-abcc8cb24865::DEBUG::2017-01-24
15:17:59,304::resourceManager::619::Storage.ResourceManager::(releaseResource)
Trying to release 

[ovirt-users] get UI working throug ALIAS and real hostname

[emanuel . santosvarina]

If I access the UI via "ALIAS" I get the Error-Page "The client is not 
authorized to request an authorization. It's required to access the system 
using FQDN.

What can I do to get UI working through ALIAS and real hostname?

Thx,
Emanuel___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] [ANN] oVirt 4.0.6 is the last 4.0 release

[Sandro Bonazzola]

Hi,
with the coming oVirt 4.1.0 GA release scheduled to be released on February
1st,
oVirt 4.0.6 is the last officially released version in 4.0 cycle.
If any critical issue will be reported upgrading to 4.1 which will require
a fix in 4.0.6, a fix will be released.

Please note that any bug reported as fixed in bugzilla against 4.0.7 has
been also fixed in 4.1.0.

on behalf of the oVirt team,
-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] 4.0 x 4.1

[Yedidyah Bar David]

On Tue, Jan 24, 2017 at 3:15 PM, Fernando Frediani
 wrote:
> Sounds reasonable.
>
> Out of curiosity what people use or do in order to rollback a failed upgrade

Usually engine-setup rolls back fine if it fails after it started
changing the system.

You can also backup the engine using engine-backup. If you then want
to downgrade,
you can use 'yum history' to undo the relevant transactions, then restore your
backup.

> or an upgrade that can bring instability in the control or operation of the
> cluster ? In VMware as vCenter used to run within a Virtual Machine I used
> to take a snapshot before starting the upgrade.
>
> In oVirt if I have my Engine running in a simple VM somewhere else out of
> the cluster as well I guess that could also be an option.

Indeed. You can use e.g. virt-manager or virsh for that.

You can even use a VM managed by another ovirt engine. I think that's
actually quite common.

> What about when it
> is a self hosted engine. Would it work ?

IIRC this was discussed recently, and the bottom line was that this does not
work currently. I don't remember the details, perhaps you can search the
list archives.

>
> Thanks
>
> Fernando
>
>
>
> On 24/01/2017 05:03, Yedidyah Bar David wrote:
>>
>> On Mon, Jan 23, 2017 at 9:36 PM, Fernando Frediani
>>  wrote:
>>>
>>> I am deploying a oVirt environment which will not get production data
>>> immediately.
>>>
>>> Obviously I would rather use 4.1 RC due the many changes and fixes
>>> present.
>>> Later when 4.1 becomes stable then upgrade to it.
>>> Does anyone see any problem in doing that way or would it be more
>>> advisable
>>> to start with 4.0.6 and upgrade to 4.1 stable when time comes ?
>>
>> If eventually it will be production, I'd start with 4.0.6.
>>
>> Generally speaking, if we find in the future a bug when upgrading from
>> 4.0.6 to 4.1.z, we'll try to solve it, so that it does not affect an
>> upgrade from 4.0.6 to 4.1.z+1. But if we find a bug that affects only
>> upgrade from a rc/beta/etc. version to a stable version, we might decide
>> it's not worth fixing.
>>
>> Also note that 4.1.0 should be out really soon:
>>
>>
>> https://www.ovirt.org/develop/release-management/releases/4.1/release-management/
>>
>> So you might as well simply wait a bit.
>>
>>> My concern are the issue people related they had when upgrading from one
>>> major version to another in the past.
>>
>> In general, or to/from beta/rc/etc versions?
>>
>> In general we appreciate very much people testing upgrades from/to beta/rc
>> versions, and if they find bugs, we do try to fix them. But people should
>> do this in test environments, not ones that are eventually destined to
>> become
>> production.
>>
>> Best,
>
>



-- 
Didi
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] 4.0 x 4.1

[Fernando Frediani]

Sounds reasonable.

Out of curiosity what people use or do in order to rollback a failed 
upgrade or an upgrade that can bring instability in the control or 
operation of the cluster ? In VMware as vCenter used to run within a 
Virtual Machine I used to take a snapshot before starting the upgrade.


In oVirt if I have my Engine running in a simple VM somewhere else out 
of the cluster as well I guess that could also be an option. What about 
when it is a self hosted engine. Would it work ?


Thanks

Fernando


On 24/01/2017 05:03, Yedidyah Bar David wrote:

On Mon, Jan 23, 2017 at 9:36 PM, Fernando Frediani
 wrote:

I am deploying a oVirt environment which will not get production data
immediately.

Obviously I would rather use 4.1 RC due the many changes and fixes present.
Later when 4.1 becomes stable then upgrade to it.
Does anyone see any problem in doing that way or would it be more advisable
to start with 4.0.6 and upgrade to 4.1 stable when time comes ?

If eventually it will be production, I'd start with 4.0.6.

Generally speaking, if we find in the future a bug when upgrading from
4.0.6 to 4.1.z, we'll try to solve it, so that it does not affect an
upgrade from 4.0.6 to 4.1.z+1. But if we find a bug that affects only
upgrade from a rc/beta/etc. version to a stable version, we might decide
it's not worth fixing.

Also note that 4.1.0 should be out really soon:

https://www.ovirt.org/develop/release-management/releases/4.1/release-management/

So you might as well simply wait a bit.


My concern are the issue people related they had when upgrading from one
major version to another in the past.

In general, or to/from beta/rc/etc versions?

In general we appreciate very much people testing upgrades from/to beta/rc
versions, and if they find bugs, we do try to fix them. But people should
do this in test environments, not ones that are eventually destined to become
production.

Best,


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Restoring Hosted-Engine from a stale backup

[Simone Tiraboschi]

On Tue, Jan 24, 2017 at 1:49 PM, Doug Ingham  wrote:

> Hey guys,
>  Just giving this a bump in the hope that someone might be able to
> advise...
>
> Hi all,
>>  One of our engines has had a DB failure* & it seems there was an
>> unnoticed problem in its backup routine, meaning the last backup I've got
>> is a couple of weeks old.
>> Luckily, VDSM has kept the underlying VMs running without any
>> interruptions, so my objective is to get the HE back online & get the hosts
>> & VMs back under its control with minimal downtime.
>>
>> So, my questions are the following...
>>
>>1. What problems can I expect to have with VMs added/modified since
>>the last backup?
>>
>> Modified VMs will be reverted to the previous configuration; additional
VMs should be seen as external VMs, then you could import.


>
>>1. As it's only the DB that's been affected, can I skip redeploying
>>the Engine & jump straight to restoring the DB & rerunning engine-setup?
>>
>>
Yes, if the engine VM is fine, you could just import the previous backup
and run engine-setup again.
Please set the global maintenance mode for hosted-engine since
engine-backup and engine-setup are going to bring down the engine.

>
>>1. The original docs I read didn't mention that it's best to leave a
>>host in maintenance mode before running the engine backup, so my plan is 
>> to
>>install a new temporary host on a separate server, re-add the old hosts &
>>then once everything's back up, remove the temporary host. Are there any
>>faults in this plan?
>>2. When it comes to deleting the old HE VM, the docs point to a
>>paywalled guide on redhat.com...?
>>
>>  To add a bit more info to 4), I'm referring to the following...
>
> Note: If the Engine database is restored successfully, but the Engine
>> virtual machine appears to be Down and cannot be migrated to another
>> self-hosted engine host, you can enable a new Engine virtual machine and
>> remove the dead Engine virtual machine from the environment by following
>> the steps provided in https://access.redhat.com/solutions/1517683.
>>
> Source: http://www.ovirt.org/documentation/self-hosted/
> chap-Backing_up_and_Restoring_an_EL-Based_Self-Hosted_Environment/
>
>
If you are re-importing the backup in place on the initial engine VM you
don't have to.
The point is just if you are migrating to a new engine VM and so you have
to remove the entry of the previous one to let the auto-import process
trigger again.


> CentOS 7
>> oVirt 4.0.4
>> Gluster 3.8
>>
>> * Apparently a write somehow cleared fsync, despite not actually having
>> been written to disk?! No idea how that happened...
>>
>> Many thanks,
>> --
>> Doug
>>
>
> Cheers,
> --
> Doug
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Restoring Hosted-Engine from a stale backup

[Doug Ingham]

Hey guys,
 Just giving this a bump in the hope that someone might be able to advise...

Hi all,
>  One of our engines has had a DB failure* & it seems there was an
> unnoticed problem in its backup routine, meaning the last backup I've got
> is a couple of weeks old.
> Luckily, VDSM has kept the underlying VMs running without any
> interruptions, so my objective is to get the HE back online & get the hosts
> & VMs back under its control with minimal downtime.
>
> So, my questions are the following...
>
>1. What problems can I expect to have with VMs added/modified since
>the last backup?
>2. As it's only the DB that's been affected, can I skip redeploying
>the Engine & jump straight to restoring the DB & rerunning engine-setup?
>3. The original docs I read didn't mention that it's best to leave a
>host in maintenance mode before running the engine backup, so my plan is to
>install a new temporary host on a separate server, re-add the old hosts &
>then once everything's back up, remove the temporary host. Are there any
>faults in this plan?
>4. When it comes to deleting the old HE VM, the docs point to a
>paywalled guide on redhat.com...?
>
>  To add a bit more info to 4), I'm referring to the following...

Note: If the Engine database is restored successfully, but the Engine
> virtual machine appears to be Down and cannot be migrated to another
> self-hosted engine host, you can enable a new Engine virtual machine and
> remove the dead Engine virtual machine from the environment by following
> the steps provided in https://access.redhat.com/solutions/1517683.
>
Source:
http://www.ovirt.org/documentation/self-hosted/chap-Backing_up_and_Restoring_an_EL-Based_Self-Hosted_Environment/

CentOS 7
> oVirt 4.0.4
> Gluster 3.8
>
> * Apparently a write somehow cleared fsync, despite not actually having
> been written to disk?! No idea how that happened...
>
> Many thanks,
> --
> Doug
>

Cheers,
-- 
Doug
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [PySDK v3] Choose storage domain

[Juan Hernández]

On 01/24/2017 01:18 PM, Nicolas Ecarnot wrote:
> Juan,
> 
> Thank you very much for your help, this is working.
> 
> Some comments below.
> 
> Le 24/01/2017 à 11:04, Juan Hernández a écrit :
>> In order to do that you need to specify that you want to clone the disks
>> of the template, and for each disk you need to specify the storage
>> domain where you want to create it.
> 
> This is what I feared, and it was not really obvious at first sight (to
> prepare a disks list...).
> I think I saw it was less weird in V4.
> 
>> [...]
> 
>> Also, please be careful when specifying the cluster and the template.
>> You are currently doing this:
>>
>>   cluster=vm_cluster,
>>   template=vm_template,
>>
>> Not sure how you are assigning the values to those 'vm_cluster' and
>> 'vm_template' variables, but you are probably doing this:
>>
>>   vm_cluster = api.vms.get(name='mycluster')
>>   vm_template = api.vms.get(name='mytemplate')
> 
> Here is what I was doing (please don't laugh) :
> 
> c_list = api.clusters.list()
> # At present (2017), each datacenter contains only one cluster
> vm_cluster = c_list[0]
> 
> vm_template = api.templates.get(name=template_name)
> 
>> That combination isn't ideal, because you will be sending with the 'add'
>> request the complete representation of the cluster and the template,
>> when the server only needs the id or the name. Consider doing this
>> instead:
>>
>>   cluster=params.Cluster(
>> id=vm_cluster.get_id()
>>   ),
>>   template=params.Cluster(
>> id=vm_template.get_id()
>>   ),
> 
> Is it right to say that this last method is only valid in the api
> context, and would not work outside of the api object scope?
> I mean : if I want to use your method, I can no longer separate the
> preparation of a vm_params object before calling the vms.add, right?
> 
> 
> 
> 
> OK, just one second before sending this e-mail, I made a quick test with
> the template object and it is working anyway.
> Does it mean nothing is instantiated before the api.vms.add call?
> 

The concern is not about preparing the objects before calling vms.add,
that is perfectly OK. The concern is what that prepared object contains.
With the code you are using currently you will be sending to the server
the complete representation of the cluster and the template. Run debug
on, with the "debug=True" parameter of the API constructor, and you will
see it, you will be sending a request like this:

  POST /ovirt-engine/api/vms

With a request body like this:

  

  mycluster
  My cluster
  ...
  ...
  


  

...
  

All those cluster and template attributes aren't needed, the server will
just ignore them, because it only needs the name (or id):

  

  mycluster


  mytemplate

...
  

So it is a waste of resources, and in some cases it may trigger hidden bugs.

If you still want to prepare the variables before calling the vms.add
method, just build their values so that they contain only the values (in
this case is better to use the id instead of the name, as it is more
specific):

  vm_template=api.templates.get(name=template_name)
  vm_template=params.Template(
id=vm_template.get_id()
  )

This isn't very convenient if you want to use other attributes of the
'vm_template' object later. That is why my recommendation is to create
this temporary 'params.Template' object within the call to the 'vms.add'
method:

  vms.add(
vm=params.Vm(
  template=params.Template(
id=vm_template.get_id()
  ),
  ...
)
  )

Just consider this as a good practice.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [PySDK v3] Choose storage domain

[Nicolas Ecarnot]

Le 24/01/2017 à 13:18, Nicolas Ecarnot a écrit :

OK, just one second before sending this e-mail, I made a quick test with
the template object and it is working anyway.


Sorry for the noise, but...
No, actually, it wasn't working. I need to start from the api object to 
reach the actual disks.


--
Nicolas ECARNOT
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] 4.0 x 4.1

[Karli Sjöberg]

On Tue, 2017-01-24 at 11:06 +, Pavel Gashev wrote:
> I'd like to apologize for 'ugly' word. From my own personal
> experience 4.0.5 had some bugs which spoiled my impression from 4.0.
> Fortunately most of them are fixed in 4.0.6. 

I should really not throwing stone in glass houses here, since we´re
still running 3.6 (I know, I know), but...

If everyone thought like that, no one would have tested and gotten
those bugs fixed in 4.0.6 either, see what I´m saying?

So if people hadn´t tested and bug-reported those things, your
impression of 4.0.6 would probably have been just as bad.

Just my two cents.

/K

> 
> -Original Message-
> From:  on behalf of Pavel Gashev  s.com>
> Date: Tuesday 24 January 2017 at 13:38
> To: Fernando Frediani , "us...@ovirt.or
> g" 
> Subject: Re: [ovirt-users] 4.0 x 4.1
> 
> I started with oVirt 3.6. It became stable since 3.6.7 just when 4.0
> is released. Also I use 4.0. The previous 4.0.5 was ugly, 4.0.6 can
> be considered more or less stable, and 4.1 is going to be released
> soon. Thus, I’d start with 4.0 and upgrade to 4.1 when 4.2 is
> released.
> 
> -Original Message-
> From:  on behalf of Fernando Frediani  ndo.fredi...@upx.com.br>
> Date: Monday 23 January 2017 at 22:36
> To: "users@ovirt.org" 
> Subject: [ovirt-users] 4.0 x 4.1
> 
> I am deploying a oVirt environment which will not get production
> data 
> immediately.
> 
> Obviously I would rather use 4.1 RC due the many changes and fixes 
> present. Later when 4.1 becomes stable then upgrade to it.
> Does anyone see any problem in doing that way or would it be more 
> advisable to start with 4.0.6 and upgrade to 4.1 stable when time
> comes ?
> 
> My concern are the issue people related they had when upgrading from
> one 
> major version to another in the past.
> 
> Thanks
> 
> Fernando
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
> 
> 
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [PySDK v3] Choose storage domain

[Nicolas Ecarnot]

Juan,

Thank you very much for your help, this is working.

Some comments below.

Le 24/01/2017 à 11:04, Juan Hernández a écrit :

In order to do that you need to specify that you want to clone the disks
of the template, and for each disk you need to specify the storage
domain where you want to create it.


This is what I feared, and it was not really obvious at first sight (to 
prepare a disks list...).

I think I saw it was less weird in V4.


[...]



Also, please be careful when specifying the cluster and the template.
You are currently doing this:

  cluster=vm_cluster,
  template=vm_template,

Not sure how you are assigning the values to those 'vm_cluster' and
'vm_template' variables, but you are probably doing this:

  vm_cluster = api.vms.get(name='mycluster')
  vm_template = api.vms.get(name='mytemplate')


Here is what I was doing (please don't laugh) :

c_list = api.clusters.list()
# At present (2017), each datacenter contains only one cluster
vm_cluster = c_list[0]

vm_template = api.templates.get(name=template_name)


That combination isn't ideal, because you will be sending with the 'add'
request the complete representation of the cluster and the template,
when the server only needs the id or the name. Consider doing this instead:

  cluster=params.Cluster(
id=vm_cluster.get_id()
  ),
  template=params.Cluster(
id=vm_template.get_id()
  ),


Is it right to say that this last method is only valid in the api 
context, and would not work outside of the api object scope?
I mean : if I want to use your method, I can no longer separate the 
preparation of a vm_params object before calling the vms.add, right?





OK, just one second before sending this e-mail, I made a quick test with 
the template object and it is working anyway.

Does it mean nothing is instantiated before the api.vms.add call?

--
Nicolas ECARNOT
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] 4.0 x 4.1

[Pavel Gashev]

I'd like to apologize for 'ugly' word. From my own personal experience 4.0.5 
had some bugs which spoiled my impression from 4.0. Fortunately most of them 
are fixed in 4.0.6. 

-Original Message-
From:  on behalf of Pavel Gashev 
Date: Tuesday 24 January 2017 at 13:38
To: Fernando Frediani , "users@ovirt.org" 

Subject: Re: [ovirt-users] 4.0 x 4.1

I started with oVirt 3.6. It became stable since 3.6.7 just when 4.0 is 
released. Also I use 4.0. The previous 4.0.5 was ugly, 4.0.6 can be considered 
more or less stable, and 4.1 is going to be released soon. Thus, I’d start with 
4.0 and upgrade to 4.1 when 4.2 is released.

-Original Message-
From:  on behalf of Fernando Frediani 

Date: Monday 23 January 2017 at 22:36
To: "users@ovirt.org" 
Subject: [ovirt-users] 4.0 x 4.1

I am deploying a oVirt environment which will not get production data 
immediately.

Obviously I would rather use 4.1 RC due the many changes and fixes 
present. Later when 4.1 becomes stable then upgrade to it.
Does anyone see any problem in doing that way or would it be more 
advisable to start with 4.0.6 and upgrade to 4.1 stable when time comes ?

My concern are the issue people related they had when upgrading from one 
major version to another in the past.

Thanks

Fernando

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] 4.0 x 4.1

[Pavel Gashev]

I started with oVirt 3.6. It became stable since 3.6.7 just when 4.0 is 
released. Also I use 4.0. The previous 4.0.5 was ugly, 4.0.6 can be considered 
more or less stable, and 4.1 is going to be released soon. Thus, I’d start with 
4.0 and upgrade to 4.1 when 4.2 is released.

-Original Message-
From:  on behalf of Fernando Frediani 

Date: Monday 23 January 2017 at 22:36
To: "users@ovirt.org" 
Subject: [ovirt-users] 4.0 x 4.1

I am deploying a oVirt environment which will not get production data 
immediately.

Obviously I would rather use 4.1 RC due the many changes and fixes 
present. Later when 4.1 becomes stable then upgrade to it.
Does anyone see any problem in doing that way or would it be more 
advisable to start with 4.0.6 and upgrade to 4.1 stable when time comes ?

My concern are the issue people related they had when upgrading from one 
major version to another in the past.

Thanks

Fernando

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] [PySDK v3] Choose storage domain

[Juan Hernández]

On 01/24/2017 10:13 AM, Nicolas Ecarnot wrote:
> Hello,
> 
> When trying to create a VM by cloning a template, I found out I couldn't
> choose the target storage domain :
> 
> [...]
> vm_storage_domain = api.storagedomains.get(name=storage_domain)
> vm_params = params.VM(name=vm_name,
> memory=vm_memory,
> cluster=vm_cluster,
> template=vm_template,
> os=vm_os,
> storage_domain=vm_storage_domain,
> )
> try:
> api.vms.add(vm=vm_params)
> [...]
> 
> I'm getting :
> Failed to create VM from Template:
> 
> status: 400
> reason: Bad Request
> detail: Cannot add VM. The selected Storage Domain does not contain the
> VM Template.
> 
> ... which I know, but I thought that, as with the GUI, I could specify
> the target storage domain.
> 
> I made my homework, and I found a nice answer from Juan :
> http://lists.ovirt.org/pipermail/users/2016-January/037321.html
> but this relates to snapshots, and not to template usage, so I'm still
> stuck.
> May I ask an advice?
> 

In order to do that you need to specify that you want to clone the disks
of the template, and for each disk you need to specify the storage
domain where you want to create it. Should be something like this:

---8<---
# Find the identifiers of the disks of the template:
template = api.templates.get(name='mytemplate')
disk_ids = [disk.get_id() for disk in template.disks.list()]

# Find the target storage domain:
sd = api.storagedomains.get(name='yourdata')

# Prepare a list of disks that specifies the target storage domain
# for each disk of the template:
disks = []
for disk_id in disk_ids:
disk = params.Disk(
id=disk_id,
storage_domains=params.StorageDomains(
storage_domain=[
params.StorageDomain(
id=sd.get_id()
)
]
)
)
disks.append(disk)

# Create the virtual machine, specifying that the list should
# be cloned, and to which storage domain they should be cloned:
api.vms.add(
vm=params.VM(
name='myvm',
cluster=params.Cluster(
name='mycluster'
),
template=params.Template(
name='mytemplate',
),
disks=params.Disks(
clone=True,
disk=disks
)
)
)
--->8---

Also, please be careful when specifying the cluster and the template.
You are currently doing this:

  cluster=vm_cluster,
  template=vm_template,

Not sure how you are assigning the values to those 'vm_cluster' and
'vm_template' variables, but you are probably doing this:

  vm_cluster = api.vms.get(name='mycluster')
  vm_template = api.vms.get(name='mytemplate')

That combination isn't ideal, because you will be sending with the 'add'
request the complete representation of the cluster and the template,
when the server only needs the id or the name. Consider doing this instead:

  cluster=params.Cluster(
id=vm_cluster.get_id()
  ),
  template=params.Cluster(
id=vm_template.get_id()
  ),

Or just the names, as in the example above.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Updated Invitation: DeepDive: Support for SRIOV migration @ Tue Jan 24, 2017 5pm - 6pm (CET) (users@ovirt.org)

[mmucha]

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VEVENT
DTSTART:20170124T16Z
DTEND:20170124T17Z
DTSTAMP:20170124T095924Z
ORGANIZER;CN=mmu...@redhat.com:mailto:mmu...@redhat.com
UID:bonqq8geqac5tfl4dkk5vqd...@google.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=dkeni...@redhat.com;X-NUM-GUESTS=0:mailto:dan...@redhat.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=mmu...@redhat.com;X-NUM-GUESTS=0:mailto:mmu...@redhat.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;RSVP=TRUE
 ;CN=mkali...@redhat.com;X-NUM-GUESTS=0:mailto:mkali...@redhat.com
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=users@ovirt.org;X-NUM-GUESTS=0:mailto:users@ovirt.org
ATTENDEE;CUTYPE=INDIVIDUAL;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=
 TRUE;CN=rhevm-qe-dept;X-NUM-GUESTS=0:mailto:rhevm-qe-d...@redhat.com
CLASS:PRIVATE
CREATED:20170116T142209Z
DESCRIPTION:Demonstration of VM migration in ovirt/rhevm\, when VM contains
  SRIOV nic.\n\nWe will look together at following demonstration and discuss
  it:\nhttps://www.youtube.com/watch?v=qlyMxvUvLaY\n\nnote: please use bluej
 eans to ask question aloud or using chat.\nView your event at https://www.g
 oogle.com/calendar/event?action=VIEW&eid=Ym9ucXE4Z2VxYWM1dGZsNGRrazV2cWR1ZG
 cgdXNlcnNAb3ZpcnQub3Jn&tok=MTcjbW11Y2hhQHJlZGhhdC5jb201N2Q4MjRmZjhlZTg1ZjQ2
 YTVjYjAyMmYzMzI2MTBhZDc3MGNjOWU3&ctz=Europe/Prague&hl=en.
LAST-MODIFIED:20170124T095923Z
LOCATION:https://bluejeans.com/7959957866
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:DeepDive: Support for SRIOV migration 
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR


invite.ics
Description: application/ics
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Large DWH Database, how to empty

[Shirly Radco]

Hi,

We don't update the ovirt-engine-dwhd.conf directly.

You need to add the new file to  /ovirt-engine-dwhd.conf.d/ with the lines
DWH_TABLES_KEEP_SAMPLES=
DWH_TABLES_KEEP_HOURLY=
DWH_TABLES_KEEP_DAILY=0

and set the values for how much time you want the data to be kept.
Keep in mind that the dashboards use the information from the samples and
hourly tables for the last 24 hours.

This file will overwrite the default configurations after you restart
ovirt-engine-dwhd.



Best regards,

Shirly Radco

BI Software Engineer
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109


On Tue, Jan 24, 2017 at 11:43 AM, Matt .  wrote:

> Shirly,
>
> I'm checking this out and aren't you sure the file is
> update_time_to_keep_records.conf and not ovirt-engine-dwhd.conf ?
>
> 2017-01-09 14:01 GMT+01:00 Matt . :
> > I think it did. Cluster exists 4 years now, hosted engine 7 months.
> >
> > 2017-01-08 13:50 GMT+01:00 Shirly Radco :
> >> No. But the delete process might have kicked in.
> >> How long does you environment exist?
> >>
> >> Best regards,
> >>
> >> Shirly Radco
> >>
> >> BI Software Engineer
> >> Red Hat Israel Ltd.
> >> 34 Jerusalem Road
> >> Building A, 4th floor
> >> Ra'anana, Israel 4350109
> >>
> >>
> >> On Sun, Jan 8, 2017 at 2:42 PM, Matt .  wrote:
> >>>
> >>> Hi,
> >>>
> >>> OK thanks! I saw that after upgrading to 4.0.5 from 4.0.4 the DB
> >>> already dropped with around 500MB directly and is now at 2GB smaller.
> >>>
> >>> Does this sounds familiar to you with other settings in 4.0.5 ?
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> Matt
> >>>
> >>>
> >>>
> >>> 2017-01-08 10:45 GMT+01:00 Shirly Radco :
> >>> > No. That will corrupt your database.
> >>> >
> >>> > Are you using the full dwh or the smaller version for the dashboards?
> >>> >
> >>> > Please set the delete thresholds to save less data and the data older
> >>> > then
> >>> > the time you set will be deleted.
> >>> > Add a file to /ovirt-engine-dwhd.conf.d/
> >>> > update_time_to_keep_records.conf
> >>> >
> >>> > Add these lines with the new configurations. The numbers represent
> the
> >>> > hours
> >>> > to keep the data.
> >>> >
> >>> > DWH_TABLES_KEEP_SAMPLES=24
> >>> > DWH_TABLES_KEEP_HOURLY=1440
> >>> > DWH_TABLES_KEEP_DAILY=43800
> >>> >
> >>> >
> >>> > These are the configurations for a full dwh.
> >>> >
> >>> > The smaller version configurations are:
> >>> > DWH_TABLES_KEEP_SAMPLES=24
> >>> > DWH_TABLES_KEEP_HOURLY=720
> >>> > DWH_TABLES_KEEP_DAILY=0
> >>> >
> >>> > The delete process by default at 3am every day
> (DWH_DELETE_JOB_HOUR=3)
> >>> >
> >>> > Best regards,
> >>> >
> >>> > Shirly Radco
> >>> >
> >>> > BI Software Engineer
> >>> > Red Hat Israel Ltd.
> >>> > 34 Jerusalem Road
> >>> > Building A, 4th floor
> >>> > Ra'anana, Israel 4350109
> >>> >
> >>> >
> >>> > On Fri, Jan 6, 2017 at 6:35 PM, Matt . 
> wrote:
> >>> >>
> >>> >> Hi,
> >>> >>
> >>> >> I seem to have some large database for the DWH logging and I wonder
> >>> >> how I can empty it safely.
> >>> >>
> >>> >> Can I just simply empty the database ?
> >>> >>
> >>> >> Have a good weekend!
> >>> >>
> >>> >> Cheers,
> >>> >>
> >>> >> Matt
> >>> >> ___
> >>> >> Users mailing list
> >>> >> Users@ovirt.org
> >>> >> http://lists.ovirt.org/mailman/listinfo/users
> >>> >
> >>> >
> >>
> >>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Large DWH Database, how to empty

[Matt .]

Shirly,

I'm checking this out and aren't you sure the file is
update_time_to_keep_records.conf and not ovirt-engine-dwhd.conf ?

2017-01-09 14:01 GMT+01:00 Matt . :
> I think it did. Cluster exists 4 years now, hosted engine 7 months.
>
> 2017-01-08 13:50 GMT+01:00 Shirly Radco :
>> No. But the delete process might have kicked in.
>> How long does you environment exist?
>>
>> Best regards,
>>
>> Shirly Radco
>>
>> BI Software Engineer
>> Red Hat Israel Ltd.
>> 34 Jerusalem Road
>> Building A, 4th floor
>> Ra'anana, Israel 4350109
>>
>>
>> On Sun, Jan 8, 2017 at 2:42 PM, Matt .  wrote:
>>>
>>> Hi,
>>>
>>> OK thanks! I saw that after upgrading to 4.0.5 from 4.0.4 the DB
>>> already dropped with around 500MB directly and is now at 2GB smaller.
>>>
>>> Does this sounds familiar to you with other settings in 4.0.5 ?
>>>
>>>
>>> Thanks,
>>>
>>> Matt
>>>
>>>
>>>
>>> 2017-01-08 10:45 GMT+01:00 Shirly Radco :
>>> > No. That will corrupt your database.
>>> >
>>> > Are you using the full dwh or the smaller version for the dashboards?
>>> >
>>> > Please set the delete thresholds to save less data and the data older
>>> > then
>>> > the time you set will be deleted.
>>> > Add a file to /ovirt-engine-dwhd.conf.d/
>>> > update_time_to_keep_records.conf
>>> >
>>> > Add these lines with the new configurations. The numbers represent the
>>> > hours
>>> > to keep the data.
>>> >
>>> > DWH_TABLES_KEEP_SAMPLES=24
>>> > DWH_TABLES_KEEP_HOURLY=1440
>>> > DWH_TABLES_KEEP_DAILY=43800
>>> >
>>> >
>>> > These are the configurations for a full dwh.
>>> >
>>> > The smaller version configurations are:
>>> > DWH_TABLES_KEEP_SAMPLES=24
>>> > DWH_TABLES_KEEP_HOURLY=720
>>> > DWH_TABLES_KEEP_DAILY=0
>>> >
>>> > The delete process by default at 3am every day (DWH_DELETE_JOB_HOUR=3)
>>> >
>>> > Best regards,
>>> >
>>> > Shirly Radco
>>> >
>>> > BI Software Engineer
>>> > Red Hat Israel Ltd.
>>> > 34 Jerusalem Road
>>> > Building A, 4th floor
>>> > Ra'anana, Israel 4350109
>>> >
>>> >
>>> > On Fri, Jan 6, 2017 at 6:35 PM, Matt .  wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> I seem to have some large database for the DWH logging and I wonder
>>> >> how I can empty it safely.
>>> >>
>>> >> Can I just simply empty the database ?
>>> >>
>>> >> Have a good weekend!
>>> >>
>>> >> Cheers,
>>> >>
>>> >> Matt
>>> >> ___
>>> >> Users mailing list
>>> >> Users@ovirt.org
>>> >> http://lists.ovirt.org/mailman/listinfo/users
>>> >
>>> >
>>
>>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] packages that can be updated without maintening hosts

[David Teigland]

On Mon, Jan 23, 2017 at 09:50:38PM +0200, Nir Soffer wrote:

> >> The major issue is sanlock, if it is maintaining a lease on storage,
> >> updating sanlock will cause the host to reboot. Sanlock is not
> >> petting the host watchdog because you killed sanlock during the
> >> upgrade, the watchdog will reboot the host.
> >
> > Is the sanlock RPM preventing an upgrade (in the pre-upgrade script) if it
> > has a lock?

I think that rpm upgrade is not interacting with the running daemon,
although there was a problem with that at one time.

___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] [PySDK v3] Choose storage domain

[Nicolas Ecarnot]

Hello,

When trying to create a VM by cloning a template, I found out I couldn't 
choose the target storage domain :


[...]
vm_storage_domain = api.storagedomains.get(name=storage_domain)
vm_params = params.VM(name=vm_name,
memory=vm_memory,
cluster=vm_cluster,
template=vm_template,
os=vm_os,
storage_domain=vm_storage_domain,
)
try:
api.vms.add(vm=vm_params)
[...]

I'm getting :
Failed to create VM from Template:

status: 400
reason: Bad Request
detail: Cannot add VM. The selected Storage Domain does not contain the 
VM Template.


... which I know, but I thought that, as with the GUI, I could specify 
the target storage domain.


I made my homework, and I found a nice answer from Juan :
http://lists.ovirt.org/pipermail/users/2016-January/037321.html
but this relates to snapshots, and not to template usage, so I'm still 
stuck.

May I ask an advice?

--
Nicolas ECARNOT
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Use of Direct Attached Storage as Storage Type

[Simone Tiraboschi]

On Mon, Jan 23, 2017 at 9:55 PM, Fernando Frediani <
fernando.fredi...@upx.com.br> wrote:

> I am trying to use a DAC (Direct Attached Storage) in a Hardware which has
> it as the only option (DELL VRTX) but I see no matching option at Storage
> Type. It has there: NFS, POSIX compliant FS, GlusterFS, iSCSI and Fiber
> Channel. The two closest are iSCSI and Fiberchannel as they use CLVM in the
> backend I understand, but of course they are not the same thing as DAC.
>
> Has anyone had a similar scenario and how solved it ?
>

Did you tried simply choosing FC for that? do you see your volumes in that
case?


>
> Thanks
>
> Fernando
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Update NFS storage of the HE server

[Simone Tiraboschi]

On Mon, Jan 23, 2017 at 6:51 PM, Claude Duropcher <
claude.duroc...@cptaq.gouv.qc.ca> wrote:

> Simone, thanks for replying,
>
> According to the documentation, global mode seems to be a superset of
> local mode. Does setting to local mode maintenance on all hosts in the
> cluster really bring any benefits?
>

No, not really: they are different and global is not superset of local.
global maintenance mode is needed if you need to do maintenance on the
engine VM, no host will restart the engine VM. local maintenance mode is if
you need to do maintenance or upgrade a single host.



>
>-
>
>global - All high-availability agents in the cluster are disabled from
>monitoring the state of the engine virtual machine. The global maintenance
>mode must be applied for any setup or upgrade operations that require the
>engine to be stopped, such as upgrading to a later version of oVirt.
>-
>
>local - The high-availability agent on the host issuing the command is
>disabled from monitoring the state of the engine virtual machine. The host
>is exempt from hosting the engine virtual machine while in local
>maintenance mode; if hosting the engine virtual machine when placed into
>this mode, the engine will be migrated to another host, provided there is a
>suitable contender. The local maintenance mode is recommended when applying
>system changes or updates to the host.
>
> Le 2017-01-23 à 12:13, Simone Tiraboschi a écrit :
>
>
>
> On Mon, Jan 23, 2017 at 4:20 PM, Claude Duropcher <
> claude.duroc...@cptaq.gouv.qc.ca> wrote:
>
>> Hi,
>>
>> We need to update/reboot the NFS server on wich the hosted engine is
>> installed. This server also hosts a couple of extra storage domains (ISO,
>> Export and a iScsi domain). I'm wondering if this procedure is complete for
>> an oVirt 4.0 installation :
>>
>> 1-set the environment to global maintenance
>>
>> 2-set the extra domains to maintenance mode
>>
>> 3-shutdown the hosted engine
>>
>> 4-update/reboot the storage server
>>
>> 5-reboot the hosted engine
>>
>> 6-reactivate extra domains
>>
>> 7-disable global maintenance mode
>>
>> I'm wondering what's happening after step 4 and how ovirt will react when
>> the NFS storage disapear and come back.
>>
>>
> ovirt-ha-agent will try to reconnect the shared storage if hosted-engine
> for all the time; depending on different factors, sanlock will fail
> updating the hosted-engine lease ans this can bring the watchdog to reboot
> the host.
> Setting also local maintenance mode on the involved hosts is a good idea.
>
>
>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Ovirt 4.0.5 reporting dashboard not working.

[Andrea Ghelardi]

Hello all,
The issue has been resolved using the following approach:

Connect to the database:
# su – postgres
-bash-4.2$ psql -U postgres  ovirt_engine_history

### Listed table before editing ###
ovirt_engine_history=# SELECT var_datetime FROM history_configuration;
  var_datetime

2017-01-23 01:00:00+00


2016-10-03 12:43:20+00
2017-01-23 11:00:00+00

(6 rows)
###

### Editing table ###
ovirt_engine_history=# UPDATE history_configuration set var_datetime =
ovirt_engine_history-# date_trunc('hour', now())- interval '24 hour' WHERE 
var_name = 'lastHourAggr';
UPDATE 1
ovirt_engine_history=# UPDATE history_configuration set var_datetime =
ovirt_engine_history-# cast(now() as date)- interval '1 day' WHERE var_name = 
'lastDayAggr';
UPDATE 1
###

## Listing table values again (after update) ###
ovirt_engine_history=# SELECT var_datetime FROM history_configuration;
  var_datetime



2016-10-03 12:43:20+00
2017-01-22 00:00:00+00

2017-01-22 09:00:00+00
(6 rows)
###

A few hours after applying above commands, usage graphs appeared on the 
dashboard.
Thanks all
Andrea

From: Shirly Radco [mailto:sra...@redhat.com]
Sent: Tuesday, January 17, 2017 9:44 PM
To: Andrea Ghelardi 
Cc: Liron Aravot ; Tal Nisan ; users 

Subject: Re: [ovirt-users] Ovirt 4.0.5 reporting dashboard not working.

Hi Andrea,

I believe that dwh not working is unrelated to what Liron mentioned.
Please open a bug on ovirt-dwh and attach the dwh log and ovirt_engine_dwh db 
dump, dashboard screenshot.

I will check what is the reason that data is not collected.


Best regards,

Shirly Radco

BI Software Engineer

Red Hat Israel Ltd.

34 Jerusalem Road

Building A, 4th floor

Ra'anana, Israel 4350109

On Tue, Jan 17, 2017 at 6:21 PM, Andrea Ghelardi 
mailto:a.ghela...@iontrading.com>> wrote:
Hello Liron,
Thank you for your reply.

So basically our DWH is not creating reports because vdsm is too slow in 
collecting results?
I understand the message logged in engine is informational instead of warning, 
but still DWH is not working.
Do you have any additional hint about what to check?

Cheers
AG

-Original Message-
From: Liron Aravot [mailto:lara...@redhat.com]
Sent: Tuesday, January 17, 2017 2:30 PM
To: Tal Nisan mailto:tni...@redhat.com>>
Cc: Shirly Radco mailto:sra...@redhat.com>>; users 
mailto:users@ovirt.org>>; Andrea Ghelardi 
mailto:a.ghela...@iontrading.com>>
Subject: Re: [ovirt-users] Ovirt 4.0.5 reporting dashboard not working.
When a host is "connected" to a storage pool it monitors the active pool 
domains. When the domain monitoring results are reported back from the host, 
the first monitor run may haven't finished yet. In that case the returned 
status from vdsm is a dummy status and not an actual result - when getting such 
a status the engine logs it.
We should change that log print to INFO rather then WARN.

On Tue, Dec 20, 2016 at 12:17 PM, Tal Nisan 
mailto:tni...@redhat.com>> wrote:
> Liron, can you please check why does this "report isn't an actual
> report" is appearing in the log?
>
> On Mon, Dec 19, 2016 at 10:33 AM, Andrea Ghelardi
> mailto:a.ghela...@iontrading.com>> wrote:
>>
>> Hello Shirly,
>>
>> I restarted dwh service as per your suggestion with no success.
>>
>>
>>
>> Here a sample of DWH log:
>>
>> 2016-12-14
>> 12:31:55|kdcGa9|GCXnuH|PIv06L|OVIRT_ENGINE_DWH|SampleTimeKeepingJob|D
>> efault|5|tWarn|tWarn_1|Can not sample data, oVirt Engine is not
>> updating the statistics. Please check your oVirt Engine status.|9704
>>
>> 2016-12-14
>> 12:32:20|ncjn2O|GCXnuH|PIv06L|OVIRT_ENGINE_DWH|SampleTimeKeepingJob|D
>> efault|5|tWarn|tWarn_1|Can not sample data, oVirt Engine is not
>> updating the statistics. Please check your oVirt Engine status.|9704
>>
>> 2016-12-14
>> 15:52:37|Xx2zzb|GCXnuH|PIv06L|OVIRT_ENGINE_DWH|SampleTimeKeepingJob|D
>> efault|5|tWarn|tWarn_1|Can not sample data, oVirt Engine is not
>> updating the statistics. Please check your oVirt Engine status.|9704
>>
>> 2016-12-16 17:39:13|ETL Service Stopped
>>
>> 2016-12-16 17:39:14|ETL Service Started
>>
>> ovirtEngineDbDriverClass|org.postgresql.Driver
>>
>>
>> ovirtEngineHistoryDbJdbcConnection|jdbc:postgresql://localhost:5432/o
>> ovirtEngineHistoryDbJdbcConnection|virt_engine_history?sslfactory=org
>> ovirtEngineHistoryDbJdbcConnection|.postgresql.ssl.NonValidatingFacto
>> ovirtEngineHistoryDbJdbcConnection|ry
>>
>> hoursToKeepDaily|0
>>
>> hoursToKeepHourly|720
>>
>> ovirtEngineDbPassword|**
>>
>> runDeleteTime|3
>>
>>
>> ovirtEngineDbJdbcConnection|jdbc:postgresql://localhost:5432/engine?s
>> ovirtEngineDbJdbcConnection|slfactory=org.postgresql.ssl.NonValidatin
>> ovirtEngineDbJdbcConnection|gFactory
>>
>> runInterleave|20
>>
>> limitRows|limit 1000
>>
>> ovirtEngineHistoryDbUser|ovirt_engine_history
>>
>> ovirtEngineDbUser|engine
>>
>> deleteIncrement|10
>>
>> timeBetweenErrorEvents|30
>>
>> hoursToKeepSamples|24
>>
>> deleteMultiplier|100