[ovirt-users] Unable to add storage domains to Node Hosted Engine

Tue May 30 06:45:06 UTC 2017

> On 30 May 2017, at 08:31, Yaniv Kaul <ykaul at redhat.com> wrote:
> 
> 
> 
> On Mon, May 29, 2017 at 2:25 PM, Andy Gibbs <andyg1001 at hotmail.co.uk <mailto:andyg1001 at hotmail.co.uk>> wrote:
> On 29 May 2017 08:22, Sandro Bonazzola wrote:
> > Hi, so if I understood correctly, you're trying to work on a single host
> > deployment right?
> > Or are you just trying to replace the bare metal all-in-one 3.6 in a context
> > with more hosts?
> > If this is the case, can you share your use case? I'm asking because for
> > single host installations there are other solutions that may fit better than
> > oVirt, like virt-manager or kimchi (https://github.com/kimchi-project/kimchi <https://github.com/kimchi-project/kimchi>)
> 
> Sandro, thank you for your reply.
> 
> I hadn't heard about kimchi before.  Virt-manager had been discounted as the user interface is not really friendly enough for non-technical people, which is important for us.  The simple web interface with oVirt, however, is excellent in this regard.
> 
> I would say that the primary use-case is this: We want a server which individual employees can log into (using their active directory logins), access company-wide "public" VMs or create their own private VMs for their own use (if permitted).  Users should be able to start and stop the "public" VMs but not be able to edit or delete them.  They should only have full control over the VMs that they create for themselves.  And very importantly, it should be possible to say which users have the ability to create their own VMs.  Nice to have would be the ability for users to be able to share their VMs with other users.  Really nice to have would be a way of detecting whether VMs are in use by someone else before opening a console and stealing it away from the current user!  (Actually, case in point, the user web interface for oVirt 3.6 always starts a console for a VM when the user logs in, if it is the only one running on the server and which the user has access to.  I don't know i
>  f this is fixed in 4.1, but our work-around is to have a dummy VM that always runs and displays a graphic with helpful text for any that see it!  Bit of a nuisance, but not too bad.  We never found a way to disable this behaviour.)
> 
> This sounds like a bug to me, if guest agent is installed and running on the guest.
> I'd appreciate if you could open a bug with all relevant details.

nothing to do with agent but rather the “connect automatically” checkbox per user. Just uncheck it for the user.
You may also check out https://github.com/oVirt/ovirt-web-ui for a modern simplified user portal. It’s not fully complete, it’s missing this “connect automatically” functionality, so it’s perfect for you:)

Thanks,
michal

> 
> 
> We started off some years ago with a server running oVirt 3.4, now running 3.6, with the all-in-one plugin and had good success with this.  The hosted engine for oVirt 4.1 seemed to be the recommended "upgrade path" -- although we did also start with entirely new server hardware.
> 
> Ultimately once this first server is set up we will want to convert the old server hardware to a second node so that we can balance the load (we have a number of very resource-hungry VMs).  This would be our secondary use-case.  More nodes may follow in future.  However, we don't see the particular need to have VMs that migrate from node to node, and each node will most likely have its own storage domains for the VMs that run on it.  But to have one central web interface for managing the whole lot is a huge advantage.
> 
> Coming then to the storage issue that comes up in my original post, we are trying to install this first server platform, keeping the node, the hosted engine, and the storage all on one physical machine.  We don't (currently) want to set up a separate storage server, and don't really see the benefit of doing so.  Since my first email, I've actually succeeded in getting the engine to recognise the node's storage paths.  However, I'm not sure it really is the right way.  The solution I found was to create a third path, /srv/ovirt/engine, in addition to the data and iso paths.  The engine gets installed to /srv/ovirt/engine and then once the engine is started up, I create a new data domain at node:/srv/ovirt/data.  This then adds the new path as the master data domain, and then after thinking a bit to itself, suddenly the hosted_storage data domain appears, and after a bit more thinking, everything seems to get properly registered and works.  I can then also create the ISO storag
>  e domain.
> 
> Does this seem like a viable solution, or have I achieved something "illegal"?
> 
> Sounds a bit of a hack, but I don't see a good reason why it wouldn't work - perhaps firewalling issues. Certainly not a common or tested scenario.
>  
> 
> I am still not having much luck with my other problem(s) to do with restarting the server: it still hangs on shutdown and it still takes a very long time (about ten minutes) after the node starts for the engine to start.  Any help on this would be much appreciated.
> 
> Logs would be appreciated - engine.log, server.log, perhaps journal entries. Perhaps there's race between NFS and Engine services?
> Y.
>  
> 
> Thanks
> Andy
> _______________________________________________
> Users mailing list
> Users at ovirt.org <mailto:Users at ovirt.org>
> http://lists.ovirt.org/mailman/listinfo/users <http://lists.ovirt.org/mailman/listinfo/users>
> 
> _______________________________________________
> Users mailing list
> Users at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170530/4d634072/attachment.html>