rPman

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

способы переноса линукс

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

Самое универсальное и быстрое - переносить изнутри виртуальной машины обычными инструментами, например clonezilla, можно создать временную виртуальную машину, в которую добавить те же диски. Возможно после потребуется обновить/установить драйвера паравиртуализации (у vmware такой пакет есть и для linux хотя не обязателен)

обычно xen/kvm виртуалки дороже openvz,
и одна из причин почему, потому что на openvz оверселить проще, потому что на openvz возможны конфигурации, когда вам реально доступно меньше оперативной памяти чем заявлено по тарифу...

НО openvz быстрее, потому что не используется виртуализация (а это +10%-30% к производительности вычислений, всего что занимает процессор), потому что оперативная память экономится (считанные десятки мегабайт) за счет того что системные процессы общие для всех виртуалок на хосте.

xen/kvm это почти полноценная машина, любые операционки (в разумных пределах, так как виртуализация кушает ресурсы), любые версии ядер, ваши собственные капризы, вплоть до gentoo... иногда это бонус.

и для параноиков, помним, на xen/kvm вы сможете настроить шифрование раздела с вводом пароля/указания ключевого файла, при перезагрузке в ssh сессии, и администраторам/хостерам будет заметно дороже (но не невозможно) получить к вашим данным доступ.

Собственно вопрос в том, как заставить Flashcache кешировать блоки по 512 байт их больше всего и если хотя бы они попадут в кеш, нам это здорово поможет.
Альтернативный вариант решения проблемы как заставить гостевую Windows оперировать исключительно блоками размером 4К

Проверить. может системный раздел ntfs, не отформатирован ли он с размером сектора 512? через backup-format-restore сделать размер сектора в 4к принудительно.

Кстати еще очень немаловажное замечание:

* xen/vmware/virtualbox/kvm — умеют работать только с контейнерами, т.е. хост система не монтирует диски гостевых контейнеров (но может это делать через снапшоты, например) — значит хостер имеет ограниченный доступ к данным своих клиентов. Так как для этих технологий вполне возможно создать свою виртуальную машину, со своим ядром и загрузчиком initramfs, тру параноики создают шифрованный контейнер, а пароль вводят через ssh в initramfs. Для получения доступа к данным такой машины потребуется чуть больше чем просто права администратора (в простом случае необходимо будет изучать дампы памяти, а в сложном — потребуется специализированное железо и много много денег)

* openvz/lxc/chroot — файловая система виртуальной машины должна быть примонтирована в хост системе, шифрование файлов и т.п. фактически недоступно (защитить данные от хостера нереально сложно, но можно поиграться с каскадированием виртуальных машин)

Доступ хостера к данным — очень важный момент для некоторых проектов (здравствуй провайдер linode и украденные много много bitcoin, послужившие теоретически основной причиной смерти сервиса bitcoinica).

Вот популярные системы в порядке понижения функционала:

Xen — на порядок сложнее и функциональнее, имеет помимо режима паравиртуализации (как openvz) режим полной виртуализации (в т.ч. поддержка соответствующих фич процессоров), есть механизмы переброса железа внутрь виртуалки (например, поддержка не самых слабых intel видеокарт), снапшоты, миграция,… много много вкусных фич.

VMWare — как и xen, сложен, наворочен, приправлен соответствующей инфраструктурой и хорошими забористыми ценами :) режима полноценной паравиртуализации не имеет

kvm/qemu — полная эмуляция процессора (а так же виртуализация через поддержку процессорами), есть вкусности от 'старших братьев' вида миграция запущенной виртуалки по сети, переброса железа (сильно хуже поддержка чем xen/vmware) и т.п. можно считать бакэндом, так как GUI в идеалогии не имеет, оно пилится желающим

VirtualBox — эмуляция процессора, в т.ч. использование поддержки виртуализации процессоров, идеален как отдельное десктопное приложение, миграции по сети нет, есть снапшоты, некоторые вкусности скрыты от GUI в коммандной строке

OpenVZ — это работа всех машин на одном ядре (патчи к нему так и зовутся openvz), нет виртуализации, максимальная скорость (так как фактически это расширенный chroot с изоляцией). Для запуска модуля ядра на поклон нужно идти к хост системе и ее администратору (например tun/tap адаптер у firstvds дают по запросу)
Снапшотов нет (но их реализуют через lvm), миграция есть, есть сброс состояния контейнера на диск и возобновление работы…

Lxc — еще проще чем openVZ, нет даже грамотной изоляции (если подсуетиться, можно, имея рут в контейнере, выйти в хост систему с рутовым доступом), прямой аналог jail во freebsd, имеет смысл для хитрых сетевых конфигураций, тестов и т.п.

Chroot — это даже не виртуалка, это просто простейшая изоляция в пределах файловой системы, подмена путей в вызовах функций работы с файлами.
p.s. lxc называют еще 'chroot на стероидах'

OpenVZ/lxc/chroot поддерживают почти полноценное каскадирование виртуалок (т.е. к примеру можно внутри контейнера openvz запустить kvm/virtualbox при наличии модулей, даже с поддержкой аппаратного ускорения)

Пользуйтесь тем, что сумеет перебросить внутрь виртуальных машин ваше оборудование… если в win7 прямого доступа к железу (в т.ч. видеокарте, например для игр) не требуется, а железо для видеокамер (карта захвата обычно pci) не перебрасывается то установите в качестве хост системы windows XP а уже в ней поднимите виртуалку (любую на выбор — qemu/kvm/vbox/vmware/hiper-v/xen) с windows 7.

Иначе ищите ту виртуальную машины, у которой есть возможность перебросить внутрь виртуалки железо для видеокамер (почти наверняка потребуется поддержка на уровне материнской платы и процессора — iommu/vt-d)… почти наверняка прийдется повозиться, причем значительно сильнее (и дороже), чем при смене управляющего ПО для камер.