[Users] oVirt ISO domain
One of the things that surprised me about oVirt/RHEV's design is the awful handling of ISO/vfd images files. One would expect to just point to an available ISO SMB/NFS share, and have the ISOs in it used. Instead, there's an horrible requirement of needing an empty NFS directory with the right permissions. If that's not unnecessary enough, forcing the user to log into the command line of an otherwise entirely graphical application, and then mount another NFS/SMB/block source or something to get the ISO, and then type the rhevm/engine-iso-uploader command to upload the image files, possibly to the same machine if the installer configured an ISO domain locally. It's completely unnecessary. The design should be changed such that the node could attempt mounting any given NFS/SMB share read-only for the ISO domain (and, even better, have the UI support SMB browsing). Presumably vdsm would have permission to at least read files in a mounted directory. This way, one can easily share a directory using windows/nautilus and have it used by oVirt; or use a graphical SFTP application to copy ISOs to the manager's NFS share. Any thoughts? -xrx ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Installing Host - action is taking longer than allowed by configuration
On 09/01/12 01:09, Alon Bar-Lev wrote: - Original Message - From: Mohsen Saeedimohsen.sae...@gmail.com To: users@ovirt.org Sent: Friday, August 31, 2012 11:57:59 PM Subject: [Users] Installing Host - action is taking longer than allowed by configuration ... The required action is taking longer than allowed by configuration. I know the reason for it. i have very slow connection. I think ovirt clean yum metadata and try to get metadata again. but my internet connection is very slow (about 64Kb/s) and takes a lot of time to finish. how can i increase the allowed time by configuration or some change on postgresql database.? Hi, You can set the SSHInactivityTimoutSeconds within vdc_options table. # psql -d engine -U postgres -c update vdc_options set option_value = 600 where option_name = 'SSHInactivityTimoutSeconds'; Is having a hard-coded timeout really a good idea? I have had the same problem; surely there must be a better way of implementing this than a timeout (which is essentially guessing how fast everyone's internet connection/machine would be)? Meanwhile perhaps the timeout should be changed to a very large value; and maybe even a mention of where the log is kept (/tmp/vds_bootstrap...) so the user can see the progress. -Rizvi ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [Users] Outage Update - www.ovirt.org and gerrit.ovirt.org
On 03/20/12 18:18, Ofer Schreiber wrote: www.ovirt.org and gerrit.ovirt.org are now up and running. We experienced two issues: 1. DB corruption on www.ovirt.org, caused by a full file system. 2. Faulty gerrit service, probably caused by #1. I highly recommend having Nagios (or it's fork Icinga) for server monitoring; it would have warned you of the FS being full well beforehand. -xrx Both issues were handled by oVirt infra team (mburns, quaid and myself) Thank you for your patience. Ofer Schreiber oVirt infra team ___ Arch mailing list a...@ovirt.org http://lists.ovirt.org/mailman/listinfo/arch ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[Users] oVirt/RHEV fencing; a single point of failure
Hello, I was worried about the high availability approach taken by RHEV/oVirt. I had read the thread titled Some thoughts on enhancing High Availability in oVirt but couldn't help but feel that oVirt is missing basic HA while it's developers are considering adding (and in my opinion unneeded) complexity with service monitoring. It all comes down to fencing. Picture this: 3 HP hypervisors running RHEV/oVirt with iLO fencing. Say hypervisor A runs 10 VMs, all of which are set to be highly available. Now suppose that hypervisor A has a power failure or an iLO failure (I've seen it happen more than once with a batch of HP DL380 G6s). Because RHEV would not be able to fence the hypervisor as it's iLO is unresponsive; those 10 HA VMs that were halted are NOT moved to other hypervisors automatically. I suggest that oVirt concentrates on having support for multiple fencing devices as a development priority. SCSI persistent reservation based fencing would be an ideal secondary, if not primary, fencing device; it would be easy to set up for users as SANs generally support it and is proven to work well, as seen on Red Hat clusters. I have brought up this point about fencing being a single point of failure in RHEV with a Red Hat employee (Mark Wagner) during the RHEV virtual event; but he said that it is not. I don't see how it isn't; one single loose iLO cable and the VMs are stuck until there is manual intervention. Any thoughts? -xrx ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
