[ovirt-users] oVirt Live USB3 question

[Lev Veyde]

Hi Michael,

I'm glad that I could help.

Yes, while USB3 has an impressive interface (and thus potential) speed of
up to 5 gbps (or over 600 MB/sec) the actual hardware normally provides
speeds which for basic DOKs are even under USB 2.0 spec. in most cases
(under 60 MB/sec.).

However, as I also mentioned, it will only affect the time it takes to
load, and from my experience with any decent DOK it's quite OK, you don't
even have to invest into ultra-expensive and ultra-fast one, especially if
you don't plan to "re-burn" the DOK very often.

Thanks in advance,

On Mon, Jun 26, 2017 at 8:05 PM, Michael McConachie <
michael.mcconachie at hotmail.com> wrote:

> Lev,
>
>
> That's exactly what I thought; you hit all the points (including slow DOM
> SATA I type performance vs. USB3 speeds).  That's all I needed
> clarification on, before running down the rabbit hole.
>
>
> MM
>
>
>
> ------------------------------
> *From:* Lev Veyde <lveyde at redhat.com>
> *Sent:* Monday, June 26, 2017 4:00 PM
> *To:* Michael McConachie
> *Cc:* users at ovirt.org
> *Subject:* Re: [ovirt-users] oVirt Live USB3 question
>
> Hi Michael,
>
> oVirt-Live's basically functions as any other LiveCD, so no special
> differences here.
> Generally it means that necessary kernel/kernel modules/programs are
> loaded into RAM, and access to the image is needed if e.g. one wants to run
> some more programs.
> All writes are done into RAM.
>
> Note however that since the whole CD isn't copied into RAM, so you still
> need it to be accessible, e.g. have the USB DOK be inserted into the
> computer.
>
> As you already mentioned the oVirt-Live is designed to work in a sandboxed
> environment as far as the network is concerned.
> It was never designed nor tested to work with i.e. external storages, as
> in order to do so the network configuration will have to be modified.
>
> Regarding performance: we haven't tested it, but probably the oVirt-Live
> may take a bit more time to load when compared to normal installation.
> This is because USB DOKs are generally slower than SAS/SATA HDDs/SSDs.
> Once loaded however the performance will be similar and in some cases even
> greater, since all writes are done to the RAM.
> The price of this is of course that once the system is rebooted for
> whatever reason all data is lost.
>
> Hope it helped,
>
> On Sat, Jun 24, 2017 at 5:10 AM, Michael McConachie <
> michael.mcconachie at hotmail.com> wrote:
>
>> Hi all,
>>
>>
>> Potentially stupid question here. Sorry in advance if so.  I have always
>> built out full blown multi rack instances of oVirt, and RHEV for clients,
>> but the following question has me wondering before I go digging and trying
>> it out...
>>
>>
>> I realize that the oVirtLive ISO is for demo purposes, sandboxing, and
>> not production: I have a client, who is in need of a bootable AIO-based USB
>> install with the caveat of being able to connect to the computer's HD and
>> other external storage at that point (for the Storage and ISO domains that
>> I'll create afterwards).  This is because they have one BM to work with and
>> they don't want the extra overhead using an SSD HD slot. They don't want to
>> use a Sata DOM either if possible.
>>
>> In saying that, and concerning the oVirt LiveISO capabilities - I have
>> two questions.
>>
>>
>> - Does the AIO USB install load necessary runtimes into memory, similar
>> to esxi bootable USBs and utilize the base hardware afterwards so that the
>> rest of the operations are ran in memory, hitting the disk (USB in this
>> case) like a normal OS load when needed for kernel calls, etc..??
>>
>> - Are there a terrible performance costs if we stay with USB3 (which has
>> a ridiculous theoretical speed in certain hardware matching situations)?
>>
>>
>> Thanks in advance for anyone who might have already crossed this bridge
>> and can provide insight.
>>
>>
>>
>> Michael J. McConachie | keys.fedoraproject.org | PubKey: 0x7BCD88F8
>>
>> *NOTE: The information included and/or attached in this electronic mail
>> transmission may contain confidential or privileged information and is
>> intended solely for the addressee(s). Any unauthorized disclosure,
>> reproduction, distribution or the taking of action in reliance on the **contents
>> of the information are strictly prohibited. If you have received the
>> message in error, please notify the sender by reply transmission and delete
>> the message without copying, disclosing or forwarding.*
>>
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>
>
> --
>
> Lev Veyde
>
> Software Engineer, RHCE | RHCVA | MCITP
>
> Red Hat Israel
>
> <https://www.redhat.com>
>
> lev at redhat.com | lveyde at redhat.com
> <https://red.ht/sig>
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>



-- 

Lev Veyde

Software Engineer, RHCE | RHCVA | MCITP

Red Hat Israel

<https://www.redhat.com>

lev at redhat.com | lveyde at redhat.com
<https://red.ht/sig>
TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20170627/50a41e8e/attachment-0001.html>