Сборка GNU parallel для CentOS/RHEL

Проще некуда:

cd /usr/src
wget http://ftp.gnu.org/gnu/parallel/parallel-latest.tar.bz2
tar -xf parallel-latest.tar.bz2
cd parallel-20140722/
./configure --prefix=/opt/parallel
make install
/opt/parallel/bin/parallel

А еще - Parallel написан на Perl и сборки-то в общем не требует.

Сравнение скорости работы хэш функций между OpenSSL 1.0.1e-fips 11 Feb 2013 (CentOS 6) и OpenSSL 1.0.2 beta 2

Платформа для тестов - Intel E5 2670v2. Объем файла - 15Гб. Объем озу на машине - 128 Гб.

Выкручиваем все процессоры на полную частоту:

cpufreq-set -g performance
echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Объем тест-файла: 15GB

Прогреваем кэш:

cat /vz/private/61350/root.hdd/root.hdd  >/dev/null

Скорость после прогрева страничного кэша:

 cat /vz/private/61350/root.hdd/root.hdd |pv >/dev/null
12,4GB 0:00:06 [2,07GB/s] [              <=>       

Тестовая строка:

for hash in md4 md5 sha1 sha256 sha512; do echo "$hash"; for i in `seq 1 3`; do time cat root.hdd | taskset -c 31 openssl $hash >/dev/null;done; echo ""; done 

 Итак, результаты для 1.0.1e-fips 11 Feb 2013 (я привожу только 1 результат из 3х запусков, так как данные очень близки и находятся в пределах 2-4% погрешности):

md4
real    0m19.018s
user    0m16.216s
sys    0m11.192s

md5
real    0m28.764s
user    0m25.793s
sys    0m12.040s

sha1
real    0m31.177s
user    0m28.992s
sys    0m11.336s

sha256
real    1m10.431s
user    1m8.714s
sys    0m10.995s

sha512
real    0m48.131s
user    0m45.186s
sys    0m12.097s

А вот результаты для OpenSSL 1.0.2 beta 2, в которой активно используются Intel SHA Extenstions:

md4
real    0m18.442s
user    0m15.761s
sys    0m10.678s

md5
real    0m28.571s
user    0m25.242s
sys    0m12.126s


sha1
real    0m30.228s
user    0m28.214s
sys    0m11.128s


sha256
real    0m56.517s
user    0m53.637s
sys    0m12.123s


sha512
real    0m43.056s
user    0m41.083s
sys    0m11.252s

Итак, выводы по скорости.

md4, md5 - без изменений, что ожидаемо - каких-либо серьезных оптимизаций алгоритмов не производилось.

sha1 - без изменений  несмотря на оптимизации за счет Intel SHA Extenstions. 

sha256 - стал быстрее на 15 секунд! Ура, оптимизация дала эффект :)

sha512 - стал быстрее на 5 секунд. Неплохо, вполне неплохо :)

Выводы - оптимизация дала плоды, но до кардинальных изменений в скорости очень далеко.

Эффективность от использования Intel Sha Extensions при использовании хэширования в OpenSSL

Это очень крутая штука в наборе инструкций современных процессоров Intel. Но чтобы задействовать это ускорение приложение, разумеется, должно использовать специальные ассемблерные команды. И примером приложения использующего их является OpenSSL версии начиная с 1.0.2beta2 и хэш алгоритмы SHA-1 / SHA-512, другие хэш функции не смотря на поддержку со стороны процессоров таким образом оптимизированы не были (видимо, по причине известных проблем с коллизиями в том же  md5).

Итак, берем машины E5 2670v2 из тестового стенда и прогоняем обычный OpenSSL (OpenSSL 1.0.1e 11 Feb 2013 из сборки Debian Wheezy) в следующей конфигурации:

for i in md4 md5 sha1 sha256 sha512; do openssl speed $i 2>&1|egrep -v '(Doing|OpenSSL|built|options|compiler)';done

И получаем вот такие цифры:

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md4              79469.84k   247447.81k   593828.73k   909654.02k  1081913.88k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              57183.56k   170794.37k   383938.70k   555845.63k   640581.52k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1             63621.49k   183943.89k   404654.92k   581348.35k   689886.95k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           49298.04k   111948.78k   193886.12k   240399.93k   256172.03k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha512           39788.22k   163034.65k   244865.02k   346445.91k   395853.82k

Как обычно бывает - md4 самый быстрый и тем ярче превосходство, чем больше блок данных (особенно велико оно на кратных 8192 байтам блоках).

Теперь собираем вручную OpenSSL версии равной или старше чем openssl-1.0.2-beta2.

И запускаем те же тесты используя свеже собранный OpenSSL на Debian 7 Wheezy:

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md4              45183.93k   159576.92k   445669.20k   805581.82k  1057753.77k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              37000.35k   125855.38k   312857.60k   516176.14k   630956.03k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1             41862.74k   134170.77k   343537.27k   562741.59k   701120.13k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           62982.42k   140178.79k   245336.79k   300390.40k   322792.20k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha512           45197.99k   180312.43k   280480.11k   396773.03k   453845.02k

Теперь повторяем тест стандартного OpenSSL но уже из состава CentOS 6 (OpenSSL 1.0.1e-fips 11 Feb 2013):

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md4              60064.70k   188973.95k   447881.22k   683383.58k   808962.73k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              44789.97k   131985.83k   293138.94k   420840.19k   483939.67k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1             48999.05k   139180.74k   304883.92k   442452.99k   521759.40k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           36892.66k    82828.82k   144455.59k   181290.18k   194063.02k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha512           29594.76k   119322.73k   185533.70k   262828.03k   299693.84k

А теперь прогоняем тест актуальной версии OpenSSL собранной вручную, но на машине на базе CentOS 6:

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md4              29176.77k   102947.75k   300172.54k   573421.63k   785858.56k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              25097.23k    83432.96k   220905.47k   375433.44k   474740.05k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1             27111.94k    89276.33k   238348.20k   409880.32k   526125.74k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           48053.63k   107633.37k   186195.20k   227252.14k   243523.58k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha512           34854.11k   141876.76k   215300.10k   301368.30k   342690.47k

Тесты в обоих версиях были прогнаны 3-5 раз, значения отличались не более чем на  1000k, что в районе 1-2% погрешности и вполне допустимо.

Выводы очень странные напрашиваются. Точно ускоряется и очень мощно sha256 - в почти 1,5 раза.

Почему замедляются md4 и md5 - для меня загадка.  Возможно это связано с флагами компиляции данных пакетов в Debian 7 Wheezy либо с деградациями в beta выпуске OpenSSL либо просто с большими отклонениями на малом объеме данных - на 8192 блоках таких колебаний вовсе нету.

А sha1 в свою очередь в любом случае показал себя как самый быстрый хэш из хэшей со вменяемыми характеристиками и стойкостью к коллизиям! :)

Ускорение хэширования, криптографии, а также сжатия силами Intel Quick Assist

У Intel на базе процессоров Intel E5 2600й серии v2 есть такая крутая отдельная плата - как Intel QuickAssist Technology,  которая в свою очередь включает ускорение ряда хэш функций SHA-1, MD5; SHA-2 [SHA-224, SHA-256, SHA-384, SHA-512. А также сжатия и криптографии!

Сборка OpenSSL актуальной версии на CentOS 6

Ставим зависимости:

yum install -y gcc make perl 

Все довольно просто за исключением того, что система сборки на Перле:

cd /usr/src
wget https://www.openssl.org/source/openssl-1.0.2-beta2.tar.gz
tar -xf openssl-1.0.2-beta2.tar.gz
cd  openssl-1.0.2-beta2/
./config --prefix=/opt/openssl --openssldir=/opt/openssl/openssldir
make
make install

Если установка не требуется, то можно запустить утилиты вручную:

./apps/openssl version

Тестирование скорости хэш функций реализованных в OpenSSL на процессорах семейства Xeon E5 26XX

Вот так запускать тесты:

for i in md4 md5 sha1 sha256 sha512; do openssl speed $i 2>&1|egrep -v '(Doing|OpenSSL|built|options|compiler)';done

Вот такие результаты вышли у меня (OpenSSL 1.0.1e-fips 11 Feb 2013, CentOS 6):

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md4              68566.14k   173477.65k   515525.95k   677865.49k   931820.76k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5              40919.27k   133902.74k   332599.15k   487704.31k   560110.13k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha1             53991.04k   156746.65k   345242.72k   502931.07k   572807.73k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha256           35243.93k    91730.62k   165080.62k   193792.86k   213022.14k
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
sha512           33810.13k   135413.99k   174028.97k   296263.47k   345636.64k

 Почему такие странности? Ой, а какие странности? Например, то, что SHA1 быстрее чем md5, что довольно неожиданно.

Беглый анализ кода OpenSSL (1.0.2.beta2) дает такие вот хитрые ответы:

• md-4 написан исключительно на C.
• md-5 использует ассемблерные оптимизации для 86_64,  i586, но НЕ использует SIMD инструкции SSE.
• sha-1 использует ассемблерные оптимизации под почти все популярные архитектуры.  Кроме этого, имеет оптимизации на SSE3, Intel AVX,  а также на Intel SHA Extensions.
• sha-256 использует ассемблерные оптимизации и немного SIMD инструкций, но без особого фанатизма, судя по коду.
• А вот sha-512 также очень тщательно оптимизирован по аналогии с sha-1.

Профилирование приложений на Golang

К сожалению, сабж весьма скудно документирован, но при этом снабжен очень крутым набором инструментов! Основной источник: http://blog.golang.org/profiling-go-programs

Мы сейчас говорим исключительно о профайлинге по потреблению CPU. Для начала нужно добавить в программу следующее:

import "runtime/pprof"
import "flag"
import "log"

 Потом добавляем в функцию main в самом начале:

 flag.Parse()
    if *cpuprofile != "" {
        f, err := os.Create(*cpuprofile)
        if err != nil {
            log.Fatal(err)
        }  
        pprof.StartCPUProfile(f)
        defer pprof.StopCPUProfile()
    }   

И запускаем программу со следующими аргументами:

./gordiff -cpuprofile=gordiff.prof

Запускаем профайлер:

go tool pprof gordiff gordiff.prof

Смотрим результаты введя в его терминале команду top10:

(pprof) top10
Total: 426 samples
     338  79.3%  79.3%      338  79.3% code.google.com/p/go.crypto/md4._Block
      57  13.4%  92.7%       57  13.4% main.faster_rollsum
      21   4.9%  97.7%       21   4.9% syscall.Syscall
      10   2.3% 100.0%       10   2.3% runtime.memmove
       0   0.0% 100.0%       21   4.9% System
       0   0.0% 100.0%       10   2.3% bufio.(*Reader).Read
       0   0.0% 100.0%      338  79.3% code.google.com/p/go.crypto/md4.(*digest).Write
       0   0.0% 100.0%      405  95.1% main.generate_signature
       0   0.0% 100.0%      405  95.1% main.main
       0   0.0% 100.0%      405  95.1% runtime.gosched0

 

Реализация утилиты rdiff на чистом Python

Прошу:

cd /usr/src
git clone git@github.com:therealmik/pyrdiff.git --branch python2
cd pyrdiff

Кому понравилось, идем на репо и ставим плюсик: https://github.com/therealmik/pyrdiff

Сборка librsync с репо на GitHub

Дадада! Rsync оживает и оживление началось с переноса проект на GitHub! 

cd /usr/src
git clone https://github.com/librsync/librsync.git
cd librsync
yum install -y autoconf automake libtool popt-devel popt
./autogen.sh
./configure --prefix=/opt/rdiff
make install

Вы не умеете бэкапить Ваши данные!

Данный заголовок касается Вас, если Вы ежедневно копируете от 100 гигабайт данных и это не базы данных.

Также этот пост касается Вас, если Вы бэкапите ploop контейнеры в OpenVZ.

Почему же? Потому что скорее всего, Ваше решение для бэкапа не отключает использование страничного кэша Linux при чтении данных для бэкапа и вытесняет оттуда данные, которые там должны быть, забивая их ненужным мусором, что в свою очередь крайне негативно сказывается на скорости дисковых операций.

К чему это может привести? К деградации производительности. Из памяти вытесняются файлы, которые реально атм должны быть!

Как это диагностировать? http://www.stableit.ru/2014/07/linux-page-cache.html

Насколько все плохо было в моих тестах? Это была OpenVZ нода с большим числом ploop контейнеров.

total cached size: 72,771,035,136

Да, да! 72 гигабайта оперативной памяти через почти сутки после бэкапа были забиты бэкапным хламом, а не реальными данными.

Что делать? Использовать прослойку, которая подключает использование O_DIRECT при чтении данных (в таком случае даннные НЕ будут помещены в страничный кэш вообще). Например, я написал такую: https://github.com/FastVPSEestiOu/cat_cache_safe Она, конечно, пока медленнее обычного cat, но зато не засоряет страничный кэш вообще.

Так что Вы можете сделать вот так: ./cat_cache_safe| tar -cpzf /place_to_archive.tar.gz - и тем самым вы избежите от помещения прочтенных данных в страничный кэш. А вот с помещением туда записанных данных все весьма сложно, поэтому я рекомендую бэкапиться вообще на удаленный сервер! Так и безопаснее и не создается лишняя нагрузку на запись на локальную дисковую систему.

Как посмотреть, какие файлы размещены в Linux Page Cache (блок cached во free/top)?

Вот так, тулзой fincore: https://code.google.com/p/linux-ftools/

Собрать ее можно так (на CentOS 6 собирается без проблем):

cd /usr/src
mkdir linux-ftools
cd linux-ftools
wget https://linux-ftools.googlecode.com/archive/2a7918d4b81b3cbbd6d7a1087b907ba346fd8338.tar.gz -Olinux-ftools.tar.gz
tar -xf linux-ftools.tar.gz
 cd linux-ftools-*
 ./configure --prefix=/opt/linux-ftools
make
make install

Использовать вот так:

/opt/linux-ftools/bin/linux-fincore --pages=false --summarize --only-cached `find /test_path -type f |perl -e 'do{chomp; print "$_ "} for <>'`
filename                                                                                       size        total_pages    min_cached page       cached_pages        cached_size        cached_perc
--------                                                                                       ----        -----------    ---------------       ------------        -----------        -----------
/vz/private/1231/root.hdd/root.hdd                                                   95,808,389,120         23,390,720                  0          9,838,415     40,298,147,840              42.06
---
total cached size: 40,298,147,840

Реализация инкрементальных бэкапов на ZFS

http://breden.org.uk/2008/05/12/home-fileserver-backups-from-zfs-snapshots/

Как сравнить поблочно два блочных устройства?

Утилитой CMP:

LANG=C cmp /dev/ploop41029 /dev/nbd0
/dev/ploop41029 /dev/nbd0 differ: char 1049613, line 1

Скорость работы tinyproxy

Ну очень медленно :)

На гигабитном канале:

 0% [                                                                                                        ] 139 650 584  599K/s  ост 30h 9m  ^C

Вы с вероятностью 90% НЕ знаете, как работает Интернет

Хотите подробностей? Хотите правда понять? Вот отличная книга для начала: http://www.ozon.ru/context/detail/id/26326082/

Отличное руководство по ext4

https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout
http://www.dfrws.org/2012/proceedings/DFRWS2012-13.pdf

Мониторинг Smart на SSD подключенных к Dell PERC H710P / MegaRAID SAS 2208

smartctl -A --device=sat+megaraid,4 /dev/sda
smartctl 5.43 2012-06-30 r3573 [x86_64-linux-2.6.32-042stab088.4] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       1227
 12 Power_Cycle_Count       0x0032   099   099   000    Old_age   Always       -       17
177 Wear_Leveling_Count     0x0013   099   099   000    Pre-fail  Always       -       7
179 Used_Rsvd_Blk_Cnt_Tot   0x0013   100   100   010    Pre-fail  Always       -       0
181 Program_Fail_Cnt_Total  0x0032   100   100   010    Old_age   Always       -       0
182 Erase_Fail_Count_Total  0x0032   100   100   010    Old_age   Always       -       0
183 Runtime_Bad_Block       0x0013   100   100   010    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0032   072   067   000    Old_age   Always       -       28
195 Hardware_ECC_Recovered  0x001a   200   200   000    Old_age   Always       -       0
199 UDMA_CRC_Error_Count    0x003e   100   100   000    Old_age   Always       -       0
235 Unknown_Attribute       0x0012   099   099   000    Old_age   Always       -       15
241 Total_LBAs_Written      0x0032   099   099   000    Old_age   Always       -       22668737356

 Самое сложное тут определить номер устройства! Они идут вовсе не подряд, а вот так:

/opt/MegaRAID/MegaCli/MegaCli64 -LdpdInfo -a0|grep 'Device Id:'
Device Id: 9
Device Id: 10
Device Id: 19
Device Id: 12
Device Id: 17
Device Id: 18
Device Id: 15
Device Id: 14
Device Id: 22
Device Id: 21
Device Id: 20
Device Id: 16

Поэтому универсальная команда выборки SMART имеет вид:

for i in `/opt/MegaRAID/MegaCli/MegaCli64 -LdpdInfo -a0|grep 'Device Id:'| awk '{print $3}'`; do smartctl -A -i -d sat+megaraid,$i /dev/sda;done

 

Яндекс не индексирует картинки на https only сайтах

Вот даже в базу знаний добавили:

Для того, чтобы в индекс попали картинки, в ссылках на которые используется протокол https, необходимо, чтобы к этой картинке был доступ по http. Например, если вы хотите, чтобы проиндексировалась картинка по адресу https://domain.ru/image.jpg, нужно дать роботу возможность скачать эту картинку по адресу http://domain.ru/image.jpg.

Источник:  http://help.yandex.ru/images/indexing.xml


Да, у Google все индексируется. Да, на моем блоге вообще нет трафика с Yandex ;)

Да, у Yandex подчас попадаются фееричсекие личности, я вынужден даже скопировать их перлы здесь:

Нельзя исключить, что мы тут неправы, а приоритет у этой задачи выше. Я пока не вижу фактов, это подтверждающих, но, возможно, я не туда смотрю? Тогда подскажите, что мы проглядели, и почему это надо сделать «СРАЗУ», а не, например, «до конца года». Аргумент про «саботирование технического прогресса», извините, принять не могу.
даже со своей недалекой колокольни могу сказать, что https/spdy 1,2,3/sni должны СРАЗУ же поддерживаться поисковиками

Как и любое другое безусловно категоричное утверждение, это не может полностью соответствовать действительности. Например, оно определенно неверно в части spdy.

Источник: habrahabr.ru/post/228693/#comment_7750639

Загрузил исходный код стабильного OpenVZ ядра в репозиторий на GitHub

Исключительно для удобства навигации по коду, чтобы каждый раз не дергать rpm:
https://github.com/pavel-odintsov/openvz_rhel6_kernel_mirror

Буду стараться выкладывать код по мере выхода стабильных ядер. Еще попробую сделать возможность, чтобы было видно, где именно OpenVZ патч. Но, боюсь, под каждое ядро придется делать самостоятельно, так как в версии от Parallels патча OpenVZ отдельно от ядра не существует, а сравнить две версии без тонн правок от RedHat очень проблематично.

Но я-таки попробую :)

Как парковать сети на VmWare ESXi в Hetzner.DE и FastVPS.ru?

Для того, чтобы клиент мог использовать подсети для разных виртуальных машин (а не только для одной) на VmWare ESXi нужно следующее:

1. Машина с установленным VmWare ESXi
2. Один дополнительный IP адрес с присвоенным к нему MAC адресом (запрашиваем MAC через интерфейс в клиентской робот панели
3. Подсеть, смаршрутизированная на IP из пункта 2 (это делается через запрос по тикету) 

Сначала нужно создать на IP из пункта 2 виртуальную машину с Debian, при этом обязательно указываем для нее выданный Датацентром MAC адрес, без этого сеть не заработает.

Создание виртуального свитча

Скачиваем клиент VMware vSphere Client (работает только на Windows). Устанавливаем и подключаемся к серверу (от клиента необходим IP и root пароль). Идем на вкладку "Configuration", далее выбираем "Hardware", "Networking". Щелкаем Add Networking. Далее "Cennection type" выбираем "Virtual Machine". Next. Далее выбираем "Create Virtual Switch". Next. Network label "SubnetSwitch", VLAN ID не трогаем. Next. Finish.

Создаем виртуальную машину "subnet-router.ru", подключенную в стандартный свитч, с сетевой карточкой (бриджет сеть). Ставим на нее Дебиян любой битности.

Добавление второго интерфейса для машину роутера

Идем на вкладку "Virtual Machines", щелкаем правой кнопкой по машину-роутеры и выбираем "Edit settings". На вкладке Hardware уже будет одна сетевая карточка - Network Adapter 1, это внешний выходит в сеть ДЦ (и для него должен быть прописан выданный ДЦ MAC). Щелкаем "Add", выбираем "Ethernet Adapter", Next, Type: e1000, Network Label: SubetSwitch. Ставим галочку "Connect at power on". Next. Finish.Ok. После этого перезагружаем машину резетом из панели управления.

Входим на машину и поднимаем сеть

Активируем форвардинг пакетов:

echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
sysctl -p

Второй интерфейс, от подсети появился как eth1:

ifconfig -a

eth0 Link encap:Ethernet HWaddr 00:50:56:15:24:49

          inet addr:46.4.18.186 Bcast:46.4.18.191 Mask:255.255.255.192

          inet6 addr: fe80::250:56ff:fe15:2449/64 Scope:Link

          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

          RX packets:1676 errors:0 dropped:0 overruns:0 frame:0

          TX packets:172 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:156685 (153.0 KiB) TX bytes:69378 (67.7 KiB)

eth1 Link encap:Ethernet HWaddr 00:0c:29:f7:a5:52

          BROADCAST MULTICAST MTU:1500 Metric:1

          RX packets:0 errors:0 dropped:0 overruns:0 frame:0

          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)

lo Link encap:Local Loopback

          inet addr:127.0.0.1 Mask:255.0.0.0

          inet6 addr: ::1/128 Scope:Host

          UP LOOPBACK RUNNING MTU:16436 Metric:1

          RX packets:8 errors:0 dropped:0 overruns:0 frame:0

          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0

          RX bytes:560 (560.0 B) TX bytes:560 (560.0 B)

 

Конфигурируем eth1.

Берем последний useable ip, но не самый последний в роботе!

nano /etc/network/interfaces

auto eth1

iface eth1 inet static

    address 78.47.208.230

    netmask 255.255.255.248

Перезапускаем сеть:

/etc/init.d/networking restart

Создаем вируталку, указывая SubnetSwitch как сетевой интерфейс для нее.

• Создать
• Configuration - Custom
• Next - Next - Next
• На вкладке Network выбираем NIC1: "SubnetSwitch". Adapter: E1000, Connact on Power On: флажок стоит.
• Ставим ОС и конфигурируем, как указано ниже. Автоматическая конфигурация работать не будет.

Конфигурируем сеть:

address [любой используемый адрес из подсети]

netmask 255.255.255.248

gateway 78.47.208.230

Вот пример конфига:

nano /etc/network/interfaces

auto eth0

iface eth0 inet static

    address 78.47.208.225

    netmask 255.255.255.248

    gateway 78.47.208.230

После того, как сеть будет настроена, должен пойти FORWARD траффик на роутере:

iptables -nvL

Chain INPUT (policy ACCEPT 2312 packets, 593K bytes)

 pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 173 packets, 34322 bytes)

 pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 2175 packets, 350K bytes)

 pkts bytes target prot opt in out source destination

 Источник: http://wiki.hetzner.de/index.php/VMware_ESXi_english 

Обращаю внимание, что для других виртуализаций ман аналогичен!