Software Archive
Read-only legacy content
Announcements
FPGA community forums and blogs have moved to the Altera Community. Existing Intel Community members can sign in with their current credentials.
17060 Discussions

Best Practical practice for Server/Dev Environments

Robert_F_2
Beginner
527 Views

At long last I am making my CentOS boot stick and copying BIOS versions to another stick.   Hopefully the magic smoke will not escape...

1 Primary Physical Box -3-4 mics -  2-3 small Projects, 4-6 remote users not terribly concurrent.

Some R, some Pynum, some C++ a bit of this a dash of that...

XEN -> and then carve up a stack of administrative servers and development vms?

Centos -> VMWare>

Something else...

What's best practice for establishing a stable multiuser workstation environment and versatile development environments that doesn't trash the base libraries on  a regular basis and also doesn't require significant adminstrative overhead that will allow projects to take turns or split the mic resources?

Is there a commonly used configuration where I can specifically attach/detach mics to an environment?

Not looking for significant snapshotting just the ability to keep people/and myself from making a mess that takes a rebuild to recover from.

Thanks,

Robert

 

 

0 Kudos
1 Reply
JJK
New Contributor III
527 Views

you're asking many questions at once ... I'll try to answer some of them:

  • virtualising your hardware will incur a 10-20% performance penalty, both on the host side as well as on the offloading side (transferring data to/from the Phis)
  • thrashing base libraries can only be done by the root user (normally) . Other users should not have write access. If you want to give multiple users root access then you should consider virtualisation.
  • if you must use virtualisation then consider upgrading to CentOS 7 (at least) - newer kernels do a better job at virtualisation.
  • as for assigning a particular Phi to a particular user: there is not "standard" to do this, but you could achieve this by modifying the ssh authorized_keys files on each Phi.
  • I'd recommend to reboot a Phi after a particular user is done, to ensure that the Phi returns to a "known good " state

 

0 Kudos
Reply