[Users] Discussion... work appears to be needed in areas of recovery and cleanup

2013-02-14 Thread Rick Beldin
Hi...

I've been working with both RHEV and Ovirt and can see distinct changes
and improvements with regards to how Ovirt is emerging and changing.

One area that still disturbs me is in the area of recovery and cleanup,
specifically around the ovirt-engine (rhevm) node.

I've observed a few things about the project:

- backup of a engine db seems to be a fairly manual process
  with many steps.  There are many files listed that need to be backed
  up manually as listed in the RHEVM admin manual. pg_dump seems to
  automate the dumping of the db, but other config files are left up
  to the admin.

- restoration appears to be equally complex

- engine-cleanup (rhevm-cleanup) doesn't always cleanup

- there appear to be instances where the only way to get a solid base
  is reinstallation.  I've removed and reinstalled components so many
  times it is now second nature.  ;)

I'm curious about:

- Are there technical issues (beyond the code not being written yet) that
  prevent backup and restore procedures from working correctly to save
  and restore an engine environment?   I would expect that a test for
  that operation would be to setup an environment, take a snapshot,
  and restore the whole thing to another management node.

- Are all the config files properly identified?  The RHEVM Admin
  manual has an extensive list but is it exhaustive?

- What technically prevents engine-cleanup from really *cleaning*
  a system?  My expectation would be that I should be able to run
  engine-cleanup and completely wipe out the setup.  All databases,
  certs, config files and the like returned to their original,
  pristine state.   Perhaps another script - engine-restore-defaults? -
  needs to go beyond where engine-cleanup goes today?

As a support professional, these are areas that I think warrant
investment and I wonder what is gating the development here.

Thanks,

Rick


-- 
+--+
| Rick Beldin|  Hewlett-Packard Company|
| email: rick.bel...@hp.com  | |
|TCEQ - Linux ERT   |   Windward Parkway West |
||  Alpharetta, GA 30004   |
+--+
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] Adding Iscsi storage to Ovirt All-in-one config

2013-01-14 Thread Rick Beldin

On 01/13/2013 02:09 AM, Itamar Heim wrote:
 On 01/13/2013 01:25 AM, Tom Brown wrote:
 you still can't mix different types of storage (local/iscsi) in same DC, so
 you need to add another DC for the hosts which will use the iscsi storage.


Thanks for pointing this out. I missed a major conceptual point here.

Does this mean you might as well not have any local storage on a node
beyond that to support the hypervisor?

How do you move the virtual disks already deployed on one type of storage
to another?  While not common, I could expect this activity to occur as
organizations grow their environment.

Thanks,

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


Re: [Users] What do you want to see in oVirt next?

2013-01-07 Thread Rick Beldin
Several topics come to mind:

- cleaner work-flow in creating and associating storage, especially NFS

- better error reporting from engine back to admin user during admin operations.

- the ability to have users access consoles of virtual machines whereever
  they may be.  I think it should be expected that limited access data centers
  will be everywhere, from complete NAT'd environments to some with external
  firewalls that limit some ports.   This should be part of engine and
  hypervisor installation, and transparent to the end user.


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