Виртуализация средствами AstraLinux 1.6 SE

oko

New member
Сообщения
1 257
#21
to Sobergun
Если вы ни разу не ловили конфликт двух схожих сервисов, запущенных одновременно, - я вам по-доброму завидую...
 

clop1000

New member
Сообщения
129
#23
Не совсем понял...
посты #2 и #17
МКЦ отключаем или нет?
Включаем.
С выключенным МКЦ virsh будет писать странные ошибки на нехватку permission при попытке выключить виртуалку.

Может это как то настраивается но каким образом - я не нашел.
 

McCake

New member
Сообщения
26
#24
Добрый день! Подскажите пожалуйста! Уже не знаю что делать. Пытаюсь поставить на Astra Linux SE 1.6 Смоленск виртуальную машину. Использую virt-install. Предварительно установил следующие пакеты: sudo apt install qemu qemu-kvm libvirt0 libvirt-daemon-system bridge-utils

Делаю:

sudo virt-install --virt-type=kvm --name MyVM --ram 4096 --vcpu=2 --os-type=linux --hvm --cdrom=/var/lib/libvirt/boot/MyVM_good.iso --network bridge=br0 --graphics vnc —disk path=/var/lib/libvirt/images/MyVM.qcow

Выдаёт:

Starting install...
ERROR access denied
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
virsh --connect qemu:///system start MyVM
otherwise, please restart your installation.

Проверяю libvirtd.service:

smith@astra:~$ sudo systemctl status libvirtd.service
● libvirtd.service - Virtualization daemon
Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2022-05-17 16:16:04 MSK; 15s ago
Docs: man:libvirtd(8)
http://libvirt.org
Process: 1871 ExecStartPre=/usr/sbin/pdp-init-libvirt (code=exited, status=0/SUCCESS)
Main PID: 1893 (libvirtd)
Tasks: 16 (limit: 4915)
CGroup: /system.slice/libvirtd.service
└─1893 /usr/sbin/libvirtd

май 17 16:16:04 astra systemd[1]: Starting Virtualization daemon...
май 17 16:16:04 astra pdp-init-libvirt[1871]: kvm_intel 204800 0
май 17 16:16:04 astra pdp-init-libvirt[1871]: kvm 598016 1 kvm_intel
май 17 16:16:04 astra pdp-init-libvirt[1871]: irqbypass 16384 1 kvm
май 17 16:16:04 astra systemd[1]: Started Virtualization daemon.
май 17 16:16:11 astra libvirtd[1893]: 1895: info : libvirt version: 3.0.0, package: 4+deb9u10astra.se13 (Rusbitech-Astra <support@ru
май 17 16:16:11 astra libvirtd[1893]: 1895: info : hostname: astra
май 17 16:16:11 astra libvirtd[1893]: 1895: error : virDomainCreateXMLEnsureACL:2353 : access denied


Предварительно делал:
sudo qemu-img create -f qcow2 /var/lib/libvirt/images/MyVM.qcow 10G
sudo chmod 750 /var/lib/libvirt/images/
sudo chown smith /var/lib/libvirt/images

Прошу помощи! Не понимаю на что мне надо права раздать, или что-то с мандатной системой ОССН…….
 
Сообщения
765
#25
Добрый день! Подскажите пожалуйста! Уже не знаю что делать. Пытаюсь поставить на Astra Linux SE 1.6 Смоленск виртуальную машину. Использую virt-install. Предварительно установил следующие пакеты: sudo apt install qemu qemu-kvm libvirt0 libvirt-daemon-system bridge-utils

Делаю:

sudo virt-install --virt-type=kvm --name MyVM --ram 4096 --vcpu=2 --os-type=linux --hvm --cdrom=/var/lib/libvirt/boot/MyVM_good.iso --network bridge=br0 --graphics vnc —disk path=/var/lib/libvirt/images/MyVM.qcow

Выдаёт:

Starting install...
ERROR access denied
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
virsh --connect qemu:///system start MyVM
otherwise, please restart your installation.

Проверяю libvirtd.service:

smith@astra:~$ sudo systemctl status libvirtd.service
● libvirtd.service - Virtualization daemon
Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2022-05-17 16:16:04 MSK; 15s ago
Docs: man:libvirtd(8)
http://libvirt.org
Process: 1871 ExecStartPre=/usr/sbin/pdp-init-libvirt (code=exited, status=0/SUCCESS)
Main PID: 1893 (libvirtd)
Tasks: 16 (limit: 4915)
CGroup: /system.slice/libvirtd.service
└─1893 /usr/sbin/libvirtd

май 17 16:16:04 astra systemd[1]: Starting Virtualization daemon...
май 17 16:16:04 astra pdp-init-libvirt[1871]: kvm_intel 204800 0
май 17 16:16:04 astra pdp-init-libvirt[1871]: kvm 598016 1 kvm_intel
май 17 16:16:04 astra pdp-init-libvirt[1871]: irqbypass 16384 1 kvm
май 17 16:16:04 astra systemd[1]: Started Virtualization daemon.
май 17 16:16:11 astra libvirtd[1893]: 1895: info : libvirt version: 3.0.0, package: 4+deb9u10astra.se13 (Rusbitech-Astra <support@ru
май 17 16:16:11 astra libvirtd[1893]: 1895: info : hostname: astra
май 17 16:16:11 astra libvirtd[1893]: 1895: error : virDomainCreateXMLEnsureACL:2353 : access denied


Предварительно делал:
sudo qemu-img create -f qcow2 /var/lib/libvirt/images/MyVM.qcow 10G
sudo chmod 750 /var/lib/libvirt/images/
sudo chown smith /var/lib/libvirt/images

Прошу помощи! Не понимаю на что мне надо права раздать, или что-то с мандатной системой ОССН…….
А где Вы нашли эту команду? sudo virt-install --virt-type=kvm --name MyVM --ram 4096 --vcpu=2 --os-type=linux --hvm --cdrom=/var/lib/libvirt/boot/MyVM_good.iso --network bridge=br0 --graphics vnc —disk path=/var/lib/libvirt/images/MyVM.qcow
 

McCake

New member
Сообщения
26
#26

McCake

New member
Сообщения
26
#27
Дело было в конфиг-файле /etc/libvirt/libvirtd.config.
Раскомментировал несколько строк (за образец взял конфиг в ubuntu, но которой все отлично завелось) и закоментил access_drivers.
 
Сообщения
765
#28
Дело было в конфиг-файле /etc/libvirt/libvirtd.config.
Раскомментировал несколько строк (за образец взял конфиг в ubuntu, но которой все отлично завелось) и закоментил access_drivers.
И помогло? А уточните пожалуйста какие строки раскоментировали или ссылку дайте на то что именно нужно раскоментировать.
 

McCake

New member
Сообщения
26
#29
И помогло? А уточните пожалуйста какие строки раскоментировали или ссылку дайте на то что именно нужно раскоментировать.
Да, помогло, действительно ВМ машина создалась и даже статус был running, но(!) не запускался оконный менеджер, так как в Astra Linux 1.6 Смоленск нет virt-managera, view-manager (в моём случае можно устанавливать пакеты только с диска, который куплен у официалов)
Короче вернулся к установке и запуску ВМ через sudo qemu-system-....... Через qemu запускается окно ВМ
Установка с ISO в выделенный раздел:
sudo qemu-system-x86_64 -hda ~/<NAME>.qcow -boot d -cdrom ~/<NAME>.iso -m 4096 -enable-kvm
Запуск установленной ВМ:
sudo qemu-system-x86_64 -hda <NAME>.qcow -m 4096 -enable-kvm -smp 2
Эти команды написал короткие, на самом деле там куча аргументов для выделения кол-ва процессоров, потоков, сетевых интерфейсов и пр.

Строки которые раскоментировал:
unix_sock_group = "libvirt"
unix_sock_ro_perms = "0777"
unix_sock_rw_perms = "0770"
auth_unix_ro = "none"
auth_unix_rw = "none"

Эту строку закоментить:
#access_drivers = [ "polkit" ]
И ниже, не помню как точно, на подобие типа такой: #access_drivers = [ "parsek" ] тоже закоментить.
 

oko

New member
Сообщения
1 257
#31
to kvv-vp
Справедливости ради, недавние "спящие" уязвимости в polkit убеждают, что и в таких мерах защиты тоже уверенности нет. А в случае синтетических мест применения (админ локалхоста, ага) ими вообще можно пренебречь...
Впрочем, помнится, в прошлом году еще раз поднимал на ALSE 1.6 виртуализацию без virt-manager и с учетом всего сказанного в этой теме...
1. Ставим Astra Linux в обычном варианте без выбора каких-либо доп.флагов (затирание, киоск, ALD и проч.) и без графики.

2. Заводим пользователя-администратора. Все действия будет совершать от его лица. При входе в консоли всегда выбираем Integrity level: 0

3. Меняем пароль root:
sudo passwd root

4. Мандатный контроль целостности не отключаем

5. Отключаем NetworkManager и создаем сетевой мост для поддержки сети в виртуальных машинах:
sudo systemctl stop NetworkManager
sudo systemctl disable NetworkManager
Правим файл /etc/network/interfaces (в примере только 1 сетевая карта - eth0) и создаем сетевой мост (к примеру, с ip-адресом 192.168.12.110 из подсети 192.168.12.0/24, где шлюз по умолчанию и DNS - роутер выхода вовне - 192.168.12.1)
sudo nano /etc/network/interfaces
auto lo
iface lo inet loopback
auto br0
iface br0 inet static
address 192.168.12.110
netmask 255.255.255.0
gateway 192.168.12.1
dns-nameservers 192.168.12.1
bridge_ports eth0
bridge_stp off
bridge_fd 0
bridge_maxwait 0

8. Перезагружаемся

9. Ставим пакеты поддержки KVM:
sudo apt install libvirt-daemon-system libvirt0 qemu-kvm bridge-utils virt*

10. Добавляем нашего пользователя-администратора в группы поддержки kvm:
sudo usermod -a -G libvirt-admin,libvirt-qemu,libvirt,disk,kvm,astra-admin,astra-console <username>

11. По умолчанию виртуальные машины создаются в /var/lib/libvirt/images, поэтому размечаем пространство в формате QCOW2 (можно и в RAW, но он более «сырой», ага) для файл-образа вирт.машины нужного объема (в пример, 20 Гигабайт):
sudo qemu-img create -f qcow2 /var/lib/libvirt/images/win81.img 20G

12. Правим конфигурацию /etc/libvirt/qemu.conf для корректной работы qemu при запросах к livbirtd:
user = "libvirt-qemu"
user = "+0"
user = "100"
group = "libvirt"

13. Создаем виртуальную машину (для примера Windows, для Linux будут иные параметр os-type и кое-что еще):
virt-install --connect qemu:///system -n win8 -r 2048 --cdrom "/mnt/Win81_64.iso" --arch=x86_64 --vcpus 2 --os-type windows --network=bridge:br0,model=e1000 --hvm --accelerate --graphics vnc,password=password,listen=0.0.0.0,port=5903 --disk "/var/lib/libvirt/images/win8.img",size=20,bus=sata,format=qcow2,cache=none
Если команда как бы подвисла, завершаем ее сочетанием Ctrl+C.
Проверяем командой sudo netstat -tpl, что *:5903 порт прослушивается - виртуальная машина создана и готова к работе.

13. Подключаемся к виртуальной машине через любой VNC-viewer на ip-адрес нашего сетевого моста, порт 5903. Вводим пароль (в примере конфигурации, password). Инсталлируем гостевую ОС из выбранного ранее источника (/mnt/Win81_64.iso). Дожидаемся окончания установки

14. Средствами самой виртуальной машины смотрим MAC-адрес. При необходимости, выставляем статический IP либо на самой виртуальной машине, либо на DHCP-сервере, обслуживающем сеть нашего гипервизора.

15. Проверяем устойчивость работы виртуальной машины и радуемся жизни! конфигурационный файл виртуальной машины лежит по адресу: /etc/libvirt/qemu/ИМЯ_МАШИНЫ.xml (редактируется тем же sudo nano).

16. Добавляем виртуальную машину в автозапуск:
sudo ln -s /etc/libvirt/qemu/win8.xml /etc/libvirt/qemu/autostart/win8.xml

17. Для корректной работы команд выключения/перезагрузки/т.п. вирт.машин необходимо скопировать шаблон файла polkit:
sudo cp /usr/share/polkit-1/rules.d/60-libvirt.rules /etc/polkit-1/rules.d/60-libvirt.rules

Завершить работу вирт.машины - аналогично с system reboot - перезагрузка вирт.машины:
virsh -c qemu:///system shutdown ИМЯ_МАШИНЫ

Редактировать конфигурацию, чтобы не лазить в файл постоянно
virsh -c qemu://system edit ИМЯ_МАШИНЫ

Для создания иного размещения вирт.машин (не /var/lib/libvirt) необходимо создать новый пул и дать на него соответствующие метки МКЦ:
sudo mkdir -p /vrt/pool1
sudo chmod 750 /vrt/pool1
sudo chown -R root:libvirt /vrt
Дополнительно необходимо отредактировать файл /usr/sbin/pdp-init-libvirt по примеру wiki astralinux

Управление пулом размещения образов вирт.машин проводится средствами virsh (в примере каталог пула - /vrt/pool1):
virsh -c qemu:///system pool-define-as pool1 --type dir --target /vrt/pool1
virsh -c qemu:///system pool-build pool1
virsh -c qemu:///system pool-start pool1
virsh -c qemu:///system pool-autostart pool1
virsh -c qemu:///system pool-list --all

ЗЫ Хорошо все-таки иметь корпоративную wiki, куда можно такие примеры/мануалы записать на память...
 

kvv-vp

New member
Сообщения
160
#32
Справедливости ради, недавние "спящие" уязвимости в polkit убеждают, что и в таких мерах защиты тоже уверенности нет. А в случае синтетических мест применения (админ локалхоста, ага) ими вообще можно пренебречь...
Уязвимостей и в ядре, как грязи. Дело в другом. Любой дистрибутив имеет некую базовую защищенность, которую разрабы обеспечивают наличием по дефолту определенного софта и настройкой конфигурации. Пользователь сознательно отключает полкит, т.е.понижает базовую защищенность, созданную разрабами. Устанавливать "защищенный" дистрибутив и разрущать эту самую "защиту" ради сииминутного профита, как то не комильфо. Не отключать надо, а подстраиваться под нее, учиться писать правила полкит. Очень напоминает ситуацию с селинукс, в рускоязычном сегменте интернета ее советуют отключать (подключите и настроите, когда надо будет). В буржуинском советуют установить и настроить. И они правы. Никто не будет добавлять селинукс в уже настроенную и отлаженную систему.
 

oko

New member
Сообщения
1 257
#33
to kvv-vp
Так-то оно так, но не совсем так...
Любой механизм защиты, включая библиотеки и модули ядра, должны применяться в оконечной системе не "чисто для себя, потому что так защищеннее", а с умом. И касательно polkit, только что глянул в ALSE 1.7 - всего 3 правила, поставляемые "из коробки". Ни одно из них не имеет отношения к взаимодействию со средой виртуализации на базе QEMU/KVM. А писать свои правила под polkit никто, собственно, не запрещает, но и не требует в явном виде согласно RedBook и Руководству...
Аналогично с SELinux, AppArmor и проч. прикольными надстройками разграничения доступа. Они хороши только тогда, когда точно знаешь, что и как делаешь. И когда имеются предпосылки для влияния на компоненты ОС, прикрытые этими надстройками, со стороны нарушителя. Впрочем, SELinux/AppArmor != PolKit, потому что и цели, и задачи у них принципиально разные. Тот же PolKit - это не столько средство защиты, сколько "защищенное средство временного повышения привилегий". И, imho, вместо его использования куда как правильнее тупо не повышать (если это не обосновано техпроцессом, разумеется)...
 

McCake

New member
Сообщения
26
#34
to kvv-vp
Так-то оно так, но не совсем так...
Любой механизм защиты, включая библиотеки и модули ядра, должны применяться в оконечной системе не "чисто для себя, потому что так защищеннее", а с умом. И касательно polkit, только что глянул в ALSE 1.7 - всего 3 правила, поставляемые "из коробки". Ни одно из них не имеет отношения к взаимодействию со средой виртуализации на базе QEMU/KVM. А писать свои правила под polkit никто, собственно, не запрещает, но и не требует в явном виде согласно RedBook и Руководству...
Аналогично с SELinux, AppArmor и проч. прикольными надстройками разграничения доступа. Они хороши только тогда, когда точно знаешь, что и как делаешь. И когда имеются предпосылки для влияния на компоненты ОС, прикрытые этими надстройками, со стороны нарушителя. Впрочем, SELinux/AppArmor != PolKit, потому что и цели, и задачи у них принципиально разные. Тот же PolKit - это не столько средство защиты, сколько "защищенное средство временного повышения привилегий". И, imho, вместо его использования куда как правильнее тупо не повышать (если это не обосновано техпроцессом, разумеется)...


Подскажите пожалуйста.
Неделю бьюсь, не пойму в чём дело.
Есть обычная сеть из двух машин. На обоих Astra Linux 1,6 Смоленск. На одной IP 192.168.1.20, а на другой есть виртуальная машина qemu.
Установка:
sudo apt install qemu qemu-kvm libvirt0 libvirt-daemon-system bridge-utils virt*
Оконного менеджера нет.
Создал раздел, установил
sudo qemu-img create -f qcow2 /var/lib/libvirt/images/OS.img 20G
sudo qemu-system-x86_64 -hda /var/lib/libvirt/images/OS.img -m 4096 -boot d -cdrom /var/lib/libvirt/boot/good.iso -enable-kvm -smp 2 -device e1000,netdev=net0,mac=5a:ff:ff:ff:ff:ff -netdev tap,id=net0


Сделал мост:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto br0
iface br0 inet static
bridge_ports eth0
bridge_stp off
bridge_fd 0
address 192.168.1.10/24
netmask 255.255.255.0
gateway 192.168.1.1
broadcast 192.168.1.255


Все установилось и запускаю так:
sudo qemu-system-x86_64 -hda /var/lib/libvirt/images/OS.img -m 4096 -enable-kvm -smp 2 -device e1000,netdev=net0,
mac=5a:ff:ff:ff:ff:ff -netdev tap,id=net0,ifname=tap0


Виртуалка стартует. В ней ставлю IP интерфейса 192,168,1,1.
ifconfig хоста с виртуалкой:
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.10 netmask 255.255.255.0 broadcast 192.168.1.255
ether 10:c3:7b:8c:9f:06 txqueuelen 1000 (Ethernet)
RX packets 20 bytes 1098 (1.0 KiB)
RX errors 0 dropped 17 overruns 0 frame 0
TX packets 5 bytes 492 (492.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0: flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST> mtu 1500
ether 10:c3:7b:8c:9f:06 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 16 bytes 960 (960.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 316 bytes 25512 (24.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 316 bytes 25512 (24.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

tap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether da:79:36:41:62:d0 txqueuelen 1000 (Ethernet)
RX packets 20 bytes 1378 (1.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1 bytes 120 (120.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


При старте виртуалки tap0 стартовал и вот:
my_user@astra:~$ sudo brctl show
bridge name bridge id STP enabled interfaces
br0 8000.10c37b8c9f06 no eth0
tap0


Вроде как и мост заработал. Получается картина такая: Виртуалка 192,168,1,1 мост 192,168,1,10 и удаленная машина 192,168,1,20.
И вот пинг от виртуалки до моста (хоста) есть, от моста (хоста) до виртуалки есть. Но удалённая машина 192,168,1,20 не пингует не виртуалку, не мост. И удаленную машину тоже не пингует.
Вот маршрутизация хоста с KVM: Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.1.1 0.0.0.0 UG 0 0 0 br0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 br0



Я уже что только не делал, нужно просто что бы из сети была видна виртуалка и наоборот.
Может с маршрутизацией что-то… IP моста, не пойму, где-то должен участвовать. Может быть строка запуска виртуалки неправильная.
Сделал всё тоже самое на Ubunte 20, все сразу заработало, маршрутизация сама настроилась, пинг до виртуалки и обратно в сеть идёт.
Получается дело в настройках Astr'ы.
Я сделал что вы описали в предыдущем посту, отключал NetManager, запихивал в группы пользователя, правил конфиг qemu. Единственное я не пользуюсь virsh, так как нужен оконный менеджер, а он запускается только с qemu-system ......
Не могу понять что не пропускает до виртуалки. Iptables может.
 

oko

New member
Сообщения
1 257
#35
to McCake
С синтаксисом qemu-kvm непосредственно не работал, но смущает следующее:
  • что значит "не пользуюсь virsh, так как нужен оконный менеджер, а он запускается только с qemu-system"? virsh же - это только CLI для libvirt, которая является всего лишь библиотекой мультиуправления в том числе и для QEMU/KVM. К тому же, выше вы говорите, что оконного менеджера нет...
  • почему "-netdev tap" и зачем тогда bridge в хостовой системе?
И iptables-save на стороне хостовой системы покажет наличие/отсутствие правил фильтрации...
 

McCake

New member
Сообщения
26
#36
to McCake
С синтаксисом qemu-kvm непосредственно не работал, но смущает следующее:
  • что значит "не пользуюсь virsh, так как нужен оконный менеджер, а он запускается только с qemu-system"? virsh же - это только CLI для libvirt, которая является всего лишь библиотекой мультиуправления в том числе и для QEMU/KVM. К тому же, выше вы говорите, что оконного менеджера нет...
  • почему "-netdev tap" и зачем тогда bridge в хостовой системе?
И iptables-save на стороне хостовой системы покажет наличие/отсутствие правил фильтрации...
1. Когда пытался запустить через virsh была надпись-предупреждение, текст которой я не помню точно, но смысл такой:
Не установлен virsh-viewer и что-то еще. И я видел через virsh-list что ВМ running, но не было оконного менеджера. Возможно я просто его как-то не подключил или просто не понимаю. На форумах пишут, что просто конектятся после запуска virsh к ВМ, типа по какому-то порту и все ок.
На счёт "оконного менеджера нет" имел ввиду нет virt-managera и virsh-viewer, QEMU открывает окно ВМ через qemu-system-...
2. netdev tap как я понимаю создаёт в ВМ tap-интерфейс, который цепляется к мосту на хосте. Ну я как понимаю мост на хосте одним концом цепляет eth0-интерфейс(физический), а другим tap (виртуальный) и таким образом происходит сквозной "канал" между хостом и ВМ. Я вот так понимаю этот процесс.
 

oko

New member
Сообщения
1 257
#37
to McCake
Primo, "подключение к ВМ", которое имеют в виду, идет по протоколу VNC (и у меня в прошлых постах в примере тоже указано - проверяем доступный порт VNC-подключения). В качестве клиента можете использовать либо любой VNC-клиент хоть с машины-хоста (гипервизора), хоть с любой сетевой машины, а можете viewer, который вам предлагала система при установке. Или как в этой теме уже обсуждалось - virt-manager (которого, увы, в составе ALSE 1.6 нет, зато в 1.7 он уже появился)...
Secundo, интерфейс оконечной вирт.машины может мапиться хоть на физ.интерфейс хостовой системы (гипервизора). В упрощенном случае используют тупо bridge (как в моем примере выше) без каких-либо доп.виртуальных интерфейсов. И тогда трафик и на хост, и на вирт.машину будет попадать в этот bridge-интерфейс. Что в вашем случае и надо. В противном случае (как у вас и вышло), вы получаете лишний элемент системы и перенаправление (кстати, судя по вашим конфигурациям, tap-интерфейс у вас ни к чему не привязан, поэтому и нет взаимодействия с другими сетями и устройствами)...
Почитайте больше мануалов в Сети по части QEMU/KVM, что, где, зачем и как - большинство вопросов отпадет. Либо пользуйтесь выложенным примером (он именно что для ALSE 1.6, обычные варианты от всяких Ubuntu не подойдут по причине наличия МКЦ и прочих механизмов защиты). И подключайтесь к вирт.машинам с другой физ.машины или из графики хостовой системы-гипервизора
 

McCake

New member
Сообщения
26
#38
to McCake
Primo, "подключение к ВМ", которое имеют в виду, идет по протоколу VNC (и у меня в прошлых постах в примере тоже указано - проверяем доступный порт VNC-подключения). В качестве клиента можете использовать либо любой VNC-клиент хоть с машины-хоста (гипервизора), хоть с любой сетевой машины, а можете viewer, который вам предлагала система при установке. Или как в этой теме уже обсуждалось - virt-manager (которого, увы, в составе ALSE 1.6 нет, зато в 1.7 он уже появился)...
Secundo, интерфейс оконечной вирт.машины может мапиться хоть на физ.интерфейс хостовой системы (гипервизора). В упрощенном случае используют тупо bridge (как в моем примере выше) без каких-либо доп.виртуальных интерфейсов. И тогда трафик и на хост, и на вирт.машину будет попадать в этот bridge-интерфейс. Что в вашем случае и надо. В противном случае (как у вас и вышло), вы получаете лишний элемент системы и перенаправление (кстати, судя по вашим конфигурациям, tap-интерфейс у вас ни к чему не привязан, поэтому и нет взаимодействия с другими сетями и устройствами)...
Почитайте больше мануалов в Сети по части QEMU/KVM, что, где, зачем и как - большинство вопросов отпадет. Либо пользуйтесь выложенным примером (он именно что для ALSE 1.6, обычные варианты от всяких Ubuntu не подойдут по причине наличия МКЦ и прочих механизмов защиты). И подключайтесь к вирт.машинам с другой физ.машины или из графики хостовой системы-гипервизора
Спасибо. Сделал я как вы описали, через virsh, содалась ВМ, XML, разобрался с VNC viuwer, поставил и его. Подключился, увидел свою виртуалку. Разница в том, что теперь создавался не tap-интерфейс, а vnet0-интерфейс. Но от так же автоматом цепляется к бриджу моему. Но проблема не ушла. Из сети ничего не пингуется...
Нашёл проблему такую на другом форуме:
https://forum.ubuntu.ru/index.php?topic=232514.msg1817587#msg1817587
Там тоже не понятно как решилась проблема.
Когда поднимается мост, eth0 уже не пингуется из сети, он как бы поглощён мостом. А мост должен быть виден сетью?
И еще, есть какие-то параметры у интерфейсов master\slave. Уже не знаю, может в этом дело.
И там у человека было поменяно static на dhcp, бридж должен получать автоматом адрес, но я когда делаю dhcp, то мост ничего не получает. Скорее всего где-то тоже надо это настраивать... Вообщем отстой
 

McCake

New member
Сообщения
26
#40
Вроде получилось. Рассказываю что сделал.
Посмотрел содержимое /etc/libvirt/qemu/networks/default.xml.
В нем написано что ip address=192.168.122.1 ну и маска. А так же ip для dhcp.
Короче поставил ip моста 192.168.122.1, а ip в ВМ 192.168.122.10, ну и ip удалённого хоста в сети 192.168.122.20.
И все заработало. Наверное поэтому если dhcp, то проблем у людей не было, если статика, то адрес должен быть как и default.xml.