On 1/20/09 5:45 PM, "Hugo Luis Vitelli" <[email protected]> wrote:
> Excuse David .. if I do not speak well ... the truth is that I have to > install a zVM in Suse Linux 5.3 and wanted to consult because they have > more experience if I could show the best way to configure the file system, > if I install in a disk or distribute in minidisks. No problem. See further down for my lame attempt at Portugese... I generally recommend that unless you have a really, REALLY good reason, minidisks are the way to go. You get much better flexibility, and (coupled with a VM directory manager like DIRMAINT or VM:Secure), you have a more foolproof way to manage the underlying storage without getting into hassles with Linux parm lines and a lot of other avoidable problems. I generally split up a system into: A single minidisk for /root at 150. Never make this a LVM as you will inevitably have disk problems and need to repair the system -- if LVM is broken, the system won't boot. By keeping this a normal minidisk, you can at least get the system up far enough to try to repair it. Additional system code minidisks (note plural) at 15x, and put them together into a large LVM pool (systemvg), and put the other directories (/usr, /etc and others as logical volumes into that pool. Makes them easy to resize without a dump/restore later. I put user data into a separate LVM pool (uservg) at 2xx. The standard /home, /var, and /opt directories generally get put into this pool, as this is volatile data that is usually specific to a particular server. This group also commonly gets resized, and you can change how you allocate minidisks to exploit your physical disk characteristics without Linux having to deal with it at all (or even switch disk technologies from traditional CKD/FBA to FCP if you so choose later without changing how Linux sees it). Use the same virtual address ranges in every Linux machine. Makes it easier to manage if all the machines have the same disk addresses. If you are installing SLES 10, be sure to use by-path disk references rather than by-id. By-id hardcodes a identifier of the physical disk into the reference, which will change if you need to move the minidisk to another physical disk, which will cause the Linux guest not to boot. By-path guarantees that the disks (and the Linux /dev entries) will be assigned in the same order if you add a disk, and it avoids the magic id problem. This lets you move minidisks around to balance things without having to redo anything inside the Linux system. I believe Novell has fixed this particular problem in SLES 10 SP3 and SLES 11 -- at least I really hope so. Beyond that, we need to know what you intend to do with the Linux system. There are other tuning steps you can take, but some are only relevant if you run specific applications, eg some things you want to do if you run Oracle, but not if you run TSM. Now, in Portugese. Please forgive any syntax problems -- I don't use the language very often, and it's not my strongest one: Não tem problema. Geralmente, recomendo que se você tem uma muito, muito boa razão, minidisks são o caminho a percorrer. Você pode ir muito melhor flexibilidade, e (juntamente com uma VM diretório como gerente ou DIRMAINT VM: Secure), você tem mais uma maneira infalível para gerenciar o armazenamento subjacente, sem entrar em aborrecimentos com Linux parm linhas e um monte de outros problemas evitáveis. Eu geralmente cindido em um sistema: Um único minidisco para / raiz em 150. Nunca faça um presente LVM como você terá inevitavelmente disco problemas e necessidade de reparar o sistema - se LVM está quebrado, o sistema não irá arrancar. Ao manter este um minidisco normal, você pode obter pelo menos o sistema até agora suficiente para tentar repará-la. Sistema de código adicional minidisks (nota plural) em 15x, e colocá-los juntos em uma grande piscina LVM (systemvg), e colocar os outros diretórios (/ usr, / etc e outros como volumes lógicos em que piscina. Torna-los fácil de redimensionar sem um dump / restaurar mais tarde. Eu coloquei dados do usuário em uma piscina separada LVM (uservg) em 2xx. O padrão / home, / var, e / opt diretórios geralmente colocados em obter este piscina, já que esta é volátil dados que normalmente é específica para um determinado servidor. Este grupo também comumente recebe redimensionada, e você pode mudar o modo como você atribuir minidisks a fim de explorar o seu disco físico características Linux sem ter que lidar com isso em todos (ou mesmo mudar de disco tecnologias tradicionais CKD / FBA para FCP se assim você quiser, mais tarde, sem alteração como o Linux vê-lo). Use o mesmo endereço virtual varia em cada máquina Linux. Torna mais fácil de gerir se todas as máquinas têm o mesmo disco endereços. Se você está instalando o SLES 10, certifique-se de utilização por caminho-disco referências em vez de por-id. By-id hardcodes um identificador do disco físico para a referência, que vai mudar se você precisar de mover o minidisco para outro disco físico, o que fará com que o hóspede não pode arrancar o Linux. Por caminho-garantias de que os discos (e no Linux / dev entradas) serão atribuídas da mesma forma, se você adicionar um disco, e evita o mágico id problema. Isto permite-lhe mover minidisks volta para equilibrar as coisas sem ter que refazer tudo dentro do sistema Linux. Creio Novell fixou este problema específico no SLES 10 SP3 e SLES 11 - pelo menos eu espero que sim. Além disso, precisamos saber o que você pretende fazer com o sistema Linux. Há outros passos que pode tomar tuning, mas alguns só são relevantes se você executar aplicações específicas, por exemplo, algumas coisas que você deseja fazer, se você executar o Oracle, mas não se você executar TSM. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
