Multiseat для Windows рабочих мест


    Хочу вам рассказать о необычном способе создания многопользовательской рабочей станции, в качестве основы которого лежит VMPlayer.

    Данное решение разрабатывалось для коммерческой эксплуатации, а в качестве посыла к решению этой задачи ставилось утверждение, что текущие характеристики приобретаемого оборудования превосходят потребности пользователей и используемого ими программного обеспечения. Конечно, это касается в основном типового офисного планктона и многих периферийных должностей. Также это будет полезно для решения проблем у тех, кому руководство по своим, вполне обоснованным соображениям, отказало или с большой вероятностью откажет в просьбе обновления рабочей станции. Печально, но так бывает…

    Для того чтобы решение стало достойным применения, ему были предъявлены следующие требования:
    • В качестве операционной системы для конечных пользователей должна остаться Windows.
    • Стоимость системного блока для двух сотрудников, в идеале должна быть сравнима со стоимостью одного типового, из приобретаемых на тот момент.
    • Работа пользователей не должна сколько-нибудь заметно замедлится или быть некомфортной, от того, что используется один компьютер.

    Ну собственно, бизнес-требования ясны, значит пора переходить к решению…

    Техническая часть


    Разработка велась на рабочей станции со скромными на текущий момент параметрами – AMD Athlon 64 X2, GeForce GT 440, DDR II 4Gb, HDD 320GB, и хотя результат оказался вполне приемлемым, для соответствия вышеуказанным требованиям, при выборе технической составляющей следует учесть следующие рекомендации:
    • Процессор с двумя ядрами — каждой VM выделяется по одному, и конечно желательна поддержка современных технологий виртуализации, тогда можно ожидать производительность, приближенную к «железной» рабочей станции.
    • Оперативная память не является особо дорогим составляющим, поэтому лучше, не жалея, рассчитать по 3Gb на каждое рабочее место, плюс 1 Gb для хост системы. Но в определенных ситуациях вполне можно обойтись и по 1,5 Gb для каждого места.
    • Жесткий диск, на котором будет расположена виртуальная машина, желательно, чтобы был отдельный для каждого рабочего места, это даст независимость операций ввода/вывода и виртуальные машины будут меньше мешать друг другу. Это требование можно опустить, если цель экономии средств является более приоритетной.
    • Материнская плата, желательно, должна быть уже с двумя видеовыходами, этим снимается необходимость в приобретении отдельной видеокарты. Но, если у вас есть желание использовать свою видеокарту и/или на материнской нет видеовыходов, то можно использовать, конечно, внешнюю.

    Есть еще несколько замечаний касающихся периферии, а именно мониторов, клавиатур и мышей, и хотя на первый взгляд они несколько странноваты, их выполнение не составит большого труда и затрат, что важно для выполнения требований к решению.
    • Мониторы. При выборе мониторов следует учесть, что материнские платы с видеовыходами DVI и VGA, не поддерживают переходники DVI->VGA. Поэтому нужно убедиться, что имеющиеся мониторы и видеовыходы соответствуют друг другу.
    • Клавиатуры и мыши. Это скорее не замечание, а больше ограничение к выбору этих HID устройств. Во первых, все устройства должны быть USB. Во вторых, VID:PID одной клавиатуры не должен совпадать с VID:PID другой. Такое же условие накладывается и на мыши. Если говорить проще, модели клавиатур должны отличатся между собой и модели мышей тоже должны быть разными. Связано это ограничение с тем, что для распределения устройств между виртуальными машинами используются VID и PID, а возможность подключения одинаковых моделей не изучалась, так как выполнение этого условия не составляет большого труда.

    Для примера приведу конфигурацию, которую мы взяли за стандарт для наших dualseat’ов: Intel Core i3, MB (DVI+VGA, Audio, GLan),HDD 500Gb x 2.

    Итак, техническую часть пояснил и обосновал. Теперь перейду к программной начинке и принципу работы.

    Подготовка


    Ну что же, приступим. Для создания dualseat нам нужно подготовить несколько основных компонентов.

    Платформа

    Первым шагом для создания платформы для dualseat инсталируем Ubuntu Server 12.04 x64. После достаточно тривиальной установки системы доставляем пакеты, которые обеспечат функционирование остальных компонентов, и заодно некоторые полезные утилиты:
    apt-get install ...
    apt-get install unclutter xinput libxcursor1 mc openssh-server binutils gcc x11-xserver-utils x11vnc xinetd alsa-base alsa-utils vim nodm fluxbox tofrodos ntfsprogs
    Если требуется, устанавливаем драйвера видеокарты.

    После инсталляции конфигурируем систему так, чтобы ее запуск был прозрачным для пользователя, да и само графическое оформление хост системы не бросалось в глаза, а еще лучше, чтобы вообще отсутствовало.

    Начнем с конфигурации nodm, который как раз предназначен для автоматического запуска X сессии, сразу во время загрузки системы:
    /etc/default/nodm
    /etc/default/nodm
    NODM_ENABLED=true
    NODM_USER=vm
    NODM_XINIT=/usr/bin/xinit
    NODM_XSESSION=/etc/X11/Xsession
    NODM_X_OPTIONS='vt7 -nolisten tcp'
    NODM_MIN_SESSION_TIME=60
    Теперь настроим оконный менеджер для организации пустого рабочего пространства. Для этого устанавливаем следующие параметры в настройках fluxbox:
    /home/vm/.fluxbox/init
    /home/vm/.fluxbox/init
    session.screen0.toolbar.visible: false
    session.screen0.workspaces: 1
    Операционная система подготовлена, и как сказал бы Лёлик из кинофильма «Брильянтовая рука» – «Шеф, усе готово, система грузится без шума и пыли».

    Далее скачиваем с официального сайта VMWare последнюю версию VMPlayer. Установка достаточно проста, но может потребовать установку патча, непосредственно сразу после установки, если vmplayer не будет запускаться. Но, чтобы добиться максимальной отзывчивости виртуальных машин, проведем
    небольшой тюнинг системы и гипервизора
    /etc/vmware/config
    mainMem.useNamedFile="FALSE"
    tmpDirectory="/run/shm"
    prefvmx.useRecommendedLockedMemSize="TRUE"
    prefvmx.minVmMemPct="100"

    /etc/sysctl.conf
    vm.swappiness=0
    vm.overcommit_memory=1
    vm.dirty_background_ratio=5
    vm.dirty_ratio=10
    vm.dirty_expire_centisecs=1000
    dev.rtc.max-user-freq=1024

    /etc/fstab
    Значение size зависит от количества установленной оперативной памяти, и не может быть меньше суммы выделенной обоим виртуальным машинам плюс 1 Gb. Это будет связано с тюнингом проводимым ниже.
    tmpfs /run/shm tmpfs size=8G

    Системное окружение

    Теперь нужно подготовить системное окружение: создать пользователя и пару папок.
    • vm — это пользователь, которым будет входить nodm, и от которого будет производится запуск виртуальных машин.
    • /home/vm/user01 и /home/vm/user02 — папки для виртуальных машин пользователей. В случае, если система подготовлена с двумя жесткими дисками, второй жесткий диск следует замонтировать в одну из этих папок.

    Виртуальные рабочие места

    Создание виртуальных машин и установку систем оставлю вам на откуп, думаю, этот процесс знаком большинству читателей. Но несколько рекомендаций все же будут, так как целью ставится комфортная работа пользователей.
    • Виртуальные диски должны быть обязательно SCSI, независимо от того, какая система будет стоять, и ни в коем случае не следует выбирать IDE, так как вы получите очень неэффективную виртуальную дисковую подсистему.
    • Неиспользуемое оборудование (Printer, Floppy disk, Serial port и т.д) следует удалить из конфигурации виртуальной машины.
    • VMWare Tools является обязательным компонентом для эффективной работы гостевой системы.

    Некоторые важные условности для скриптов, расположенных ниже:
    • Ожидается, что имена обоих vmx файлов — это workstation.vmx.
    • Имена виртуальных машин должны быть user00 и user01 соответственно.

    После того как виртуальные рабочие станции подготовлены и расположены в своих местах, проведем их тюнинг, опять же выжимая максимальную производительность.
    /home/vm/user00/workstation.vmx и /home/vm/user01/workstation.vmx
    /home/vm/user00/workstation.vmx и /home/vm/user01/workstation.vmx
    mem.ShareScanTotal=0
    mem.ShareScanVM=0
    mem.ShareScanThreshold=8192  # Значение зависит от количества установленной оперативной памяти
    sched.mem.maxmemctl=0
    sched.mem.pshare.enable = "FALSE"
    mainMem.useNamedFile = "FALSE" 
    MemTrimRate = "0"
    MemAllowAutoScaleDown = "FALSE"
    

    Все компоненты подготовлены и оптимизированы, остается собрать все воедино и добавить пару штрихов.

    Конфигурация запуска системы


    Для запуска dualseat используем /home/vm/.fluxbox/startup, содержимое которого, последовательно и комментируя, привожу далее (обратите внимание на настройку мониторов).
    /home/vm/.fluxbox/startup
    /home/vm/.fluxbox/startup
    Отключаем все попытки системы «потушить» экран:
    xset -dpms
    xset s off
    setterm -blank 0
    setterm -powerdown 0

    По умолчанию, система с двумя мониторами запускается в режиме clone, это когда мы видим одну и ту же картинку на обоих мониторах. Для настройки корректного отображения будем использовать утилиту xrandr (вместо конфигурации в xorg.conf).
    Чтобы получить доступные разрешения для каждого монитора, используется команда xrandr -q. Нужно обратить внимание на то, что DVI выход системой показывается как HDMI.
    Настройка обоих мониторов происходит в момент запуска fluxbox, для этого используются следующие строки (порядок строк важен), значения в которых, у вас конечно должны быть свои:

    # Устанавливаем разрешение монитора подключенного к VGA
    xrandr --output VGA1 --mode 1280x1024 
    # Устанавливаем разрешение монитора подключенного к HDMI
    xrandr --output HDMI1 --mode 1920x1080
    	
    # Располагаем HDMI пространство слева от VGA
    xrandr --output HDMI1 --left-of VGA1 
    # Делаем HDMI монитор основным (с которого будет начинаться нумерация)
    xrandr --output HDMI1 --primary

    Системный курсор нам не нужен, а сам по себе он остается всегда видимым, поэтому «тушим» его таким образом
    unclutter -idle 1 -root &

    Теперь запуск графической оболочки и сразу после нее запуск самих виртуальных машин
    exec fluxbox &
    fbpid=$!
    sleep 1
    {
     /home/vm/user00/start &  # Скрипт запуска VM00 
     /home/vm/user01/start &  # Скрипт запуска VM01
    } &
    wait $fbpid

    Далее приведены скрипты запуска самих виртуальных машин, где в первую очередь проверяется, не запущена ли уже целевая машина. Сам запуск, следом, сопровождается скриптом check_shutdown, который выполнится сразу после выключения VM. Он нужен для проверки на необходимость выключения компьютера, при выключении обоих рабочих мест.
    Cкрипты запуска виртуальных машин
    /home/vm/user00/start
    if ps ax | grep -v grep | grep -P "vmplayer.*user00" > /dev/null
    then
        exit
    else    
        /usr/bin/vmplayer -X /home/vm/user00/workstation.vmx && /home/vm/check_shutdown &
    fi

    /home/vm/user01/start
    if ps ax | grep -v grep | grep -P "vmplayer.*user01" > /dev/null
    then
        exit
    else    
        /usr/bin/vmplayer -X /home/vm/user01/workstation.vmx && /home/vm/check_shutdown &
    fi

    /home/vm/check_shutdown
    if ps ax | grep -v grep | grep vmplayer > /dev/null then
      exit 0
    else
      sudo shutdown -h now
    fi

    Для выполнения команды sudo shutdown без ввода пароля, нужно добавить в файл /etc/sudoers строку:
    vm ALL=NOPASSWD: /sbin/shutdown


    Изоляция


    Теперь приступим к изоляции ресурсов между рабочими местами.

    Мониторы

    Для запуска виртуальных машин, каждой на своем мониторе, используем возможности оконного менеджера fluxbox, где в файле /home/vm/.fluxbox/apps указаны правила расположения виртуальных машин в момент запуска.
    /home/vm/.fluxbox/apps
    /home/vm/.fluxbox/apps
    # для VMPlayer user00
    [app] (title=.*user00.*)
        # Монитор 2
        [Head] {2}
        # Убираем оформление
        [Deco] {NONE}
        # Запустить минимизированным 
        [Minimized] {yes}
    [end]
    
    # для VMPlayer user00
    [app] (title=.*user01.*)
        # Монитор 1
        [Head] {1}
        # Убираем оформление
        [Deco] {NONE}
        # Запустить минимизированным 
        [Minimized] {yes}    
    [end]
    
    # Other applications
    [app] (title=.*)	
    	[Jump] {no}
    #	[Workspace] {1}
    	[Position] (CENTER) {0 0}
    	[Layer] {12}
    [end]

    Обратите внимание, что VMPlayer запускается минимизированным, это сделано для того, чтобы пользователь не видел запуск оболочки VMPlayer. Но для того, чтобы этот эффект до конца сработал, нужно не забыть в настройках VMPlayer поставить галочку на опции «Enter full screen mode after powering on» или как эквивалент — в workstation.vmx установить параметр gui.viewModeAtPowerOn = "fullscreen".
    Если у вас видеокарта NVidia или Radeon и вы установили драйвера, то вы можете полноценно воспользоваться функцией проброса 3D ускорителя в виртуальный видеодевайс, установив галочку в параметре «Accelerate 3D graphics». В workstation.vmx за это отвечает параметр mks.enable3d = "TRUE".

    Клавиатуры и мыши

    Для распределения этих HID девайсов используется возможность VMPlayer захватывать в монопольное использование USB оборудование. Перед тем, как распределять устройства, выясняем их VID и PID, воспользовавшись утилитой lsusb. После того, как выяснены все идентификаторы устройств, прописываем следующие параметры в каждом workstation.vmx.
    /home/vm/user00/workstation.vmx и /home/vm/user01/workstation.vmx
    /home/vm/user00/workstation.vmx и /home/vm/user01/workstation.vmx
    # Общие установки
    vmmouse.present = "FALSE"
    usb.generic.allowHID = "TRUE"
    svga.noHWCursor = "TRUE" 
    
    # Для клавиатуры c VID=0458 и PID=010e
    usb.quirks.device0 = "0x0458:0x010e allow" 
    usb.autoConnect.device0 = "0x0458:0x010e" 
    
    # Для мыши c VID=0566 и PID=3107
    usb.quirks.device1 = "0x0566:0x3107 allow"
    usb.autoConnect.device1 = "0x0566:0x3107"

    USB

    Все USB устройства можно разделить на две категории: постоянно подключенные и подключаемые во время работы.
    С постоянно подключенными проблем нет, они прописываются в соответствующей workstation.vmx, по аналогии и с помощью того же параметра usb.autoConnect.deviceN и утилиты lsusb, что использовались при подключении мышки и клавиатуры.
    Для подключения USB устройств во время работы есть два варианта. Первый вариант — это когда все USB устройства прокидываются только на одну машину. Для этого, в файле workstation.vmx этой машины, устанавливаем параметр usb.generic.autoconnect=TRUE, а в другой соответственно usb.generic.autoconnect = "FALSE".
    Второй вариант, который позволяет распределять USB устройства во время подключения самими пользователями — это использовать технологию USB over IP. Хотя этот способ может оказаться несколько затратным, но он решает поставленную задачу. Задача решается следующим образом: на хост ставится серверная часть, которая расшаривает USB устройства, а на гостевую систему ставится клиент. К сожалению opensource проект usb/ip оказался сырой и приемлемого результата добиться не удалось. При острой необходимости можно воспользоваться коммерческими продуктами, например, мы использовали этот: USB Redirector for Linux (эта часть бесплатная) и USB Redirector Client (эта стоит денег).

    Последний штрих


    Для полноты решения должны работать следующие сценарии:
    1. При включении системного блока, виртуальные машины запускаются автоматически.
    2. Каждое из рабочих мест можно включать и выключать, даже если работает соседнее рабочее место.
    3. При выключении всех рабочих мест, системный блок должен выключиться.

    Пункт 1 и 3 реализованы с помощью скриптов расположенных выше. Пункт два выполнен частично. При выключении одной из виртуальных машин, вторая останется работать. Но как обратно включить выключенную машину? Решается вопрос очень элегантно: для этого вешаем на кнопу Power (это та, что на системном блоке) команду запуска виртуальных машин. Для этого в файле /home/vm/.fluxbox/keys прописываем несколько строк:
    /home/vm/.fluxbox/keys
    /home/vm/.fluxbox/keys
    124 :Exec /home/vm/user00/start & /home/vm/user01/start
    133 :Exec /home/vm/user00/start & /home/vm/user01/start

    После такой конфигурации пользователь будет включать свою машину привычным для себя способом.

    Результат


    Я постарался изложить решение полностью, но некоторые детали я опустил, дабы не засорять и так разросшуюся статью, надеюсь, они не помешают собрать свой dualseat, а если у вас действительно возникнет такое желание, готов ответить на все вопросы возникшие в процессе сборки.

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

    Как это работает у нас

    Решение действительно работает. Сборка dualseat'а на самом деле сведена к минимуму. После установки системы, скриптом устанавливаются дополнительные пакеты, vmplayer и копируются все упомянутые конфиги и скрипты. Виртуальные машины просто тиражируются, используя «золотой шаблон». В конце требуется небольшая доводка: установить корректные разрешения у мониторов, подключить стационарные устройства и сконфигурировать работу с USB.

    Отзывчивость системы более чем приемлема для большинства наших сотрудников. Конечно, повального применения мы не делаем, но закрыли многие вопросы по организации и обновлению рабочих мест, для которых данное решение является наилучшим.

    Спасибо всем за внимание, надеюсь получилось интересно.
    Поделиться публикацией
    Комментарии 39
      0
      USB хабы не пробовали использовать? Чтобы их в виртуалки пробросить, а уже в хабы втыкать всю USB периферию.
        0
        Пробовал. Пришлось даже купить для тестирование. Получилось прокинуть только ту часть хаба, которая отвечает за microSD, SD и т.д. Обычные USB порты так и остались видны только в хосте, виртуалка так их и не увидела.
          0
          Странно, мой китайский ноунейм спокойно пробрасывается в виртуалку со всеми потрохами, при этом целиком пропадая на хосте.
        0
        Вроде ж был какой-то Windows Multipoint Server
          0
          Если честно, именно он натолкнул меня когда-то на мысль, о экспериментах с multiseat, где у пользователя оказалась бы Windows.
          +2
          ps ax | grep? Гораздо проще и надёжнее использовать [[ "$(ps -C vmplayer -o args=)" == *user01* ]] (bash/zsh) или эквивалент с grep.
            0
            У меня ещё
            alias pps='ps -o pid=,args= -C'
            , помогает узнать, запущено ли что‐то, что надо указать kill, если killall неприменим и что я редактирую в Vim’ах (с прибиванием лишнего).
              0
              pgrep и pkill знаете?
                0
                Знаю. Абсолютно бесполезная для меня вещь: во‐первых, мне не нужно и абсолютно не радует использование шаблонов (особенно, требующих по‐умолчанию только частичного совпадения). Во‐вторых, pgrep не пишет аргументы. Нафига мне знать, какие 15 PID соответствуют Vim, если завис и надо прибить только один? Аргументы, с которым я запустил зависший известны, но не номер pty (к тому же, часто не уникальный), не PID (зачем бы мне иначе ps -C?), не SID (что это вообще такое? впрочем не отвечайте, сам нашёл. Проблема та же, что и с терминалом) и не куча других неуникальных параметров.
                  0
                  pgrep -fl
                  очень даже пишет аргументы.
                    0
                    Ага, только я теперь не могу нормально сказать, что хочу видеть только запущенные vim, а не какой‐нибудь screen с -S vim-test. Писать шаблон, который с гарантией выберет только запущенные vim мне не хочется совершенно. Уж лучше я использую сокращения zsh чтобы сократить | grep в G: pps vim G foo. Или просто выберу глазами, гарантированно не получив в числе прочего вывода мусор с vim в аргументах или безумно длинные строчки (люблю открывать все файлы проекта сразу, всё равно vim реально их грузит в память только при необходимости) (ps обрезает строчки, если вывод осуществляется на терминал, pgrep нет).
              0
              Попробую. Интересное предложение, спасибо.
            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Я им пользуюсь около 6 лет. Тормоза могут быть из-за нехватки оперативки, банально потому что некоторые процессы запущены в двух экземлярах. А если мощности компьютера хватает, то можно даже в 3D игры играть на одной видеокарте, устраивая сетевую баталия из двух аккаунтов на одном системнике.
                Разработка отечественная, очень эффективная. По сути, активирует скрытые возможности Windows. Т.е. если бы Microsoft хотели, это решалось бы одной галочкой в настройках.
                  0
                  Кстати, есть уже версия для Win7 и будет для Win8: www.ibik-soft.com/
                0
                Почему не был предложен VDI?
                Разделение мощности компьютера на 2, не самое удачное, имхо, решение. Добавляется множество ограничений и, я уверен, много проблем в будущем, которые сложно предсказать.
                  0
                  Используя VDI технологию, вы сможете организовать два рабочих места на одной железке?
                    0
                    Нет, но я полагаю цель заказчика — консолидировать ресурсы. vdi в этом плане как нельзя кстати подходит.
                  0
                  Спасибо, это может пригодиться. Но мне кажется, что два ЖД по 500гБ тут совершенно ни к чему. При таких потерях производительности вы сможете использоваться только офис, автокад — предел, а им винчестеры совершенно ни к чему, лучше бы в raid1 воткнули. Он как раз и ускоряет немного.
                    0
                    Вообще потребность во втором диске стала видна во время загрузки обоих ОС, когда происходит включение компьютера. Системы грузились в несколько раз медленнее, чем после их разноса на два жестких диска.

                    Размер жесткого диска вообще не важен, это вопрос больше цены, так как рядовому офисному сотруднику и 100Gb зачастую больше чем надо. А на текущий момент 500Gb — по цене, это достаточно приемлемый вариант по соотношению цена/размер.

                    Потеря производительности практически не вида обычному офисному сотруднику, во всех рядовых офисных и бизнес приложениях, это сейчас я могу заявить со 100% гарантией.

                    AutoCAD с ценником в несколько тысяч долларов думаю требует вообще серьезного подхода к рабочему месту, это наверно не совсем тот случай.
                      0
                      Проверьте пожалуйста такой момент:
                      один пользователь приносит переносной USB диск на много гигабайт порнухи важных данных, диск пробрасывается в виртуалку. Пользователь ставит копирование на свой диск (скорость ~20МБайт/с — в зависимости от USB-переходника)
                      и идёт пить чай.
                      Второй пользователь может при этом работать?
                      У меня вот хостовая убунта 12.04 сильно лагала, когда такое копирование происходило на виртуальной XP.
                    0
                    Отказ одного компонента хоста приведёт недоступности сразу два рабочих места. Зачастую люди, дублирующие свои функциональные обязанности, сидят на работе как раз рядом. Учитывая это, не думали про некую административную защиту от такой своеобразной единой точки отказа?
                      +1
                      Компенсируется в два раза меньшими средствами на обслуживание.
                        0
                        В таких случаях техника всегда лежит в резерве, а развернуть бекапы виртуалок это пара минут. Мне кажется именно такой вариант достаточно эффективный в плане быстрой замены!
                          0
                          Полностью согласен, риск есть. Для снижения вероятности его наступления, сделать видимо ничего нельзя, но качестве реактивных мер предусмотрено: Постоянное наличие резервного компьютера; Комплектующие для ремонта; Thinstation
                          В качестве превентивных мер: Бекапирование пользовательских данных; Наличие шаблона виртуальной машины

                          На самом деле, мы не используем данное решение в критичных местах, где простой может вылиться во что-то серьезное.
                        0
                        Кстати, при использовании Астер все ресурсы компьютера доступны всем пользователям. Т.е. нет жёсткого разделения, как при использовании вирт машин, хотя на них только оперативка разделена, но это тоже минус. Да и с файлами удобнее работать.
                          0
                          Астер неплох, но только если заработал сразу и с лицензированием нет заморочек (дом или офис дома).
                          Разработчик забил на продукт.
                          У меня вот на одной установке CD-ROM на втором месте никак не виделся, но не критично — забил.
                          0
                          А на сколько реально востребован такой подход, в кто (я имею ввиду общие характеристики компании) может быть заказчиком? Не встречал ни разу таких реализаций. Обычно народ использует тонкие клиенты, либо с каким-нибудь Windows Server, либо, последнее время так особенно — VDI.
                            0
                            Подход был одно время очень востребован, когда мы закрыли им несколько «заказов» на рабочие места, отклоненные руководством, как «не обязательные», но прямые руководители, все же, очень хотели иметь обновленные или недостающие рабочие станции у своих сотрудников.

                            Сейчас мы чаще используем Thinstation, используя в качестве терминалов бездисковые станции, а если быть точнее, порядком устаревшие компьютеры.

                            А вообще, мы достаточно крупная компания, но ситуации бывают разные у всех.
                              0
                              Написали бы статейку про как используете Thinstation, с удовольствием бы почитал!
                                0
                                Да, в планах есть. Обязательно напишу.
                                0
                                а на сервере — xrdp? Можно поподробнее?
                                  0
                                  Есть ESXi, на нем крутятся виртуалки, каждая конкретного пользователя. Доступ клиента по rdp.
                                    0
                                    1. На виртуалках только «рабочий» софт? Проверьте пожалуйста, как работает скроллинг «барахолочки» в контакте, или веб интерфейса mail.ru — с лагами или без. По сравнению с обычным десктопом.
                                    2. Как настроено ограничение ресурсов (чтоб один юзер, запустив пяток страниц с флеш баннерами или архиваци. winrar — не повесил всех)?
                                      0
                                      1.а) Скролинг очень неприятный, но в IE. Специально для TS по умолчанию установлен Firefox, результат приемлимый.
                                      1.б) Установлен весь необходимый корпоративный софт, но это не влияет на производительность, ESXi крутится на ОЧЕНЬ мощном сервере, и у каждой виртуалки по 3Gb оперативки.
                                      2) ограничений нет
                                0
                                Не могли бы Вы слегка расшифровать параметры в резделе «небольшой тюнинг системы и гипервизора»?
                                Для решивших повторить Ваш эксперимент (в том числе и меня) это было бы неплохой эконимией времени на гуглёж.
                                  0
                                  Основная часть тюнинга — это оптимизация работы с оперативной памятью и дисковой подсистемой.
                                  /etc/vmware/config
                                  mainMem.useNamedFile="FALSE"
                                  tmpDirectory="/run/shm"
                                  prefvmx.useRecommendedLockedMemSize="TRUE"
                                  вместе с
                                  workstation.vmx
                                  mainMem.useNamedFile = "FALSE"
                                  дают самый потрясающий прирост производительности. Как я понял NamedFile — это, что-то вроде, файла подкачки. Но даже выключив его, vmplayer все еще что-то кэширует, tmpDirectory перенаправляет этот кэш в оперативную память.

                                  Многие параметры по тюнингу, были найдены на интернет просторах. Поиском всяких хитростей уже занимаюсь более трех лет, и к сожалению часть информации уже утеряна. Но большая часть тюнинга описана в VMware Knowledge Base.
                                    0
                                    Рекомендую сделать поиск «troubleshooting performance» в VMware Knowledge Base, найдете много интересного для себя. Несмотря на то, что выдача может касаться различных продуктов VMware, большая часть информации применима ко всем продуктам VMware.
                                    0
                                    Думаю о таком варианте — один пользователь работает на хосте (Ubuntu любой WM, браузер и Libreoffice) а второй — на виртуалке с XP (спецсофт). Допустим даже ручной запуск виртуалки.
                                    Остаётся только вопрос — как не дать курсору мыши хостового пользователя залезть на территорию виртуалки?

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое