Number of nics что это vmware
When you configure a virtual machine, you can add network adapters (NICs) and specify the adapter type.
Пример настройки
Пример показывает как с помощью vSphere Client можно настроить NIC Teaming на хосте с использованием Route based on IP hash.
В моем случае все физические порты ESXi хоста подключены к коммутатору Cisco, на котором уже собран EtherChannel
1. Выбираем необходимы хост и переходим во вкладку Configuration - Networking. По умолчанию в системе всегда уже имеется стандартный vSwitch - его свойства мы и откроем нажав на кнопку Properties.
2. В появившемся окне выбираем vSwitch и нажмем кнопку редактировать Edit
3. В появившемся окне откроем вкладку NIC Teaming и укажем следующие параметры:
Опцию Load Balancing установим в Route based on IP hash
Опцию Network Failure Detection установим в link status only
Опцию Notify Switches установим в Yes
Опцию Failback установим в Yes
Так же проследим, что все физические порты активированы и переведены в раздел Active Adapters
Если посмотреть конфиг любого файрвола, то, скорее всего, мы увидим простыню с кучей IP-адресов, портов, протоколов и подсетей. Так классически реализуются политики сетевой безопасности для доступа пользователей к ресурсам. Сначала в конфиге стараются поддерживать порядок, но потом сотрудники начинают переходить из отдела в отдел, сервера размножаться и менять свои роли, появляются доступы для разных проектов туда, куда им обычно нельзя, и получаются сотни неизвестных козьих тропок.
Около каких-то правил, если повезет, прописаны комментарии «Попросил сделать Вася» или «Это проход в DMZ». Сетевой администратор увольняется, и все становится совсем непонятно. Потом кто-то решил почистить конфиг от Васи, и упал SAP, потому что когда-то Вася просил этот доступ для работы боевого SAP.
Сегодня я расскажу про решение VMware NSX, которое помогает точечно применять политики сетевого взаимодействия и безопасности без неразберихи в конфигах файрвола. Покажу, какие новые функции появились по сравнению с тем, что было раньше у VMware в этой части.
VMWare NSX – платформа виртуализации и обеспечения безопасности сетевых сервисов. NSX решает задачи маршрутизации, коммутации, балансировки нагрузки, файрвола и умеет много другого интересного.
NSX – это преемник собственного продукта VMware vCloud Networking and Security (vCNS) и приобретенного Nicira NVP.
Beacon probing
Данная опция отправляет и слушает специальные пакеты-маяки на все физические интерфейсы в группе и использует полученную информацию. В дополнение так же использует статус физического порта для определения проблемы подключения. Данная опция способна более точно определить проблему в отличие от link status only.
Не используйте Beacon probing вместе с Route based on IP hash чтобы избежать ложных срабатываний.
Route based on the originating virtual port
Данная опция является стандартным для любого только что созданного vSwitch и каждая виртуальная машина и VMkernel порт на vSwitch подключён к виртуальному порту. Когда vSwitch получает трафик от подключённых к нему объектов он назначает виртуальный порт и физический порт и использует его для передачи данных. Выбранный физический порт не меняется до тех пор пока не произойдёт какая либо ошибка или виртуальная машина не выключится или не мигрирует на другой сервер.
От vCNS к NSX
Раньше у клиента в облаке, построенном на VMware vCloud, была отдельная виртуальная машина vCNS vShield Edge. Он выполнял роль пограничного шлюза, где можно было настроить множество сетевых функций: NAT, DHCP, Firewall, VPN, балансировщика нагрузки и пр. vShield Edge ограничивал взаимодействие виртуальной машины с внешним миром согласно правилам, прописанным в Firewall и NAT. Внутри сети виртуальные машины общались между собой свободно в пределах подсетей. Если очень хочется разделять и властвовать трафиком, можно сделать отдельную сеть для отдельных частей приложений (разных виртуальных машин) и прописать в файрволе соответствующие правила по их сетевому взаимодействию. Но это долго, сложно и неинтересно, особенно когда у вас несколько десятков виртуальных машин.
В NSX VMware реализовала концепцию микросегментации с помощью распределенного файрвола (distributed firewall), встроенного в ядро гипервизора. В нем прописываются политики безопасности и сетевого взаимодействия не только для IP- и MAC-адресов, но и для других объектов: виртуальных машин, приложений. Если NSX развернут внутри организации, то такими объектами могут стать пользователь или группа пользователей из Active Directory. Каждый такой объект превращается в микросегмент в своем контуре безопасности, в нужной подсети, со своей уютненькой DMZ :).
Раньше периметр безопасности был один на весь пул ресурсов, защищался пограничным коммутатором, а с NSX можно оградить от лишних взаимодействий отдельную виртуальную машину даже в пределах одной сети.
Политики безопасности и сетевого взаимодействия адаптируются, если объект переезжает в другую сеть. Например, если мы перенесем машину с базой данных в другой сетевой сегмент или даже в другой связанный виртуальный дата-центр, то правила, прописанные для этой виртуальной машины, продолжат действовать безотносительно ее нового положения. Сервер приложений по-прежнему сможет взаимодействовать с базой данных.
На смену самому пограничному шлюзу vCNS vShield Edge пришел NSX Edge. У него есть весь джентльменский набор старого Edge плюс несколько новых полезных функций. Про них и пойдет речь дальше.
Notify Switches
По умолчанию данный пункт установлен как "YES" и он позволяет уведомить коммутатор о том, что виртуальная машина использует другой физический порт, посылая специальный Reverse Address Resolution Protocol фрейм принимающим физическому коммутаторы для обновления таблицы MAC-адресов коммутатора.
Active adapters
Адаптеры, используемые для передачи трафика.
Failback
Данная опция отвечает за активацию физического порта, который находится в режиме ожидания если больше нет ни одно активного физического порта. Опция представляет своего рода активацию запасного порта на случай сбоя активного порта. Так же система переводит "запасной" порт в режим ожидания если соединение по "основному" порту восстановлено.
Route based on IP hash
Данная опция используется совместно с группой агрегации каналов LAG, так же называется EtherChannel или Port Channel. Когда трафик попадает на vSwitch, политика балансировки каналов создаёт в пакете хеш IP-адреса источника и назначения. Результирующий хеш указывает какой физический порт будет использоваться.
Legacy Network Adapters and ESXi Virtual Hardware Versions
The default network adapter types for all legacy virtual machines depend on the adapters available and compatible to the guest operating system and the version of virtual hardware on which the virtual machine was created.
If you do not upgrade a virtual machine to use a virtual hardware version, your adapter settings remain unchanged. If you upgrade your virtual machine to take advantage of newer virtual hardware, your default adapter settings will likely change to be compatible with the guest operating system and upgraded host hardware.
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- VMware Technology Network
- :
- Cloud & SDDC
- :
- ESXi
- :
- ESXi Discussions
- :
- Number of NICS?
hurdle
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
As servers become more and more robust I have noticed consolidation ratios have the potentional to increase as well.
There are many doc's out there on sizing from a memory/processor perspective but I have not seen much on the number of NICS per host dedicted for the VM Network. Now I know this number can vary in terms of type of traffic ect. But is there a base number out there that anyone is aware of? At what point does the standard two ports not sufficient? What effect does vlan tagging have on a virtual switch ect.
There is always the wait to see what it looks like but in enviroment such as a blade where you are limited to how many nics you need a reactive aproach is not always exceptable.
amvmware
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
That is one of the limitations of a blade infrastructure - although you can get upto 8 nic ports in a lot of the blades these days.
I generally assign 2 nics for VM traffic and never had an issue - but these are your general Infrastructure servers - file, print, email, web. etc.
If you have an application that you believe is network intensive then it would make sense to understand the bandwidth requirements before virtualising it.
With blades these days you also have the ability to flex the bandwidth.
krismcewan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
A general rule about Nics is get as many as you can.
I have seen some users with 12 nics for a dozen or so VM's using Iscsi. 4 for Iscsi, 2 for Vmotion, 2 for DMZ and 4 for production.
Beware with some Blades. trade off on extra nics can come at the cost of HBA's so if you have Fibre cards you may only get a max of 4 Nics.
A VMware Consultant in Scotland for Taupo Consulting
If you think I'm right or helpful award me some points please
vmroyale
- Mark as New
- Bookmark
- Subscribe
- Mute
- Email to a Friend
Now I know this number can vary in terms of type of traffic ect. But is there a base number out there that anyone is aware of?
Obviously, one is required and two would be better for redundancy. But like you said, it is going to be different for each environment. In a very small shop with a single flat network, 2 nics might be sufficient for both the management and virtual machine traffic. If the size of the shop increases, then that number may need to go up to accommodate shared IP storage, vMotion, etc. This variety of requirements in the setup is why there isn't really a published base number to work with.
At what point does the standard two ports not sufficient?
When you need separation of management from virtual machine networks with redundancy.
When you add IP-based storage.
When you need to use other advanced features like vMotion or FT.
The requirements of the setup will ultimately dictate the number of nics required.
В данной статье рассматриваются назначения NIC Teaming в сетевой конфигурации VmWare ESXi и приводится пример настройки на основе Route based on IP hash.
NIC Teaming это агрегирование каналов, то есть объединение физических каналов в логические.
Network Failure Detection
Данный пункт отвечает за определение ошибок в подключении физических портов и имеет две опции.
Unused adapters
Неиспользуемые для передачи трафика адаптеры.
Network Adapter Types
The type of network adapters that are available depend on the following factors:
- The virtual machine compatibility, which depends on the host that created or most recently updated it.
- Whether the virtual machine compatibility has been updated to the latest version for the current host.
- The guest operating system.
Supported NICs currently differ between an on-premises environment and VMware Cloud on AWS . The following NIC types are supported in an on-premises deployment:
E1000E Emulated version of the Intel 82574 Gigabit Ethernet NIC. E1000E is the default adapter for Windows 8 and Windows Server 2012. E1000 Emulated version of the Intel 82545EM Gigabit Ethernet NIC, with drivers available in most newer guest operating systems, including Windows XP and later and Linux versions 2.4.19 and later. Flexible Identifies itself as a Vlance adapter when a virtual machine boots, but initializes itself and functions as either a Vlance or a VMXNET adapter, depending on which driver initializes it. With VMware Tools installed, the VMXNET driver changes the Vlance adapter to the higher performance VMXNET adapter. Vlance Emulated version of the AMD 79C970 PCnet32 LANCE NIC, an older 10 Mbps NIC with drivers available in 32-bit legacy guest operating systems. A virtual machine configured with this network adapter can use its network immediately. VMXNET Optimized for performance in a virtual machine and has no physical counterpart. Because operating system vendors do not provide built-in drivers for this card, you must install VMware Tools to have a driver for the VMXNET network adapter available. VMXNET 2 (Enhanced) Based on the VMXNET adapter but provides high-performance features commonly used on modern networks, such as jumbo frames and hardware offloads. VMXNET 2 (Enhanced) is available only for some guest operating systems on ESX/ ESXi 3.5 and later. VMXNET 3 A paravirtualized NIC designed for performance. VMXNET 3 offers all the features available in VMXNET 2 and adds several new features, such as multiqueue support (also known as Receive Side Scaling in Windows), IPv6 offloads, and MSI/MSI-X interrupt delivery. VMXNET 3 is not related to VMXNET or VMXNET 2. PVRDMA
A paravirtualized NIC that supports remote direct memory access (RDMA) between virtual machines through the OFED verbs API. All virtual machines must have a PVRDMA device and should be connected to a distributed switch. PVRDMA supports VMware vSphere vMotion and snapshot technology. It is available in virtual machines with hardware version 13 and guest operating system Linux kernel 4.6 and later.
For information about assigning an PVRDMA network adapter to a virtual machine, see the vSphere Networking documentation.
SR-IOV passthrough Representation of a virtual function (VF) on a physical NIC with SR-IOV support. The virtual machine and the physical adapter exchange data without using the VMkernel as an intermediary. This adapter type is suitable for virtual machines where latency might cause failure or that require more CPU resources.
SR-IOV passthrough is available in ESXi 6.0 and later for guest operating systems Red Hat Enterprise Linux 6 and later, and Windows Server 2008 R2 with SP2. An operating system release might contain a default VF driver for certain NICs, while for others you must download and install it from a location provided by the vendor of the NIC or of the host.
For information about assigning an SR-IOV passthrough network adapter to a virtual machine, see the vSphere Networking documentation.
Standby adapter
Адаптеры в режиме ожидания, используются если активные адаптеры дали сбой.
Route based on source MAC hash
Данная опция схожа по принципу работы с Route based on IP hash, за исключением того, что политика рассматривает только MAC-адрес источника в кадре Ethernet.
link status only
Данная опция позволяет определить ошибки, вызванные отключением кабеля или проблемой физического интерфейса и не способна определять конфигурационный ошибки, такие как если физический коммутатор заблокировал порт из-за ошибок конфигурации VLAN,spanning tree или отключения кабеля на другой стороне физического коммутатора.
Load Balancing
Первым пунктом в настройке является load-balancing policy. Говоря по простому мы выбираем как vSwitch будет обрабатывать исходящий трафик.
Имеется 4 варианта обработки трафика:
- Route based on the originating virtual port
- Route based on IP hash
- Route based on source MAC hash
- Use explicit failover order
Failover Order
Данная опция отвечает за отказоустойчивость и имеет 3 разных статуса адаптера:
Что нового у NSX Edge?
Функциональность NSX Edge зависит от редакции NSX. Всего их пять: Standard, Professional, Advanced, Enterprise, Plus Remote Branch Office. Все новое и интересное можно увидеть только начиная с Advanced. В том числе и новый интерфейс, который до полного перехода vCloud на HTML5 (VMware обещает лето 2019-го) открывается в новой вкладке.
Firewall. В качестве объектов, к которым будут применяться правила, можно выбрать IP-адреса, сети, интерфейсы шлюза и виртуальные машины.
DHCP. Помимо настройки диапазона IP-адресов, которые будут автоматически выдаваться виртуальным машинам этой сети, в NSX Edge стали доступны функции Binding и Relay.
Во вкладке Bindings можно привязать MAC-адрес виртуальной машины к IP-адресу, если нужно чтобы IP-адрес не менялся. Главное, чтобы этот IP-адрес не входил в DHCP Pool.
Маршрутизация. У vShield Edge можно было настраивать только статическую маршрутизацию. Здесь появилась динамическая маршрутизация с поддержкой протоколов OSPF и BGP. Также стали доступны настройки ECMP (Active-active), а значит и аварийное переключение типа «активный-активный» на физические маршрутизаторы.
Настройка OSPF
Настройка BGP
Еще из нового – настройка передачи маршрутов между различными протоколами,
перераспределение маршрутов (route redistribution).
Также во вкладке Application Rules теперь можно добавлять скрипты, которые будут напрямую управлять балансировкой трафика.
VPN. В дополнение к IPSec VPN, NSX Edge поддерживает:
- L2 VPN, позволяющий растянуть сети между географически разнесенными площадками. Такой VPN нужен, например, чтобы при переезде на другую площадку виртуальная машина оставалась в той же подсети и сохраняла IP-адрес.
- SSL VPN Plus, который позволяет пользователям подключаться удаленно к корпоративной сети. На уровне vSphere такая функция была, а вот для vCloud Director это новшество.
Группы объектов (Grouping Objects). В этой вкладке как раз задаются группы объектов, для которых будут действовать те или иные правила сетевого взаимодействия, например правила файрвола.
Этими объектами могут быть IP- и MAC-адреса.
Здесь также указан список сервисов (сочетание протокол-порт) и приложений, которые можно использовать при составлении правил файрвола. Новые сервисы и приложения добавлять может только администратор портала vCD.
Статистика. Статистика по подключениям: трафик, который проходит через шлюз, файрвол и балансировщик.
Статус и статистику по каждому туннелю IPSEC VPN и L2 VPN.
Логирование. Во вкладке Edge Settings можно задать сервер для записи логов. Логирование работает для DNAT/SNAT, DHCP, Firewall, маршрутизации, балансировщика, IPsec VPN, SSL VPN Plus.
Для каждого объекта/сервиса доступны следующие типы оповещений:
— Debug
— Alert
— Critical
— Error
— Warning
— Notice
— Info
Размеры NSX Edge
В зависимости от решаемых задач и объемов VMware рекомендует создавать NSX Edge следующих размеров:
NSX Edge (Compact) | NSX Edge (Large) | NSX Edge (Quad-Large) | NSX Edge (X-Large) | |
vCPU | 1 | 2 | 4 | 6 |
Memory | 512MB | 1GB | 1GB | 8GB |
Disk | 512MB | 512MB | 512MB | 4.5GB + 4GB |
Назначение | Одно приложение, тестовый дата-центр | Небольшой или средний дата-центр | Нагруженный файрвол | Балансировка нагрузки на уровне L7 |
Ниже в таблице – рабочие метрики сетевых служб в зависимости от размера NSX Edge.
NSX Edge (Compact) | NSX Edge (Large) | NSX Edge (Quad-Large) | NSX Edge (X-Large) | |
Interfaces | 10 | 10 | 10 | 10 |
Sub Interfaces (Trunk) | 200 | 200 | 200 | 200 |
NAT Rules | 2,048 | 4,096 | 4,096 | 8,192 |
ARP Entries Until Overwrite | 1,024 | 2,048 | 2,048 | 2,048 |
FW Rules | 2000 | 2000 | 2000 | 2000 |
FW Performance | 3Gbps | 9.7Gbps | 9.7Gbps | 9.7Gbps |
DHCP Pools | 20,000 | 20,000 | 20,000 | 20,000 |
ECMP Paths | 8 | 8 | 8 | 8 |
Static Routes | 2,048 | 2,048 | 2,048 | 2,048 |
LB Pools | 64 | 64 | 64 | 1,024 |
LB Virtual Servers | 64 | 64 | 64 | 1,024 |
LB Server / Pool | 32 | 32 | 32 | 32 |
LB Health Checks | 320 | 320 | 320 | 3,072 |
LB Application Rules | 4,096 | 4,096 | 4,096 | 4,096 |
L2VPN Clients Hub to Spoke | 5 | 5 | 5 | 5 |
L2VPN Networks per Client/Server | 200 | 200 | 200 | 200 |
IPSec Tunnels | 512 | 1,600 | 4,096 | 6,000 |
SSLVPN Tunnels | 50 | 100 | 100 | 1,000 |
SSLVPN Private Networks | 16 | 16 | 16 | 16 |
Concurrent Sessions | 64,000 | 1,000,000 | 1,000,000 | 1,000,000 |
Sessions/Second | 8,000 | 50,000 | 50,000 | 50,000 |
LB Throughput L7 Proxy) | 2.2Gbps | 2.2Gbps | 3Gbps | |
LB Throughput L4 Mode) | 6Gbps | 6Gbps | 6Gbps | |
LB Connections/s (L7 Proxy) | 46,000 | 50,000 | 50,000 | |
LB Concurrent Connections (L7 Proxy) | 8,000 | 60,000 | 60,000 | |
LB Connections/s (L4 Mode) | 50,000 | 50,000 | 50,000 | |
LB Concurrent Connections (L4 Mode) | 600,000 | 1,000,000 | 1,000,000 | |
BGP Routes | 20,000 | 50,000 | 250,000 | 250,000 |
BGP Neighbors | 10 | 20 | 100 | 100 |
BGP Routes Redistributed | No Limit | No Limit | No Limit | No Limit |
OSPF Routes | 20,000 | 50,000 | 100,000 | 100,000 |
OSPF LSA Entries Max 750 Type-1 | 20,000 | 50,000 | 100,000 | 100,000 |
OSPF Adjacencies | 10 | 20 | 40 | 40 |
OSPF Routes Redistributed | 2000 | 5000 | 20,000 | 20,000 |
Total Routes | 20,000 | 50,000 | 250,000 | 250,000 |
Из таблицы видно, что балансировку на NSX Edge для продуктивных сценариев рекомендуется организовывать, только начиная с размера Large.
На сегодня у меня все. В следующих частях подробно пройдусь по настройке каждой сетевой службы NSX Edge.
UPDATE: Мы автоматизировали создание сети и правил NAT. Теперь при оформление подписки все это создается само :). Все что вам остается — это развернуть виртуальную машину из шаблона или с нуля. При этом у вас по-прежнему остается возможность менять настройки сети при необходимости.
Только не забываем про Firewall, который по умолчанию не пропускает никакой трафик и требует настройки правил.
В vCloud Director виртуальные машины «живут» в контейнерах vApp, поэтому создание ВМ начинается с создания vApp. Можно выбрать следующие варианты:
- vApp из шаблона (с ВМ с предустановленной ОС);
- vApp c «пустой» ВМ, т.е. без ОС.
- «пустой» vApp и добавить ВМ туда позже.
В данном материале подробно рассмотрим первые два случая.
Создание виртуальной машины из готового шаблона
1. Заходим в раздел My Cloud и выбираем вкладку vApps и нажимаем на зеленый +.
2. В новом окне в поле Look in выбираем Public Catalog
В таблице ниже появятся список доступных шаблонов виртуальных машин с ОС. Выберите нужный.
В нижней части окна будет содержаться информация об этом шаблоне, включая логин для входа, необходимое дисковое пространство и пр. Жмем Next.
3. Вводим название или оставляем существующее (Name), заполняем описание по необходимости (Description). Жмем Next.
4. Во вкладке Configure Resources вносим, если нужно, изменения поле Computer Name (имя, которое будет показываться внутри гостевой ОС при кастомизации). Кнопка Next.
5. Во вкладке Network Mapping задаем параметры сети.
6. Проскакиваем шаг Custom Properties и попадаем на вкладку Customize Hardware. Здесь отображаются параметры CPU, Memory, Hard Disk. Рекомендуем не менять их во время разворачиваня ВМ, а сделать это уже после ее создания. Кнопка Next.
7. На последней вкладке Ready to Complete внимательно проверьте все выбранные на предыдущих этапах параметры вашей виртуальной машины. Здесь же вы можете автоматически запустить созданную виртуальную машину, сделав отметку в чекбоксе Power on vApp after this wizard is finished. Нажмите Finish.
Если есть желание развернуть ВМ из своего собственного шаблона, то в vCloud Director это тоже можно сделать. Для этого нужно создать каталог (папку, в которую вы будете загружать данный шаблон), ну, и импортировать сам шаблон. В поле Look in соответственно вместо Public Catalog выбирайте ваш каталог.
Создание виртуальной машины с нуля (без предустановленной ОС)
Если на создаваемую виртуальную машину необходимо загрузить свою ОС, то для этого создаем vApp c «пустой» ВМ.
1. Возвращаемся в раздел My Cloud, во вкладке vApps нажимаем на значок, отмеченный желтым маркером (Build new vApp).
3. Во вкладке Add Virtual Machines выберите опцию New Virtual Machine. Жмем Next.
4. В появившемся окне New Virtual Machine необходимо выбрать параметры создаваемой виртуальной машины:
— имя (Virtual Machine Name);
— имя, которое будет показываться внутри гостевой ОС при кастомизации (Computer Name);
— ее описание при необходимости (Description);
— семейство и конкретную операционную систему, которую будем потом устанавливать. Например, выберем Centos;
— объем оперативной памяти и диска;
— общее количество виртуальных ядер, которое будет выделено ВМ (Number of virtual CPUs);
— количество ядер на виртуальный сокет.
Последние два параметра важны для лицензирования некоторых ОС. Например, для Windows Server Standard количество сокетов должно быть не более 4. В других вариантах лучше оставить оставить 1 ядро на сокет.
Параметры, которые выставляются автоматически и которые мы не рекомендуем менять:
— версия контейнера виртуальной машины (Virtual hardware version);
— тип шины виртуальных дисков (Bus type). Это не имеет отношения к типу дисков (SAS, SATA, VSAN) :).
— количество виртуальных сетевых адаптеров (Number of NICs). Если нет специализированных потребностей, то рекомендуем оставить 1.
5. Новая виртуальная машина появляется в списке создаваемого vApp. Жмем Next.
6. На вкладке Configure Resources просто жмем Next.
7. При необходимости вносим изменения в поле Computer Name, выбираем сеть, к которой хотим подключить созданную виртуальную машину. В данном случае выбираем сеть Test_Network, что мы создали в предыдущем материале. Жмем Next.
8. Во вкладке Configure Networking можно посмотреть параметры сети. Тут же можно выбрать опцию Fence vApp. Она позволяет назначить виртуальным машинам в разных vApp одинаковые IP, избегая при этом конфликта IP-адресов. Это удобно, если есть несколько сред для тестирования или разработки с идентичными ВМ.
9. На последней вкладке Ready to Complete еще раз внимательно проверяем все параметры виртуальной машины. Если все устраивается, то жмем Finish.
10. Ждем некоторое время, пока ВМ под Centos развернется.
Далее нужно установить соответствующую ОС через подключение образа установочного диска (ISO-образ) или самого диска. Вот подробная инструкция на этот случай.
Создание «пустого vApp
Тут совсем все просто. Начало такое же. как и в предыдущем случае. Единственное — в этот раз мы не жмем на Add New Virtual Machine. Вместо этого жмем Next до победного. В этом „пустом“ vApp потом аналогично развернуть ВМ из шаблона или с нуля (без ОС) так же, как мы это уже проделали сегодня.
Из важного
Кастомизация
При первом включении ВМ происходит так называемая кастомизация, когда к виртуальной машине применяются все заданные настройки:
• имя виртуальной машины;
• настройки сети;
• SID;
• пароль администратора.
Если кастомизация недоступна, то параметры ВМ можно настроить вручную через консоль.
Пароль от гостевой ОС
О том, где посмотреть пароль к гостевой ОС, читайте здесь
Вопросы по данному материалу и пожелания по темам будущих tutorial оставляйте в комментариях.
Успехов в освоении vCloud Director! :)
Use explicit failover order
Данная опция в действительности не выполняет никакой балансировки нагрузки и если у вас используется для подключения несколько физических портов то в любой момент времени использоваться будет только один. Сначала система пытается использовать первый активный физический сетевой порт. Если использовать первый физический порт не удаётся, то используется следующий активный физический порт и так далее.
Читайте также: