12:35 a.m.
This is a multi-part message in MIME format.
--------------030102090804010701010307
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
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(a)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_...
> 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,
--------------030102090804010701010307
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=utf-8"
http-equiv="Content-Type">
</head>
<body text="#003300" bgcolor="#FFFFFF">
<font face="Helvetica, Arial, sans-serif">Hi again,<br>
<br>
Sorry for not getting back to you sooner.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
Thanks again - amazing product. I'm enjoying this despite the
initial confusion and trial-and-error learning.<br>
<br>
<br>
<br>
<br>
</font>
<div class="moz-cite-prefix">On 23/11/15 17:27, Yedidyah Bar David
wrote:<br>
</div>
<blockquote
cite="mid:CAHRwYXt1+ENPCuevWhFaJ2C6PzE8VRo8B=m5+Hs-_5Jp-7+bCw@mail.gmail.com"
type="cite">
<pre wrap="">On Mon, Nov 23, 2015 at 3:17 AM, Kenneth Marsh <a
class="moz-txt-link-rfc2396E"
href="mailto:kenskyfish@gmail.com"><kenskyfish@gmail.com></a>
wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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] <a class="moz-txt-link-freetext"
href="http://www.ovirt.org/Architecture">http://www.ovirt.or...
Also adding Mikey.
</pre>
<blockquote type="cite">
<pre wrap="">Which versions of CentOS/Fedora/oVirt Node are
compatible at which oVirt
compatibility level? This would normally be addressed in the release notes.
</pre>
</blockquote>
<pre wrap="">
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] <a class="moz-txt-link-freetext"
href="http://www.ovirt.org/OVirt_3.6_Release_Notes">http://w...
[3] <a class="moz-txt-link-freetext"
href="http://www.ovirt.org/Download">http://www.ovirt.org/Do...
</pre>
<blockquote type="cite">
<pre wrap="">It was also confusing to discover oVirt node 3.2.1 is
compatible at the 3.5
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">
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] <a class="moz-txt-link-freetext"
href="http://www.ovirt.org/Vdsm_Storage_Terminology">http://...
[5] <a class="moz-txt-link-freetext"
href="http://www.ovirt.org/Features/GlusterFS-Hyperconvergence"...
[6] <a class="moz-txt-link-freetext"
href="http://www.ovirt.org/Features/Self_Hosted_Engine_Hyper_Converg...
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
You are very welcome :-)
</pre>
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
Have a nice oVirt journey and thanks for the report!
Best regards,
</pre>
</blockquote>
<br>
</body>
</html>
--------------030102090804010701010307--