Re: [Users] Instructions to add a remote controlled power strip not in the native list?

2014-03-16 Thread Yedidyah Bar David
 From: David Smith dsm...@mypchelp.com
 To: Marek Grac mg...@redhat.com
 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


Re: [Users] Source code unerstanding

2014-03-16 Thread Moti Asayag


- Original Message -
 From: aditya mamidwar aditya.mamid...@gmail.com
 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] Migrate simple configuration to self-hosted

2014-03-16 Thread Yedidyah Bar David
- Original Message -
 From: Doron Fediuck dfedi...@redhat.com
 To: Bob Doolittle b...@doolittle.us.com
 Cc: users users@ovirt.org, Sandro Bonazzola sbona...@redhat.com, 
 Yedidyah Bar David d...@redhat.com
 Sent: Thursday, March 13, 2014 9:23:03 PM
 Subject: Re: [Users] Migrate simple configuration to self-hosted
 
 
 
 - Original Message -
  From: Bob Doolittle b...@doolittle.us.com
  To: users users@ovirt.org
  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 deploy 

Re: [Users] Request for Wiki - dates

2014-03-16 Thread Yedidyah Bar David
- Original Message -
 From: Bob Doolittle b...@doolittle.us.com
 To: Doron Fediuck dfedi...@redhat.com
 Cc: users users@ovirt.org
 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 b...@doolittle.us.com
  To: users users@ovirt.org
  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_Engineaction=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] Request for Wiki - dates

2014-03-16 Thread Yedidyah Bar David
- Original Message -
 From: Sandro Bonazzola sbona...@redhat.com
 To: Doron Fediuck dfedi...@redhat.com, Bob Doolittle 
 b...@doolittle.us.com
 Cc: users users@ovirt.org, Yedidyah Bar David d...@redhat.com
 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 b...@doolittle.us.com
  To: Doron Fediuck dfedi...@redhat.com
  Cc: users users@ovirt.org
  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 b...@doolittle.us.com
  To: users users@ovirt.org
  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] affects of changing compatibility setting on running cluster

2014-03-16 Thread Omer Frenkel


- Original Message -
 From: Itamar Heim ih...@redhat.com
 To: Charles Weber chawe...@gmail.com
 Cc: ybronhei ybron...@redhat.com, Dan Kenigsberg dan...@redhat.com, 
 users@ovirt.org, Eli Mesika
 emes...@redhat.com, Sven Kieske s.kie...@mittwald.de, Omer Frenkel 
 ofren...@redhat.com
 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 ih...@redhat.com
  mailto:ih...@redhat.com 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 
clusterversion major=\3\ minor=\3\//cluster


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

2014-03-16 Thread Meital Bourvine
Hi Eric,

Inline

- Original Message -
 From: Eric Bollengier e...@baculasystems.com
 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] Self-hosted-engine setup error

2014-03-16 Thread Yedidyah Bar David
 From: Giuseppe Ragusa giuseppe.rag...@hotmail.com
 To: Yedidyah Bar David d...@redhat.com
 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 giuseppe.rag...@hotmail.com
 
  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

2014-03-16 Thread 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] Ovirt 3.4rc + Qemu Live snapshot : Problem to delete a Snapshot

2014-03-16 Thread 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 e...@baculasystems.com
To: Meital Bourvine mbour...@redhat.com
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

2014-03-16 Thread 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] Reimporting storage domains after reinstalling ovirt

2014-03-16 Thread Liron Aravot


- Original Message -
 From: Boudewijn Ector boudew...@boudewijnector.nl
 To: Liron Aravot lara...@redhat.com
 Cc: Jason Brooks jbro...@redhat.com, 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 boudew...@boudewijnector.nl
  To: Jason Brooks jbro...@redhat.com
  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 down immediately (immediately means within few seconds) 
and after the copy tasks 

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

2014-03-16 Thread 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 giuseppe.rag...@hotmail.com
To: Yedidyah Bar David d...@redhat.com
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 giuseppe.rag...@hotmail.com
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] adding scripts

2014-03-16 Thread 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 gsher...@redhat.com
 To: Aditya Mamidwar aditya.mamid...@gmail.com
 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 aditya.mamid...@gmail.com
 To: Einav Cohen eco...@redhat.com, Vojtech Szocs vsz...@redhat.com
 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 aditya.mamid...@gmail.com
  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] Migrate simple configuration to self-hosted

2014-03-16 Thread 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] Request for Wiki - dates

2014-03-16 Thread Bob Doolittle


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

- Original Message -

From: Bob Doolittle b...@doolittle.us.com
To: Doron Fediuck dfedi...@redhat.com
Cc: users users@ovirt.org
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 b...@doolittle.us.com
To: users users@ovirt.org
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_Engineaction=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] oVIRT3.3.3 Live Migration fails

2014-03-16 Thread 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] Host CPU type is not compatible with Cluster Properties

2014-03-16 Thread 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 : UNKNOWN.

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] Reimporting storage domains after reinstalling ovirt

2014-03-16 Thread 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
 c040505a-da58-4ee1-8e17-8e32b97656082014-02-03 18:05:14+01  \N
 15  

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

2014-03-16 Thread 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

2014-03-16 Thread 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