[ovirt-users] Greetings and observations from an oVirt noob

Ken Marsh kenskyfish at gmail.com
Fri Dec 4 21:35:48 UTC 2015


Hi again,

Sorry for not getting back to you sooner.

I did read all that stuff, but what was totally unclear to me I finally 
understood from the Red Hat documentation. It's just the concept that an 
oVirt node's storage isn't used for VMs. I never would have guessed that 
in a million years.

Here's my situation - I have a bunch of Xeon workstations, each with 2TB 
HDD. I'd like to use them as both RHEV nodes AND use their HDD for 
storage. If I understand correctly, I can't do that. I'll need to set 
some up with RHEL 6.5 and share the storage, and I'll need to set others 
up as RHEV nodes to run the VMs. On the RHEL machines the CPU will go to 
waste and on the RHEV nodes the disk space goes to waste. Is this right?

The confusion I had about the hypervisor version is because when you are 
booting the 3.5 hypervisor, it says in the splash screen "oVirt 3.2.1". 
I'd much rather it said "Press F1 to see something useful," but now that 
I've figured this out I'm very happy with it.

I'm still learning and the more I learn the more I like. It's just so 
conceptually different from VMWare, and the doco and naming conventions 
seem to take the general concept for granted. Is the VM's disk really 
used over the network and not locally copied to the oVirt node where it 
runs? I guess in a purely datacenter environment that makes sense but I 
was hoping to make use of the storage on nodes too.

I think better I keep learning about it and when I understand 
completely, then I'll make suggestions on how to add/change the 
documentation. That would probably be more helpful, right?

Thanks again - amazing product. I'm enjoying this despite the initial 
confusion and trial-and-error learning.




On 23/11/15 17:27, Yedidyah Bar David wrote:
> On Mon, Nov 23, 2015 at 3:17 AM, Kenneth Marsh <kenskyfish at gmail.com> wrote:
>> Hello all,
>>
>> I do development operations for a part of a software division of a large
>> multinational. I'm an experienced user of VMWare and Amazon AWS, soon to be
>> pushed onto Azure, and I've found a common thread among all solutions - they
>> are all expensive enough that my budget will certainly not be approved with
>> them. I'm deferred to the IT part of the organisation, which operates too
>> slowly and inefficiently (in terms of both cost and time) for my
>> requirements. This is what led me to RHEV, and ultimately to oVirt. This is
>> a feasibility study for what may ultimately be a RHEV-based data center in a
>> new office, and if I succeed we will be doing more on a fixed budget by
>> using more RHEV and less Azure.
>>
>> I spent the weekend working with oVirt and I'm very impressed. I had no idea
>> such a comprehensive enterprise-class solution was even available. Being a
>> complete newcomer, I started without a clue and after a weekend had set up a
>> nearly-working data centre including an oVirt hypervisor node, all on old
>> Dell notebooks loaned to me temporarily by our IT group. I started with RHEV
>> but decided to use oVirt for two reasons - one being to see what's possible
>> with the latest and greatest, the other because RHEV required some licensing
>> I've not yet purchased. Long term it'll have to be RHEV for enterprise
>> support reasons I'm sure many are familiar with.
>>
>> There are a few things I found, from a newcomer's perspective, very unclear.
>>
>> What is oVirt, vs oVirt engine, vs oVirt node, vs oVirt host. Try to find
>> documentation on any of these and get spammed with references to the others.
>> I think I've worked out that these are the collective suite of products, the
>> management centre, the bare-metal hypervisor, and participating member
>> servers, respectively.
> You got it mostly right.
>
> Did you have a look at [1]?
>
> The engine is the process that manages the whole thing. It exposes an admin
> interface (web+api), monitors the hosts and VMs, etc.
>
> A host and node are where VMs run. In many cases these terms are
> interchangeable,
> although usually "node" is a host installed with the ovirt-node image, whereas
> an "ovirt host" is a host installed with a "normal" OS and later provisioned to
> be used (by installing stuff on it, usually using the "New Host" wizard in the
> web ui).
>
> [1] http://www.ovirt.org/Architecture
>
> Also adding Mikey.
>
>> Which versions of CentOS/Fedora/oVirt Node are compatible at which oVirt
>> compatibility level? This would normally be addressed in the release notes.
> I assume you refer to 3.6, released a few weeks ago.
>
> The release notes page [2] does mention specific versions of fedora
> and el. I agree
> it could be written more clearly. The Download page [3] lists them too.
>
> [2] http://www.ovirt.org/OVirt_3.6_Release_Notes
> [3] http://www.ovirt.org/Download
>
>> It was also confusing to discover oVirt node 3.2.1 is compatible at the 3.5
> 3.2.1? Where is this one referenced?
>
> RN [2] has a section "ovirt node" with links to pre-release (has
> ovirt-node-iso-3.6-0.999.201510221942) and final (still empty).
>
> Adding Fabian.
>
>> level. The answer to this remains unclear but I'm trying to use Fedora 22
>> across the board now with oVirt node 3.2.1 and this seems to be working,
>> although I haven't gotten a server node into a cluster yet, only oVirt
>> nodes.
> Not sure I fully understand. ovirt node includes its own OS, and IIUC we only
> ship one based on el7. Technically it's probably possible to build one with
> fedora, never tried that.
>
>> Storage domains - much doco about them being needed and how to configure
>> them but nothing about what they are or why they are needed. I would have
> Architecture [1] above does have some text about that, and links at [4] which
> has more.
>
> Some more info:
>
> Generally speaking, and until 3.5, storage was separated from what we call
> "compute nodes" (those running VMs). You can bring your own external storage,
> be it a mere linux machine serving its disks through nfs/iscsi/etc., or some
> "dedicated" storage boxes (netapp/emc/etc.). You can also use gluster. The
> engine also manages gluster storage. In 3.6 there was some work to allow
> using the same hosts for both. Some of it was finished, some postponed
> to 4.0. You can check e.g. [5][6].
>
> [4] http://www.ovirt.org/Vdsm_Storage_Terminology
> [5] http://www.ovirt.org/Features/GlusterFS-Hyperconvergence
> [6] http://www.ovirt.org/Features/Self_Hosted_Engine_Hyper_Converged_Gluster_Support
>
>> expected an oVirt node to be capable of both data and ISO storage but
>> apparently there needs to be an NFS or iSCSI filesystem there first? And
>> there's local storage vs shared, another concept much talked about how to
>> prepare and add it but not explained why one would want to do that or what
>> it means.
>>
>> I think with further internet combing and by trial-and-error I'm very likely
>> to figure it all out. I hope all goes well and implement this stuff in our
>> new data centre and then I'd be keen to contribute some of my own tech
>> writing.
> You are very welcome :-)
>
>> Meanwhile, I hope to be active on this mailing list and I thank everyone in
>> advance for sharing their oVirt experience. For any who are looking at the
>> doco thanks much for the plethora of stuff out there already and I hope the
>> above bullet points help you understand where doco most needs more
>> attention. At least from the perspective of one who has just come across
>> oVirt.
> Have a nice oVirt journey and thanks for the report!
>
> Best regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20151205/9a34290c/attachment-0001.html>


More information about the Users mailing list