On Mon, May 29, 2017 at 2:25 PM, Andy Gibbs <andyg1001(a)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)
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.
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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/users