На свете существует замечательный гипервизор ESXi от компании VMWare, и все в нем хорошо, но вот требования к “железу”, на котором он может работать, весьма нескромные. ESXi принципиально не поддерживает программные RAID’ы, 100-мегабитные и дешевые гигабитные сетевые карты, поэтому попробовать, каков он в работе, можно только закупившись соответствующим оборудованием.
Однако ESXi самые “вкусные” возможности ESXi открываются тогда, когда у нас есть не один, а несколько хостов ESXi — это кластеризация, живая миграция, распределенное хранилище VSAN, распределенный сетевой коммутатор и т.п. В этом случае затраты на тестовое оборудование уже могут составить приличную сумму. К счастью, ESXi поддерживает Nested Virtualization — то есть способность запускаться из-под уже работающего гипервизора. При этом и внешний гипервизор понимает, что его гостю нужен доступ к аппаратной виртуализации, и ESXi знает, что работает не на голом железе. Как правило, в качестве основного гипервизора также используется ESXi — такая конфигурация поддерживается VMWare уже довольно давно. Мы же попробуем запустить ESXi, использую гипервизор QEMU. В сети есть инструкции и на этот счет, но, как мы увидим ниже, они слегка устарели.

Для начала обозначим версию QEMU, на которой будем ставить эксперименты:

user@debian-pc:~$ QEMU emulator version 2.8.0(Debian 1:2.8+dfsg-2)
Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers

Последняя на данный момент версия, но у меня фокус получался даже на 2.4.0.
Затем отключим невежливое поведение модуля KVM в моменты, когда гость пытается читать машинно-специфические регистры, которых на самом деле нет. По-умолчанию, KVM в ответ на это генерирует внутри гостя исключение General protection fault, отчего гость ложится в синий (в нашем случае-розовый) экран смерти. Сделаем под рутом:

root@debian-pc:/> echo 1 > /sys/module/kvm/parameters/ignore_msrs

В некоторых дистрибутивах модуль kvm грузится по умолчанию с нужными параметрами, в некоторых — нет. В любом случае нужно проверить dmesg на наличие строк

user@debian-pc:~$ dmesg | grep kvm
[    6.266942] kvm: Nested Virtualization enabled                                                                                                
[    6.266947] kvm: Nested Paging enabled

Если этих строк нет — добавить в /etc/modprobe.d/kvm.conf строку

options kvm-amd npt=1 nested=1

и перезагрузиться. Для процессора Intel строка примет вид:

options kvm-intel ept=1 nested=1

Что интересно — сообщения о включенных Nested Paging/Nested Virtualization в dmesg подает только kvm-amd, а kvm-intel этого не делает.

Попробуем решить проблему “в лоб” — пойдем на сайт VMWare, зарегистрируемся там и скачем последний на данный момент образ VMware-VMvisor-Installer-201701001-4887370.x86_64.iso.

Не будем измудряться, создадим аналог “флешки” на 16Gb, возьмем наверняка поддерживаемую сетевую карту e1000, поставим RAM в 4 Gb (с меньшим количеством памяти ESXi гарантированно не встанет) и запустим установку, полагая, что в такой конфигурации ESXi как минимум не увидит IDE-диска:

user@debian-pc:~$ qemu-img create -f qcow2 -o nocow=on /media/storage/VMs/esx_6.5-1.qcow2 16G
Formatting '/media/storage/VMs/esx_6.5-1.qcow2', fmt=qcow2 size=17179869184 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 nocow=on

user@debian-pc:~$ qemu-system-x86_64 --enable-kvm -cpu host -smp 2 -m 4096 -hda /media/storage/VMs/esxi_6.5-1.qcow2 -cdrom /media/storage/iso/VMware-VMvisor-Installer-201701001-4887370.x86_64.iso -netdev user,id=hostnet0  -device e1000,netdev=hostnet0,id=net0

И тут нас ждет первая неожиданность — ESXi не только обнаруживает наш IDE-диск, но и успешно ставиться на него, правда, на пять минут подвисая на 27% установки:





Кстати, перед началом установки у меня появляется вот такое сообщение:



Ну, с процессором понятно — я использовал опцию -cpu host, которая копирует CPUID хостового процессора в гостя, а хостовой процессор у меня — AMD A8-3850 APU под почивший сокет FM1. Странно, что ESXi вообще ставится на такое железо.

А вот 8086:100e — это идентификатор чипа “Intel 82540EM Gigabit Ethernet Controller”, который с некоторых пор объявлен unsupported, т.е. он работает, но с ним не работает техническая поддержка.

Вообще, QEMU поддерживает эмуляцию разных сетевых карт:

user@debian-pc:~$ qemu-system-x86_64 -device help
<Тут неинтересно>
Network devices:
name "e1000", bus PCI, alias "e1000-82540em", desc "Intel Gigabit Ethernet"
name "e1000-82544gc", bus PCI, desc "Intel Gigabit Ethernet"
name "e1000-82545em", bus PCI, desc "Intel Gigabit Ethernet"
name "e1000e", bus PCI, desc "Intel 82574L GbE Controller"
name "i82550", bus PCI, desc "Intel i82550 Ethernet"
name "i82551", bus PCI, desc "Intel i82551 Ethernet"
name "i82557a", bus PCI, desc "Intel i82557A Ethernet"
name "i82557b", bus PCI, desc "Intel i82557B Ethernet"
name "i82557c", bus PCI, desc "Intel i82557C Ethernet"
name "i82558a", bus PCI, desc "Intel i82558A Ethernet"
name "i82558b", bus PCI, desc "Intel i82558B Ethernet"
name "i82559a", bus PCI, desc "Intel i82559A Ethernet"
name "i82559b", bus PCI, desc "Intel i82559B Ethernet"
name "i82559c", bus PCI, desc "Intel i82559C Ethernet"
name "i82559er", bus PCI, desc "Intel i82559ER Ethernet"
name "i82562", bus PCI, desc "Intel i82562 Ethernet"
name "i82801", bus PCI, desc "Intel i82801 Ethernet"
name "ne2k_isa", bus ISA
name "ne2k_pci", bus PCI
name "pcnet", bus PCI
name "rocker", bus PCI, desc "Rocker Switch"
name "rtl8139", bus PCI
name "usb-bt-dongle", bus usb-bus
name "usb-net", bus usb-bus
name "virtio-net-device", bus virtio-bus
name "virtio-net-pci", bus PCI, alias "virtio-net"
name "vmxnet3", bus PCI, desc "VMWare Paravirtualized Ethernet v3"
<Тут тоже не интересно>

но не все они работают в ESXi одинаково хорошо, например, с формально поддерживаемым e1000e не работает проброс портов в user-режиме сети, а у vmxnet3 пропадает половина пакетов. Так что остановимся на e1000.

Перезагружаем ВМ и видим, что гипервизор стартовал успешно. Собственно, и все — патчить QEMU для ESXi, как рекомендуют некоторые руководства, не нужно.

Нужно отметить, что я использую параметр nocow=on при создании диска, поскольку диск ВМ будет лежать на btrfs, которая сама по себе является ФС с концепцией copy-on-write. Если добавить к этому то, что и thin-provisioned диск формата qcow2 тоже реализует этот принцип, то получится кратное увеличение числа записей на диск. Параметр nocow=on заставляет qemu-img создавать файл с атрибутом nocow и тем самым блокировать механизм copy-on-write в btrfs для конкретного файла.

В режиме сети user внутри ВМ работает легковесный DHCP-сервер, поэтому адрес присваивать не нужно, однако придется пробрасывать порты. Заходим в консоль QEMU, нажав Ctrl+Alt+1, вводим там команду

> hostfwd_add tcp::4443-:443

и пробрасываем 443 порт с сетевого интерфейса виртуальной машины на 4443 порт хоста. Затем в браузере набираем

https://localhost:4443/ui

подтвердим исключение безопасности (ESXi, понятное дело, пока использует самоподписанный сертификат для https) и увидим Web-интерфейс гипервизора:



Удивительно, но установщик ESXi даже создал в свободной области диска “хранилище” размером целых 8Gb. Первый делом поставим пакет с обновленным Web-интерфейсом, потому что разработка этого полезнейшего компонента идет быстрее, чем выходят новые версии ESXi. Идем в консоль QEMU по Ctrl+Alt+1 и пробрасываем там 22 порт:

> hostfwd_add tcp::2222-:22

потом переключаемся в консоль гипервизора по Ctrl+Alt+2, нажимаем F2 — Troubleshooting Options — Enable SSH и подключаемся клиентом SSH:

user@debian-pc:~$ ssh root@127.0.0.1 -p 2222
Password: 
The time and date of this login have been sent to the system logs.

VMware offers supported, powerful system administration tools.  Please
see www.vmware.com/go/sysadmintools for details.

The ESXi Shell can be disabled by an administrative user. See the
vSphere Security documentation for more information.

Идем во временный каталог

[root@localhost:~] cd /tmp

Скачиваем обновление

[root@localhost:/tmp] wget http://download3.vmware.com/software/vmw-tools/esxui/esxui-offline-bundle-6.x-5214684.zip
Connecting to download3.vmware.com (172.227.88.162:80)
esxui-offline-bundle 100% |************************************************************************************|  3398k  0:00:00 ETA

и ставим его

[root@localhost:/tmp] esxcli software vib install -d /tmp/esxui-offline-bundle-6.x-5214684.zip  
Installation Result
  Message: Operation finished successfully.
  Reboot Required: false
  VIBs Installed: VMware_bootbank_esx-ui_1.17.0-5214684
  VIBs Removed: VMware_bootbank_esx-ui_1.8.0-4516221
  VIBs Skipped:

Как видно, размер Web-интерфейса — чуть больше трех мегабайт.

Теперь попробуем улучшить нашу виртуальную машину. Первым делом сменим контроллер дисков с IDE на AHCI, потому что реализация контроллера PIIX3 1996 года выпуска в QEMU, как бы это сказать, слегка тормознутая. А контроллер AHCI (эмулируется чипсет Intel ICH9) во-первых, быстрее, а, во вторых, поддерживает очереди команд NCQ.

user@debian-pc:~$  qemu-system-x86_64 --enable-kvm -cpu host -smp 2 -m 4096 -device ich9-ahci,id=ahci -drive file=/media/storage/VMs/esxi_6.5-1.qcow2,if=none,id=drive0 -device ide-drive,drive=drive0,bus=ahci.0 -netdev user,id=hostnet0 -device e1000,netdev=hostnet0,id=net0

Даже по уменьшению времени загрузки компонентов гипервизора видно, что прирост в скорости мы получили. На радостях заходим в Web-интерфейс и… как это нет дисков? На вкладке “Adapters” AHCI-контроллер имеется, однако диски на нем не определяются. А как же тогда загрузился гипервизор? Очень просто — на начальном этапе загрузчик считывает данные диска при помощи BIOS и видеть диски напрямую ему не нужно. После того, как компоненты загружены в память, загрузчик передает на них управление, а инициализация гипервизора проходит уже без обращений к диску.



Как бы то ни было, ESXi 6.5 дисков на AHCI-контроллере не видит, а вот ESXi 6.0 эти диски видел — зуб даю. С помощью Google и такой-то матери выясняем причину: в ESXi 6.5 старый драйвер ahci замене на полностью переписанный драйвер vmw_ahci, из-за чего у кучи народа тормозят SSD, а у нас не определятся диски. Согласно совету из статьи делаем на гипервизоре

[root@localhost:~] esxcli system module set --enabled=false --module=vmw_ahci

перезагружаемся и… ничего не происходит. А чего мы хотели? Дисков-то нет, записывать конфигурацию некуда, следовательно, наши изменения и не сохранились. Надо вернуться на IDE-диск, выполнить эту команду и уже потом загружаться с AHCI — тогда диски определяться.

Кстати, если мы зайдем в web-интерфейс, то увидим, что созданное установщиком 8-гигабайтное “хранилище” теперь недоступно. Так что для разных типов контроллеров VMWare имеет разные политики определения хранилищ. Теперь попробуем изобразить реальную конфигурацию системы, когда ESXi установлен на флеш-накопитель, подключенный по USB, а хранилище располагается на жестких дисках. Используем эмуляцию USB 3.0:

user@debian-pc:~$  qemu-system-x86_64 --enable-kvm -cpu host -smp 2 -m 4096 -device nec-usb-xhci,id=xhci -drive file=/media/storage/VMs/esxi_6.5-1.qcow2,if=none,id=drive0 -device usb-storage,drive=drive0,bus=xhci.0 -netdev user,id=hostnet0, -device e1000,netdev=hostnet0,id=net0

USB 3.0 диски тоже не определяются. Видимо, и здесь драйвер переписан. Ну что ж, мы уже знаем, что делать. Идем в консоль гипервизора, там пишем

 esxcli system module set -m=vmkusb -e=FALSE

Когда система загрузится, зайдем в Storage — Devices и увидим там нашу флешку. Кстати, с USB 3.0 контроллером nec-usb-xhci система загружается намного быстрее, чем с ich9-usb-ehci2.



Итак, минимум два драйвера контроллера диска в ESXi 6.5 переписаны заново по сравнению с ESXi 6.0. А казалось бы — только цифра после точки в номере версии изменилась, можно сказать, минорный релиз.

Если мы добавим к конфигурации виртуальной машины диск объемом 1 Tb, то сможем создать полноценное хранилище в дополнение к диску с гипервизором. Чтобы система грузилась с usb-диска, а не с ahci, воспользуемся параметром bootindex. Обычно для управления порядком загрузки применяют параметр -boot, но в нашем случае он не поможет, потому что диски “висят” на разных контроллерах. Заодно заменим платформу со старого чипсета 440fx на новый Q35/ICH9.

user@debian-pc:~$ qemu-img create -f qcow2 -o nocow=on /media/storage/VMs/esxi_6.5-1.qcow2 1T

user@debian-pc:~$ qemu-system-x86_64 -machine q35 --enable-kvm -cpu host -smp 2 -m 4096 -device nec-usb-xhci,id=xhci -drive file=/media/storage/VMs/esxi_6.5-1.qcow2,if=none,id=drive0 -device usb-storage,drive=drive0,bus=xhci.0,bootindex=1 -device ich9-ahci,id=ahci -drive file=/media/storage/VMs/esxi_6.5-1-1T.qcow2,if=none,id=drive1 -device ide-drive,drive=drive1,bus=ahci.0,bootindex=2  -netdev user,id=hostnet0  -device e1000,netdev=hostnet0,id=net0

Заходим в консоль — вот они, наши диски.



Продолжим эксперименты: теперь нам нужно объединить несколько гипервизоров в сеть. Какой-нибудь libvirt самостоятельно создает виртуальный коммутатор и подключает к нему машины, а мы попробуем провести эти операции вручную.

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

user@debian-pc:~$ sudo ip tuntap add mode tap tap0
user@debian-pc:~$ sudo ip tuntap add mode tap tap1

Теперь нам нужен виртуальный коммутатор. Долгое время для этих целей принято было использовать встроенный в ядро Linux виртуальный коммутатор, управляемый утилитой brctl. Сейчас же принято решать задачу через Open vSwitch — реализацию коммутатора, предназначенную именно для виртуальных сред. Open vSwitch имеет встроенную поддержку VLAN, протоколов туннелирования (GRE и т.п) для объединения нескольких коммутаторов и, что самое интересное — технологии OpenFlow. Иными словами, в коммутатор можно загружать правила фильтрации L2/L3 в удобочитаемом формате. Раньше для фильтрации требовалось использовать iptables/ebtables, а, как говориться, хорошую вещь “ebtables” не назовут.

Установим Open vSwitch, если он еще не стоит:

user@debian-pc:~$ sudo aptitude install openvswitch-switch

Создадим виртуальный коммутатор:

user@debian-pc:~$ sudo ovs-vsctl add-br ovs-bridge

Добавим в него интерфейсы:

user@debian-pc:~$ sudo sudo ovs-vsctl add-port ovs-bridge tap0
user@debian-pc:~$ sudo sudo ovs-vsctl add-port ovs-bridge tap1

Посмотрим, что получилось:

user@debian-pc:~$ sudo ovs-vsctl show
e4397bbd-0a73-4c0b-8007-12872cf132d9
   Bridge ovs-bridge
       Port "tap1"
           Interface "tap1"
       Port ovs-bridge
           Interface ovs-bridge
               type: internal
       Port "tap0"
           Interface "tap0"
   ovs_version: "2.6.2"

Запустим интерфейсы:

user@debian-pc:~$ sudo ip link set tap0 up
user@debian-pc:~$ sudo ip link set tap1 up
user@debian-pc:~$ sudo ip link set ovs-bridge up

Теперь присвоим интерфейсу коммутатора адрес:

user@debian-pc:~$ sudo ip addr add 192.168.101.1 dev ovs-bridge

Казалось бы, достаточно просто изменить тип сети в командной строке QEMU с user на tap, примерно так:

-netdev tap,ifname=tap,script=no,downscripot=no,id=hostnet0  -device e1000,netdev=hostnet0,id=net0

и все будет работать.

Попробуем:

user@debian-pc:~$ qemu-system-x86_64 -machine q35 --enable-kvm -cpu host -smp 2 -m 4096 -device nec-usb-xhci,id=xhci -drive file=/media/storage/VMs/esxi_6.5-1.qcow2,if=none,id=drive0 -device usb-storage,drive=drive0,bus=xhci.0,bootindex=1 -device ich9-ahci,id=ahci -drive file=/media/storage/VMs/esxi_6.5-1-1T.qcow2,if=none,id=drive1 -device ide-drive,drive=drive1,bus=ahci.0,bootindex=2  -netdev tap,ifname=tap0,script=no,downscript=no,id=hostnet0  -device e1000,netdev=hostnet0,id=net0

Зайдем в консоль ESXi и присвоим ему адрес — 192.168.101.2, а затем проверим связь:

user@debian-pc:~$ ping 192.168.101.2
PING 192.168.101.2 (192.168.101.2) 56(84) bytes of data.
64 bytes from 192.168.101.2: icmp_seq=1 ttl=64 time=0.582 ms
64 bytes from 192.168.101.2: icmp_seq=2 ttl=64 time=0.611 ms

….
и из консоли ESXi — F2- Test Network

Все работает, пинги ходят.

Сделаем копию диска esxi_6.5-1.qcow2 и запустим второй экземпляра ESXi:

user@debian-pc:~$ qemu-img create -f qcow2 -o nocow=on /media/storage/VMs/esxi_6.5-2.qcow2 16G           
Formatting '/media/storage/VMs/esxi_6.5-2.qcow2', fmt=qcow2 size=17179869184 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 nocow=on

user@debian-pc:~$ dd if=/media/storage/VMs/esxi_6.5-1.qcow2 of=/media/storage/VMs/esxi_6.5-2.qcow2 bs=16M
31+1 records in
31+1 records out
531759104 bytes (532 MB, 507 MiB) copied, 10.6647 s, 49.9 MB/s

user@debian-pc:~$ qemu-img create -f qcow2 -o nocow=on /media/storage/VMs/esxi_6.5-2-1T.qcow2 1T
Formatting '/media/storage/VMs/esxi_6.5-2-1T.qcow2', fmt=qcow2 size=1099511627776 encryption=off cluster_size=65536 lazy_refcounts=off refcount_bits=16 nocow=on

user@debian-pc:~$ qemu-system-x86_64 -machine q35 --enable-kvm -cpu host -smp 2 -m 4096 -device nec-usb-xhci,id=xhci -drive file=/media/storage/VMs/esxi_6.5-2.qcow2,if=none,id=drive0 -device usb-storage,drive=drive0,bus=xhci.0,bootindex=1 -device ich9-ahci,id=ahci -drive file=/media/storage/VMs/esxi_6.5-2-1T.qcow2,if=none,id=drive1 -device ide-drive,drive=drive1,bus=ahci.0,bootindex=2  -netdev tap,ifname=tap0,script=no,downscript=no,id=hostnet0  -device e1000,netdev=hostnet0,id=net0

Тут нас ждут неожиданности: ping от хоста к первому гостю ходит лишь до того момента, пока мы не запускаем пинг ко второму гостю. После прерывания второй команды ping пакеты к первому гостю начинают ходить секунд через 10. Пинги между гостями не ходят вообще.

Ясно, что мы напортачили с mac-адресами, и действительно, QEMU присваивает всем tap-адаптерам один и тот же mac-адрес, если не указано иное.

Выключим оба ESXi’а, укажем им уникальные mac’и и запустим снова.

user@debian-pc:~$ qemu-system-x86_64 -machine q35 --enable-kvm -cpu host -smp 2 -m 4096 -device nec-usb-xhci,id=xhci -drive file=/media/storage/VMs/esxi_6.5-1.qcow2,if=none,id=drive0 -device usb-storage,drive=drive0,bus=xhci.0,bootindex=1 -device ich9-ahci,id=ahci -drive file=/media/storage/VMs/esxi_6.5-1-1T.qcow2,if=none,id=drive1 -device ide-drive,drive=drive1,bus=ahci.0,bootindex=2  -netdev tap,ifname=tap0,script=no,downscript=no,id=hostnet0  -device e1000,netdev=hostnet0,id=net0,mac=DE:AD:BE:EF:16:B6

И в другой консоли:

user@debian-pc:~$ qemu-system-x86_64 -machine q35 --enable-kvm -cpu host -smp 2 -m 4096 -device nec-usb-xhci,id=xhci -drive file=/media/storage/VMs/esxi_6.5-2.qcow2,if=none,id=drive0 -device usb-storage,drive=drive0,bus=xhci.0,bootindex=1 -device ich9-ahci,id=ahci -drive file=/media/storage/VMs/esxi_6.5-2-1T.qcow2,if=none,id=drive1 -device ide-drive,drive=drive1,bus=ahci.0,bootindex=2  -netdev tap,ifname=tap0,script=no,downscript=no,id=hostnet0  -device e1000,netdev=hostnet0,id=net0,mac=DE:AD:BE:EF:C3:FD

К нашему громадному удивлению, проблема с пингами никуда не делась, мало того, команда arp показывает, что не изменились и MAC-адреса гипервизоров. Тут самое время вспомнить, как устроена сеть в ESXi: физическая сетевая карта переведена в “неразборчивый режим” и подключена в качестве одного из портов к виртуальному коммутатору. Другим портом к этому коммутатору подключен интерфейс vmkernel, который и является сетевой картой с точки зрения гипервизора. В момент установки ESXi аппаратный адрес физической сетевой карты клонируется в vmkernel, чтобы не смущать системного администратора. После этого его можно изменить только удалив интерфейс и создав его заново или же указав гипервизору, что следует переконфигурировать vmkernel из-за изменения адреса физической карты.

Первый способ:

Удаляем:

esxcfg-vmknic -d -p pgName

Создаем:

esxcfg-vmknic -a -i DHCP -p pgName

или

esxcfg-vmknic -a -i x.x.x.x -n 255.255.255.0 pgName

Второй способ:

esxcfg-advcfg -s 1 /Net/FollowHardwareMac

Существенная различие между указанными способами состоит в том, что первый не требует перезагрузки гипервизора, а второй — требует.

Выполнив эти нехитрые операции, мы получим в одной сети два гипервизора.

Теперь можно ставить vCenter и проверять”живую миграцию”. С некоторых пор vCenter доступен в виде образа виртуальной машины с Linux и соответствующими службами на борту. Именно такой вариант мы попробуем установить. Берем образ VMware-VCSA-all-6.5.0-5178943.iso, монтируем его в хостовой ОС, запускаем инсталлятор из каталога vcsc-ui-installer\lin64 и разворачиваем образ, следуя указаниям мастера. Для виртуальной машины потребуется 10 Gb оперативной памяти, так что на хостовой системе неплохо было бы иметь минимум 16 Gb. Впрочем, у меня образ развернулся и на 12 Gb RAM, съев всю доступную память и загнав систему в своп.



После установки VCSA заходим в Web-интерфейс с учетными данными вида administrator@mydomain.tlb и паролем, которые мы указали при настройке SSO. После этого добавляем в vCenter оба хоста и получаем простейший кластер, в котором работает живая миграция. Настроим vMotion на сетевых картах обоих хостов, создадим виртуальную машину TestVM и убедимся, что она может переезжать с одного хоста на другой, меняя как хост, так и хранилище.



Кстати, на предыдущих версиях ESXi до 6.0 включительно виртуальную машину невозможно было запустить в режиме вложенной виртуализации без добавления строки

vmx.allowNested = TRUE

в ее конфигурационный файл. В ESXi 6.5 этого делать не требуется, и виртуальная машина запускается без вопросов.

В заключение — небольшой лайфхак. Допустим, вам нужно скопировать файл диска ВМ из хранилища ESXi куда-нибудь на сервер резервных копий, при этом у вас нет возможности пользоваться FastSCP из состава Veeam Backup and Replication. Вам на помощь придет старый добрый rsync, нужно только найти бинарный файл, который запуститься на ESXi. К сожалению, в rsync вплоть до версии 3.0.9 включительно есть баг, из-за которого некорректно обрабатываются большие файлы на томах VMFS, поэтому стоит использовать rsync версии 3.1.0. и выше. Взять его можно здесь.