Обновление VMware ESXi из командной строки
13.04.2022
itpro
VMware, Виртуализация
Комментариев пока нет
В этой статье мы рассмотрим процесс ручной установки rollup патчей на хост VMware ESXi из командной строки, а также процесс апгрейда версии ESXi (в этом примере разберем обновление с VMware ESXi 6.7 до 7.0).
Ручное обновление ESXi из консоль esxcli можно использовать для обновления отдельно-стоящих хостов ESXI (или бесплатного VMware vSphere Hypervisor), небольших инсталляций или тестовых сред. Для обновления большой инфраструктуры на базе VMware vSphere с vCenter предпочтительнее использовать используется VMware Update Manager/VMware Lifecycle manager.
Определите текущую версию ESXi, установленную на вашем сервере. Вы можете получить версию из vSphere Web Client:
Или из консоли ESXi с помощью команды:
В этом примере на сервере установлен VMware ESXi 6.7.0 build-1716773 .
Установка обновлений (патчей) на VMware ESXi из командной строки esxcli
Если вы хотите на свой ESXi хост установить обновления безопасности и исправления, скачать последнее обновление для вашей версии ОС.
Для офлайн установки rollup обновления на ESXi:
- Авторизуйтесь в личном кабинете на сайте VMware (можно использовать личную запись) и перейдите на страницу https://my.vmware.com/group/vmware/patch
- Выберите продукт: ESXi (Embedded and Installable);
- Доступно последнее обновление ESXi670-202111001 (18828794) от 2021-11-23;
- Скачайте zip архив с обновлениями;
- Воспользуйтесь DataStore Browser, чтобы скопировать архив на любое из доступных хосту хранилищ (это может быть локальный диск, NFS папка, VMFS LUN, подключенный по iSCSI или Fiber Channel, или внешний USB диск, подключенный к хосту ESXi). Если места на хранилище недостаточно, расширьте VMFS;
- Подключитесь к хосту ESXi через SSH и переведите хост в режим обслуживания: esxcli system maintenanceMode set —enable=true
- Для установки патчей выполните команду: esxcli software vib update —depot /vmfs/volumes/607eb5b4-c6e3e815-7b50-000c29808a13/update/ESXi670-202111001.zip
- Перезагрузите хост ESXi: reboot -f
- Отключите режим обслуживания: esxcli system maintenanceMode set —enable=false
- Убедитесь, что версия ОС обновилась: vmware –v
Install-VMHostPatch -HostPath /vmfs/volumes/volume/esxi_patch.zip
Ручной обновление (апгрейд) версии VMware ESXi из консоли esxcli
Вы можете вручную обновить версию ESXi на своем хосте. В этом примере я выполню апгрейд ESXi 6.7 до 7.0.
- При выполнении обновления между версиями ESXi убедитесь, что оборудование вашего сервера поддерживается более новой версией ОС. Используйте VMware Compatibility Guide и VMware Product Interoperability Matrix.
- Не обновляйте релиз ESXi, если хост подключен к vCenter до того, как вы обновите версию vCSA.
Есть два способа апргейда версии ESXi из командной строки esxcli:
- Оффлайн обновление – вы должны вручную скачать установочный образ ESXi на локальное хранилище;
- Онлайн обновление – подойдет для случаев, если ваш ESXi может получить доступ к репозиторию VMware через интернет.
Сначала рассмотрим процедуру офлайн обновления. Вам нужно вручную скачать офлайн образ с новой версией ESXi:
- Перейдите на https://customerconnect.vmware.com/downloads/info/slug/datacenter_cloud_infrastructure/vmware_vsphere/7_0
- Найдите версию VMware ESXi, до которой вы хотите обновиться. Если вы используете кастомный образ ESXi от вендора, перейдите на вкладку Custom ISOs. В моем примере я будут использовать образ для серверов HPE — HPE Custom Image for ESXi 7.0 U2 Install CD. Скачайте образ HPE Custom Image for ESXi 7.0 U2 Offline Bundle ;
- Скопируйте образ на любое хранилище, доступное с ESXi хоста;
- Выведите список доступных профилей в образе: esxcli software sources profile list -d /vmfs/volumes/datastore1/update/VMware-ESXi-7.0.2-17867351-HPE-702.0.0.10.7.0.52-May2021-depot.zip
- В нашем примере в образе есть только один профиль HPE-Custom-AddOn_702.0.0.10.7.0-52;
- Переведите хост в режим обслуживания: esxcli system maintenanceMode set —enable=true
- Обновите версию ESXi с помощью выбранного профиля: esxcli software profile update -d /vmfs/volumes/datastore1/update/VMware-ESXi-7.0.2-17867351-HPE-702.0.0.10.7.0.52-May2021-depot.zip -p HPE-Custom-AddOn_702.0.0.10.7.0-52
Для онлайн апгрейда версии ESXi через интернет, нужно:
- Разрешить HTTP трафик в файерволе ESXi: esxcli network firewall ruleset set -e true -r httpClient
- Проверить список доступных профилей ESXi в VMware online depot: esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml | grep -i ESXi-7.0
- Найдите имя нужного профиля, и выполните апгрейд версии ESXi: esxcli software profile update -p HPE-Custom-AddOn_702.0.0.10.7.0-52 -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
- Отключите HTTP доступ в интернет: esxcli network firewall ruleset set -e false -r httpClient
Итак, в этой статьи мы рассмотрели, как установить патчи на хост VMware ESXi, и как обновить версию ОС на вашем сервере с ESXi 6.7 до vSphere 7.0U2.
Предыдущая статья Следующая статья 
How to Upgrade to ESXi 6.7 Using VMware vSphere Update Manager
Using vSphere Update Manager 6.7, you can upgrade ESXi from 6.0 to 6.7 or ESXi from 6.5 to 6.7. If you are trying to upgrade vSphere 5.5 to 6.7 you can still use VUM, but it will be a two step process. You will first need to upgrade ESXi from 5.5 to 6.5 and then ESXi from 6.5 to 6.7. Now, let’s talk about what you need to get started with your ESXi 6.7 upgrade.
Getting Ready to Upgrade to ESXi 6.7 Using vSphere Update Manager
Before you update ESXi to 6.7, there are a couple of things you you need to do first:
- Have a vSphere 6.7 VCSA deployed. You can easily upgrade your existing VCSA or deploy a new one. This is essential to using vSphere Update Manager for your upgrade.
- Have the ESXi 6.7 ISO downloaded. You will need this to upgrade your ESXi hosts from vSphere 6.0 or 6.5.
- Verified your vSphere environment is compatible with ESXi 6.7. This includes your server hardware, your storage array, and anything else that directly touches your vSphere environment. If you do not check this list, you can find yourself in big trouble when it comes to running a supported configuration after your ESXi 6.7 update. If you are not familiar with the VMware Compatibility Guide, be sure to read this post for step-by-step instructions how to use it.
All of these steps are essential to your ESXi 6.7 upgrade success!
Ready for your ESXi 6.7 upgrade? Great. Here is the step by step guide on how to upgrade ESXi 6.5 to 6.7.
The ESXi Update Process: Getting Used to vCenter 6.7 and the vSphere Client
If you have not used the HTML5 based vSphere Client, it is the client of choice in vSphere 6.7. You will notice things look a little difference once you navigate to your VCSA.
Once you are logged using the first option, the vSphere Client, you will notice things look a little different. Do not worry, if you have not spent much time using the HTML5 based vSphere client, it as easy and intuitive to use as the vSphere Web Client was.
I recommend using the HTML5 based vSphere client for you ESXi 6.7 upgrade, since the upgrade process is so simple. These simple tasks will help you become more familiar with the HTML5 client.
Finding Update Manager in vSphere 6.7 for the ESXi 6.7 Upgrade
There are many, many ways to get to Update Manager in vSphere 6.7 when you want to upgrade to ESXi 6.7. Personally, I click Shortcuts under Home in the left navigation pane, then Update Manager in the right pane.
You will see that as you browse other vSphere inventory items, there is often a link for vSphere Update Manager Home. This will bring you to the same place. There are many different ways to do things in VMware vSphere.
ESXi Update Process: Preparing Update Manager for ESXi 6.7 Host Upgrade
Now that we have accessed VUM, we need to configure it in order to be able to upgrade ESXi from 6.5 to 6.7. The first thing we are going to do is upload our ESXi 6.7 image. It is important to do this first, as we will need to have it uploaded for later configuration steps.
In the vSphere Update Manager screen, we simply need to click ESXi images on the right, then click IMPORT. Preparing vSphere Update Manager is essential when it is time to update ESXi.
I hope you remembered where you downloaded that ESXi 6.7 ISO, since we are performing the ESXi 6.7 update. Just browse to the location, and click Import. The import should go quickly, and you are one step closer to completing your ESXi upgrade.
Create A New Update Manager Baseline to Upgrade ESXi 6.5 to 6.7
A baseline is just a fancy term for the state you would like Update Manager to bring your vSphere environment to. Start by clicking Baselines, and select New Baseline. It is important that you have uploaded your ESXi 6.7 image before performing this step.
There are three types of baselines in vSphere Update Manager. We are going to create an Upgrade baseline to upgrade ESXi. There is also a Patch baseline for installing ESXi patches, and an Extension baseline to add additional software to an ESXi host. Enter a name for your Upgrade Baseline and click Next.
It is important to use a name which makes sense, such as vSphere 6.7 Upgrade or vSphere 6.7 Update. That way, in later steps, you will know exactly what the purpose of each baseline is.
Remember that ESXi 6.7 image we imported? Select it, and click next.
Now our vSphere Update Manager baseline is ready to complete. You will see a summary of the host upgrade baseline you have just created. Click Finish to create the baseline. This baseline is for your vSphere 6.7 upgrade to ESXi 6.7.
Attaching a Baseline to ESXi Hosts for ESXi 6.7
The next step is to attach a Baseline to the ESXi hosts you would like to upgrade. There are many different ways to accomplish this. You can attach baselines to different objects within VMware vCenter Server.
I prefer to attach them to vSphere clusters, but you can also attach them at the Datacenter or individual ESXi host level. No matter which way you decide to do this, it is a key step of the ESXi update process.
Click the vSphere cluster in Hosts and Clusters View. In the right pane, click Updates. Remember I said there were many ways to get to Update Manager? You will see you can click GO TO UPDATE MANAGER HOME to get to the Update Manager interface we were just using.
Click ATTACH to attach to select which baseline to attach to the cluster. We are almost ready to update ESXi!
Now, select the baseline you have previously created, I named mine vSphere 6.7 Upgrade. Click OK.
That is it! We are now ready to upgrade ESXi.
Upgrading ESXi to from 6.5 to 6.7 or Upgrade ESXi 6.0 to 6.7
Fist and foremost, let’s take a look at one of the ESXi hosts we will be upgrading to ESXi 6.7 from ESXi 6.5. You could also upgrade ESXi 6.0 to 6.7 using this method. To do this, you would follow the same steps in your vSphere 6.0 environment. The method is identical other than your starting point.
As you can see, my host is running ESXi 6.5, and yes, it is virtual ESXi host. Now we are going to get this host running the latest and greatest version of VMware vSphere!
I wish I was going to click a cool UPGRADE NOW button, but I will select REMEDIATE from the Update pane of our cluster.
Remediate is a nice way of saying make sure our host is compliant with its attached baseline. In this case, clicking the button is what will actually update ESXi. After we click REMEDIATE, we will be prompted to accept the VMware EULA.
After we click accept the EULA, we will see exactly what is about to get upgrade in our environment.
Now, we simply click OK and off our hosts go! They will now be updated to ESXi 6.7. vCenter will cycle through the cluster, putting the hosts into maintenance mode and upgrading them as you can see here:
Now is a good time to step away and get a nice beverage while your ESXi environment upgrades itself. As you can see, our upgrade has been successful and we are now running ESXi 6.7!
You will also see it is complaint with the attached baseline. This is another way of showing it is now running ESXi 6.7 since that is what the baseline was configured to do.
Congratulations! You are now running the latest version of VMware vSphere. I hope you are reading this article before you perform your upgrade, because there are a number of things to think about before hand.
As I mentioned, it is important to make sure your environment is compatible with vSphere 6.7 before you perform your upgrade. Just because everything “works”, that does not mean it is supported!
In addition, a vSphere upgrade can also be an opportunity to fix some things in your environment that may not be optimal. Rebecca Fitzhugh and I presented a session at VMworld 2017 entitled Upgrading to vSphere 6.5 the VCDX Way. This methodology is still valid when upgrading to vSphere 6.7.
VMware vSphere Upgrade Paths to ESXi 6.7
Now that we have shown how to perform an ESXi update to 6.7, we will review your upgrade path options. Remember, before you start your upgrade you should ensure all components (both software and hardware) are compatible on the VMware Compatibility Guide.
Upgrade ESXi 6.5 to 6.7
You are in the right place! Simply follow the steps in this article.
Upgrade ESXi 6.0 to 6.7
Again, you have come to the right place! Simply follow the steps in this article.
Upgrade ESXi 5.5 to 6.5
If you are still running vSphere 5.5, remember, end of general support is coming on September 19, 2018! It will be a two step upgrade from vSphere 5.5 to vSphere 6.7, so the time is now to start planning. You can find instructions for upgrading from ESXi 5.5 to 6.5 using Update Manager here.
After you have finished your upgrade to vSphere 6.5, simply follow this article you are reading now to update ESXi to 6.7.
VMware makes it very easy to perform an ESXi upgrade. Upgrading to ESXi 6.7 is not much different than the previous versions, other than the addition of the HTML5 based vSphere client.
If you are just not yet comfortable with new client for your ESXi 6.7 upgrade, you can still use the former vSphere Web Client. You can follow these instructions on upgrading from ESXi 5.5 to 6.5, and simply use the ESXi 6.7 ISO file.
Why Should I Upgrade to ESXi 6.7?
Great question! As much as we all want to upgrade to ESXi 6.7 since it is the latest and greatest version of ESXi, the fact of the matter is we are going to need a good reason to do our ESXi 6.7 upgrade.
The Change Management practices in organizations generally do not like to see someone upgrading an environment just to get to the latest version. Generally, you will have much more success in getting your ESXi 6.7 upgrade approved if you have good business reasons behind it.
Some examples are:
- To remain on a supported version of ESXi (we always want to make sure we can call VMware support if we need to!)
- To take advantage of new features and functionality (check out this blog from VMware on what is new in vSphere 6.7)
- To enhance the security of our environment
- To make the environment easier to use for operations team, such as allowing them to take advantage of the new and improved HTML5 vSphere Client
These are just a couple of ideas to get you started on your upgrade path. Good luck, and enjoy ESXi 6.7
Going Beyond ESXi 6.7?
Are you going beyond ESXi 6.7? Be sure to check out these resources:
Remember, before you update your production environment to vSphere 6.7, it is always nice to get a feel for the upgrade in a development or test environment. After all, each VMware release is full of new features, like in the case of VMware vSphere 6.7 U2 – What You Need to Know.
After testing the new version of vSphere in development or test, you can update your operational documentation before your production environment and be ready to hit the ground running after your VMware vSphere upgrade.
Melissa is an Independent Technology Analyst & Content Creator, focused on IT infrastructure and information security. She is a VMware Certified Design Expert (VCDX-236) and has spent her career focused on the full IT infrastructure stack.
How to patch ESXi with Update Manager
With the utilization of Update Manager, ESXi patching is simply a routine method to maintain your VMware vSphere environment.
In a previous post, I wrote about how one can go about patching ESXi from the command line using the esxcli software vib command . This is all well and good when you only have a couple of hosts at hand. What would you do instead when faced with a significant number of esxi hosts you need to update? The short answer is, use vSphere Update Manager (VUM). I’ve written about VUM in the past, so I’m skipping the how to install and configure it bits. If you’d like to learn more, have a look at these:
One of the features I like most about vCSA 6.5, is that VUM comes readily installed with the appliance , something that was on everybody’s wishlist since the appliance first shipped out. If you’re running vCenter Server for Windows, well, you’re stuck with installing VUM manually.
Today, I’ll be using vCenter Server Appliance 6.5 to update an ESXi 6.5 GA host to 6.5.0 d. The 4-part update process is as follows:
-
- Import an ESXi image to VUM
-
- Create a baseline
-
- Attach the baseline
-
- Remediate
Undefined vSphere Update Manager
Update Manager comes as a vCenter plug-in that is accessible from a number of places within the vSphere Web client. To load it, click on the Update Manager icon from the Home screen or simply select the vCenter Server hostname in Navigator and change over to the Update Manager tab. The interface of vSphere update manager consists of two main views, Admin and Compliance . The Admin view allows you to configure various aspects of VUM itself as well as manage baselines, the patch repository and ESXi images. The Compliance view, on the other hand, is where you carry out tasks such as attaching baselines, scanning for applicable updates and remediating.
Figure 1 – The Update Manager icon on the Home screen in vSphere Web Client
Import esxi patching image
So, the first thing we need to do to update ESXi via VUM, is to download the respective image from my.vmware.com and import it to Update Manager.
Step 1 – Highlight the vCenter Server name in Navigator , select the Update Manager tab and click on the Go To Admin View button.
Figure 2 – Changing to VUM’s Admin view in vSphere Web client
Step 2 – Once in Admin view, select the ESXi Images tab and click on Import ESXi Image . Doing so loads another dialog box where you specify the ESXi image (ISO file) you want to be imported. Click on Browse and navigate to the folder where the image is stored. Select the ISO file and click OK. The file will upload as shown in Fig. 3. The upload progress bar shows the remaining time and the speed at which the file is being uploaded.
Figure 3 – Importing an ESXi ISO image to VUM
Step 3 – Once the ISO is uploaded, details about the ESXi image are displayed as per Figure 4.
Figure 4 – Product and version details for the ESXi image just imported
Creating a Baseline
Step 4 – Next, we create what’s called a Host Baseline. To do this, we simply right-click on the image just imported and select Create baseline as shown in Figure 5.
Figure 5 – Creating an ESXi host baseline
Step 5 – Type in a name for the baseline and press OK . The baseline should now be listed under the Hosts Baselines under Custom as per Fig. 6.
Figure 6 – The freshly created baseline as listed under the Hosts Baselines screen
Attaching the baseline and scanning the hosts
Step 6 – We’re almost there. The idea now is to attach the baseline to one or more hosts. We then run a compliance check to determine if the upgrade or update is actually required. To do this, one must change over to Compliance view. Just hit the Go to compliance view button at the top-right corner as shown in Fig. 7.
Figure 7 – Changing over to Compliance view
The baseline can in fact be attached to a number of objects including a datacenter, cluster or an individual ESXi host. This (esxi host configuration) is what allows you to patch multiple hosts. It is important to note though that you may inadvertently hit hosts not earmarked for updates so be careful when attaching baseline to higher-level objects.
In the example that follows, I’ve attached the baseline to one of three ESXi hosts forming a cluster.
Figure 8 – Attaching a baseline to a host
Step 7 – Next, we carry out a scan on the ESXi host to verify that the update/upgrade is in fact required. From the same screen, click on Scan for Updates and select Upgrades on the dialog that pops up followed by OK . This will initiate a scan the results of which are displayed under the Compliance Status column after the scan completes.
Figure 9 – Scanning a host for compliance
As expected, the host is found to be non-compliant, meaning that the 6.5.0d update is in fact applicable.
Figure 10 – A non-compliant result indicates that the host is missing one or more updates
ESXI patching with Remediate
In this case, remediating is the act of pushing a patch esxi or update to an ESXi host. A host is remediated by clicking on the Remediate button. Alternatively, right-click on the ESXi hostname (or IP address) in Navigator and select Remediate from the Update Manager menu.
Figure 11 – Remediating a host from the context menu
Step 1 – The remediation process starts by selecting the baseline image you want applied. In this case, I’ve selected the one created for the 6.5.0d upgrade.
Figure 12 – Remediation Step 1 – Select the baseline applied
Step 2 – Next, select the host you wish to remediate. In this case, only one host is listed which is the one highlighted in Navigator . If say, the baseline had been attached to a cluster, then you’d have all the hosts within that cluster listed as target objects.
Figure 13 – Remediation Step 2 – Selecting the target to remediate
Step 3 – Accept the EULA by ticking the box at the bottom.
Figure 14 – Remediation Step 3 – Accept the End User License Agreement
Step 4 – The next screen, gives you the option to postpone remediation tasks to a later date and time. You can also set the task to ignore warnings in reference to unsupported devices and such.
Figure 15 – Remediation Step 4 – Scheduling the remediation task (Optional)
Step 5 – In all probability, the ESXi being remediated will be hosting VMs. This screen gives you control over what happens to the VMs currently powered on. You can choose to have them powered off, suspended or leave them in their current state, with no additional virtual backup available. Like it or not, powered on VMs must be migrated or shut down for the remediation process to complete. Your options are to migrate VMs manually to some other host or simply power them off prior to remediating. Alternatively, set the VMs to power down by selecting the Power Off virtual machines option from the VM Power State drop-down box as shown in Fig. 16. You can also set the task to disconnect removable media from any hosted VMs as this may cause the remediation task to stall.
Figure 16 – Remediation Step 5 – Configuring the host remediation options
Step 6 – If the VMware host being remediated is a cluster member, you can control various aspects related to clustering as shown in Fig. 17. Further details on each setting are available here .
Figure 17 – Remediation Step 6 – Configuring the cluster remediation options
Step 7 – The Pre-check Remediation tasks runs a series of checks and generates a report of what exactly is carried out on the ESXi host. Press Finish to initiate the remediation task.
Figure 18 – Remediation Step 7 – Completing the remediation task
The remediation task’s progress is displayed in the Recent Tasks window in vSphere Web client.
Figure 19 – A remediation task in progress
The host should enter maintenance mode and later disconnect while the update is being applied. It should then reboot and re-connect automatically, assuming the remediation processes succeeded in updating the host.
Figure 20 – A host is disconnected while being updated as can be seen in vSphere client and DCUI.
Once remediation completes, you can easily verify that the esxi host is running the latest version by inspecting the host details on the Summary screen. Fig. 21 compares the host’s summary pre and post remediation.
Figure 21 – Comparing ESXi version details pre and post-remediation
This VMware KB article helps you correlate build and version numbers if needed. As per the partial table below, you can see that in our case, the ESXi host updated from 6.5 GA to 6.5.0d.
Figure 22 – Correlating ESXi version and build numbers
To properly protect your VMware environment, use Altaro VM Backup to securely backup and replicate your virtual machines. We work hard perpetually to give our customers confidence in their VMware backup strategy.
To keep up to date with the latest VMware best practices, become a member of the VMware DOJO now (it’s free).
Conclusion
ESXi patching is of utmost importance to any organization worldwide operating on vSphere.
Update Manager is a must-have if you want to easily and effectively implement patch management for ESXi. Incidentally, Update Manager is one other reason why you’d want to move over to vCSA 6.5 since VUM is now embedded with this vCenter release.
Обновляем ESXi до версии 7.0U2
Начиная с 09.03.21 г. доступен второй апдейт vSphere 7.0, и многие, наверняка, захотят протестировать ее обновленный интерфейс и множество новых функций, которые мы перечисляли в недавно опубликованных нами релизах «VMware ESXi 7.0 Update 2 Release Notes» и «VMware vCenter Server 7.0 Update 2 Release Notes». Бесспорно, весьма разумной тактикой будет не апгрейдить продакшен, пока не выйдет хотя бы первый патч к ESXi 7.0U2 (кстати, он вышел 29 апреля, об этом мы писали вот здесь), ведь ошибок и проблем с ним имеется еще масса (см. наш материал «Возможные ошибки в VMware ESXi 7.0 Update 2»), однако для тестовой среды, а также в качестве рекомендации для будущего обновления эта статья будет более чем полезной.
Сегодня мы поговорим о требованиях и вопросах совместимости новой версии нашего гипервизора, процедурах подготовки к апгрейду и о нем самом – в деталях, а также о том, что необходимо сделать после успешного его завершения, дабы один из ключевых компонентов виртуальной среды смог проявить свой функционал во всей красе. На опорной теории, думается, останавливаться смысла нет – все, что нужно знать, уже излагалось в одном из старых наших материалов «Инсталляция и разворот VMware vSphere 7.0». К тому же, предметом сегодняшнего обсуждения является именно обновление со старых версий на последнюю, следовательно, читатель, наверняка неплохо разбирается в герое этой статьи.
Что ж, давайте оставим предисловия позади и перейдем непосредственно к делу.
Требования и совместимость
Апгрейд ESXi можно осуществлять с версий 6.5/6.7 на 7.0.х напрямую. Но, перед тем, как приступать к подготовке к нему и самому непосредственному процессу, стоит самым внимательным образом изучить требования к среде и ее компонентам, а также получить все сведения о совместимости того, что у нас уже есть в системе (либо точно планируется заполучить в ближайшем будущем – до смены версии гипервизора), чтобы обновление не дало сбой, либо же после него не оказалось, что обстоятельства вынуждают откатываться назад.
Совместимость с платформами, ОС, версионностью «железа» и прочим проверяем, как обычно, здесь, в VCG. С другими решениями и продуктами VMware (а без гипервизора у нас, как известно, очень многое, попросту не существует) – здесь.
Поддерживаемые пути апгрейда
Учтите, что хосты, версии 6.5U1 и древнее, на «семерку» сходу обновить не получится – сначала доводим их до 6.5U2, а еще лучше – сразу до 6.7.х, и только потом – до самой свежей. Вообще же совместимость версий гипервизора проверяется в этой таблице, а для ESXi 6.5U2 и новее она сейчас выглядит, например, вот так:
Важно! Если что, откатиться на 6.х-версии ESXi не получится (причины раскрываются ниже в подразделе «Требования к уровню системного хранилища»). Рекомендуется сделать бэкап загрузочного устройства до обновления и, при необходимости, восстановиться с него.
Требования к уровню системного хранилища
Уровень системного хранилища ESXi в 7.х-семействе – это гибкое управление партициями для больших модулей, агрегация со сторонними компонентами и чрезвычайно упрощенная отладка. Если у вас версия 6.5/6.7, вы, конечно же, в курсе, что она декларирует фиксированный размер партиций, за исключением партиции «/scratch» и опционального VMFS-датастора, а также статичное их кол-во наряду с ограниченными возможностями управления. В «семерке» все консолидировалось в меньшее по количеству партиций, но больших размеров хозяйство, причем, все это интересно масштабируемо.
Уровень системного хранилища сейчас раздроблен всего на четыре партиции:
- System Boot (хранит загрузчик и модули EFI, 100 МБ),
- Boot-bank 0 и Boot-bank 1 (системные пространства для модулей загрузки ESXi, 500 МБ – 4 ГБ каждая),
- ESX-OSData (консолидированная локация для хранения дополнительных модулей, не используемая в загрузке и для ВМ, содержит старую «/scratch», партицию локера для VMware Tools и назначения дампа ядра, до 138 ГБ).
Первые три относятся к типу FAT16, а ESX-OSData – к VMFS-L. Последний том поделен на постоянные (образа VMware Tools, конфигурации и дампы ядра) и непостоянные (логи, глобальные трассировки VMFS, данные vSAN Entry Persistence Daemon (EPD), трассировки vSAN и БД в реальном времени) данные.
Также к этому всему прилагается традиционный датастор VMFS, объем которого – это все, что осталось. Для высоконадежных носителей, к примеру, это 142+ ГБ, и в этом случае хранилище VMFS создается автоматически с целью хранения данных ВМ.
Инсталлятор ESXi позволяет лимитировать размер партиций системного хранилища на загрузочном носителе с помощью опции «systemMediaSize», значения которой:
- «min» (33 ГБ – одиночный диск или встроенные сервера),
- «small» (69 ГБ – сервера с, минимум, 512 ГБ оперативной памяти),
- «default» (138 ГБ),
- «max» (все доступное пространство – для мульти-терабайтных серверов).
Учтите, что процесс апгрейда ESXi со старых версий на любую из «семерок» повлечет за собой перераспределение партиций на загрузочном диске. При этом, если пользователем место назначения дампа ядра не настроено, система водрузит его, по умолчанию, в том ESX-OSData. VMware Tools будут смигрированы из партиции локера и этот раздел очистится. Партиция дампа ядра очистится тоже, а если syslog-служба настроена на хранение файлов логов на 4 ГБ VFAT scratch-партиции, их переместят из «var/run/log» в том ESX-OSData.
Требования к «железу»
На хосте, поддерживающем ESXi 7.0.х, должно быть, минимум (исходя из нужд среды и выбранной конфигурации):
- 2 CPU (широкий диапазон 64-битных х86 процессоров – проверять в VCG, со включенным битом NX/XD в BIOS),
- 4 ГБ RAM (от 8 ГБ для запуска ВМ в типичных продакшен-средах),
- Gigabit или более быстрые Ethernet-контроллеры (совместимость смотрим там же),
- загрузочный диск с 8 ГБ для USB/SD и 32ГБ для HDD/SSD/NVMe,
- SCSI-диск или локальный, несетевой RAID LUN с неразделенным пространством для ВМ,
Важно! Загрузочный диск не должен использоваться совместно несколькими ESXi-хостами.
- удаленный (не локальный) SATA-диск, подключенный через поддерживаемые SAS-контроллеры или встроенные SATA-контроллеры. Такие диски не могут использоваться как scratch-партиция по дефолту.
По best practice максимальных показателей производительности можно достичь при обновлении ESXi в надежной системе с хорошим запасом оперативной памяти и несколькими физическими дисками.
Важно! ESXi-хосты всегда требуют больше RAM, чем типичные серверы.
Важно! Чем быстрее процессоры – тем лучше производительность ESXi. Учтите, что некоторые рабочие процессы весьма требовательны к производительности и для них хорошо бы предусмотреть больший кэш.
Требования к хранилищу
По размеру хранилища для ESXi 7.0.х рекомендовано следующее:
- 8 ГБ USB/SD + 32 ГБ локального диска (загрузочные партиции будут на USB/SD, а том ESX-OSData – на локальном диске);
- локальный диск на 32 ГБ (загрузочные партиции вместе с томом ESX-OSData);
- локальный диск на 142 ГБ или больше (там все – и загрузочные партиции, и том ESX-OSData, и VMFS-датастор).
Важно! Рекомендуется размещать все данные, используемые ВМ на специально выделенных для них физических дисках. Для повышения производительности стоит не размещать ВМ там, где содержится загрузочный образ ESXi.
Если используется Auto Deploy метод инсталляции, либо же директория логов отличается от дефолтной локации в scratch-директории на томе VMFS, может понадобиться изменить текущий размер журнала логов и параметры оборотов, для уверенности, что для них хватит места. Дефолтные значения объема логов зависят от доступного места на хранилище и от того, как настроена система логгирования. Хосты с Auto Deploy хранят логи на RAM диска, то есть, пространство для них выделяется довольно маленькое. В этом случае лучше перенаправить логи по сети с помощью удаленного коллектора, либо же на NAS или NFS-хранилище. Минимальный размер и конфигурация ротации для логов hostd, vpxa и fdm:
Тип логов Максимальный размер файла логов, МБ Кол-во оборотов для сохранения Минимальный требуемый объем диска, МБ Management Agent (hostd) 10 10 100 VirtualCenter Agent (vpxa) 5 10 50 Агент vSphere HA (Fault Domain Manager, fdm) 5 10 50 Требования к сети
Важно! Рекомендуется размещать управляющую сеть и сети ВМ на разных физических сетевых картах.
В ESXi есть встроенный файервол, включенный по дефолту. При инсталляции он настроен для блокирования входящего и исходящего трафика, за исключением трафика для сервисов, разрешенных на профиле безопасности хоста.
По поводу открытия портов, следует свериться с этой таблицей. Если устанавливаются другие VIB на хосте, должны быть доступны дополнительные сервисы и порты файерволлинга – здесь все индивидуально.
Требования к браузеру
В разрезе ОС клиентом хоста поддерживаются следующие версии браузера:
Браузер, версия Mac OS Windows Linux Google Chrome 75+ 75+ 75+ Mozilla Firefox 60+ 60+ 60+ Microsoft Edge – 79+ – Safari 9.0+ – – Подготовка к обновлению гипервизора
Важно! Гипервизор всегда обновляется после vCenter Server. Как его апгрейдить до последней версии мы учились в статье «Обновляем vCenter Server до версии 7.0U2».
Обновление ESXi VMware рекомендует делать, согласно следующей схеме:
Вот по ней, собственно, и начнем свое продвижение.
В первую очередь, проверяем соответствие требованиям, описанным нами выше в разделе «Требования и совместимость». Затем нам предстоит выбрать метод, которым может осуществляться апгрейд. Всего их пять:
- интерактивный с подмонтированного носителя (CD, DVD или USB) через GUI,
- скриптованный,
- ESXCLI,
- Auto Deploy,
- через vSphere Lifecycle Manager.
Каждый имеет свои преимущества и недостатки, а также идеальную сферу применения. Так, первый метод весьма нагляден для начинающих виртуализаторов и удобен, если всего несколько хостов нуждаются в обновлении. Скрипты – прекрасный вариант, если хостов множество. vLCM – замечательный комплексный инструмент по обслуживанию всего жизненного цикла компонентов vSphere, включая апгрейд, исправление и прочие касающиеся предмета нашего сегодняшнего разговора вещи. Его оркестровка существенно упрощает жизнь, проверено на практике.
Если же мы говорим о vSphere Auto Deploy, он подходит только в варианте, когда и предыдущая версия разворачивалась тоже с ним – метод повторной подготовки хоста и перезагрузки его уже с новым профилем образа. В таком профиле будет обновление или исправление ESXi, профайл конфигурации хоста и, при необходимости, сторонние драйверы или агенты управления, предоставляемые партнерами VMware. Можно готовить кастомные образа, используя vSphere ESXi Image Builder CLI.
И, наконец, классика ESXCLI – для любителей работы с командной строкой, находящихся на короткой ноге с синтаксисом JSON, опытных виртуализаторов, тех, кто предпочитает автоматизировать свою работу, особенно в случае управления сотнями хостов с отличными конфигурациями.
Помимо выбора генеральной методы, в процессе подготовки стоит учесть еще несколько важных замечаний:
- Если к хосту подключен vSAN, нужно отключить систему Fibre Channel. Не отключать карты HBA в BIOS;
- Сделать бэкап хоста;
- Смигрировать или выключить ВМ на хосте (см. ниже по каждому методу апгрейда), погрузить хост в режим техобслуживания (требуется в ряде случаев).
Как и начальная инсталляция, апгрейд производится под учетной записью локального администратора на ESXi-хосте.
Важно! Требования к паролям: должны содержать, минимум, одну большую букву, одну маленькую, одну цифру и спецсимвол, быть длиной от 7 до 40 знаков, не совпадать со словами из словаря или их частью. Если начинается с большой буквы, все равно далее должна встречаться еще одна большая буква. Если заканчивается на цифру, еще одна цифра должна присутствовать в теле пароля. По дефолту, аккаунт блокируется после 5 попыток ввода неправильного пароля. Разблокировка происходит, обычно, через 15 минут.
Подготовка к апгрейду через vLCM
vLCM способен управлять обновлением хостов с помощью baseline или образов. У вторых, на данный момент, функционал масштабнее и ярче, но image работают только с «семерки», чего не скажешь о baseline, хоть под ними недоступны ROBO-поддержка, REST API и ограничена поддержка рекомендаций софта – только для кластеров vSAN в формате рекомендаций baseline.
Важно! Если перешли на апгрейд через vLCM с образами, вернуться к старой стратегии (с baseline), если таковая применялась, не получится. Разве что перенести хосты в кластер, использующий baseline.
Образа vLCM представляют собой желаемую спецификацию софта, предназначенную для применения ко всем хостам в кластере (версию ESXi, дополнительное ПО VMware, вендорское и стороннее ПО, в т. ч. драйвера и firmware). По итогу, нам нужен будет только один образ, который и станет управлять всеми хостами в кластере, благодаря чему достигается желаемая гомогенность. Сейчас в деталях изучать vLCM мы не будем – уж больно масштабная тема, действительно, с тоннами теории и возможностей, поэтому расскажем о его применении к процессу апгрейда хостов.
В плане подготовки к этому типу обновления, нам нужно всего лишь убедиться, что апдейты софта доступны в локальном хранилище vLCM, куда они поступают путем его синхронизации с официальным хранилищем VMware. В принципе, их можно загружать и вручную или с оффлайн-ресурса. Выбор конкретного типа хранилища задается в настройках vLCM, а доступ к нему самому осуществляется через клиент vSphere. Рассмотрим все варианты загрузки образов и их апдейтов по очереди:
- Оффлайн-пакет в zip-формате. Используется в ручной загрузке апдейтов: опцией импорта после выкачки они заходят в хранилище vLCM. Начиная с 7.0-версии vSphere, оффлайн-пакеты содержат не только патчи и расширения, но и базовый образ ESXi, вендорские аддоны или стороннее ПО, те же асинхронизированные драйвера, специфичные для требований OEM hardware и пр. Скачивается zip-пакет отсюда. Нужны будут привилегии VMware vSphere Lifecycle Manager.Upload File.Upload File;
- ISO-образ для импортирования в локальное хранилище vLCM. Применяется для апгрейда ESXi с 6.5.х/6.7.х до 7.0. Выбрав нужный тип лицензии, скачиваем ISO отсюда:
Процедуру подгрузки апдейтов в клиенте vSphere и работу с импортированными образами рассмотрим в деталях со скриншотами ниже в подразделе «Обновление с помощью vLCM» главы «Процедура апгрейда ESXi до версии 7.0U2».
Кстати, можно настроить связь vLCM с центром обновлений для автоматического получения апдейтов по расписанию, либо же, когда необходимо, вручную загружать их. Во втором случае нам нужно пройти на домашнюю страницу vLCM (в клиенте vSphere выбрать в «Menu» – «Lifecycle Manager» и в выпадающем меню «Lifecycle Manager» отыскать нужный нам vCenter Server). Далее в «Actions» выбираем «Sync Updates» вверху, после чего стартует синхронизация. Загруженные патчи и расширения теперь появятся на вкладке «Updates».
Синхронизация автоматического типа изначально включена по дефолту и ее работа начинается, как только будет развернут vCenter Server. Расписание предписанного обновления включает в себя частые проверки, но, его можно изменить, по желанию. Чтобы поменять эти настройки, в клиенте vSphere заходим через «Menu» в «Lifecycle Manager» и из выпадающего меню выбираем нужный нам vCenter Server. Затем проходим на вкладку «Settings», где в «Administration» выбираем «Patch Downloads», и на панели «Automatic Download Settings» кликаем на кнопку «Edit». Откроется соответствующее диалоговое окно, где ставим галочку на «Download patches» и задаем настройки нашего расписания, после чего сохраняем все по «Save».
Подготовка к интерактивному обновлению через CD/DVD/USB
В качестве первого пункта подготовки рекомендуется отключить сетевое хранилище, чтобы уменьшить время поиска доступных приводов дисков инсталлятором. При этом, разумеется, нельзя отключать LUN, содержащий существующую инсталляцию ESXi.
Далее помещаем ISO инсталлятора на CD/DVD или на USB-флешку. Также можно использовать PXE для загрузки. И проверяем, установлены ли часы «железа» сервера на UTC (в BIOS).
Важно! Если поддерживаемые пользовательские VIB не включены в ISO инсталлятора ESXi, они будут смигрированы.
И, напоследок, следует сделать резервную копию существующего хранилища VMFS и внимательно ознакомиться с документацией вендора по hardware на предмет изменения порядка загрузки.
Подготовка к обновлению через скрипт
Размещать скрипт обновления следует на чем-то одном из следующего: FTP-сервере, HTTP/HTTPS-сервере, NFS-сервере, USB-устройстве, приводе CD-ROM. Сам скрипт представляет собой текстовый файл («ks.cfg» или пользовательский, но с именем такого вида «ks_*.cfg») с поддерживаемыми командами, командная секция которых содержит опции инсталляции ESXi – она всегда должна стоять первой.
Для определения, который диск включен для инсталляции или апгрейда ESXi, в скрипте должны быть команды: «install»/«upgrade»/«installorupgrade». Команда «install» генерирует дефолтную партицию, включая датастор VMFS, занимающую все доступное пространство после создания всех остальных партиций. Список остальных команд и упомянутых, с расшифровкой:
- аccepteula/vmaccepteula (требуется);
- clearpart (опционально) – очищает все существующие партиции на диске (только с «install»). Аргументы:
- –drives= (удаляет партиции на указанных дисках),
- –alldrives (удаляет партиции на каждом диске),
- –ignoredrives= (удаляет партиции на всех дисках, кроме указанных – работает только, если первые две не указывались),
- –overwritevmfs (позволяет перезаписывать партиции VMFS на указанных дисках, по дефолту не разрешено),
- –firstdisk= («disk-type1»/«[disk-type2,…]», производится разбитие на партиции по первому доступному диску. Порядок, по умолчанию: локальный, удаленный, USB. Можно изменить, добавив список в аргумент, разделив запятыми его участников),
[ disk-type2,…]» (партиции разбиваются на первом доступном диске – порядок см. выше), «–ignoressd» (исключает твердотельные диски из создания партиций, используется только с «install» и «–firstdisk»), «–overwritevsan» (если ESXi устанавливается на диск из дисковой группы vSAN, диск очищается), «–overwritevmfs» (нуждается в уже существующем VMFS, перезаписывает поверх), «–preservevmfs» (сохраняет существующий VMFS), «–novmfsondisk» (запрещает создавать партиции VMFS на диске, используется только с «–overwritevmfs», и если партиции VMFS уже есть на диске);
- installorupgrade – аргументы: «–disk=»/«–drive=»,
- keyboard (опционально) – устанавливает тип клавиатуры для системы. Аргумент «keyboardType», доступны следующие типы: Belgian, Brazilian, Croatian, Czechoslovakian, Danish, Estonian, Finnish, French, German, Greek, Icelandic, Italian, Japanese, Latin American, Norwegian, Polish, Portuguese, Russian, Slovenian, Spanish, Swedish, Swiss French, Swiss German, Turkish, Ukrainian, United Kingdom, US Default, US Dvorak;
- network (опционально) – указывает сетевой адрес для системы. Аргументы: «—bootproto=[dhcp|static]» (указывает откуда получать сетевые настройки – из DHCP или устанавливать их вручную), «–device=» (указывает либо МАС сетевой карты, либо имя устройства в формате «vmnicNN», относится к аплинку виртуального свитча), «–ip=» (IP-адрес машины в формате «xxx.xxx.xxx.xxx», нуждается в опции «–bootproto=static»), «–gateway=» (обозначает дефолтный шлюз как IP-адрес, в формате «xxx.xxx.xxx.xxx», используется с опцией «–bootproto=static»), «–nameserver=» (обозначает имя первичного сервера как IP-адрес, используется с опцией «–bootproto=static», пропускаем, если не используем DNS, может принимать два айпишника, например, «–nameserver=”10.126.87.104[,10.126.87.120]”»), «–netmask=» (указывает маску подсети для инсталлируемой системы в формате «xxx.xxx.xxx», используется с опцией «–bootproto=static»), «–hostname=» (указывает имя хоста), «–vlanid=vlanid» (указывает какая система VLAN доступна, значение от 1 до 4096), «–addvmportgroup=(0|1)» (указывает, надо ли добавлять VM Network порт-группу, используемую для ВМ, по дефолту значение «1»);
- paranoid (опционально) – выводит предупреждающие сообщения, прерывая инсталляцию, если пропустить, сообщения будут сохраняться в логи;
- part/partition (опционально) – создает дополнительный VMFS-датастор в системе (можно только один на диск, только одна партиция указывается для одного диска и она может быть только партицией VMFS). Аргументы: «datastore name» (указывает, где партиция будет подмонтирована), «-ondisk=»/«–ondrive=» (указывает диск или привод, где будет создана партиция),
[ disk-type2,…]» (разбивает первый найденный диск);
- reboot (опционально) – перезагружает машину по окончанию скриптованной инсталляции. Аргумент: «<–noeject>» (CD не вынимается после);
- rootpw (требуется) – устанавливает пароль рута для системы. Аргументы: «–iscrypted» (зашифрованный), «password» (тело пароля);
- upgrade – аргументы: «–disk=»/«–drive=» (см. выше),
- %include/include (опционально) – указывает другой инсталляционный скрипт для анализа. Аргумент: «filename» (пример – «%include part.cfg»);
- %pre (опционально) – указывает на скрипт, который должен быть запущен до того, как оценится конфигурация kickstart (можно использовать, чтобы генерировать файлы для включения в kickstart). Аргумент:
=[python|busybox]» (задает другой скрипт инсталляции для parseSpecifies интерпретатора, по дефолту «busybox»);
- %post (опционально) – запускает указанный скрипт после окончания пакетной инсталляции, если задать несколько таких секций, они будут запускаться в порядке местонахождения в скрипте. Аргументы:
=[python|busybox]» (задает интерпретера), «–timeout=secs» (указывает таймаут для работы скрипта, скрипт может не закончить свою работу по его истечению и тогда он остановится силовым методом),
=[true|false]» (если значение «true», инсталляция будет считаться успешной, даже если скрипт «%post» остановится с ошибкой);
- %firstboot – создает скрипт «init», который запускается только при первой загрузке. На другие последующие скрипты влияния не оказывает. Если таких секций много, они будут запускаться в порядке, в котором расположены в файле kickstart.
Важно! Этот скрипт не запустится, если на ESXi-хосте разрешена безопасная загрузка.
=[python|busybox]» (задает интерпретатора, по дефолту – «busybox»).
Можно пользоваться как дефолтными скриптами, так и писать свои собственные. Помимо перечисленных команд и их аргументов, также важно обратить внимание на правильное написание имен дисковых устройств (часто используется):
Формат Описание Пример NAA Идентификатор SCSI INQUIRY naa.6d09466044143600247aee55ca2a6405 EUI Идентификатор SCSI INQUIRY eui.3966623838646463 T10 Идентификатор SCSI INQUIRY t10.SanDisk00Cruzer_Blade000000004C530001171118101244 VML Устаревший идентификатор VMkernel vml.00025261 MPX Идентификатор на основе пути mpx.vmhba0:C0:T0:L0 А также идентификаторам и именам устройств хранилища. Идентификаторы могут быть даны самим хранилищем в формате «naa.xxx»/«eui.xxx»/«t10.xxx», либо же опираться в своем отображении на путь, например, выглядеть так: «mpx.vmhba1:C0:T1:L3». Чтобы вывести имена всех девайсов в vSphere CLI, нужно ввести команду:
esxcli storage core device list
Осуществляя подготовку к обновлению с использованием скриптов, не получится обойти вниманием такой важнейший файл, как «boot.cfg». Этот файл конфигурации загрузчика уточняет ядро, его опции и модули загрузки, которые загрузчик «mboot.c32» или «mboot.efi» использует в установке ESXi. Этот файл предоставляется самим инсталлятором, и строка «kernelopt» в нем отвечает за спецификацию локации инсталляционного скрипта либо же за передачу других опций загрузки. Его команды:
- «title=STRING»,
- «prefix=STRING» (опционально, добавляет «DIRPATH/» спереди каждой «FILEPATH»-команды в «kernel=» и «modules=», которые не начинаются с «/» или с «http://»),
- «kernel=FILEPATH» (установка пути к ядру как «FILEPATH»),
- «kernelopt=STRING» (добавляет «STRING» к параметрам загрузки ядра),
- «modules=FILEPATH1— FILEPATH2… — FILEPATHn» (выдает список модулей, подлежащих загрузке, разделенных тремя дефисами «—»).
Теперь рассмотрим подготовку к инсталляции через сетевую загрузку. Если хотим грузиться с сети (PXE-загрузка хоста ESXi с сетевого устройства), хост будет использовать старый BIOS или UEFI, либо же, если поддерживается нативный UEFI HTTP, можно использовать HTTP для загрузки. PXE-загрузка нуждается в специфической сетевой инфраструктуре и машине с PXE-совместимым сетевым адаптером, однако в большинстве случаев все это доступно по умолчанию. Нативный UEFI HTTP использует DHCP и HTTP в процессе загрузки, и здесь нужно, чтобы версия firmware UEFI на хосте включала функцию HTTP-загрузки, а сетевой адаптер поддерживал UEFI-сеть. Этот тип загрузки более быстр и доступен, чем использование TFTP. Если же ESXi-хосты не поддерживают нативный UEFI HTTP, можно использовать iPXE HTTP.
Важно! Сетевая загрузка со старым firmware BIOS возможна исключительно по IPv4. Если же есть возможность работать с UEFI BIOS, без разницы, у нас IPv4 или IPv6. Однако, и это важно, микс этих протоколов не поддерживается.
В плане подготовки к этому типу загрузки инсталлятора нам нужно проделать следующее, в разрезе возможных сценариев исходных данных:
- С нативным UEFI HTTP. Firmware UEFI должен поддерживать функцию загрузки HTTP, а конфигурация «железа» целевого хоста – поддерживаться версией ESXi, и на нем должен быть сетевой адаптер с UEFI-сетью. Также следует настроить DHCP-сервер с загрузкой UEFI HTTP и использовать родной VLAN, причем NIC должна поддерживать спецификацию VLAN ID;
- С iPXE и HTTP. Конфигурация «железа» целевого хоста должна поддерживаться версией ESXi, как и сетевой адаптер с PXE. Также необходим DHCP-сервер, настроенный под загрузку PXE, TFTP-сервер, причем, политики сетевой безопасности должны разрешать трафик TFTP (UDP-порт 69), и нужно использовать родной VLAN, причем NIC поддерживает спецификацию VLAN ID. Если у нас старый BIOS, важно получить версию 3.86 пакета SYSLINUX;
- С PXE и TFTP. Конфигурация «железа» целевого хоста должна поддерживаться версией ESXi, как и сетевой адаптер с PXE. DHCP-сервер должен быть в состоянии настаивать PXE-загрузку, также имеется в наличии TFTP-сервер, и его трафик разрешают политики безопасности сети (UDP-порт 69). Также нужно использовать родной VLAN, причем NIC поддерживает спецификацию VLAN ID. Если у нас старый BIOS, важно получить версию 3.86 пакета SYSLINUX.
Еще один немаловажный момент, о котором хотелось бы сказать, завершая разговор о подготовке к скриптованной инсталляции обновления ESXi через сетевую загрузку, это настройка DHCP-сервера – мы постоянно упоминали ее, когда говорили о требуемых шагах при разных сценариях исходных данных. По итогу мы должны добиться того, чтобы DHCP-сервер посылал адрес TFTP/HTTP-сервера и имя файла стартового загрузчика на ESXi-хост. Когда целевая машина загружается впервые, она рассылает пакет по сети, запрашивая информацию для своей загрузки, и DHCP-сервер ей отвечает. Он должен распознавать, позволено ли целевой машине загружаться, и расположение двоичного файла начального загрузчика. Для PXE это файл на сервере TFTP, а для UEFI HTTP-загрузки локация – это URL.
Важно! Если в сети уже есть один DHCP-сервер, второй делать нельзя. Иначе будет конфликт получения IP-адресов машинами, либо же произойдет сбой получения правильной загрузочной информации.
Приведем несколько примеров настройки DHCP. Если загрузка использует PXE и TFTP с IPv4:
# ISC DHCP server configuration file snippet. This is not a complete
# configuration file; see the ISC server documentation for details on
# how to configure the DHCP server.
option client-system-arch code 93 = unsigned integer 16;
match if substring(option vendor-class-identifier, 0, 9) = “PXEClient”;
if option client-system-arch = 00:07 or option client-system-arch = 00:09 <
Если загрузка использует PXE и TFTP с IPv6:
# ISC DHCPv6 server configuration file snippet. This is not a complete
# configuration file; see the ISC server documentation for details on
# how to configure the DHCP server.
option dhcp6.bootfile-url code 59 = string;
option dhcp6.bootfile-url “tftp://[xxxx:xxxx:xxxx:xxxx::xxxx]/mboot.efi”;
Если загрузка использует iPXE и HTTP с IPv4:
# ISC DHCP server configuration file snippet. This is not a complete
# configuration file; see the ISC server documentation for details on
# how to configure the DHCP server.
option client-system-arch code 93 = unsigned integer 16;
match if substring(option vendor-class-identifier, 0, 9) = “PXEClient”;
if option client-system-arch = 00:07 or option client-system-arch = 00:09 <
if exists user-class and option user-class = “iPXE” <
# Instruct iPXE to load mboot.efi as secondary bootloader
# Load the snponly.efi configuration of iPXE as initial bootloader
if exists user-class and option user-class = “iPXE” <
# Instruct iPXE to load pxelinux as secondary bootloader
# Load the undionly configuration of iPXE as initial bootloader
Если загрузка использует iPXE и HTTP с IPv6:
# ISC DHCPv6 server configuration file snippet. This is not a complete
# configuration file; see the ISC server documentation for details on
# how to configure the DHCP server.
option dhcp6.bootfile-url code 59 = string;
if exists user-class and option user-class = “iPXE” <
# Instruct iPXE to load mboot.efi as secondary bootloader
option dhcp6.bootfile-url “tftp://[xxxx:xxxx:xxxx:xxxx::xxxx]/mboot.efi”;
# Load the snponly.efi configuration of iPXE as initial bootloader
option dhcp6.bootfile-url “tftp://[xxxx:xxxx:xxxx:xxxx::xxxx]/snponly.efi”;
Если загрузка использует UEFI HTTP с IPv4:
# ISC DHCP server configuration file snippet. This is not a complete
# configuration file; see the ISC server documentation for details on
# how to configure the DHCP server.
option client-system-arch code 93 = unsigned integer 16;
match if substring(option vendor-class-identifier, 0, 10) = “HTTPClient”;
option vendor-class-identifier “HTTPClient”;
if option client-system-arch = 00:10 <
# x86_64 UEFI HTTP client
И если загрузка использует UEFI HTTP с IPv6:
# ISC DHCPv6 server configuration file snippet. This is not a complete
# configuration file; see the ISC server documentation for details on
# how to configure the DHCP server.
option dhcp6.bootfile-url code 59 = string;
if option dhcp6.client-arch-type = 00:10 <
# x86_64 HTTP clients
option dhcp6.vendor-class 0 10 “HTTPClient”;
option dhcp6.bootfile-url “http://www.example.com/esxi/mboot.efi”;
Подготовка к обновлению с использованием ESXCLI
Выбор этого метода обновления требует понимания VIB (пакетов ПО ESXi от VMware и партнеров с решениями, драйверами, CIM-провайдерами и приложениями, расширяющими платформу – доступных в хранилищах софта, используются для создания и кастомизации образов, апгрейда хостов), профилей образов (определяющих образ ESXi и состоящих из VIB, включающих базовый VIB и, часто, другие VIB, проверяется и определяется с помощью vSphere ESXi Image Builder) и хранилищ софта (коллекций VIB и профилей образов, имеющих иерархическую структуру файлов и папок и доступных через HTTP URL или ZIP-файл).
Важно! Если далее по тексту какие-то команды будут непонятны, либо захочется отступить от предложенной схемы в каких-то целях, следует вбить в командную строку «esxcli –help», чтобы увидеть список поддерживаемых опций.
Каждый VIB характеризуется неизменяемым уровнем приемлемости, определяющим, какие VIB могут быть установлены на хост. Этот уровень применяется индивидуально по каждому VIB использованием команд «esxcli software vib install» и «esxcli software vib update», а также по проинсталлированным с помощью vLCM VIB и к VIB в профилях образов. Уровень приемлемости должен быть настолько высоким, насколько это возможно, например, если уровень хоста – VmwareAccepted, на него можно ставить только VIB VMwareCertified /VMwareAccepted, но не PartnerSupported/CommunitySupported. В принципе, эту политику, при желании, можно изменить, если поменять в клиенте vSphere параметры приемлемости хоста командами «esxcli software acceptance». Уровни приемлемости VIB, требуемые для установки на хостах:
Уровень приемлемости хоста VMwareCertified VIB VMwareAccepted VIB PartnerSupported VIB CommunitySupported VIB VMwareCertified Х VMwareAccepted Х Х PartnerSupported Х Х Х CommunitySupported Х Х Х Х Инсталляция VIB наживую не требует перезагрузки хоста, однако может нуждаться в его погружении в режим maintenance. Чего не скажешь о прочих видах инсталляции.
В плане подготовки к обновлению через ESXCLI, если ранее с ним не сталкивались, нужно всего лишь проинсталлировать ESXCLI и, конечно же, изучить официальный мануал по работе с ним, выложенный здесь, который поможет и с инсталляцией этого инструмента, в том числе.
Подготовка к обновлению через Auto Deploy
Сервер vSphere Auto Deploy автоматически обновляется при апгрейде соответствующего vCenter Server (начиная с 6.0 он всегда находится на той же управляющей ноде, что и система vCenter Server):
Среди компонентов этой схемы:
- vSphere Auto Deploy server – сервер vSphere Auto Deploy (предоставляет образа и профили хостов ESXi-хостам),
- vSphere Auto Deploy rules engine – механизм правил vSphereAutoDeploy (посылает информацию на сервер vSphere Auto Deploy о том, какой профиль образа и какой профиль хоста должен быть предоставлен тому или иному хосту. Эти правила можно настраивать),
- Image profiles – профили образов (определяют набор VIB для загрузки с ними ESXi-хостов. VMware вместе с партнерами выкладывают профили образов и VIB в публичных хранилищах, которые исследуются vSphere ESXi Image Builder, опираясь на механизм правил, чтобы понять, какой образ следует применить к тому или иному хосту. Кроме того, пользователи могут создавать свои собственные образы, исходя из тех, что в этом хранилище, с целью последующего применения),
- Host profiles – профили хостов (определяют специфичную для машин конфигурацию, например, сетевые настройки или настройки хранилища. Их можно создавать с помощью специального UI),
- Host customization – настройка хоста (хранит информацию, предоставляемую пользователем при применении профилей хоста к хосту. Должна содержать IP-адрес или другие соответствующие данные).
Информация о хосте – это выполняемое ПО для запуска на хосте ESXi (профиль образа, созданный vSphere ESXi Image Builder), настраиваемые параметры, определяющие, как хост был сконфигурирован (виртуальные свитчи, настройки драйвера, сгенерированные приватные ключи, параметры загрузки и т.д. – профиль хоста, созданный соответствующим UI), динамическое состояние (состояние в реальном времени, генерируемое запущенным софтом – работающими БД, сгенерированными приватными ключами и пр., например, память хоста, теряемая в процессе перезагрузки), состояние ВМ (тех, что хранятся на хосте и данные по автозапуску машин – только последовательный запуск), пользовательские данные (состояние, опирающееся на пользовательский ввод – IP-адрес, предоставляемый пользователем, когда запускается система, к примеру, словом, все то, что автоматически не включается в профиль хоста, и хранится vCenter Server при первой загрузке).
Подготовка к Auto Deploy заключается в следующем:
- Проверяем, подключены ли по сети ESXi-хосты к vCenter Server, и открыты ли все порты (см. раздел «Требования и совместимость» выше);
- Убеждаемся, что в среде есть TFTP и DHCP сервера, чтобы была доступна посылка файлов и назначение сетевых адресов хостам, к ним было подключение ESXi-хостов, как и к серверам vSphere Auto Deploy;
- Учитываем, что для репозитория vSphere Auto Deploy есть, минимум, 2 ГБ свободного места (четыре профиля образов и немного сверх того – а вообще, рассчитывается, исходя из того, сколько профилей планируется к использованию);
- Если хочется использовать VLAN в среде, устанавливаем правильно связь и вручную вносим изменения в интерфейс UEFI/BIOS так, чтобы драйвер firmware при PXE-загрузке хоста помечал фреймы правильными идентификаторами VLAN. Также важно корректно настроить порт-группы ESXi с VLAN ID;
- Меняем имя файла «gpxelinux.0» на «snponly64.efi.vmw-hardwired», если у нас UEFI, либо же на «undionly.kpxe.vmw-hardwired» – если BIOS;
- Защищаем сеть от любого другого метода PXE-разворота. Несмотря на то, что Auto Deploy передает данные по SSL, аутентификация клиента или сервера Auto Deploy не проверяется при загрузке;
- Если хотим управлять vSphere Auto Deploy при помощи PowerCLI cmdlet, следует убедиться, что на Windows-машине проинсталлированы Microsoft .NET Framework 4.5/4.5.x и Windows PowerShell 3.0/4.0;
- Устанавливаем удаленный сервер Syslog, настраиваем первый загружаемый хост для его использования и применяем такой профиль хоста ко всем другим целевым хостам. Опционально можно поставить и использовать vSphere Syslog Collector – инструмент vCenter Server, предлагающий унифицированную архитектуру для системного логгирования, разрешающий сохранение логов сети и комбинирующий информацию со множества хостов;
- Инсталлируем ESXi Dump Collector, настраиваем первый хост так, чтобы все дампы ядра направлялись на него, и применяем этот профиль ко всем остальным хостам;
- Если хосты с BIOS, следует проверить, есть ли у сервера vSphere Auto Deploy IPv4-адрес.
Учтите, что нам еще понадобятся права администратора на сервере DHCP, управляющем сегментом, откуда хотим совершать загрузку.
Также очень полезно будет заранее научиться, как написать правило и назначить его одному или большему кол-ву хостов с vSphere Auto Deploy. Для этого нам понадобятся PowerCLI и все перечисленное выше ПО, а также придется экспортировать профиль хоста, который хотим использовать. Далее в сеансе PowerCLI запускаем «Connect-VIServer», чтобы подключиться к системе vCenter Server, с которой был зарегистрирован и vSphere Auto Deploy:
Может вернуть предупреждение о сертификации (если речь о продакшене, проблему нужно исправить). Далее через клиент vSphere задаем хост с настройками, которые хотим использовать и с него создаем профиль хоста, а после ищем имя профиля хоста командой «Get-VMhostProfile», передавая хост с которого создавался профиль. Теперь в командной строке определяем правило с конкретными параметрами, например, с диапазоном IP-адресов:
New-DeployRule -Name “testrule2” -Item my_host_profile -Pattern “vendor=Acme,Zven”, “ipv4=192.XXX.1.10-192.XXX.1.20”
И добавляем правило к набору:
По умолчанию, работающий набор правил сразу же станет активным и любые изменения применятся. Если же пока не хочется, чтобы он значился активным, поможет параметр «NoActivate».
Далее просто нужно назначить предоставленному с помощью vSphere Auto Deploy хосту новый профиль с помощью теста соответствия и операций восстановления (см. ниже в соответствующем подразделе следующей главы). И, наконец, включить не предоставленные хосты, чтобы они предоставились с этим профилем.
Процедура апгрейда ESXi до версии 7.0U2
В качестве исходных данных будем рассматривать 6.7 версию ESXi (пускай, это будет три хоста с тремя ВМ, с vCenter Server и организованным в нем дата-центром и кластером vSAN). О стартовом обновлении vCenter Server мы рассказывали в статье «Обновляем vCenter Server до версии 7.0U2» – именно с него мы всегда начинаем обновление нашей среды. Предположим, что все требования по совместимости и другим важным вещам, описанные выше в разделе «Требования и совместимость», нами соблюдены, все этапы подготовки к апгрейду также пройдены, значит, настало время непосредственно перейти к процессу приведения хостов к новой версии.
Обновление с помощью vLCM
Итак, как мы уже говорили, у нас на данный момент vSAN-кластер с хостами 6.7-версии:
А обновление vCSA уже успешно завершилось (см. выше ссылку на соответствующий мануал). Грейдить будем сразу кластер, поэтому выделяем его в боковом меню инвентаря клиента vSphere и в верхней панели ищем выпадающий список действий «Menu», где нас интересует пункт «Lifecycle Manager»:
Если на него нажать и в верхнем меню правой рабочей области выбрать «Baselines», мы увидим список предустановленных путей апдейта:
Перед тем, как начать в нем работать, нам нужно загрузить скаченный предварительно образ новой версии гипервизора в секцию «Imported ISOs». Для этого кликаем на «Import ISO» ниже, и в появившемся окне нажимаем на кнопку «Browse», выбираем нужный образ и затем запускаем его загрузку по кнопке «IMPORT»:
Теперь нам нужно создать новый baseline с этим образом. Для этого в «Imported ISOs» ставим на нем флажок и нажимаем на «New Baseline» нашего меню действий:
Появится мини-визард, по пунктам которого пройдемся последовательно:
- «NameandDescription». Задаем имя нашего нового baseline и, опционально, его описание, флажок на «Upgrade», после чего жмем на «Next»;
- «SelectISO». Здесь автоматически подгрузится список с нашим предварительно импортированным образом, ставим на нем флажочек. «Next»:
- «Summary». Проверяем, все ли верно, и запускаем процесс создания нового baseline кнопкой «Finish»:
Теперь нам нужно прикрепить его к нашему кластеру, для чего возвращаемся в инвентарь и становимся на кластер, затем в верхнем меню жмем на «Updates», в боковом списке рабочей области ищем под «Hosts» «Baselines», а под информационными плитками – нужный блок действий и выпадающее меню «Attach», в котором нужно выбрать пункт «Attach Baseline or Baseline Group»:
В появившемся окошке ищем только что нами созданный baseline, отмечаем его галочкой и нажимаем кнопку «Attach»:
Теперь он появится в списке «Baselines». Здесь же, выбрав его галочкой в списке, жмем в плитке с «Check Compliance» на одноименное действие, чтобы проверить соответствие по всем нашим хостам кластера:
Далее, в плитке правее ищем действие «Pre-check Remediation» и жмем уже на него, чтобы проверить готовность к выполнению:
Появится окно с соответствующей информацией:
Далее, оставив свой выбор на нашем baseline, нажимаем кнопку действий «Remediate»:
Появится окно с лицензионным соглашением, где ставим галочку и кликаем на «OK»:
Затем в непосредственном окне настроек выполнения, проверяем, все ли подлежащие обновлению хосты отмечены галочкой в блоке «n hosts will remediate»:
Здесь ниже есть еще пара очень полезных и интересных блоков (раскрыть их содержимое можно, если нажать по ним на значок «>»). Например, можно задать выполнение не немедленно, а по расписанию, если поставить галочку в «Schedule this remediation to run later» и выбрать дату и время, назвать как-то нашу будущую задачу и опционально – привести ее описание. А еще ниже можно, при желании, поставить галочку в «Quick Boot», выключить «Check host health after update» (не рекомендовано, однако иногда полезно, если знаете, что хелс-чек не пройдет, а обновиться все равно надо, но потом все равно займетесь выявленными проблемами), выбрать «Ignore warnings about hardware errors» (снова-таки, не рекомендовано, но, если предполагаете, что с железом также все не идеально, можно поставить, а затем обязательно решить вопрос). И, наконец, можно запустить параллельное выполнение, если оно необходимо:
Запуск процесса идет по кнопке «Remediate»:
Все наши хосты кластера, по очереди, будут погружаться в режим техобслуживания и за прогрессом их обновления можно будет следить в задачах:
Со временем хост, над которым сейчас трудится vLCM, временно перестанет отвечать:
Это нормальный ход вещей, не надо пугаться, процесс все равно завершится.
Когда все хосты вернутся в свое обычное состояние, если по кластеру выберем наш baseline и запустим «Check Compliance», увидим вот такую картину:
Все хосты прошли успешно проверку на соответствие, и в «Summary» по каждому из них мы уже будем наблюдать новую, самую последнюю из доступных версий:
Интерактивное обновление хостов ESXi через внешний носитель
Если все этапы подготовки к интерактивному апгрейду через CD/DVD/USB пройдены успешно, проделываем следующее:
- Вставляем внешний носитель и перезагружаем машину;
- Устанавливаем в BIOS загружаться с внешнего устройства;
- В панели «Select a Disk» выбираем нужный привод (по отмеченному диску можно нажать F1 для получения информации);
- Запускаем процесс обновления, если инсталлятор нашел соответствующий файл и VMFS-датастор. Если существующее хранилище VMFS не может быть сохранено, выбирается установка с перезаписью существующего хранилища VMFS, либо же она отменяется, в принципе. Все произойдет, если нажать F11;
- По окончанию процесса, вынимаем инсталляционное внешнее устройство и нажимаем Enter для перезагрузки хоста;
- Меняем в настройках обратно загрузочное устройство на то, которое использовалось до установки внешнего носителя.
Обновление через скрипт
Запуск скрипта апгрейда производится вводом параметров загрузки в командной строке загрузки инсталлятора ESXi. При этом может потребоваться указать опции для доступа к файлу «kickstart», и с такой целью нужно нажать в загрузчике на Shift+O:
Если используется вариант с загрузкой PXE, параметры можно передать через строку «kernelopts» файла «boot.cfg» (о его синтаксисе и командах мы писали в разделе «Подготовка…» выше). Для указания местоположения скрипта служит параметр «ks=filepath», где «filepath» – это локация файла «kickstart». Поддерживаемые опции загрузки для инсталляции ESXi:
Опция загрузки Описание BOOTIF=hwtype-MAC address То же самое, что и опция «netdevice» (см. ниже), за исключением формата PXELINUX (за объяснениями обращайтесь на syslinux.org в SYSLINUX, опция «IPAPPEND») gateway=ip address Устанавливает сетевой шлюз как дефолтный для загрузки инсталляционного скрипта с устройств ip=ip address Устанавливает статический IP-адрес для загрузки инсталляционного скрипта с устройств. Для этой опции формат PXELINUX, в т. ч., поддерживается ks=cdrom:/path Путь к скрипту с инсталляцией на CD в приводе CD-ROM (подмонтируется и проверится в процессе нахождения файла) ks=file://path Путь к скрипту ks=protocol://serverpath Путь к скрипту в сети на данном URL. «protocol» – это «http», «https», «ftp», «nfs» ks=usb Путь к скрипту на USB (будет искать скрипт с именем «ks.cfg», должен быть расположен обязательно в корневой директории диска). Если присоединено множество USB, поиск будет осуществляться, пока не будет найден первый файл с таким именем. Поддерживаются только файловые системы FAT16/FAT32 ks=usb:/path Путь к скрипту на USB в указанном местоположении ksdevice=device Будет пытаться использовать сетевой адаптер «device» при поиске скрипта на устройстве. Указывается как МАС-адрес, либо имя vmnicNN. Если ничего не указать, инсталлятор отыщет первый подключенный сетевой адаптер и выйдет в сеть через него nameserver=ip address Указывает доменное имя сервера, используемого для загрузки инсталляционного скрипта netdevice=device Будет пытаться использовать сетевой адаптер «device» при поиске скрипта на устройстве. Указывается как МАС-адрес, либо имя vmnicNN. Если ничего не указать, инсталлятор отыщет первый подключенный сетевой адаптер и выйдет в сеть через него netmask=subnet mask Указывает маску подсети для сетевого интерфейса, который будет загружать инсталлятор vlanid=vlanid Настраивает сетевую карту для представления в качестве указанного VLAN Теперь в командной строке нужно задать:
ks=location of installation script plus boot command-line options
Примером ввода может служить такое:
ks=http://00.00.00.00/kickstart/ks-osdc-pdp101.cfg nameserver=00.00.0.0 ip=00.00.00.000 netmask=255.255.255.0 gateway=00.00.00.000
С помощью скриптов апгрейд ESXi можно осуществлять как через CD/DVD, так и через USB-привод или же через сетевую загрузку инсталлятора. В первом и втором случае нам нужно просто загрузить инсталлятор через привод и когда появится его окно, нужно тоже просто нажать на Shift+O (как это выглядит – см. предыдущий скриншот), чтобы отредактировать параметры загрузки, как было описано выше (параметр загрузки имеет формат «ks=»). И после всего нажать на Enter.
Альтернативно, рассмотрим процедуру сетевой загрузки инсталлятора для всех трех возможных вариантов:
- Нативный UEFI HTTP. Копируем файл «efi/boot/bootx64.efi» из образа инсталлятора в директорию на HTTP-сервере и переименовываем файл на «mboot.efi». Далее создаем директорию на HTTP-сервере с именем, повторяющим версию ESXi, содержащегося на нем, например: «http://www.example.com/esxi/ESXi-7.x.x-XXXXXX», и копируем содержимое образа инсталлятора в нее. Изменяем файл «boot.cfg», добавив строку с URL новосозданной директории: «prefix=http://www.example.com/esxi/ESXi-7.x.x-XXXXXX». Если в этом файле строки «kernel=» и «modules=» начинаются с «/», удаляем этот символ, а если в строке «kernelopt=» есть «cdromBoot», удаляем «cdromBoot». Добавляем опцию «kernelopt» в строку после команд ядра в файл «boot.cfg», чтобы указать локацию инсталляционного скрипта (пример – «kernelopt=ks=http://www.example.com/esxi_ksFiles/ks.cfg») и указываем, хотим ли, чтобы все хосты UEFI загружались с одного и того же инсталлятора (опции «Same installer» или «Different installers»).
- iPXE и HTTP. Для начала нам нужно получить и настроить iPXE, на его загрузочной странице слушаясь инструкций и запустив одну из команд:
- «make bin/undionly.kpxe» для ESXi-хостов со старым BIOS;
- «make bin-x86_64-efi/snponly.efi» для ESXi-хостов с UEFI;
И копируем файл «undionly.kpxe» или «snponly.efi» в директорию «/tftpboot» на TFTP-сервер. Если на хосте старый BIOS, достаем и настраиваем PXELINUX (получаем SYSLINUX 3.86, распаковываем и копируем файл «pxelinux.0» в директорию «/tftpboot» TFTP-сервера, создаем конфигурационный файл PXELINUX по такой модели кода:
APPEND -c ESXi-7.x.x-XXXXXX/boot.cfg
Важно! С синтаксисом конфигурационного файла PXELINUX поможет ресурс. В нем обязательно должны быть прописаны пути к файлам «mboot.c32» и «boot.cfg», а его имя может строиться по одной из трех схем: «01-mac_address_of_target_ESXi_host», «default» или IP-адрес целевого хоста в шестнадцатеричной системе исчисления. Сохранять его следует только на TFTP-сервере в «/tftpboot/pxelinux.cfg/».
Сохраняем его в директорию «/tftpboot/pxelinux.cfg» на TFTP-сервере). Если же UEFI, копируем файл «efi/boot/bootx64.efi» из образа инсталлятора в папку «/tftpboot» на TFTP-сервере и переименовываем файл на «mboot.efi». Создаем директорию на HTTP-сервере с таким же именем, что и содержащаяся на нем версия ESXi (например, «/var/www/html/ESXi-7.x.x-XXXXXX»), копируем контент образа инсталлятора в нее и редактируем файл «boot.cfg», добавив строку «prefix=http://XXX.XXX.XXX.XXX/ESXi-7.x.x-XXXXXX». Если в этом файле строки «kernel=» и «modules=» начинаются с «/», удаляем этот символ, а если в строке «kernelopt=» есть «cdromBoot», удаляем «cdromBoot». Добавляем опцию «kernelopt» в строку после команд ядра в файл «boot.cfg», чтобы указать локацию инсталляционного скрипта, используя модель кода: «kernelopt=ks=http://XXX.XXX.XXX.XXX/esxi_ksFiles/ks.cfg», где «XXX.XXX.XXX.XXX» – IP-адрес сервера, где находится инсталляционный скрипт, а «esxi_ksFiles» – директория, содержащая файл «ks.cfg», а также указываем, хотим ли, чтобы все UEFI-хосты грузились с одного и того же инсталлятора, или нет;
- PXE и TFTP. При старом BIOS повторяем сему получения и настройки PXELINUX (см. выше) и сохраняем его в директорию «/tftpboot/pxelinux.cfg» на TFTP-сервере. Если у нас UEFI, копируем файл «efi/boot/bootx64.efi» с образа инсталлятора ESXi в папку «/tftpboot» на TFTP-сервере и переименовываем его на «mboot.efi». Далее создаем поддиректорию на верхнем уровне директории «/tftpboot» (например, «/tftpboot/ESXi-7.x.x-xxxxx») и копируем контент образа инсталлятора ESXi в эту новую директорию. Модифицируем файл «boot.cfg», добавив строку «prefix=ESXi-7.x.x-xxxxxx». Если в этом файле строки «kernel=» и «modules=» начинаются с «/», удаляем этот символ, а если в строке «kernelopt=» есть «cdromBoot», удаляем «cdromBoot». Добавляем опцию «kernelopt» в строку после команд ядра в файл «boot.cfg», чтобы указать локацию инсталляционного скрипта, используя модель кода: «kernelopt=ks=http://XXX.XXX.XXX.XXX/esxi_ksFiles/ks.cfg», где «XXX.XXX.XXX» – IP-адрес сервера, где находится инсталляционный скрипт, а «esxi_ksFiles» – директория, содержащая файл «ks.cfg», а также указываем, хотим ли, чтобы все UEFI-хосты грузились с одного и того же инсталлятора, или нет.
Обновление ESXi-хостов через ESXCLI
Перед тем, как приступать непосредственно к процедуре апгрейда по этому методу, осуществляем необходимую подготовку согласно рекомендациям подраздела «Подготовка к обновлению с использованием ESXCLI» выше.
Если запустить команду «esxcli», и после этого сразу нажать на Ctrl+C, появится интерфейс командной строки. Далее следуем следующей процедуре:
- Проверяем, нуждается ли инсталлируемый VIB или профиль образа в погружении хоста в режим техобслуживания, либо же в перезагрузке по окончанию одной из команд, одна из которых служит для проверки VIB:
esxcli –server=<server_name> software sources vib get -v <absolute_path_to_vib>
другая – для проверки VIB на хранилище:
esxcli –server=<server_name> software sources vib get –depot=<depot_name>
и, наконец, третья – для проверки профиля образа в хранилище:
esxcli –server=<server_name> software sources profile get –depot=<depot_name>
Возврат будет представлен значениями параметров «Live-Install-Allowed» и «Live-Remove-Allowed», «false» по первому проинструктирует систему о том, что нужна перезагрузка после инсталляции, а «false» по второму – что нужна перезагрузка после удаления VIB;
- vLCM автоматически погружает хосты в режим maintenance, а вот при использовании команд esxcli это придется делать вручную. И вначале нам нужно проверить, не находится ли хост уже в этом режиме командой:
esxcli –server=<server_name> system maintenanceMode get
Если еще нет, выключаем ВМ, работающую на ESXi-хосте (список всех запущенных машин, если не знаете их ID, можно получить командой «esxcli –server=<server_name> vm process list»), одной из следующих команд. Если хотим выключить гостевую операционку, а затем выключить ВМ:
esxcli –server=<server_name> vm process kill –type soft –world-id <vm_ID>
Если хотим просто сразу выключить машину:
esxcli –server=<server_name> vm process kill –type hard –world-id <vm_ID>
Выключить силовым методом, не взирая ни на что:
esxcli –server=<server_name> vm process kill –type force –world-id <vm_ID>
Если не хочется выключать работающие ВМ, их можно смигрировать на другой хост.
После этого погружаем хост в режим техобслуживания командой:
esxcli –server=<server_name> system maintenanceMode set –enable true
И проверяем, нормально ли он туда ушел:
esxcli –server=<server_name> system maintenanceMode get
- Апдейтим хост с помощью VIB из хранилища софта, доступного по URL или из оффлайнового ZIP-хранилища, либо с помощью профилей образов, либо просто загрузкой zip-файла на хранилище.
Важно! Если апдейт ESXi-хоста производится zip bundle из хранилища, поддерживаемого VMware (доступ через сайт или загруженные локально – не важно), работать можно только через профили образов командой «esxcli software profile update –depot=<depot_location> –profile=<profile_name>».
-
- В первом случае вначале указываем целевой сервер (с помощью «–server=<server_name>»), после чего нас запросят ввести имя пользователя и пароль. Затем определяем, какие VIB уже проинсталлированы на хосте:
esxcli –server=<server_name> software vib list
Находим VIB, доступные в хранилище, если пользуемся URL, то командой:
esxcli –server=<server_name> software sources vib list –depot=http://<web_server>/<depot_name>
а если из локального хранилища zip-файлов:
esxcli –server=<server_name> software sources vib list –depot=<absolute_path_to_depot_zip_file>
Если нужно указать прокси-сервер, используем опцию «–proxy».
И устанавливаем новые VIB, либо же апдейтим уже установленные. Для апдейта из доступного по URL хранилища командой:
esxcli –server=<server_name> software vib update –depot=http://<web_server>/<depot_name>
для апдейта из локального хранилища zip-файлов:
esxcli –server=<server_name> software vib update –depot=<absolute_path_to_depot_ZIP_file>
и для инсталляции всех VIB из zip-файла на указанном оффлайн-хранилище (включая партнерские):
esxcli –server=<server_name> software vib install –depot <path_to_VMware_vib_ZIP_file>\<VMware_vib_ZIP_file> –depot <path_to_partner_vib_ZIP_file>\<partner_vib_ZIP_file>
Убеждаемся, что VIB успешно проинсталлировались на ESXi-хосте командой:
esxcli –server=<server_name> software vib list
-
- Если нужно поработать с профилями образов (результат команд приведет весь контент образа хоста в соответствие с результатом комплексного метода ISO-инсталлятора), указываем целевой сервер командой «–server=<server_name>», после чего на попросят ввести имя пользователя и пароль. Далее определяем, какие VIB уже проинсталлированы на хосте:
esxcli –server=<server_name> software vib list
и какие профили образов доступны на хранилище:
esxcli –server=<server_name> software sources profile list –depot=http://<web_server>/<depot_name>
Можно указать прокси-сервер, используя опцию «–proxy». Затем обновляем существующий профиль образа, чтобы включить VIB или проинсталлировать новые. Если нужно проапдейтить профиль образа из поддерживаемого VMware zip-пакета в хранилище, доступном через сайт или загруженном локально:
esxcli software profile update –depot=<depot_location> –profile=<profile_name>
(такие пакеты называются по типу «VMware-ESXi-<version_number>-<build_number>-depot.zip», а сам профиль может называться либо «ESXi-<version_number>-<build_number>-standard», либо «ESXi-<version_number>-<build_number>-notools», если без VMware Tools).
Если же это обновление профиля образа из доступно по URL хранилища:
esxcli –server=<server_name> software profile update –depot=http://<web_server>/<depot_name> –profile=<profile_name>
а из zip-файла на локальном хранилище целевого сервера:
esxcli –server=<server_name> software profile update –depot=file:///<path_to_profile_ZIP_file>/<profile_ZIP_file> –profile=<profile_name>
скопированного на датастор:
esxcli –server=<server_name> software profile update –depot=<datastore_name>/<profile_ZIP_file> –profile=<profile_name>
скопированного локально и примененного к целевому серверу:
esxcli –server=<server_name> software profile update –depot=/<root_dir>/<path_to_profile_ZIP_file>/<profile_ZIP_file> –profile=<profile_name>
А если нужно проинсталлировать все новые VIB в указанном профиле, доступном по URL:
esxcli –server=<server_name> software profile install –depot=http://<web_server>/<depot_name> –profile=<profile_name>
То же самое, но из zip-файла, хранимого локально на целевом сервере:
esxcli –server=<server_name> software profile install –depot=file:///<path_to_profile_ZIP_file>/<profile_ZIP_file> –profile=<profile_name>
Из zip-файла на целевом сервере, скопированного на датастор:
esxcli –server=<server_name> software profile install –depot=<datastore_name>/<profile_ZIP_file> –profile=<profile_name>
Все новые VIB из zip-файла, скопированного локально и примененного к целевому серверу:
esxcli –server=<server_name> software profile install –depot=/<root_dir>/<path_to_profile_ZIP_file>/<profile_ZIP_file> –profile=<profile_name>
И окончательно убедиться, что все нужные VIB установились на хосте:
esxcli –server=<server_name> software vib list
-
- При простой загрузке zip-файла на хранилище, инсталлируется он одной командой:
esxcli –server=<server_name> software vib update –depot=/<path_to_vib_ZIP>/<ZIP_file_name>.zip
Важно! Метод ESXCLI осуществляет предпроверку на наличие потенциальных проблем (недостаток памяти, неподдерживаемые устройства и т.д.) только для ESXi 6.7U1 и новее. Тогда как ISO-инсталлятор пре-чек делает всегда и по всему.
Важно! Если хост принадлежит к НА-кластеру и апдейт требует перезагрузки, вначале нужно удалить этот хост из кластера, либо же отключить на время НА, а потом только приступать к любому методу обновления.
Если профиль образа нужно подчистить от уже не актуальных VIB, проделываем вышеуказанные п. 1-2 и удаляем VIB командой: «esxcli –server=<server_name> software vib remove –vibname=<name>». Кстати, их можно удалять сразу комплексом, если в конце написать не просто имя, а «<vendor>:<name>» или «<vendor>:<name>:<version>» (с уточнением по версии), а также только определенные версии одного VIB: «<name>:<version>». Например, вот так:
esxcli –-server myEsxiHost software vib remove –vibname=PatchVendor:patch42:version3
По best practice, перед тем, как накатывать обновления на рабочие хосты, рекомендуется запускать, т. н. Dry Run. Это продемонстрирует, каковы будут результаты апгрейда, однако никаких изменений пока не произведется. Для этого существует опция «–dry-run» – ее просто нужно добавить в конце строки вводимой для инсталляции или апдейта команды, к примеру:
esxcli –server=<server_name> software vib update –dry-run
После этого просто оценивается вывод и, если все хорошо, хосты обновляются уже как положено.
Обновление через Auto Deploy
Чтобы перепредоставить хосты ESXi с помощью Auto Deploy нам нужно:
- Заходим в «Home» – «Auto Deploy» под правами администратора и на странице «Auto Deploy» выбираем из выпадающего меню вверху соответствующий vCenter Server;
- Кликаем на «Enable Auto Deploy and Image Builder». Если сервис уже активен, проходим на вкладку «Configure» и нажимаем на «Enable Auto Deploy Service»;
- На странице «Software Depot» настраиваем TFTP-сервер: заходим на вкладку «Configure» и нажимаем на «Download TFTP Boot Zip», чтобы загрузить конфигурационный файл TFTP, и распаковываем его в директорию, где хранятся файлы этого сервера. Опционально, если нужно использовать прокси-сервер, кликаем на «Add» в панели «Auto Deploy Runtime Summary» и вводим URL прокси-сервера в текстовом поле;
- Настраиваем DHCP-сервер, чтобы указывал на наш TFTP-сервер, вначале вписав IP-адрес TFTP-сервера в параметре 66 DHCP («next-server»), а затем имя файла загрузчика «efi.vmw-hardwired» (если UEFI) или «undionly.kpxe.vmw-hardwired» (если BIOS) в параметре 67 DHCP («boot-filename»);
- Указываем каждый хост, который хотим предоставить с помощью vSphere Auto Deploy, для сетевой загрузки или PXE-загрузки (опираясь на инструкции производителя);
- Опционально, если хотим настроить среду для использования режима Thumbprint, можно применять собственный СА, заместив OpenSSL-сертификат «rbd-ca.crt» и приватный ключ OpenSSL «rbd-ca.key» пользовательскими. Для справки, файлы находятся в «/etc/vmware-rbd/ssl/», и по дефолту vCenter Server использует VMCA.
Теперь после запуска хоста, он будет связываться с DHCP-сервером и перенаправляться на сервер Auto Deploy, предоставляющим хост с указанным профилем образа из активного набора правил. Далее, при желании, можно изменить дефолтные параметры конфигурации в «Auto Deploy Service» и в «Image Builder Service», определить правила, назначающие профиль образа и, опционально, профиль хоста, его расположение или пакет скрипта для хоста. Также, при необходимости, можно настроить первый предоставляемый хост как эталонный, используя настройки сети, хранения и другие, которые хотим, чтобы были одинаковыми для всех целевых хостов, задать авторазбивку для эталонного хоста, если нужно, чтобы Auto Deploy перезаписал существующие партиции, и все это применилось к другим хостам после соответствующего отражения в профиле хоста и т. д.
После всех соответствующих настроек перепредоставление хостов осуществляется: простой перезагрузкой/перезагрузкой отдельных хостов, в процессе которой пользователю задаются определенные вопросы/перепредоставлением с другим профилем образа/перепредоставлением с другим профилем хоста. В первом случае нужно просто погрузить хост в режим техобслуживания и перезагрузить его (если он – часть DRS-кластера, машины сами смигрируют на соответствующие хосты при погружении в maintenance, а если нет – придется самостоятельно мигрировать все ВМ на другие хосты и потом каждый хост погружать в режим техобслуживания).
Если же хочется перепредоставить хост с новым профилем образа, можно использовать сеанс PowerCLI, изменив правило для хоста и выполнив тест, после которого нужно будет предпринять операцию по исправлению соответствия. В случае, когда нужные VIB поддерживают live-апдейт, можно применить команду «esxcli software vib», но, до этого обязательно нужно обновить правило, установленное для этого профиля образа, чтобы оно включало новые VIB. Также при тестировании стоит помнить, что профиль образа можно применить к отдельному хосту, используя cmdlet «Apply-EsxImageProfile» и перезагрузив хост, чтобы изменения вступили в силу. Правда, при этом лишь проапдейтятся ассоциации между хостов и профилем образа, однако сами VIB не установятся. Если все это неинтересно, можно просто сделать следующее:
- В командной строке PowerShell запускаем cmdlet «Connect-VIServer» для подключения к системе vCenter Server, с которой зарегистрирован vSphere Auto Deploy:
Вернется предупреждение о сертификате. В производственной среде, важно сделать все, чтобы больше оно не возникало;
- Определяем местонахождение публичного хранилища софта с нужным нам профилем образа, либо же задаем пользовательский профиль образа с помощью «vSphere ESXi Image Builder»;
- Запускаем «Add-EsxSoftwareDepot», чтобы добавить это хранилище к сеансу PowerCLI. Если это удаленное хранилище, команда выглядит так:
А если zip-файл (предварительно нужно загрузить или создать подмонтированную локальную точку к машине PowerCLI), то так:
- Запускаем «Get-EsxImageProfile», чтобы вывести список профилей образов и решить, который будем использовать;
- Запускаем «Copy-DeployRule» и указываем параметр «ReplaceItem», чтобы изменить правило. В результате текущий профиль образа сменится новым:
Copy-DeployRule myrule -ReplaceItem my_new_imageprofile
где «my_new_imageprofile» – новый профиль, а «myrule» – правило, которое будет применять новый профиль образа к хостам (старая версия правила будет переименована и скрыта);
- Тестируем соответствие правила для каждого хоста, вначале проверив доступ к самому хосту:
Get-VMHost -Name ESXi_hostname
а затем запустив и сам тест:
$tr = Test-DeployRuleSetCompliance ESXi_hostname
Проверить разницу между содержимым набора правил и конфигурацией хоста можно командой «$tr.itemlist». Система вернет таблицу текущих и ожидаемых объектов, после чего нужно запустить исправление хоста, чтобы в следующий раз при первой загрузке хоста к нему применились эти правила:
- Окончательно перезагружаем хост с новым профилем образа.
Операции пост-апгрейда
По завершению обновления нашего хоста, чтобы убедиться в его успешности и полноценной работоспособности системы, следует скрупулезно пройтись по этим пунктам:
- Тестируем систему любым предпочитаемым методом (в первую очередь, правильное переподключение к управляющему vCenter Server – выбираем наш хост в инвентаре vCenter Server, кликаем по нему правой кнопкой мыши и в выпадающем меню выбираем «Connect»);
- Применяем лицензии хоста;
- При необходимости настраиваем сервер syslog для удаленного сбора логов, чтобы их файлам хватало места. Этот шаг просто жизненно необходим, если у вас весьма ограниченное пространство локального хранилища для хоста. Кстати, инструмент vSphere Syslog Collector включен как одна из служб, еще начиная с версии 6.0 vCenter Server.
Если обновление происходит в рамках одной мажорной версии (с 7.0, к примеру, на 7.0U2), замещать существующую лицензию не требуется. Однако, если ситуация, как в нашем примере – с версией 6.7, сделать это придется. В принципе, срочности в этой операции никакой нет – автоматически включается 60-дневный триал, на протяжении которого у нас явно появится время заполучить и применить новую лицензию под «семерку». Делается это элементарно: получаем лицензию от My VMware и используем функционал управления лицензиями в клиенте vSphere, либо же, в случае предпочтения методов скриптования апгрейда, ключ просто вписывается в файл «kickstart (ks)». Кстати, забыть о необходимости что-то сделать с лицензией vSphere Client нам попросту не даст – постоянно будет висеть весьма настойчивое предупреждение, в котором просто стоит нажать на кнопку «Manage your Licenses», чтобы инициировать процедуру замены:
После описанных обязательных акций пост-инсталляции, если нужно, можно проверить, как перенеслись все используемые сторонние пользовательские VIB (драйвера, агенты управления и т. д.), а также как произошла перенумерация устройств хоста sdX (при необходимости, обновляем все скрипты, ссылающиеся на устройства sdX). И, наконец, если есть необходимость, апгрейдим все ВМ на хосте, используя пошаговый визард клиента vSphere, либо же vLCM, а также с помощью последнего – версию VMware Tools.
В принципе, это все, о чем хотелось поговорить в отношении обновления гипервизора ESXi до версии 7.0U2. Если в процессе возникнут какие-то проблемы, изучайте логи апдейта, обращайтесь к нашему материалу по траблшутингу этого продукта «Возможные ошибки в VMware ESXi 7.0 Update 2», или же напрямую адресуйте свои вопросы в саппорт вендора, а также сертифицированным консультантам области. Последние два совета актуальны и в том случае, если хотите освоить какой-то экзотический функционал.