VirtIO Drivers And CentOS 5.4(Final)

Home » CentOS » VirtIO Drivers And CentOS 5.4(Final)
CentOS 15 Comments

Hi All

My guest is a CentOS 5.4 VM:

[root@localhost ~]# uname -a Linux localhost 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64
x86_64 x86_64 GNU/Linux
[root@localhost ~]# cat /etc/*release CentOS release 5.4 (Final)

I wanted to know if the virtio drivers on this guest are stable.

The reason for asking this question is that i found this link:

http://wiki.libvirt.org/page/Virtio

which states that in order to use the virtio drivers i need to be using the kernel >=2.6.25 , but i am using the kernel version 2.6.18 in my guest VM. I am actually able to use the virtio drivers in my VM even with this kernel version and hence i wanted to know if they are stable to be used.

Did red hat backport these drivers to CentOS 5.4 ? If yes , Can you please point me to any bug to track this backport activity or any announcement of this backport task ? I need that to show to my team so that we can release note this information as part of releasing our product.

Appreciate your help in this regard.

Thanks Jatin

15 thoughts on - VirtIO Drivers And CentOS 5.4(Final)

  • Am 06.05.2015 um 09:33 schrieb Jatin Davey :

    Best practice: update to the latest OS version:

    # cat /etc/redhat-release CentOS release 5.11 (Final)

    Latest kernel package is stable:

    # rpm -q kernel kernel-2.6.18-404.el5

    # rpm -q kernel –changelog | grep -i virtio | grep -i backp
    – [virtio] console: Backport driver for RHEL 5.6 (Amit Shah) [620037]

  • Thanks Leon,

    I cannot upgrade the OS in the guest as it is being used in production environments and customers would not be comfortable with the entire OS
    upgrade.

    This is the output that i get when i check about the backporting of the virtio drivers.

    ***********************
    [root@localhost ~]# rpm -q kernel –changelog | grep virtio
    – [xen] virtio: do not statically allocate root device (Mark McLoughlin
    ) [501468]
    – [xen] virtio: add PCI device release function (Mark McLoughlin ) [501468]
    – [net] virtio_net: mergeable receive buffers (Mark McLoughlin ) [473120]
    – [net] virtio_net: jumbo frame support (Mark McLoughlin ) [473114]
    – [xen] virtio_net: some relatively minor fixes (Mark McLoughlin ) [468034]
    – [xen] virtio: include headers in kernel-headers package (Eduardo Pereira Habkost ) [446214]
    – [xen] virtio: add PV network and block drivers for KVM (Mark McLoughlin ) [446214]
    *************************

    Do you think if i am safe to keep using the virtio drivers within the same kernel ?

    Thanks Jatin

  • So they are comfortable not maintaining security?

    If you look at this page .. that install is susceptible to every issue on that page since page 75 (if the other components are also at the same level as that kernel):

    https://rhn.redhat.com/errata/rhel-server-errata.html

    There are literally 75 pages of updates at 25 updates per page or about
    1875 updates to CentOS-5 that are unapplied.

    Of those updates, 23 pages (or 575 updates) are security updates.

    Just these two alone are worth upgrading for:

    https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt

    https://isc.sans.edu/forums/diary/Samba+vulnerability+Remote+Code+Execution+CVE20150240/19373/

    You have several hundred more Critical or Important security updates outstanding. If that box touches the Internet in any way, it is likely compromised. Just in the last 6 months there are 21 Important or Critical updates.

    Thanks, Johnny Hughes

  • That is an important qualifier: *If* that box touches the Internet in any way. Although one might add that attacks on the LAN can be nastier since there usually is local access.

    While I’m all for keeping machines current, there are production environments where upgrading is a huge pain or outright impossible. Where any upgrades need to undergo a rigorous QA process. Where an outdated environment including equally outdated production tools needs to be maintained, on the chance e.g. that a customer return requires reworking an old part. I would consider it part of list etiquette to not second-guess those who for one reason or another make a conscious decision to stick to a particular environent.

    I will no doubt be told that CentOS 5.4 = CentOS 5.11 = CentOS 5, ie. the same OS, but this is not strictly true. For example, it would appear that autofs breakage and performance loss is at a minimum in 5.4.

    There :)

  • Am 06.05.2015 um 13:04 schrieb lhecking@users.sourceforge.net:

    +1

    updating vs upgrading?

    and such “impossible” cases are rare compared to the majority of EL OS installations. Saying that because the implicitness should be systems in a current state and not contrariwise.

    the solution: automation

    they are also unconscious decisions based on missing information :-)

    regressions exist also in cases where some one stick on an old version. I remember that nscd was consuming the whole memory – fixed in later minor OS versions …

    :-)

  • Leon Fauster wrote:

    And a) the manager who made the decision to not upgrade needs to be made aware of a) the dangers of *not* upgrading; b) the minimal risks up an upgrade (security & bugfixes), and c) needs to stop coming up with impossible schedules and put time into that least sexy thing of all, maintenance of infrastructure.

    And I, personally, would want an email from aforesaid manager telling me not to do any upgrades, which I would print out in several copies and put in a secure place….

    mark “CYA”

  • You do not understand the situation I presented. This is about avoiding a situation where in a highly complex envirnoment, due to a quirk in one of the dozens of tools involved in designing your product, the product suddenly changes because libc was updated to a newer rev. So you keep your design environment static – all parts of it. We’re talking business process here, not some stand-alone, uninformed PHB decision.

  • I can understand you – on a smaller scale…

    I have a couple of boxes with NVIDIA cards and fancy screen setup. I have to use NVIDIA proprietary driver, open source driver does not support configuration. Darn Nvidia never released enough information about their chip’s internals for open source developers to be able to write more versatile driver. I hate Nvidia for that. I love their competitor ATI: not only open source driver is way better, their proprietary drivers are consistently less buggy, and the same can be said about chips, at least I’ve never seen artifacts on ATI cards, I’ve seen artifacts on NVIDIA
    based cards a few times.

    Now, back to my boxes. NVIDIA declared these fancy cards obsolete (the are only about 6 years old, and hardware still does appropriate job for what we need). There is no proprietary NVIDIA driver which you can install with latest kernels (latest speaking CentOS 6 kernels). You know you have to compile kernel interface for their binary driver. No way: no updated binary driver for these my obsoleted by NVIDIA cards. So, NVIDIA locked me on these boxes to older kernel.

    So, how would you like this company after that!?

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Valeri Galtsev wrote:

    There is a proprietary driver package that you can build that will support them. I have a Guadro 4000 aka GL100GL on my workstation, and am running
    6.6 current, and NVIDIA-Linux-x86_64-310.40.run, which you can still d/l from NVida’s site, for it (I need the proprietary for two screens).

    Hope that helps.

    mark

  • Am 06.05.2015 um 16:28 schrieb lhecking@users.sourceforge.net:

    I am on your site – but this approach (your word, static) is also a goal of an enterprise operation system. So, your argument is valid but
    rare in the above example (libc breakage, enterprise context).

  • Thanks Mark! Will try.

    As someone said: you don’t need to know everything. You just need to know right person to ask ;-)

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Akemi Yagi wrote:
    install have to am running Thanks, Akemi, that’s really useful, and I’d never heard of it. I suppose that as it gets updated, it’ll tell me the most current legacy to use (in my case, the 310.40 worked, but the 340.58 did not… and that was trial and error.

    mark

  • It’s all in the README that comes with the driver … once upon a time, I wrote a script to extract driver info for the installed card (not on CentOS), but nvidia-detect is arguably better.