Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
> отсутствуют удобные графические оболочки для запуска и редактирования виртуальных машин
Если не секрет, а чем libvirtd + virt-manager не устроили?
Если не секрет, а чем libvirtd + virt-manager не устроили?
> Если не секрет, а чем libvirtd + virt-manager не устроили?
Тяжеловесностью, глючностью и заточенностью под представления авторов. Возможно, за год с момента последней проверки ситуация изменилась к лучшему, но тогда было так.
Например, «virsh shutdown» менял статус контейнера на «shutdowning...», но kvm-контейнер продолжал работать до «killall kvm» на ферме либо «poweroff» в гостевой системе.
Конфиги контейнеров (доменов в терминологии либвирта) требовалось менять при миграции с одной фермы на другую (например, между Дебианом и Центосом), потому что дистрибутиво-специфичные вещи libvirt предпочитает хранить не в общесистемных настройках, а запихивает прямо в настройки контейнеров.
Писатели либвирта явно считали, что для связи гостей с внешним миром должен быть только один способ — через бридж. Попытки настроить базовую систему как роутер средствами либвирта привели к проблемам, которых при прямом использовании КВМ не было и в помине:
1) Сначала либвирт не давал КВМу создавать TAP-интерфейсы из-за зарезанных привилегий.
2) Когда это победили и обновились с libvirt с 0.6 из Центоса до 0.7 из Епеля, появились новые ограничения привилегий, из-за которых настроенные конфиги снова нерабочими.
3) Если в конфигах либвирта включались DHCP и/или TFTP, либвирт автоматически запускал dnsmasq, но с такими параметрами, что на TAP-интерфейсах использовать его было нельзя: с ключом «bind-interfaces» он их просто не видел, потому что запускался либвиртом ДО создания интерфейса.
Получилось, что своими проблемами либвирт зря отнял время, а в плане облегчения работы с КВМ никак не помог. Скорее наоборот, разобраться непосредственно с КВМ оказалось бы быстрее. Но это только мой личный опыт, коллективный разум вроде бы считает иначе.
Тяжеловесностью, глючностью и заточенностью под представления авторов. Возможно, за год с момента последней проверки ситуация изменилась к лучшему, но тогда было так.
Например, «virsh shutdown» менял статус контейнера на «shutdowning...», но kvm-контейнер продолжал работать до «killall kvm» на ферме либо «poweroff» в гостевой системе.
Конфиги контейнеров (доменов в терминологии либвирта) требовалось менять при миграции с одной фермы на другую (например, между Дебианом и Центосом), потому что дистрибутиво-специфичные вещи libvirt предпочитает хранить не в общесистемных настройках, а запихивает прямо в настройки контейнеров.
Писатели либвирта явно считали, что для связи гостей с внешним миром должен быть только один способ — через бридж. Попытки настроить базовую систему как роутер средствами либвирта привели к проблемам, которых при прямом использовании КВМ не было и в помине:
1) Сначала либвирт не давал КВМу создавать TAP-интерфейсы из-за зарезанных привилегий.
2) Когда это победили и обновились с libvirt с 0.6 из Центоса до 0.7 из Епеля, появились новые ограничения привилегий, из-за которых настроенные конфиги снова нерабочими.
3) Если в конфигах либвирта включались DHCP и/или TFTP, либвирт автоматически запускал dnsmasq, но с такими параметрами, что на TAP-интерфейсах использовать его было нельзя: с ключом «bind-interfaces» он их просто не видел, потому что запускался либвиртом ДО создания интерфейса.
Получилось, что своими проблемами либвирт зря отнял время, а в плане облегчения работы с КВМ никак не помог. Скорее наоборот, разобраться непосредственно с КВМ оказалось бы быстрее. Но это только мой личный опыт, коллективный разум вроде бы считает иначе.
libvirt действительно был глючноват пару лет назад. Сейчас очень даже ничего.
1. virsh destroy не?
2.Ну как ещё то, если у каждого дистрибутива свой велосипедик? Как раз vibvirt и призван привнести некий уровень абстракции в это дело.
3. Бред какой-то. Прямо сейчас у меня работает два конфига, один как роутер, второй как NAT. По умолчанию действительно bridge, но это меняется в один клик.
4. Не знаю, TAP не делал, но 0.6 это древность какая-то.
5. И правильно что он dnsmasq так запустил. По умолчанию dnsmasq считает своим долгом раздавать IP во все внешние сети, куда дотянется. Кстати, там есть какая-то версия dnsmasq с багом, где bind-interfaces не работает. Так вот libvirtd вообще не запустится с ней.
Не знаю как на счёт freebsd, но я запустил netbsd6 через virsh, без каких либо проблем с конфигами по дефолту. Это заняло у меня 5 минут. Мне кажется вы придумали себе проблему и отчаянно с ней боритесь, а проблемы то особо и нет.
1. virsh destroy не?
2.Ну как ещё то, если у каждого дистрибутива свой велосипедик? Как раз vibvirt и призван привнести некий уровень абстракции в это дело.
3. Бред какой-то. Прямо сейчас у меня работает два конфига, один как роутер, второй как NAT. По умолчанию действительно bridge, но это меняется в один клик.
4. Не знаю, TAP не делал, но 0.6 это древность какая-то.
5. И правильно что он dnsmasq так запустил. По умолчанию dnsmasq считает своим долгом раздавать IP во все внешние сети, куда дотянется. Кстати, там есть какая-то версия dnsmasq с багом, где bind-interfaces не работает. Так вот libvirtd вообще не запустится с ней.
Не знаю как на счёт freebsd, но я запустил netbsd6 через virsh, без каких либо проблем с конфигами по дефолту. Это заняло у меня 5 минут. Мне кажется вы придумали себе проблему и отчаянно с ней боритесь, а проблемы то особо и нет.
1. не. разбирайтесь, чем destroy отличается от shutdown.
2. если особенности фермы запихнуты в настройки всех контейнеров, то это какой-то странный уровень абстракции.
3. менялось так, как написано. проблемы были такие, как перечислены.
4. версия из последнего на тот момент официального релиза rhel. все претензии к редхату.
5. откройте для себя ключ dnsmasq --except-interface. если нужна более серьезная защита, можете почитать про iptables.
2. если особенности фермы запихнуты в настройки всех контейнеров, то это какой-то странный уровень абстракции.
3. менялось так, как написано. проблемы были такие, как перечислены.
4. версия из последнего на тот момент официального релиза rhel. все претензии к редхату.
5. откройте для себя ключ dnsmasq --except-interface. если нужна более серьезная защита, можете почитать про iptables.
1. Я понимаю, чем они отличаются. У вас машина не слышит ACPI, но это не проблема не virt-manager явно.
2. pastebin.com/rdnLTBmB Где тут что-то дистрибутиво-зависимое то?
3. virt-manager 0.6.1 Monday Jan 26th, 2009 Я думаю что, обсуждать софт 4 летней давности смысла никакого нет
4. см п3
5. Тот же принцип, вид с боку. Зачем ещё городить забор из iptables, когда есть нормальное решение привязать dhcp сервер туда куда нужно?
2. pastebin.com/rdnLTBmB Где тут что-то дистрибутиво-зависимое то?
3. virt-manager 0.6.1 Monday Jan 26th, 2009 Я думаю что, обсуждать софт 4 летней давности смысла никакого нет
4. см п3
5. Тот же принцип, вид с боку. Зачем ещё городить забор из iptables, когда есть нормальное решение привязать dhcp сервер туда куда нужно?
«отсутствуют удобные графические оболочки для запуска и редактирования виртуальных машин»…
Тут вы батенька не правы, очень даже удобно:
Тут вы батенька не правы, очень даже удобно:
Я выше написал, чем лично меня не устроила libvirt.
Вряд ли virt-manager настолько умный, что умеет обходить её ограничения.
Формально из того, что перечислено на странице www.linux-kvm.org/page/Management_Tools,
для начального знакомства к KVM лучше всего подходит AQemu:
лёгкая GUI-оболочка без собственных представлений о том, что правильно, а что нет.
Увы, но на практике оказалось, что он пока слишком сырой: в первый раз кое-как запустился,
но когда создал в ~/.aqemu описание первой виртуалки, стал стабильно падать с ошибкой сегментирования прямо при запуске.
Вряд ли virt-manager настолько умный, что умеет обходить её ограничения.
Формально из того, что перечислено на странице www.linux-kvm.org/page/Management_Tools,
для начального знакомства к KVM лучше всего подходит AQemu:
лёгкая GUI-оболочка без собственных представлений о том, что правильно, а что нет.
Увы, но на практике оказалось, что он пока слишком сырой: в первый раз кое-как запустился,
но когда создал в ~/.aqemu описание первой виртуалки, стал стабильно падать с ошибкой сегментирования прямо при запуске.
Не знаю, у меня описанных вами проблем с virt-manager небыло.
В качестве хостовой системы ubuntu 12.10 server, изначально ставил 12.04 но случайно обновил, а переустанавливать было лень.
-...что дистрибутиво-специфичные вещи libvirt предпочитает хранить не в общесистемных настройках, а запихивает прямо в настройки контейнеров. — на мой взгляд так правильно
-Писатели либвирта явно считали, что для связи гостей с внешним миром должен быть только один способ — через бридж. Попытки настроить базовую систему как роутер средствами либвирта привели к проблемам, — у меня такого небыло, специально экспериментировал с настройками сети, NAT есть и работает, DHCP работает. Возможно Ваши проблемы с виртуальными интерфейсами связаны с настройками Selinux, который в CentOS включён по-умолчанию.
По поводу тяжеловесности virt-manage — я не замечал, но возможно по тому, что в качестве хостовой системы у меня достаточно мощный сервер.
В качестве хостовой системы ubuntu 12.10 server, изначально ставил 12.04 но случайно обновил, а переустанавливать было лень.
-...что дистрибутиво-специфичные вещи libvirt предпочитает хранить не в общесистемных настройках, а запихивает прямо в настройки контейнеров. — на мой взгляд так правильно
-Писатели либвирта явно считали, что для связи гостей с внешним миром должен быть только один способ — через бридж. Попытки настроить базовую систему как роутер средствами либвирта привели к проблемам, — у меня такого небыло, специально экспериментировал с настройками сети, NAT есть и работает, DHCP работает. Возможно Ваши проблемы с виртуальными интерфейсами связаны с настройками Selinux, который в CentOS включён по-умолчанию.
По поводу тяжеловесности virt-manage — я не замечал, но возможно по тому, что в качестве хостовой системы у меня достаточно мощный сервер.
Посмотрите в сторону Proxmox, вполне удобно и даст Вам KVM виртуализацию с GUI обвязкой.
Proxmox cluster будет вполне удобно для фермы.
Я гоняю на ней в продакше FreeBSD через KVM безо всяких проблем, даже очень старые типа 4.1.
C другой стороны они потребовали гораздо меньше танцев при переноски с VmWare платформы виртуализации, чем Win2k например.
Proxmox cluster будет вполне удобно для фермы.
Я гоняю на ней в продакше FreeBSD через KVM безо всяких проблем, даже очень старые типа 4.1.
C другой стороны они потребовали гораздо меньше танцев при переноски с VmWare платформы виртуализации, чем Win2k например.
Спасибо, про Proxmox я знаю :) Запускал под ним бухгалтерскую Венду с терминал сервером, Астериски, контроллер Unifi и много другого интересного. В данном случае он плохо подходит под требования задачи — смотрите первое предложение статьи:
Proxmox: требует продуманной инсталляции на отдельный компьютер; вряд ли пригоден для экспериментов на десктопном компе; засирает каждую базовую систему кучей интерфейсных плюшек, работающих с рутовыми правами, которым по хорошему место в отдельном контейнере; ради поддержки OpenVZ построен на сильно неновом и редко обновляемом кастомизированном ядре; имеет несколько страшноватую систему обновления с обязательным пересозданием кластера.
То есть у Proxmox есть своя ниша в Enterprise, где он imho лучший, но мне требовалось такое решение, которое можно было бы запустить на существующих серверах без кардинальных переделок, и иметь возможность до задействования серверов по максимуму тестировать его локально.
Задача: запустить FreeBSD из-под Linux, желательно с минимумом изменений в Linux-системе при начальной настройке и обновлениях, возможностью запуска на рабочей станции и на сервере
Proxmox: требует продуманной инсталляции на отдельный компьютер; вряд ли пригоден для экспериментов на десктопном компе; засирает каждую базовую систему кучей интерфейсных плюшек, работающих с рутовыми правами, которым по хорошему место в отдельном контейнере; ради поддержки OpenVZ построен на сильно неновом и редко обновляемом кастомизированном ядре; имеет несколько страшноватую систему обновления с обязательным пересозданием кластера.
То есть у Proxmox есть своя ниша в Enterprise, где он imho лучший, но мне требовалось такое решение, которое можно было бы запустить на существующих серверах без кардинальных переделок, и иметь возможность до задействования серверов по максимуму тестировать его локально.
>Proxmox: требует продуманной инсталляции на отдельный компьютер;
В общем и целом неправда, поверх дебиана ставится.
>засирает каждую базовую систему кучей интерфейсных плюшек, работающих с рутовыми правами,
Сам интерфейс работает через апач, который работает совсем даже без рутовых прав:
2233 root 20 0 268M 41780 5680 S 0.0 0.1 0:07.86 `- /usr/sbin/apache2 -k start
208590 www-data 20 0 276M 40884 3908 S 0.0 0.1 0:00.13 | `- /usr/sbin/apache2 -k start
208573 www-data 20 0 276M 40916 3924 S 0.0 0.1 0:00.20 | `- /usr/sbin/apache2 -k start
>построен на сильно неновом и редко обновляемом кастомизированном ядре
Первое не особо верное, они ядро утащили с RHEL 6 а там интересная картина с версиями. Например, у них последний QEMU:
forum.proxmox.com/threads/12236-Updates-for-Proxmox-VE-2-2-including-QEMU-1-3
>имеет несколько страшноватую систему обновления с обязательным пересозданием кластера.
Кластер пересоздать несложно, виртуалки никуда не денутся при этом, более того, их даже останавливать не придется. Вот, например:
undefinederror.org/how-to-reset-cluster-configuration-in-proxmox-2/
Единственное что в нем существенно — если ставить не на дебиан, то можно заиметь себе ненужных развлечений. Ну а для вашего случая вообще можно без танцев с мостами и конфигами. Я написал внизу, как именно.
В общем и целом неправда, поверх дебиана ставится.
>засирает каждую базовую систему кучей интерфейсных плюшек, работающих с рутовыми правами,
Сам интерфейс работает через апач, который работает совсем даже без рутовых прав:
2233 root 20 0 268M 41780 5680 S 0.0 0.1 0:07.86 `- /usr/sbin/apache2 -k start
208590 www-data 20 0 276M 40884 3908 S 0.0 0.1 0:00.13 | `- /usr/sbin/apache2 -k start
208573 www-data 20 0 276M 40916 3924 S 0.0 0.1 0:00.20 | `- /usr/sbin/apache2 -k start
>построен на сильно неновом и редко обновляемом кастомизированном ядре
Первое не особо верное, они ядро утащили с RHEL 6 а там интересная картина с версиями. Например, у них последний QEMU:
forum.proxmox.com/threads/12236-Updates-for-Proxmox-VE-2-2-including-QEMU-1-3
>имеет несколько страшноватую систему обновления с обязательным пересозданием кластера.
Кластер пересоздать несложно, виртуалки никуда не денутся при этом, более того, их даже останавливать не придется. Вот, например:
undefinederror.org/how-to-reset-cluster-configuration-in-proxmox-2/
Единственное что в нем существенно — если ставить не на дебиан, то можно заиметь себе ненужных развлечений. Ну а для вашего случая вообще можно без танцев с мостами и конфигами. Я написал внизу, как именно.
>> Proxmox: требует продуманной инсталляции на отдельный компьютер;
> В общем и целом неправда, поверх дебиана ставится.
Спасибо, кэп :) У Вас на десктопе Дебиан?
Если потребуется что-то проверить, Вы взгромоздите Проксмокс прямо на него?
«Поверх дебиана» — это значит, что продумывать инсталляцию Проксмокса уже не надо?
> интерфейс работает через апач, который работает совсем даже без рутовых прав:
И при этом позволяет создавать и удалять виртуалки, образы дисков, хранилища
и прочее, что очевидно требует суперпользовательских привилегий.
Вы твёрдо уверены, что доступа к рутовой консоли из него никак не получить?
Кстати, вот неплохой отзыв: klinkov.ya.ru/replies.xml?item_no=2112
У меня таких страшных косяков не было, возможно потому, что задачи для Проксмокса были попроще.
> они ядро утащили с RHEL 6 а там интересная картина с версиями. Например, у них последний QEMU:
Ядро скорее уж не от RHEL, а от Parallels: download.openvz.org/kernel/branches/rhel6-2.6.32/stable/
То, что на pve.proxmox.com/wiki/Proxmox_VE_Kernel написано "based on RHEL6x", для ovz-ядра верно.
Qemu там может быть какой угодно, но очевидно, что новые функции переносятся в rhel-ядра не полностью и не сразу.
На практике из-за этого периодически приходилось сталкиваться с ситуациями наподобие такой:
forum.nag.ru/forum/index.php?showtopic=70612&view=findpost&p=653589
> В общем и целом неправда, поверх дебиана ставится.
Спасибо, кэп :) У Вас на десктопе Дебиан?
Если потребуется что-то проверить, Вы взгромоздите Проксмокс прямо на него?
«Поверх дебиана» — это значит, что продумывать инсталляцию Проксмокса уже не надо?
> интерфейс работает через апач, который работает совсем даже без рутовых прав:
И при этом позволяет создавать и удалять виртуалки, образы дисков, хранилища
и прочее, что очевидно требует суперпользовательских привилегий.
Вы твёрдо уверены, что доступа к рутовой консоли из него никак не получить?
Кстати, вот неплохой отзыв: klinkov.ya.ru/replies.xml?item_no=2112
У меня таких страшных косяков не было, возможно потому, что задачи для Проксмокса были попроще.
> они ядро утащили с RHEL 6 а там интересная картина с версиями. Например, у них последний QEMU:
Ядро скорее уж не от RHEL, а от Parallels: download.openvz.org/kernel/branches/rhel6-2.6.32/stable/
То, что на pve.proxmox.com/wiki/Proxmox_VE_Kernel написано "based on RHEL6x", для ovz-ядра верно.
Qemu там может быть какой угодно, но очевидно, что новые функции переносятся в rhel-ядра не полностью и не сразу.
На практике из-за этого периодически приходилось сталкиваться с ситуациями наподобие такой:
forum.nag.ru/forum/index.php?showtopic=70612&view=findpost&p=653589
>Спасибо, кэп :) У Вас на десктопе Дебиан?
Работаю я с линуксовой машины, на которой внезапно да, дебиан.
>Если потребуется что-то проверить, Вы взгромоздите Проксмокс прямо на него?
Громоздил уже.
>«Поверх дебиана» — это значит, что продумывать инсталляцию Проксмокса уже не надо?
Не надо, чего там продумывать то? Имена мостам придумать?
>И при этом позволяет создавать и удалять виртуалки, образы дисков, хранилища
>и прочее, что очевидно требует суперпользовательских привилегий.
>Вы твёрдо уверены, что доступа к рутовой консоли из него никак не получить?
А там свои права есть, это уж как настроишь. Ну и да, общается этот интерфейс с сервисами которые из-под рута крутятся.
>Qemu там может быть какой угодно, но очевидно, что новые функции переносятся в rhel-ядра не полностью и не сразу. На практике из-за этого периодически приходилось сталкиваться с ситуациями наподобие такой:
Да, такое может быть. У меня еще правда не было, хотя есть и весьма новые сервера.
Работаю я с линуксовой машины, на которой внезапно да, дебиан.
>Если потребуется что-то проверить, Вы взгромоздите Проксмокс прямо на него?
Громоздил уже.
>«Поверх дебиана» — это значит, что продумывать инсталляцию Проксмокса уже не надо?
Не надо, чего там продумывать то? Имена мостам придумать?
>И при этом позволяет создавать и удалять виртуалки, образы дисков, хранилища
>и прочее, что очевидно требует суперпользовательских привилегий.
>Вы твёрдо уверены, что доступа к рутовой консоли из него никак не получить?
А там свои права есть, это уж как настроишь. Ну и да, общается этот интерфейс с сервисами которые из-под рута крутятся.
>Qemu там может быть какой угодно, но очевидно, что новые функции переносятся в rhel-ядра не полностью и не сразу. На практике из-за этого периодически приходилось сталкиваться с ситуациями наподобие такой:
Да, такое может быть. У меня еще правда не было, хотя есть и весьма новые сервера.
Если уж действительно с минимумом возни, то почему из командной строки не создать и не запустить виртуалку? Например, так для дебиана, в других системах аналогично, только kvm по-другому нужно ставить:
Когда фряха воткнется и virtio тоже, заменить model=e1000 на model=virtio.
aptitude install kvm
mkdir /srv/kvm
cd /srv/kvm
wget ftp2.ru.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/9.1/FreeBSD-9.1-RELEASE-amd64-disc1.iso
mv FreeBSD-9.1-RELEASE-amd64-disc1.iso freebsd.iso
qemu-img create /srv/kvm/kvm1.raw -f raw 10G
kvm -rtc base=localtime -smp 1 -m 1024 -vnc '10.0.0.1:0' -boot d kvm1.raw -net nic,vlan=0,model=e1000 -net tap,vlan=0,ifname=tap0,script=no -cdrom freebsd.iso &
ip a a 10.2.2.1/29 dev tap0
ip link set dev tap0 up
iptables -t nat -A POSTROUTING -s 10.2.2.2 -o eth0 -j MASQUERADE
Когда фряха воткнется и virtio тоже, заменить model=e1000 на model=virtio.
А что мешает вручную в livecd или fixit поставить с virtio и блекджеком??
Автор не предложил такой вариант. А я фряху редко ставлю, и не знаю. Если знаете конкретно как, напишите.
Берете пакет отсюда (сейчас только amd64, но я думаю нет проблем собрать один раз пакет и ставить из локальной сети)
people.freebsd.org/~kuriyama/virtio/
Делаете как здесь только с ufs
www.infracaninophile.co.uk/articles/install-on-zfs/
Соответственно работаете с virtio подсистемами.
Для установки изначального пакета можно собрать свой livecd или не геморроится и подключить вторую сетевуху с em1000 и по ее коннекту поставить virtio драйвер. Потом ее отключить в настройке kvm.
Кстати:
csup -h cvsup2.ru.FreeBSD.org /usr/share/examples/cvsup/standard-supfile
это не будет работать скоро кстати, так как код переводят на svn
И добавлю в 10ке обещают virtio в базовом пакете. Так что может в 9.3 он тоже будет в базовом.
people.freebsd.org/~kuriyama/virtio/
Делаете как здесь только с ufs
www.infracaninophile.co.uk/articles/install-on-zfs/
Соответственно работаете с virtio подсистемами.
Для установки изначального пакета можно собрать свой livecd или не геморроится и подключить вторую сетевуху с em1000 и по ее коннекту поставить virtio драйвер. Потом ее отключить в настройке kvm.
Кстати:
csup -h cvsup2.ru.FreeBSD.org /usr/share/examples/cvsup/standard-supfile
это не будет работать скоро кстати, так как код переводят на svn
И добавлю в 10ке обещают virtio в базовом пакете. Так что может в 9.3 он тоже будет в базовом.
1) Не мешает для гарантии включать sysctl net.ipv4.ip_forward=1
2) В домашней или офисной локалке ProxyARP имхо предпочтительнее маскарадинга,
потому что позволит без дополнительных настроек заходить на виртуалку с соседних компов.
И не сильно сложнее в настройке.
3) И без dnsmasq не комильфо, на гостевой системе придётся настраивать статический IP.
2) В домашней или офисной локалке ProxyARP имхо предпочтительнее маскарадинга,
потому что позволит без дополнительных настроек заходить на виртуалку с соседних компов.
И не сильно сложнее в настройке.
3) И без dnsmasq не комильфо, на гостевой системе придётся настраивать статический IP.
4) ip+iptables корректнее выносить в -net tap,script=kvm-ifup
5) vlan=0 не нужен, ifname=tap0 незачем (kvm-ifup получит автоматическое имя интерфейса в $1) и вредно (tap0 может быть уже занят).
5) vlan=0 не нужен, ifname=tap0 незачем (kvm-ifup получит автоматическое имя интерфейса в $1) и вредно (tap0 может быть уже занят).
4) Так вся моя идея в том, чтобы без скриптов обойтись. Вообще.
5) Про vlan не знал, завтра проверю. А про tap, я думаю что чтобы проверить в общем-то самое то. Я когда с KVM разбирался, скачал livecd и прибил интерфейс и IP руками. А если интерфейс уже занят, KVM насколько помню ругнется и не взлетит.
5) Про vlan не знал, завтра проверю. А про tap, я думаю что чтобы проверить в общем-то самое то. Я когда с KVM разбирался, скачал livecd и прибил интерфейс и IP руками. А если интерфейс уже занят, KVM насколько помню ругнется и не взлетит.
6) -boot d kvm1.raw
очепятка? не должно быть "-hda kvm1.raw"?
очепятка? не должно быть "-hda kvm1.raw"?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Запуск FreeBSD в Linux KVM