Re: [Users] Reimporting storage domains after reinstalling ovirt

[Gianluca Cecchi]

On Mon, Mar 17, 2014 at 2:18 AM, Boudewijn Ector wrote:

>
> Okay that sounds like database permissions:
>
>
> [root@Xovirt-engine]# cat
> /etc/ovirt-engine/engine.conf.d/10-setup-database.conf
> ENGINE_DB_HOST="localhost"
> ENGINE_DB_PORT="5432"
> ENGINE_DB_USER="engine"
> ENGINE_DB_PASSWORD=""
> ENGINE_DB_DATABASE="engine"
> ENGINE_DB_SECURED="False"
> ENGINE_DB_SECURED_VALIDATION="False"
> ENGINE_DB_DRIVER="org.postgresql.Driver"
> ENGINE_DB_URL="jdbc:postgresql://${ENGINE_DB_HOST}:${ENGINE_DB_PORT}/${ENGINE_DB_DATABASE}?sslfactory=org.postgresql.ssl.NonValidatingFactory"
>
> I tried to reset the database's password using this in the psql shell:
>
> alter user  engine WITH password '';
> (the same password as above)
>
> Still authentication fails, but when I do this:
>
>  psql -h localhost -p 5432 -U engine engine
>
> It works fine... O gosh more debugging ;). Any clue where I should have
> a look?
> I just tried copying the old /etc/ovirt* stuff over /etc/overt* so both
> configs and db are sync'ed again. To no avail.
>
> Thanks guys!
>
>
> Boudewijn
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

For PostgreSQL access you have to check your previous settings in
/var/lib/pgsql/data

relevant files are
pg_hba.conf
and
postgresql.conf

On a standard ovirt 3.3.3 on CentOS 6.5 my config is

pg_hba.conf;
local   all all   ident
hostengine  engine  0.0.0.0/0   md5
hostengine  engine  ::0/0   md5
hostall all 127.0.0.1/32  ident
hostall all ::1/128   ident


If I compare modifications made by engine setup in respect of pre-defined ones:

[root@ovirteng02 data]# diff postgresql.conf postgresql.conf.20140301072333
64,65c64
< # max_connections = 100   # (change requires restart)
< max_connections = 150
---
> max_connections = 100 # (change requires restart)

[root@ovirteng02 data]# diff pg_hba.conf pg_hba.conf.20140301072333
71,72d70
< hostengine  engine  0.0.0.0/0   md5
< hostengine  engine  ::0/0   md5

check also your PostgreSQL version with the original one.

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

[Users] migration of VM, which protocol actually works?

[aditya mamidwar]

i wanted to learn about the modules so that i could understand how the
engine POSTS and sends data to the backend sql database and other scripts
to perform various options.

for e.g i need to know which code actually collects the storage path for
the ISO s during ISCSI storage domain setup.
also how the hosts, clusters and data centers are made and stored at the
backend.
if i want to add a new UI that bypasses some of these complicated tasks
(again for personal understanding), will I be able to do that.

Also i would like to mention that am working on making a little changes to
how the ISCSI protocol works..


My another doubt is:
when are the NFS/ISCSI/FC protocols actually used in ovirt. like what part
of the VM running state?
are their purpose limited to just copying the ISO from the storage center
to the path required by the Host.

Are the protocols them self responsible for sending and getting data during
VM execution on a node.
The concept of node and migration has left me a little confused.
since each node can run multiple VMs , so during the running/execution of
the VM , do the network protocols actully work, if not , then how is that
achieved.
if yes, again my question arises, which module should i focus on regarding
this issue.

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

Re: [Users] Reimporting storage domains after reinstalling ovirt

[Boudewijn Ector]

> 
> Hi Boudewijn,
> if you have db backup and you won't lose any data using it - it would be the 
> simplest approach.
> 
> Please read carefully the following options and keep backup before attempting 
> any of it -
> for vm's that you don't have space issue with - you can try to previously 
> suggested approach, but it'll obviously take longer as it requires copying of 
> the data.
> 
> Option A -
> *doesn't require copying the disks
> *if your vms had snapshots involving disks - it won't work currently.
> 
> let's try to restore a specific vm and continue from there - i'm adding here 
> info - if needed i'll test it on my own deployment.
> A. first of all, let's get the disks attached to some vm : some options to do 
> that.
> *under the webadmin ui, select a vm listed under the "export" domain, there 
> should be a disks tab indicating what disks are attached to the vm - check if 
> you can see the disk id's there.
> B. query the storage domain content using rest-api - afaik we don't return 
> that info from there. so let's skip that option.
> 1. under the storage domain storage directory (storage) enter the /vms 
> directory - you should see bunch of OVF files there - that's a file 
> containing a vm configuration.
> 2. open one specific ovf file - that's the vm that we'll attempt to restore - 
> the ovf file is a file containing the vm configuration
> *within the ovf file look for the following string: "diskId" and copy those 
> ids aside, these should be the vm attached disks.
> *copy the vm disk from the other storage domain, edit the metadata 
> accordingly to have the proper storage domain id listed
> *try to import the disks using the method specified here:  
> https://bugzilla.redhat.com/show_bug.cgi?id=886133
> *after this, you should see the disks as "floating", then you can add the vm 
> using the OVF file we discussed in stage 2 using the method specified here:
> http://gerrit.ovirt.org/#/c/15894/
> 
> 
> Option B -
> *Replace the images data files with blank files
> *Initiate Import for the vm, should be really quick obviously.
> *As soon as the import starts, you can either:
> 1. let the import be done and replace the data, not that in that case the 
> info saved in the engine db won't be correct (for example, the actual image 
> size..etc)
> 2. after the tasks for importing are created (you'll see that in the engine 
> log), turn the engine down immediately (immediately means within few seconds) 
> and after the copy tasks completes on the host replace the data files and 
> then start the engine - so that when the engine will start it'll update the 
> db information according to the updated data files.
> 


Hi Guys,

Thank you for the elaborate information. I'll try to restore the DB
indeed and make sure all the mounts I previously (when creating the
DB-dump) had will be there too.


I also just had a look in my old DB, which I've just restored:

engine=# select vm_name from vm_static;
 vm_name
-
 Blank
 template
 mail
 nagios
 bacula
 debian-template
 jabber
 downloadbak
 vpn
(9 rows)



That's looking great. Actually the most important VMs to restore (the
rest are re-created in about 2-3 hours so having to re-create those
instead of restoring would be okayish):

- bacula
- downloadbak

Problem is that both of those are the VMs with the most of the disks
attached.
Just had a look in the databasedump for the vm id's and found this:


> COPY disks_vm_map (history_id, vm_disk_id, vm_id, attach_date, detach_date) 
> FROM stdin;
> 2   b2c5d2d5-636c-408b-b52f-b7f5558c0f7f
> a16e4354-0c32-47c1-a01b-7131da3dbb6b2014-01-21 02:32:58+01  \N
> 1   4ef54bf7-525b-4a73-b071-c6750fc7c907
> 33f78ede-e885-4636-bb0b-1021c31d1cca2014-01-21 02:32:58+01  2014-01-21 
> 18:52:00+01
> 5   38eee7d5-9fd1-44b0-876c-b24e4bc0085b
> 0b062e65-7b0f-4177-9e08-cba48230f89a2014-01-22 00:02:01+01  \N
> 4   988f90f6-a37d-4dfd-8477-70aa5d2db5b6
> 0b062e65-7b0f-4177-9e08-cba48230f89a2014-01-21 22:57:01+01  2014-01-22 
> 00:02:01+01
> 6   88a7d07b-b4a3-497d-b2e5-3e6ebc85d83e
> a466a009-cde7-40db-b3db-712b737eb64a2014-01-22 00:37:01+01  \N
> 7   2cd8d3dc-e92f-4be5-88fa-923076aba287
> c040505a-da58-4ee1-8e17-8e32b97656082014-01-22 00:46:01+01  \N
> 8   5e56a396-8deb-4c04-9897-0e4f6582abcc
> 45434b2f-2a79-4a13-812e-a4fd2f5639472014-01-22 01:45:01+01  \N
> 9   caecf666-302d-426c-8a32-65eda8d9e5df
> 0edd5aea-3425-4780-8f54-1c84f9a877652014-01-22 19:42:02+01  \N
> 10  8633fb9b-9c08-406b-925e-7d5955912165
> f45a4a7c-5db5-40c2-af06-230aa5f2b0902014-01-22 19:57:02+01  \N
> 11  81b71076-be95-436b-9657-61890e81cee9
> c040505a-da58-4ee1-8e17-8e32b97656082014-01-22 23:22:02+01  2014-01-30 
> 02:09:09+01
> 12  924e5ba6-913e-4591-a15f-3b61eb66a2e1
> c040505a-da58-4ee1-8e17-8e32b97656082014-02-01 20:42:12+01  2014-02-03 
> 18:00:14+01
> 14  f613aa23-4831-4aba-806e-fb7dcdcd704d
> c040

Re: [Users] feedback-on-oVirt-engine-3.3.4-1.el6

[Maurice James]

You have to use ovirt-manage-domains to attach it to LDAP/Kerberos
infrastructure

-Original Message-
From: users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] On Behalf Of
kirtech_support
Sent: Thursday, March 13, 2014 8:12 AM
To: users@ovirt.org
Subject: [Users] feedback-on-oVirt-engine-3.3.4-1.el6

Good day, how can I create additional users for a user portal?
___
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: [Users] Host CPU type is not compatible with Cluster Properties

[Itamar Heim]

On 03/14/2014 10:02 PM, Hans Hinrichsen Hills wrote:

I’m learning (self-learning) about Ovirt Server, and I had Inatlled in
one IBM Server xSeries 209 with CentOS release 6.5 (Final) 64 bit. I
setup ovirt engine with no problem. In the same server I try to put de
same Host and receive the following messages:

Host MiPrueba moved to Non-Operational state as host does not meet the
cluster’s minimum CPU level. Missing CPU Features : .

In the console, the host is market with Host CPU type is not compatible
with Cluster Properties

cpuFlags =
'fpu,vme,de,pse,tsc,msr,pae,mce,cx8,apic,sep,mtrr,pge,mca,cmov,pat,pse36,clflush,dts,acpi,mmx,fxsr,sse,sse2,ss,ht,tm,pbe,syscall,nx,lm,constant_tsc,pebs,bts,pni,dtes64,monitor,ds_cpl,est,cid,cx16,xtpr,lahf_lm,model_coreduo'

I need to know if I can use this server to ovirt-engine

Saludos cordiales,
Hans Hinrichsen Hills



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



which cpu model does it have (from cat /proc/cpuinfo)?
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] oVIRT3.3.3 Live Migration fails

[Dan Kenigsberg]

On Thu, Mar 13, 2014 at 12:39:24PM -0400, Hans-Joachim wrote:
> Hello,
> 
> Thank you for your help.
> 
> finally, it was a mismatch between a server running in SE permissive mode and 
> a server running in disabled mode.

Yet another reminder that we should implement

894084  [RFE] engine should check and enforce selinux state in
cluster policies

Having Vdsm report selinux state (disabled/enforcing/permissive) in
getVdsCaps should be a piece of cake.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Request for Wiki - dates

[Bob Doolittle]

On 03/16/2014 04:35 AM, Yedidyah Bar David wrote:

- Original Message -

From: "Bob Doolittle" 
To: "Doron Fediuck" 
Cc: "users" 
Sent: Thursday, March 13, 2014 10:17:22 PM
Subject: Re: [Users] Request for Wiki - dates


On 03/13/2014 03:28 PM, Doron Fediuck wrote:

- Original Message -

From: "Bob Doolittle" 
To: "users" 
Sent: Thursday, March 13, 2014 6:53:13 PM
Subject: [Users] Request for Wiki - dates

Hi,

As most are aware, there's a lot of information on the Ovirt Wiki that's
out of date. In spite of our best efforts, that will probably always be
true - it's the nature of Wikis.

When I look for information on our Wiki, I never know where the most
current information is.

I think it would be really helpful if someplace on each Wiki page was a
useful date to let us know the currency of the info. Probably the most
useful date is last-modified, although creation date might also be
useful. Maybe we could even map/display the date to the version number
of whatever the current stable release was at the time for context
(sometimes the content of a page calls out a particular version it's
addressing, but a lot of the time it does not).

Just as an example, I want to find out about migrating my existing
configuration to self-hosted, using 3.4 RC2. A google search shows the
following links (in order shown):

http://www.ovirt.org/Features/Self_Hosted_Engine
http://www.ovirt.org/Migrate_to_Hosted_Engine
http://www.ovirt.org/Hosted_Engine_Howto
...

I'm sure the Features page is ancient at this point. It's hard to tell
about the 2nd page.

Of course the date a page was last modified doesn't directly indicate
how correct/current the information is, but there's a correlation.
Knowing the date would be useful in making a judgment. It might even
help the task of identifying and cleaning up obsolete pages.

Easy to do?

-Bob


Hi Bob,
I'm not against it and I'm aware of the fact that pages tend to become out
of date.
Since every page has a history as you can see in the attached, adding
another date
seems needles.

What do you think?

Hi Doron,

I was thinking of something very simple - a clear text date on ever page
on the Wiki.

I can't see anything that looks like your attached picture of menus on
this page, for example:
http://www.ovirt.org/Features/Self_Hosted_Engine

Do you have to log in to see that menu? If so, that's not very helpful
to those without accounts...

1. So create an account, it's free :-)

2. It's indeed *shown* only to logged in users, but the links are accessible
to everyone. You can "guess" them by looking at any other mediawiki site.
E.g. for this page, the history one is:

http://www.ovirt.org/index.php?title=Features/Self_Hosted_Engine&action=history


I trust we can both agree we could do better, without too much trouble.

We want to make our Wiki pages as easy to use and as helpful as possible 
to everyone, not just people with accounts who have logged in before 
searching for information, or who know how to do magical transformations 
on Wiki URLs to determine the date ;)


I'm not trying to be critical of where we are now - just trying to 
establish a baseline of what we should hope to achieve.


Regards,
   Bob

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

Re: [Users] Migrate simple configuration to self-hosted

[Bob Doolittle]

Thanks for the careful reading. First to repeat my start point and goals:


I want to migrate my existing deployment to self-hosted. I have a simple
deployment:

A: Machine Fedora 20
B: libvirt VM (hosted on A) RHEL 6.5 running Engine 3.3.4-1
C: Machine RHEL 6.5 acts as Hypervisor/Host/Node (VDSM 4.13.3-4)

ISO NFS Domain is on B
Data (Master) NFS Domain is on C

I want to migrate VM B to Machine C, as self-hosted, and free up Machine A


Comments inline:

On 03/16/2014 04:12 AM, Yedidyah Bar David wrote:
This document assumes the most trivial settings, where the only thing 
you care about is simplicity, stability and minimizing downtime. It 
specifically does not try to use the minimum hardware possible.


I see two demographics interested in migrating their current Ovirt 
deployment to self-hosted:

1 Those interested in freeing up a machine to use as another hypervisor.
2 Those (like me) interested in freeing up a machine to use for another 
purpose.


Both groups want to free up a machine, presumably because they need more 
resources. So I don't think our primary How-To should involve requiring 
a new machine in order to migrate. I think many (like me) will find such 
a solution intractable.


For those who have resources to spare, the current How-To seems fine, 
but that might not be the majority.



I can think of several different directions:



Direction 2
===
If you do not care about uptime - the simplest.

Backup everything(!) - engine VM, other VMs, etc., then start from scratch:
Reinstall OS on host C, install and deploy hosted-engine there, restore
actual engine data from backup as described in the wiki.


This sounds like the most interesting approach for my needs. I like 
simple, and I can live with some downtime.


Can you give me a complete list of things I should back up please?

Also (and this gets back to my comment about the usefulness of some kind 
of date on pages visible to people who are not logged in) there are many 
pages regarding backup/restore. Is there one in particular you are 
thinking of/recommend? For backing up VMs I imagine it will not be 
sufficient for me to export my VMs to an export domain somewhere remote 
to host C (which I'll be scratching/reinstalling OS in order to target 
self-hosted). Later if I restore actual engine data, and then import my 
VMs, I imagine the UUIDs won't match? Or is the UUID preserved across 
export/import?


What if I were to create a new temp NFS Storage Domain with my current 
oVirt, someplace other than host C, and then move my VMs to it? Then, 
after I set up self-hosted and restore my engine data, I could move them 
back and nuke my temp domain?


I'm willing to be a guinea pig here, and report back what I find, if I 
can get a little more guidance as to avenues that might be useful to pursue.


Many Thanks,
   Bob

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

Re: [Users] adding scripts

[Einav Cohen]

may I ask what is the general purpose of these buttons that you 
would like to add and where (in the GUI) would you like to add 
them?

if you would like to add buttons to existing main-tab(s) / sub-
tab(s), the way to go is to write a UI Plugin that does that 
(especially if you intend these buttons to do something very 
specific for your needs). 

If you would like to add these buttons elsewhere, you will 
need to follow Greg's instructions and dig into the code for 
the specific needed location. 

> I want to commit changes to the engine... 

note that we can push into the code only things that make sense 
to include in oVirt (i.e. things that will be useful for typical 
oVirt users); again, if these buttons will do something very 
specific for your own needs, you should definitely utilize the 
UI Plugins infrastructure instead. 

> ... and make few tweaks for personal use...

if these tweaks are in the "branding" area (i.e. if you want to 
change main color themes, top-left image on the top banner, etc), 
then writing your own branding [1] is the way to go [you can 
override only part of the branding (depending on what you would 
like to tweak), you don't actually need to come up with a 
complete alternative branding].  


Thanks,
Einav

[1] http://www.ovirt.org/Feature/Branding

- Original Message -
> From: "Greg Sheremeta" 
> To: "Aditya Mamidwar" 
> Cc: engine-de...@ovirt.org, users@ovirt.org
> Sent: Saturday, March 15, 2014 10:15:59 AM
> Subject: Re: [Users] adding scripts
> 
> There's not one html file like that, since we use GWT [1]. However, if you
> search for *.ui.xml files, you'll find all the GWT UIBinder files. That's
> the place to start for simple UI tweaks. The application is partitioned into
> small components, so you'll have to do some digging. For example, each
> dialog has its own ui.xml file -- so if you want to tweak a specific dialog,
> you'll need to find the right file. Feel free to post questions about those
> to engine-devel and we can help you out.
> 
> Greg
> 
> [1] http://www.gwtproject.org/
> 
> 
> 
> 
> From: "Aditya Mamidwar" 
> To: "Einav Cohen" , "Vojtech Szocs" 
> Cc: engine-de...@ovirt.org, users@ovirt.org
> Sent: Saturday, March 15, 2014 8:30:21 AM
> Subject: Re: [Users] adding scripts
> 
> Hey thanks on the previous issue.
> Also is there a way i can access WebAdmin.Html to add custom buttons and make
> few tweaks for personal use?
> I just cant find that file after using git.
> 
> Aditya Mamidwar
> 
> From: Einav Cohen
> Sent: ‎14-‎03-‎2014 01:21
> To: aditya mamidwar ; Vojtech Szocs
> Cc: users@ovirt.org ; engine-de...@ovirt.org
> Subject: Re: [Users] adding scripts
> 
> if you are trying to hook into UI-specific events, it sounds
> like you will need to write an oVirt UI Plugin [1] in order to
> do that. However, I believe that the oVirt UI Plugins
> infrastructure doesn't support hooking to events such as "tab
> x was selected" and/or "button b was clicked".
> It does allow you to add new (custom) tabs/sub-tabs/buttons of
> your own, and there is a chance that it allows you to hook
> into events such as 'row x was selected in the grid'.
> 
> @Vojtech will know better. Vojtech?
> 
> if you are trying to hook into engine events (e.g. you want to
> run a script every time a VM is started in oVirt, no matter if
> the user started it by clicking the 'run' button in the oVirt-
> engine webadmin, or invoked a REST API request, or an SDK
> command), then it will require some sort of an "engine-plugin"
> infrastructure that we don't have at the moment AFAIK.
> there is a chance that for some of the events you will be able
> to utilize the VDSM hooks (at the Host level) [2].
> 
> 
> Thanks,
> Einav
> 
> [1] http://www.ovirt.org/Features/UIPlugins
> 
> [2] http://www.ovirt.org/VDSM-Hooks
> 
> 
> - Original Message -
> > From: "aditya mamidwar" 
> > To: users@ovirt.org, engine-de...@ovirt.org
> > Sent: Thursday, March 13, 2014 11:23:35 AM
> > Subject: [Users] adding scripts
> > 
> > 
> > I want to commit changes to the engine by adding some bash scripts.
> > the scripts should be invoked once a button or tab is selected in the
> > webadmin portal by the user.
> > 
> > can someone guide on achieving this.
> > 
> > --
> > -Aditya Mamidwar
> > 
> > ___
> > 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: [Users] Self-hosted-engine setup error

[Giuseppe Ragusa]

Date: Sun, 16 Mar 2014 05:14:39 -0400
From: d...@redhat.com
To: giuseppe.rag...@hotmail.com
CC: users@ovirt.org
Subject: Re: [Users] Self-hosted-engine setup error

From: "Giuseppe Ragusa" 
To: "Yedidyah Bar David" 
Cc: users@ovirt.org
Sent: Saturday, March 15, 2014 2:15:18 AM
Subject: RE: [Users] Self-hosted-engine setup error




Hi Didi,

Date: Thu, 13 Mar 2014 02:46:50 -0400
From: d...@redhat.com
To: giuseppe.rag...@hotmail.com
CC: users@ovirt.org
Subject: Re: [Users] Self-hosted-engine setup error

From: "Giuseppe Ragusa" 
To: users@ovirt.org
Sent: Thursday, March 13, 2014 2:38:42 AM
Subject: [Users] Self-hosted-engine setup error

Hi all,
while attempting a from-scratch self-hosted-engine installation on CentOS 6.5 
(also freshly reinstalled from scratch) on a physical node (oVirt 3.4.0_pre + 
GlusterFS 3.5.0beta4; NFS storage for engine VM), the process fails almost 
immediately with:

[root@cluster1 ~]# ovirt-hosted-engine-setup 
--config-append=/root/ovhe-setup-answers.conf
[ INFO  ] Stage: Initializing
  Continuing will configure this host for serving as hypervisor and 
create a VM where you have to install oVirt Engine afterwards.
  Are you sure you want to continue? (Yes, No)[Yes]:
[ INFO  ] Generating a temporary VNC password.
[ INFO  ] Stage: Environment setup
  Configuration files: ['/root/ovhe-setup-answers.conf']
  Log file: 
/var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20140313010526.log
  Version: otopi-1.2.0_rc3 (otopi-1.2.0-0.9.rc3.el6)
[ INFO  ] Hardware supports virtualization
[ INFO  ] Bridge ovirtmgmt already created
[ INFO  ] Stage: Environment packages setup
[ INFO  ] Stage: Programs detection
[ INFO  ] Stage: Environment setup
[ INFO  ] Generating VDSM certificates
[ ERROR ] Failed to execute stage 'Environment setup': [Errno 2] No such file 
or directory: '/etc/pki/libvirt/clientcert.pem'
I already got another such report yesterday - seems like a bug in the fix for 
https://bugzilla.redhat.com/show_bug.cgi?id=1034634 .I hope to push a fix later 
today.

I look forward to have the fix pushed/merged in actual packages.


[ INFO  ] Stage: Clean up
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination

The /root/ovhe-setup-answers.conf has been saved from a previous installation 
(before reinstalling) and only minimally edited (removed some lines with UUIDs 
etc.).

The /etc/pki/libvirt dir is completely missing on both nodes; last time I tried 
the whole setup I do not recall of having such problems, but maybe something 
was different then.

The generated 
/var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20140313010526.log 
has been saved as:

http://pastebin.com/ezAJETBN

I hope to be able to progress further to test the whole 2-nodes setup (second 
node freshly reinstalled too and already up with GlusterFS and waiting to be 
added to oVirt cluster) and datacenter configuration.

Many thanks in advance for any suggestions/help,
For now, you can simply:mkdir /etc/pki/libvirt
This should be enough.

The workaround works: the self-hosted-engine installation proceeds now.

Thanks for the report!-- 
Didi

Many thanks for your kind and prompt assistance,
Giuseppe

  

Thanks for the report. The workaround is probably not enough, depends on what 
youare trying to do. 'mkdir /etc/pki/libvirt/private' is needed too. Without 
it, the code thatcopies there a key will create a file 'private' instead of 
copying it into a directory 'private'.
Fix [1] was merged to all branches.
[1] http://gerrit.ovirt.org/25747
Best regards,-- Didi

Hi Didi,
the workaround seemed actually to be enough to make the self-hosted-engine 
setup go through up to the end without any user-visible error, but it left me 
with a non-running Engine VM afterwards (basically it did not restart up 
automatically under HA protection).

I collected all logs and reported it in a separate message with subject 
"Self-hosted engine setup ok but no engine vm running‏ " but got no comments 
yet.

If I get no suggestions I will try to perform some "corrective actions" based 
on my understanding of the problems at hand, but I did not want to "corrupt" 
the exact state to help in debugging (starting again from scratch with full 
first node reinstallation is a somewhat lenghty process since I have no local 
repo mirrors).

Many thanks again,
Giuseppe


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

Re: [Users] Reimporting storage domains after reinstalling ovirt

[Liron Aravot]

- Original Message -
> From: "Boudewijn Ector" 
> To: "Liron Aravot" 
> Cc: "Jason Brooks" , users@ovirt.org
> Sent: Saturday, March 15, 2014 5:01:55 PM
> Subject: Re: [Users] Reimporting storage domains after reinstalling ovirt
> 
> On 11-03-14 16:39, Liron Aravot wrote:
> >
> > - Original Message -
> >> From: "Boudewijn Ector" 
> >> To: "Jason Brooks" 
> >> Cc: users@ovirt.org
> >> Sent: Tuesday, March 11, 2014 1:32:00 AM
> >> Subject: Re: [Users] Reimporting storage domains after reinstalling ovirt
> >>
> >>
> >>> Some people have reported success creating an image of the desired
> >>> size, then noting the name of this new image, and copying the old
> >>> image into the place of the new one, with the new name. Something
> >>> like that might work, but I don't have first-hand experience w/
> >>> it.
> >>>
> >>> Jason
> >> Hi Jason,
> >>
> >>
> >> Due to lack of viable alternative, I've decided to go and try this
> >> approach. I just had a look at my datafiles:
> >>
> >> - these are either 8gb (OS) or 250gb (LVM images)
> >> - can't mount those directly in my host OS (tried because of the next
> >> point)
> >> - I don't know to what VM this image/VM belongs . They're all quite
> >> the same (basic debian install), so determining it just by running
> >> strings etc on those will not be easy
> >> - I can't import the old VMs from the old storage. If I create new
> >> images and dd the old information into those new images the metadata
> >> will not be copied too.
> >>
> >> So the only option is not reusing the VM's  but creating completely
> >> new ones and determining which disk images are required for these VMs.
> >> Then creating the new image structure and dd'ing the corresponding
> >> images from the old VMs into the new ones. In order to do so I need to
> >> know what data belongs to what VM.
> >> Is there a trick for doing this?
> >>
> >> I still do have the database from the old ovirt machine, this might
> >> save me. Will have a look into that one tomorrow.
> >>
> >> Cheers,
> >>
> >> Boudewijn
> > Hi Boudewijn,
> > So we can proceed and recover your data i'd like to know -
> > 1. can you use the db backup? will you lose any important data if you chose
> > to use it?
> > 2, did you have snapshots for your vm?
> >
> > please answer so we can proceed with it, we can find methods for restoring
> > without having to perform images copy (and to restore with copying) - but
> > each way has it's implications.
> > thanks,
> > Liron.
> >
> Hi Liron,
> 
> 
> 
> Have you already been able to look at my reply on the list? It would be
> great for me to be able to make some decent progress this weekend.
> 
> Cheers,
> 
> Boudewijn

Hi Boudewijn,
if you have db backup and you won't lose any data using it - it would be the 
simplest approach.

Please read carefully the following options and keep backup before attempting 
any of it -
for vm's that you don't have space issue with - you can try to previously 
suggested approach, but it'll obviously take longer as it requires copying of 
the data.

Option A -
*doesn't require copying the disks
*if your vms had snapshots involving disks - it won't work currently.

let's try to restore a specific vm and continue from there - i'm adding here 
info - if needed i'll test it on my own deployment.
A. first of all, let's get the disks attached to some vm : some options to do 
that.
*under the webadmin ui, select a vm listed under the "export" domain, there 
should be a disks tab indicating what disks are attached to the vm - check if 
you can see the disk id's there.
B. query the storage domain content using rest-api - afaik we don't return that 
info from there. so let's skip that option.
1. under the storage domain storage directory (storage) enter the /vms 
directory - you should see bunch of OVF files there - that's a file containing 
a vm configuration.
2. open one specific ovf file - that's the vm that we'll attempt to restore - 
the ovf file is a file containing the vm configuration
*within the ovf file look for the following string: "diskId" and copy those ids 
aside, these should be the vm attached disks.
*copy the vm disk from the other storage domain, edit the metadata accordingly 
to have the proper storage domain id listed
*try to import the disks using the method specified here:  
https://bugzilla.redhat.com/show_bug.cgi?id=886133
*after this, you should see the disks as "floating", then you can add the vm 
using the OVF file we discussed in stage 2 using the method specified here:
http://gerrit.ovirt.org/#/c/15894/


Option B -
*Replace the images data files with blank files
*Initiate Import for the vm, should be really quick obviously.
*As soon as the import starts, you can either:
1. let the import be done and replace the data, not that in that case the info 
saved in the engine db won't be correct (for example, the actual image 
size..etc)
2. after the tasks for importing are created (you'll see that in the engine 
log), turn the engine d

Re: [Users] Ovirt 3.4rc + Qemu Live snapshot : Problem to delete a Snapshot

[Eric Bollengier]

Hello Gadi,

On 03/16/2014 11:04 AM, Gadi Ickowicz wrote:
> Hi Eric,
> 
> Live merge is not yet supported (IIRC by qemu). From the Live_Snapshots wiki 
> page:
> "Live merge is not present in the upstream component yet (libvirt/qemu)"

OK, thanks for this clarification, it was not obvious for me, now I'm sure.

Thanks,

Regards,

Eric


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

Re: [Users] Ovirt 3.4rc + Qemu Live snapshot : Problem to delete a Snapshot

[Gadi Ickowicz]

Hi Eric,

Live merge is not yet supported (IIRC by qemu). From the Live_Snapshots wiki 
page:
"Live merge is not present in the upstream component yet (libvirt/qemu)"

Gadi Ickowicz

- Original Message -
From: "Eric Bollengier" 
To: "Meital Bourvine" 
Cc: users@ovirt.org
Sent: Sunday, March 16, 2014 11:41:54 AM
Subject: Re: [Users] Ovirt 3.4rc + Qemu Live snapshot : Problem to delete a 
Snapshot

Hello Meital,

Thanks for your answer,

On 03/16/2014 10:04 AM, Meital Bourvine wrote:
>> I upgraded to Ovirt 3.4rc allinone on centos6, and I compiled/installed
>> the qemu-kvm-rhev to be able to take live snapshots.
>>
>> Taking the snapshot is OK, but I would like to delete them, and the
>> button and the menu are disabled (grey) until I shutdown the VM.
>>
>> Once powered off, actions are available, and I'm able to delete snapshots.
>
> This is the expected behaviour. 
>>
>> When looking the Snapshot Actions Matrix:
>> http://www.ovirt.org/Live_Snapshots
>>
>> Is the "Revert" operation needed to delete a snapshot ? (Deleting a
>> snapshot file implies to write changes from the snapshot file to the
>> parent file, looks to be "Commit" for me).
>
> As far as I understand, revert means to go back to the point that you took 
> the snapshot,
> while delete means to stay at the current point of time but deleting the 
> option to go back.


OK, so given the Snapshot Actions Matrix, it should be possible to
delete the snapshot via a "Live Merge" operation. So, why the delete
action is not available while the VM is running? How can I enable this
feature? Or maybe this feature is in the roadmap?

Thanks,

Regards,

Eric
___
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: [Users] Ovirt 3.4rc + Qemu Live snapshot : Problem to delete a Snapshot

[Eric Bollengier]

Hello Meital,

Thanks for your answer,

On 03/16/2014 10:04 AM, Meital Bourvine wrote:
>> I upgraded to Ovirt 3.4rc allinone on centos6, and I compiled/installed
>> the qemu-kvm-rhev to be able to take live snapshots.
>>
>> Taking the snapshot is OK, but I would like to delete them, and the
>> button and the menu are disabled (grey) until I shutdown the VM.
>>
>> Once powered off, actions are available, and I'm able to delete snapshots.
>
> This is the expected behaviour. 
>>
>> When looking the Snapshot Actions Matrix:
>> http://www.ovirt.org/Live_Snapshots
>>
>> Is the "Revert" operation needed to delete a snapshot ? (Deleting a
>> snapshot file implies to write changes from the snapshot file to the
>> parent file, looks to be "Commit" for me).
>
> As far as I understand, revert means to go back to the point that you took 
> the snapshot,
> while delete means to stay at the current point of time but deleting the 
> option to go back.


OK, so given the Snapshot Actions Matrix, it should be possible to
delete the snapshot via a "Live Merge" operation. So, why the delete
action is not available while the VM is running? How can I enable this
feature? Or maybe this feature is in the roadmap?

Thanks,

Regards,

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

Re: [Users] Self-hosted-engine setup error

[Yedidyah Bar David]

> From: "Giuseppe Ragusa" 
> To: "Yedidyah Bar David" 
> Cc: users@ovirt.org
> Sent: Saturday, March 15, 2014 2:15:18 AM
> Subject: RE: [Users] Self-hosted-engine setup error

> Hi Didi,

> Date: Thu, 13 Mar 2014 02:46:50 -0400
> From: d...@redhat.com
> To: giuseppe.rag...@hotmail.com
> CC: users@ovirt.org
> Subject: Re: [Users] Self-hosted-engine setup error

> > From: "Giuseppe Ragusa" 
> 
> > To: users@ovirt.org
> 
> > Sent: Thursday, March 13, 2014 2:38:42 AM
> 
> > Subject: [Users] Self-hosted-engine setup error
> 

> > Hi all,
> 
> > while attempting a from-scratch self-hosted-engine installation on CentOS
> > 6.5
> > (also freshly reinstalled from scratch) on a physical node (oVirt 3.4.0_pre
> > + GlusterFS 3.5.0beta4; NFS storage for engine VM), the process fails
> > almost
> > immediately with:
> 

> > [root@cluster1 ~]# ovirt-hosted-engine-setup
> > --config-append=/root/ovhe-setup-answers.conf
> 
> > [ INFO ] Stage: Initializing
> 
> > Continuing will configure this host for serving as hypervisor and create a
> > VM
> > where you have to install oVirt Engine afterwards.
> 
> > Are you sure you want to continue? (Yes, No)[Yes]:
> 
> > [ INFO ] Generating a temporary VNC password.
> 
> > [ INFO ] Stage: Environment setup
> 
> > Configuration files: ['/root/ovhe-setup-answers.conf']
> 
> > Log file:
> > /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20140313010526.log
> 
> > Version: otopi-1.2.0_rc3 (otopi-1.2.0-0.9.rc3.el6)
> 
> > [ INFO ] Hardware supports virtualization
> 
> > [ INFO ] Bridge ovirtmgmt already created
> 
> > [ INFO ] Stage: Environment packages setup
> 
> > [ INFO ] Stage: Programs detection
> 
> > [ INFO ] Stage: Environment setup
> 
> > [ INFO ] Generating VDSM certificates
> 
> > [ ERROR ] Failed to execute stage 'Environment setup': [Errno 2] No such
> > file
> > or directory: '/etc/pki/libvirt/clientcert.pem'
> 

> I already got another such report yesterday - seems like a bug in the fix for
> https://bugzilla.redhat.com/show_bug.cgi?id=1034634 .
> I hope to push a fix later today.

> I look forward to have the fix pushed/merged in actual packages.

> > [ INFO ] Stage: Clean up
> 
> > [ INFO ] Stage: Pre-termination
> 
> > [ INFO ] Stage: Termination
> 

> > The /root/ovhe-setup-answers.conf has been saved from a previous
> > installation
> > (before reinstalling) and only minimally edited (removed some lines with
> > UUIDs etc.).
> 

> > The /etc/pki/libvirt dir is completely missing on both nodes; last time I
> > tried the whole setup I do not recall of having such problems, but maybe
> > something was different then.
> 

> > The generated
> > /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20140313010526.log
> > has been saved as:
> 

> > http://pastebin.com/ezAJETBN
> 

> > I hope to be able to progress further to test the whole 2-nodes setup
> > (second
> > node freshly reinstalled too and already up with GlusterFS and waiting to
> > be
> > added to oVirt cluster) and datacenter configuration.
> 

> > Many thanks in advance for any suggestions/help,
> 

> For now, you can simply:
> mkdir /etc/pki/libvirt

> This should be enough.

> The workaround works: the self-hosted-engine installation proceeds now.

> Thanks for the report!
> --
> Didi

> Many thanks for your kind and prompt assistance,
> Giuseppe

Thanks for the report. The workaround is probably not enough, depends on what 
you 
are trying to do. 'mkdir /etc/pki/libvirt/private' is needed too. Without it, 
the code that 
copies there a key will create a file 'private' instead of copying it into a 
directory 'private'. 

Fix [1] was merged to all branches. 

[1] http://gerrit.ovirt.org/25747 

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

Re: [Users] Ovirt 3.4rc + Qemu Live snapshot : Problem to delete a Snapshot

[Meital Bourvine]

Hi Eric,

Inline

- Original Message -
> From: "Eric Bollengier" 
> To: users@ovirt.org
> Sent: Friday, March 14, 2014 6:47:39 PM
> Subject: [Users] Ovirt 3.4rc + Qemu Live snapshot : Problem to delete a   
> Snapshot
> 
> Hello,
> 
> I upgraded to Ovirt 3.4rc allinone on centos6, and I compiled/installed
> the qemu-kvm-rhev to be able to take live snapshots.
> 
> Taking the snapshot is OK, but I would like to delete them, and the
> button and the menu are disabled (grey) until I shutdown the VM.
> 
> Once powered off, actions are available, and I'm able to delete snapshots.
This is the expected behaviour. 
> 
> When looking the Snapshot Actions Matrix:
> http://www.ovirt.org/Live_Snapshots
> 
> Is the "Revert" operation needed to delete a snapshot ? (Deleting a
> snapshot file implies to write changes from the snapshot file to the
> parent file, looks to be "Commit" for me).
As far as I understand, revert means to go back to the point that you took the 
snapshot,
while delete means to stay at the current point of time but deleting the option 
to go back.
> 
> If not, should I have to upgrade something else, like libvirt, to be
> able to delete snapshots?
No.
> 
> Thanks in advance
> 
> Best Regards,
> 
> Eric
> 
> 
> ovirt-engine-setup-plugin-ovirt-engine-common-3.4.0-0.13.rc.el6.noarch
> ovirt-iso-uploader-3.4.0-1.el6.noarch
> ovirt-engine-tools-3.4.0-0.13.rc.el6.noarch
> ovirt-engine-backend-3.4.0-0.13.rc.el6.noarch
> ovirt-host-deploy-1.1.3-1.el6.noarch
> ovirt-host-deploy-java-1.1.3-1.el6.noarch
> ovirt-engine-cli-3.3.0.6-1.el6.noarch
> ovirt-host-deploy-offline-1.1.3-1.el6.noarch
> ovirt-engine-setup-base-3.4.0-0.13.rc.el6.noarch
> ovirt-engine-setup-plugin-ovirt-engine-3.4.0-0.13.rc.el6.noarch
> ovirt-engine-setup-plugin-allinone-3.4.0-0.13.rc.el6.noarch
> ovirt-log-collector-3.4.1-1.el6.noarch
> ovirt-engine-setup-plugin-websocket-proxy-3.4.0-0.13.rc.el6.noarch
> ovirt-engine-webadmin-portal-3.4.0-0.13.rc.el6.noarch
> ovirt-engine-userportal-3.4.0-0.13.rc.el6.noarch
> ovirt-engine-dbscripts-3.4.0-0.13.rc.el6.noarch
> ovirt-engine-3.4.0-0.13.rc.el6.noarch
> ovirt-engine-lib-3.4.0-0.13.rc.el6.noarch
> ovirt-engine-setup-3.4.0-0.13.rc.el6.noarch
> ovirt-image-uploader-3.4.0-1.el6.noarch
> ovirt-engine-websocket-proxy-3.4.0-0.13.rc.el6.noarch
> ovirt-engine-restapi-3.4.0-0.13.rc.el6.noarch
> ovirt-release-11.0.2-1.noarch
> vdsm-4.13.3-4.el6.x86_64
> qemu-img-rhev-0.12.1.2-2.415.el6.5.x86_64
> qemu-kvm-rhev-0.12.1.2-2.415.el6.5.x86_64
> qemu-kvm-rhev-tools-0.12.1.2-2.415.el6.5.x86_64
> libvirt-0.10.2-29.el6_5.5.x86_64
> libvirt-lock-sanlock-0.10.2-29.el6_5.5.x86_64
> ___
> 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: [Users] affects of changing compatibility setting on running cluster

[Omer Frenkel]

- Original Message -
> From: "Itamar Heim" 
> To: "Charles Weber" 
> Cc: "ybronhei" , "Dan Kenigsberg" , 
> users@ovirt.org, "Eli Mesika"
> , "Sven Kieske" , "Omer Frenkel" 
> 
> Sent: Friday, March 14, 2014 12:58:57 AM
> Subject: Re: [Users] affects of changing compatibility setting on running 
> cluster
> 
> On 03/13/2014 05:33 PM, Charles Weber wrote:
> >
> > On Mar 12, 2014, at 5:14 PM, Itamar Heim  > > wrote:
> >
> >> On 03/12/2014 10:45 PM, ybronhei wrote:
> >>> On 03/12/2014 04:33 PM, Itamar Heim wrote:
>  On 03/12/2014 04:32 PM, ybronhei wrote:
> > On 03/12/2014 04:25 PM, Dan Kenigsberg wrote:
> >> On Wed, Mar 12, 2014 at 10:15:21AM +0200, Itamar Heim wrote:
> >>> On 03/12/2014 10:11 AM, Sven Kieske wrote:
> 
> 
>  Am 11.03.2014 17:38, schrieb Itamar Heim:
> >
> > i understood this to "you can't use 4.14 with 3.4.0".
> 
>  Well I examined BZ 1067096 again, this is what did not work:
> 
>  Steps to Reproduce:
>  1.  Run Engine 3.3 Compatibility level 3.2 or 3.3
>  2.  Add node (vdsm 4.14)
> 
>  Actual results:
>  Host is installed with VDSM version (4.14) and cannot join cluster
>  which
>  is compatible with VDSM versions [4.13, 4.9, 4.11, 4.12, 4.10].
> 
>  Pay attention to the engine version, it states 3.3. not 3.4.0
> 
>  So my conclusion is, you can't install vdsm 4.14. when you want
>  to use engine 3.3.
> 
>  Am I reading something wrong?
> 
>  Here's the link again:
>  https://bugzilla.redhat.com/show_bug.cgi?id=1067096#c0
> 
> >>>
> >>> this can be fixed via engine config, but is not supposed to be
> >>> needed, as vdsm is supposed to have
> >>> vdsm/dsaversion.py.in:'supportedENGINEs': ['3.0', '3.1', '3.2',
> >>> '3.3', '3.4'],
> >>>
> >>> danken/eli - thoughts?
> >>
> >> I do not really understand why we have this recurrent Engine bug, of
> >> ignoring supportedENGINEs; I think Yaniv does.
> >>
> >
> > i recall asking for detailed explanation for why do we have 3 different
> > restrictions , one for supportedEngines, one for the allowed vdsm
> > versions, and one for the cluster level?
> >
> > if vdsm version is supported why isn't it in engine's capabilities yet?
> 
>  because its a vdsm version which was released after that engine was
>  released, hence the vdsm package has to declare its supporting the old
>  engine.
> 
> >>>
> >>> so its an hack to allow users to add beta vdsm version to new engine
> >>> release?.. sounds like that
> >>
> >> no. its to add the next release of vdsm to a previously released
> >> engine. but that's not supposed to be an issue, since its supposed to
> >> already report the previous version of engine (which it does)
> >>
> >>>
> >>> please reopen if it reproduced
> >>>
> >
> > the issue was verified in
> > https://bugzilla.redhat.com/show_bug.cgi?id=1016461, please reopen if
> > it still appears
> >
> >
> >
> 
> >>>
> >>>
> >>
> >
> > I do have an issue still with this.
> > When I try to change compatibility version at the datacenter level it
> > behaves as expected, i.e. warns me to change the cluster level first. I
> > see a matching log entry in the engine log. However when I try to change
> > the compatibility version at the cluster level the edit cluster dialog
> > box just hangs there. There are no log entries in the engine log. The
> > dialog box goes away when I click cancel. If I select 3.2 or 3.3 and
> > click OK nothing happens. This occurs either during normal running or
> > with hosts in maintenance mode.
> >
> > I would like to change to 3.3. Can you direct me to the sql table or cmd
> > line by any chance.
> 
> do not hack the db for such a change, you may skip important upgrade
> logic/validation.
> 
> >
> > Is this a known problem or something specific to my special setup.
> >   Actually my setup is pretty plain, see below or original post in this
> > thread.
> 
> sounds like a bug, at least for not telling you what is the error.
> omer - thoughts?
> 

if nothing happens when clicking ok it's usually some validation in the dialog,
can you check there is nothing highlighted in red (check also other tabs in the 
dialog)?

adding Tomas, might have a better idea.

you can try updating using rest api (change user/pass and cluster uuid):

curl -X PUT -H "Accept: application/xml" -H "Content-Type: application/xml" -u 
"admin@internal:password" 
"http://localhost:8080/api/clusters/dd746d43-4bd1-46aa-b97b-b7bad3f2e498"; -d 
""


> >
> > Engine 3.3.4-1.el6
> > CO6.5
> > Nodes are 3.0.4-1.0.201401291204.el6
> > Storage is SAN
> >
> >
> 
> 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Request for Wiki - dates

[Yedidyah Bar David]

- Original Message -
> From: "Sandro Bonazzola" 
> To: "Doron Fediuck" , "Bob Doolittle" 
> 
> Cc: "users" , "Yedidyah Bar David" 
> Sent: Friday, March 14, 2014 10:15:04 AM
> Subject: Re: [Users] Request for Wiki - dates
> 
> Il 14/03/2014 04:16, Doron Fediuck ha scritto:
> > 
> > 
> > - Original Message -
> >> From: "Bob Doolittle" 
> >> To: "Doron Fediuck" 
> >> Cc: "users" 
> >> Sent: Thursday, March 13, 2014 10:17:22 PM
> >> Subject: Re: [Users] Request for Wiki - dates
> >>
> >>
> >> On 03/13/2014 03:28 PM, Doron Fediuck wrote:
> >>>
> >>> - Original Message -
>  From: "Bob Doolittle" 
>  To: "users" 
>  Sent: Thursday, March 13, 2014 6:53:13 PM
>  Subject: [Users] Request for Wiki - dates
> 
>  Hi,
> 
>  As most are aware, there's a lot of information on the Ovirt Wiki that's
>  out of date. In spite of our best efforts, that will probably always be
>  true - it's the nature of Wikis.
> 
>  When I look for information on our Wiki, I never know where the most
>  current information is.
> 
>  I think it would be really helpful if someplace on each Wiki page was a
>  useful date to let us know the currency of the info. Probably the most
>  useful date is last-modified, although creation date might also be
>  useful. Maybe we could even map/display the date to the version number
>  of whatever the current stable release was at the time for context
>  (sometimes the content of a page calls out a particular version it's
>  addressing, but a lot of the time it does not).
> 
>  Just as an example, I want to find out about migrating my existing
>  configuration to self-hosted, using 3.4 RC2. A google search shows the
>  following links (in order shown):
> 
>  http://www.ovirt.org/Features/Self_Hosted_Engine
>  http://www.ovirt.org/Migrate_to_Hosted_Engine
>  http://www.ovirt.org/Hosted_Engine_Howto
>  ...
> 
>  I'm sure the Features page is ancient at this point. It's hard to tell
>  about the 2nd page.
> 
>  Of course the date a page was last modified doesn't directly indicate
>  how correct/current the information is, but there's a correlation.
>  Knowing the date would be useful in making a judgment. It might even
>  help the task of identifying and cleaning up obsolete pages.
> 
>  Easy to do?
> 
>  -Bob
> 
> >>> Hi Bob,
> >>> I'm not against it and I'm aware of the fact that pages tend to become
> >>> out
> >>> of date.
> >>> Since every page has a history as you can see in the attached, adding
> >>> another date
> >>> seems needles.
> >>>
> >>> What do you think?
> >> Hi Doron,
> >>
> >> I was thinking of something very simple - a clear text date on ever page
> >> on the Wiki.
> >>
> >> I can't see anything that looks like your attached picture of menus on
> >> this page, for example:
> >> http://www.ovirt.org/Features/Self_Hosted_Engine
> >>
> >> Do you have to log in to see that menu? If so, that's not very helpful
> >> to those without accounts...
> >>
> >> -Bob
> >>
> > 
> > Hi Bob,
> > so for that we have the update date:
> > 
> > Current status
> >  Initial POC devel
> >  Last updated: March 13, 2014
> 
> 
> There is an ongoing discussion about adding correct edit dates to all wiki
> pages
> http://lists.ovirt.org/pipermail/infra/2014-February/005448.html

Indeed. Last post in that thread [1] is from 3 weeks ago. Any news about that?

[1] http://lists.ovirt.org/pipermail/infra/2014-February/005502.html

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

Re: [Users] Request for Wiki - dates

[Yedidyah Bar David]

- Original Message -
> From: "Bob Doolittle" 
> To: "Doron Fediuck" 
> Cc: "users" 
> Sent: Thursday, March 13, 2014 10:17:22 PM
> Subject: Re: [Users] Request for Wiki - dates
> 
> 
> On 03/13/2014 03:28 PM, Doron Fediuck wrote:
> >
> > - Original Message -
> >> From: "Bob Doolittle" 
> >> To: "users" 
> >> Sent: Thursday, March 13, 2014 6:53:13 PM
> >> Subject: [Users] Request for Wiki - dates
> >>
> >> Hi,
> >>
> >> As most are aware, there's a lot of information on the Ovirt Wiki that's
> >> out of date. In spite of our best efforts, that will probably always be
> >> true - it's the nature of Wikis.
> >>
> >> When I look for information on our Wiki, I never know where the most
> >> current information is.
> >>
> >> I think it would be really helpful if someplace on each Wiki page was a
> >> useful date to let us know the currency of the info. Probably the most
> >> useful date is last-modified, although creation date might also be
> >> useful. Maybe we could even map/display the date to the version number
> >> of whatever the current stable release was at the time for context
> >> (sometimes the content of a page calls out a particular version it's
> >> addressing, but a lot of the time it does not).
> >>
> >> Just as an example, I want to find out about migrating my existing
> >> configuration to self-hosted, using 3.4 RC2. A google search shows the
> >> following links (in order shown):
> >>
> >> http://www.ovirt.org/Features/Self_Hosted_Engine
> >> http://www.ovirt.org/Migrate_to_Hosted_Engine
> >> http://www.ovirt.org/Hosted_Engine_Howto
> >> ...
> >>
> >> I'm sure the Features page is ancient at this point. It's hard to tell
> >> about the 2nd page.
> >>
> >> Of course the date a page was last modified doesn't directly indicate
> >> how correct/current the information is, but there's a correlation.
> >> Knowing the date would be useful in making a judgment. It might even
> >> help the task of identifying and cleaning up obsolete pages.
> >>
> >> Easy to do?
> >>
> >> -Bob
> >>
> > Hi Bob,
> > I'm not against it and I'm aware of the fact that pages tend to become out
> > of date.
> > Since every page has a history as you can see in the attached, adding
> > another date
> > seems needles.
> >
> > What do you think?
> Hi Doron,
> 
> I was thinking of something very simple - a clear text date on ever page
> on the Wiki.
> 
> I can't see anything that looks like your attached picture of menus on
> this page, for example:
> http://www.ovirt.org/Features/Self_Hosted_Engine
> 
> Do you have to log in to see that menu? If so, that's not very helpful
> to those without accounts...

1. So create an account, it's free :-)

2. It's indeed *shown* only to logged in users, but the links are accessible
to everyone. You can "guess" them by looking at any other mediawiki site.
E.g. for this page, the history one is:

http://www.ovirt.org/index.php?title=Features/Self_Hosted_Engine&action=history

(You'll still need to be logged in in order to edit a page).

Not sure why this is so - probably the default of the theme used there or
something like that.
-- 
Didi
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [Users] Migrate simple configuration to self-hosted

[Yedidyah Bar David]

- Original Message -
> From: "Doron Fediuck" 
> To: "Bob Doolittle" 
> Cc: "users" , "Sandro Bonazzola" , 
> "Yedidyah Bar David" 
> Sent: Thursday, March 13, 2014 9:23:03 PM
> Subject: Re: [Users] Migrate simple configuration to self-hosted
> 
> 
> 
> - Original Message -
> > From: "Bob Doolittle" 
> > To: "users" 
> > Sent: Thursday, March 13, 2014 8:25:51 PM
> > Subject: [Users] Migrate simple configuration to self-hosted
> > 
> > Hi,
> > 
> > I want to migrate my existing deployment to self-hosted. I have a simple
> > deployment:
> > 
> > A: Machine Fedora 20
> > B: libvirt VM (hosted on A) RHEL 6.5 running Engine 3.3.4-1
> > C: Machine RHEL 6.5 acts as Hypervisor/Host/Node (VDSM 4.13.3-4)
> > 
> > ISO NFS Domain is on B
> > Data (Master) NFS Domain is on C
> > 
> > I want to migrate VM B to Machine C, as self-hosted, and free up Machine A
> > 
> > When I look at these instructions:
> > http://www.ovirt.org/Migrate_to_Hosted_Engine
> > 
> > It starts with "I installed a new host with fedora 19".
> > 
> > I don't understand this. Won't most people doing this migration want to
> > start with their existing Hypervisor/Host/Node, and migrate their Engine
> > to it? Do I really need a new 3rd machine, when my goal is to free up
> > one of my 2 existing machines?

This document assumes the most trivial settings, where the only thing you
care about is simplicity, stability and minimizing downtime. It specifically
does not try to use the minimum hardware possible.

> > 
> > Or can I go ahead and assume these instructions are fine to apply to an
> > existing Host already running VDSM 4.13.3-4?

Not necessarily. I can definitely tell you that I stumbled into various
problems during testing when trying to deploy a "dirty" host. Current deploy
assumes a clean host, and might or might not work on an existing, in-use one.

> > 
> > I would have (naively?) imagined that the typical migration would be
> > something like:
> > 
> > 0. Upgrade Engine and Host to 3.4
> > 1. Create a new VM

You probably mean a new VM managed by your existing oVirt engine, not a
new libvirt VM on host A.

> > 2. Install OS on new VM, start it up
> > 3. Backup current Engine
> > 4. Stop current Engine (leave Host and VM running), change hostname
> > (local and DNS), maybe power off for good luck until done

More important is to disable relevant services (ovirt-engine, maybe others)
from starting on reboot. It would be rather bad if you start it up after the
new engine is up and two engines try to manage the same resources.

> > 5. Login to new VM (probably using ssh unless there's a way to connect
> > directly to the VM via Spice/VNC while the Engine is down) to:
> >  A. Assign previous Engine hostname to it (local and DNS), possibly
> > reboot

No need to change hostname (also on the old host, for that matter). You just
have to make sure that the dns points at the new machine's IP address.

> >  B. Set it up as a self-hosted Engine

That's the tough part. How are you going to do that? 'hosted-engine --deploy'
will not help you here, it's not designed for this scenario. It creates the
VM by itself.

> >  C. Restore backup to it
> >  D. Start up new engine
> > 
> > What am I missing?

I can think of several different directions:

Direction 1
===
Most similar to what you intended.
0. Upgrade to 3.4
1. Run 'hosted-engine --deploy' on C . As I said, this has a good chance
to not work and/or cause other problems - do not try this if you care
about uptime and without good backups.
This will create a VM for you. Install OS+engine inside it, use backup
and restore to migrate the engine itself, with the dns/disabling/etc
as you described (and as described in the wiki).

That's an interesting direction to take, but will probably require some
manual fixes etc., if successful at all.

Direction 2
===
If you do not care about uptime - the simplest.

Backup everything(!) - engine VM, other VMs, etc., then start from scratch:
Reinstall OS on host C, install and deploy hosted-engine there, restore
actual engine data from backup as described in the wiki.

Direction 3
===

Most complex, but might be quite risk-free, and require less downtime.

1. Create a new oVirt VM on C, install OS+engine on it, and backup/restore
engine data from B to this new machine. Let's call it TempEngine.

Technically speaking, at this poing, you'll get a self-hosted engine.
But nothing will know about that except you. So now you want to migrate
to "real" hosted engine. Now that you freed up machine A, you can use it
as a temporary host to do that.

For the future, it might make sense to add some tool/function to allow
doing that without more migrations - just somehow tell the engine that it's
running in a VM hosted by a host it manages itself, and that it should
treat it as expected (including adding HA and whatever). You are welcome to
open an RFE bug if you care...

2. Reinstall host A with a supported OS, install and deplo

Re: [Users] Source code unerstanding

[Moti Asayag]

- Original Message -
> From: "aditya mamidwar" 
> To: users@ovirt.org, engine-de...@ovirt.org
> Sent: Friday, March 14, 2014 5:09:49 PM
> Subject: [Users] Source code unerstanding
> 
> 
> Hey,
> 
> is there a simpler way to know which code is responsible for which module of
> the engine.
> is there a documentation maintained. or how can identify the files which are
> important for me.
> 

Here is a place to start:
https://www.ovirt.org/Category:Architecture

And specifically for the backend:
https://www.ovirt.org/Backend_modules_bll

> --
> -Aditya Mamidwar
> 
> ___
> 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: [Users] Instructions to add a remote controlled power strip not in the native list?

[Yedidyah Bar David]

> From: "David Smith" 
> To: "Marek Grac" 
> Cc: users@ovirt.org
> Sent: Friday, March 14, 2014 7:21:48 PM
> Subject: Re: [Users] Instructions to add a remote controlled power strip not
> in the native list?

> Hi Marek,

> that link requires a redhat login..

Here: 
http://lists.ovirt.org/pipermail/users/2014-January/019655.html 

(Exactly one month ago I sent this link replying to the same question. 
Perhaps better to put this info on the wiki). 
-- 
Didi 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users