SCIENTIFIC-LINUX-USERS Archives

April 2012

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Oleg Sadov <[log in to unmask]>
Reply To:
Oleg Sadov <[log in to unmask]>
Date:
Wed, 18 Apr 2012 15:37:07 +0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (98 lines)
If we are talking about included to SL6/RHEL6 KVM, this hypervisor does
not support paravirtualization for CPU (like Xen) -- only x86 hvm
virtualization (vt/svm instructions set), but may support
paravirtualization for device drivers.

For example, you may connect USB3 storage to VM as a VirtIO disk device.
Direct mapping of hosts xHCI USB controller to VMs QEMU uHCI USB
controller is possible too, but as I remember, USB3 devices may be not
visible through such mapping.

16/04/2012 07:03 -0400, Rich wrote:
> That would either require it be paravirtualized to run the newer
> kernel (e.g. the same version as the host), which doesn't solve any of
> his problems with  SL6 kernel on SL5 userland, or fully virtualized
> and he still runs a custom kernel in the VM.
> 
> Either way, virtualizing this doesn't solve the problem he's trying to
> solve, unless I missed something.
> 
> [Did you mean chroot?]
> 
> - Rich
> 
> On Mon, Apr 16, 2012 at 6:48 AM, Oleg Sadov <[log in to unmask]> wrote:
> > 15/04/2012 17:06 -0700, Konstantin Olchanski wrote:
> >> On Sun, Apr 15, 2012 at 02:46:49PM -0500, Kevin K wrote:
> >> > Depending on what special features you might use on your system
> >> (virtualization, third party drivers), it might be possible to build a
> >> kernel from kernel.org.  I've tried this in the past but since the
> >> latest kernel still didn't properly support the broken hardware I
> >> didn't pursue it further.
> >>
> >>
> >> Yes, what you say is possible. I run a few SL5 machines with a custom
> >> built 2.6.34 kernel (the funny hardware requires non-default access
> >> method to PCI config space).
> >>
> >> Last I remember, it was not too hard to build a vanilla linux kernel that
> >> booted the SL5 userland. I do remember a few gotchas - some boot scripts expected
> >> some drivers to be loadable modules (I had them compiled into the kernel),
> >> autofs did not work because /dev/random broke (SL5 kernel uses the network
> >> as source of randomness, but vanilla kernel does not, and there is no other
> >> hardware present in the system). Took maybe half a day to sort this all out.
> >> (I am not looking forward to repeat this with the 3.x kernels).
> >>
> >>
> >> > On Apr 15, 2012, at 1:46 PM, Keith Lofstrom wrote:
> >> >
> >> > > I'm running S.L. 5.6 on a few machines, and have grown somewhat
> >> > > dependent on it.  However, there are features in the kernel
> >> > > that comes with 6.2 (like USB3) which I would like to have.
> >> > >
> >> > > Is it possible to upgrade just the kernel and associated modules
> >> > > and "miscellaneous"?
> >> > >
> >> > > I assume this is tricky, and fraught with dangers, and the usual
> >> > > cautions (make backups, work on a copy of the disk, tweak yum
> >> > > updates so they won't regress the 2.6.32 kernel, etc) apply.
> >>
> >>
> >> I do not see any danger or special caution - if an SL6 kernel would boot
> >> SL5 userland, it should run okey. But you will run into trouble with
> >> userland stuff required to support the kernel - udev, mkinitrd, mdadm & co -
> >> the SL5 stock tools might be too old for the recent kernels.
> >>
> >> That said, where I am, lack of support for new hardware is the main reason
> >> we move from SL3 to SL4 to SL5 to SL6.
> >>
> >> For new kernel features, you can run mongrel systems with mismatched
> >> userland and kernels, but at some point the cost of diverging
> >> from the mainstream becomes bigger than the cost of moving
> >> all your apps to latest SL. (At which point effort of creating
> >> and maintaining a mongrel system is wasted; while the effort
> >> of moving apps to latest SL is mostly in understanding your apps
> >> and in keeping *them* up to date, which you should do anyway,
> >> regardless).
> >
> > The most simple solution for this problem -- using virtualized SL5
> > installation on SL6 host.
> >
> >> K.O.
> >>
> >>
> >>
> >> > >
> >> > > For now, I just want to know whether this is worthy of further
> >> > > consideration, or instead I should set aside a few weeks to
> >> > > upgrade everything then rebuild a lot of poorly written custom
> >> > > apps.
> >> > >
> >> > > Keith
> >> > >
> >> > > --
> >> > > Keith Lofstrom          [log in to unmask]         Voice (503)-520-1993
> >> > > KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
> >> > > Design Contracting in Bipolar and CMOS - Analog, Digital, and Scan ICs
> >>

ATOM RSS1 RSS2