По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Неисправности
Вы не можете запустить виртуальную машину и получаете сообщения об ошибках зависимости диска и отсутствии файла.
В случае отсутствия файлов вы видите такие ошибки, как:
Cannot open the disk '/vmfs/volumes/volume/vm/vm-000002.vmdk' or one of the snapshot disks it depends on.
Cannot open disk "/vmfs/volumes/volume/vm/vm-000002.vmdk": The parent virtual disk has been modified since the child was created (18).
В случае отсутствия файлов, в файле vmware.log виртуальной машины есть сообщения, похожие на:
vmx| DISKLIB-LINK : "myvm.vmdk" : failed to open (The system cannot find the file specified).
vmx| DISKLIB-CHAIN : "myvm.vmdk" : failed to open (The system cannot find the file specified).
В случае сбоя зависимости снимка диска, в файле vmware.log виртуальной машины не будет ошибки «Невозможно найти указанный файл» (cannot find the file specified), но Вы увидите сообщения о том, что родительский виртуальный диск был изменён:
Cannot open the disk '/vmfs/volumes/4a365b5d-eceda119-439b-000cfc0086f3/examplevm/examplevm-000002.vmdk' or one of the snapshot disks it depends on.
The parent virtual disk has been modified since the child was created.
Эти ошибки могут возникать, если дескриптор диска виртуальной машины (VMDK) или файл данных отсутствуют или цепочка снимков стала несовместимой.
Решение
Это решение разбито на 2 части, в зависимости от проблемы:
Вы не можете запустить виртуальную машину из-за ошибки system cannot find the file specified (Система не может найти указанный файл) или других ошибок, например - file not found(Файл не найден).
Вы не можете запустить виртуальную машину из-за того, что the parent virtual disk has been modified since the child was created (Родительский виртуальный диск был изменён с момента создания дочернего диска).
System cannot find the file specified
Вы должны убедиться, что файлы диска виртуальной машины представлены должным образом.
Для каждого диска, включая снимок диска, должен быть файл дескриптора в виде vmName.vmdk
Кроме того, для базового диска также должен существовать файл с расширением flat.vmdk или separse.vmdk в виде vmName-flat.vmdk или vmName-separse.vmdk.
Для снимка диска, должен быть файл с разрешением delta.vdmk или sesparse.vmdk в виде vmName-######-delta.vmdk или vmName-######-separse.vmdk.
Если файлы дескриптора отсутствуют, то Вам необходимо создать их заново.
Если файлы данных (-flat, -delta или –sparse) отсутствуют, возможно, потребуется восстановить виртуальную машину из резервной копии.
The parent virtual disk has been modified since the child was created
Эта проблема обычно возникает из-за несоответствия идентификатора содержимого (CID). Чтобы устранить несоответствие CID, необходимо отредактировать файлы дескрипторов VMDK, чтобы обеспечить согласованность цепочки снимков.
Дополнительная информация
Для дисков RDM не будет файла –flat или –sesparse для базового диска. Физический режим RDM будет иметь файл в виде vmName-rdmp.vmdk. Виртуальный режим RDM будет иметь файл в виде vmName-rdm.vmdk.
Если дескриптор RDMA отсутствует, его также можно создать заново.
Первая часть тут.
В конце 1980—х в мире сетевой инженерии появилась новая тема для обсуждения-асинхронный режим передачи данных (ATM). Потребность в более скоростных схемах в сочетании с медленным развитием в коммутации пакетов персонально на основе их адресов назначения привела к толчку к новому виду передачи, который, в конечном счете, реконфигурировал бы весь набор (или стек, потому что каждый протокол образует слой поверх протокола ниже, как «слоёный пирог») протоколов, используемых в современных сетях. ATM объединил размер ячейки (или пакета) с фиксированной длиной коммутации каналов с заголовком из коммутации пакетов (хотя и значительно упрощенным), чтобы произвести «промежуточное» технологическое решение. Было два ключевых момента для ATM: label switching и fixed call sizes; рисунок 1 иллюстрирует первый вариант.
На рис. 1 G отправляет пакет, предназначенный для H. При получении этого пакета A проверяет локальную таблицу и обнаруживает, что следующий переход к H — это C. Локальная таблица A также указывает метку, показанную как L, а не «просто» информацию о том, куда переслать пакет. A вставляет эту метку в специальное поле в начале пакета и пересылает ее в C. Когда C получает пакет, ему не нужно читать адрес назначения в заголовке, скорее, он просто читает метку, которая является коротким полем фиксированной длины. Метка просматривается в локальной таблице, которая сообщает C переадресовать трафик в D для назначения H. Метка очень мала и поэтому легко обрабатывается для устройств пересылки, что делает переключение намного быстрее.
В некотором смысле метка также может «содержать» информацию для обработки пакета. Например, если на самом деле существует два потока трафика между G и H, каждому из них может быть назначена своя метка (или набор меток) через сеть. Пакеты, несущие одну метку, могут иметь приоритет над пакетами, несущими другую метку, поэтому сетевым устройствам не нужно просматривать какие-либо поля в заголовке, чтобы определить, как обрабатывать конкретный пакет.
Это можно рассматривать как компромисс между коммутацией пакетов и коммутацией каналов. В то время как каждый пакет все еще пересылается hop by hop, виртуальный канал также может быть определен путем метки через сеть. Второй момент заключался в том, что ATM также был основан на ячейке фиксированного размера: каждый пакет был ограничен 53 октетами информации. Ячейки фиксированного размера могут показаться незначительной проблемой, но пакеты фиксированного размера могут иметь огромное значение для производительности. Рисунок 2 иллюстрирует некоторые факторы, связанные с фиксированными размерами ячеек.
На рисунке 2 пакет 1 (A1) копируется из сети в память на сетевой карте или интерфейсе LC1; затем он проходит через внутреннюю структуру внутри B (между ячейками памяти) к LC2, и, наконец, возвращается в сеть на исходящем интерфейсе B. На такой диаграмме это может показаться тривиальным, но, пожалуй, наиболее важным фактором скорости, с которой устройство может переключать / обрабатывать пакеты, является время, необходимое для копирования пакета по любым внутренним путям между ячейками памяти. Процесс копирования информации из одного места в памяти в другое является одной из самых медленных операций, которые может выполнять устройство, особенно на старых процессорах. Создание одинакового пакета (фиксированный размер ячейки) позволило оптимизировать код во время процесса копирования, что значительно увеличило скорость переключения.
Путь пакета 2 через B еще хуже с точки зрения производительности; сначала он копируется из сети в локальную память. Когда порт назначения определяется путем поиска в локальной таблице пересылки, код, обрабатывающий пакет, понимает, что пакет должен быть фрагментирован, чтобы соответствовать наибольшему размеру пакета, разрешенному на исходящем канале [B,C]. Карта входящей линии, LC1, фрагментирует пакет на A1 и A2, создавая второй заголовок и корректируя любые значения в заголовке по мере необходимости. Пакет делится на два пакета, А1 и А2. Эти два пакета копируются в двух операциях через матрицу на исходящую сетевую карту LC2. Используя ячейки фиксированного размера, ATM избегает затрат на производительность фрагментации пакетов (в то время, когда предлагалась ATM), понесенных почти любой другой системой коммутации пакетов.
ATM, на самом деле, не начинался в ядре сети и не прокладывал свой путь к краю сети. А почему бы и нет? Первый ответ заключается в довольно странном выборе размера ячейки. Почему 53 октета? Ответ прост-и, возможно, немного поразителен. АТМ должна была заменить не только сети с коммутацией пакетов, но и тогдашнее поколение голосовых сетей, основанных на технологиях коммутации каналов. Объединяя эти две технологии, провайдеры могли бы предлагать оба вида услуг на одном наборе схем и устройств.
Какой объем информации или размер пакета идеально подходит для передачи голосового трафика? Около 48 октетов. Какой объем информации или размер пакета является минимумом, который имеет какой-либо смысл для передачи данных? Около 64 октетов. Пятьдесят три октета были выбраны в качестве компромисса между этими двумя размерами; это не было бы идеально для передачи голоса, так как 5 октетов каждой ячейки, несущей голос, были бы потрачены впустую. Это не было бы идеально для трафика данных, потому что самый распространенный размер пакета, 64 октета, должен был бы быть разделен на две ячейки для переноса через сеть ATM. Общим мнением во время проведения этих обсуждений было то, что протоколы передачи данных могли бы адаптироваться к немного меньшему размеру ячейки, что делает 53 октета оптимальным размером для поддержки широкого спектра трафика. Протоколы передачи данных, однако, не изменились. Для переноса 64-октетного блока данных одна ячейка будет содержать 53 октета, а вторая - 9 октетов с 42 октетами свободного пространства. Провайдеры обнаружили 50% или более доступной пропускной способности на каналах ATM использовались пустые ячейки, что фактически приводило к потере пропускной способности. Следовательно, поставщики данных прекратили развертывание ATM, поставщики голосовой связи так и не начали его развертывание, и ATM умер.
Что интересно, так это то, как наследие таких проектов, как ATM, живет в других протоколах и идеях. Концепция переключения меток была подхвачена Yakov Rekhter и другими инженерами и превращена в переключение меток. Это сохраняет многие фундаментальные преимущества быстрого поиска ATM на пути пересылки и объединения метаданных об обработке пакетов в саму метку. Коммутация по меткам в конечном итоге стала Multiprotocol Label Switching (MPLS), которая не только обеспечивает более быстрый поиск, но также стеки меток и виртуализацию. Таким образом, была взята и расширена основная идея, которая существенно повлияла на современные сетевые протоколы и конструкции.
Вторым наследием ATM является фиксированный размер ячейки. В течение многих лет доминирующий сетевой транспортный пакет, основанный на TCP и IP, позволял сетевым устройствам фрагментировать пакеты при их пересылке. Однако это хорошо известный способ снижения производительности сети. Бит «не фрагментировать» был добавлен в заголовок IP, сообщая сетевым устройствам о необходимости отбрасывать пакеты, а не фрагментировать их, и были предприняты серьезные усилия для обнаружения самого большого пакета, который может передаваться по сети между любой парой устройств. Новое поколение IP, названное IPv6, удалило фрагментацию сетевыми устройствами из спецификации протокола.
Третья часть тут.
Мессенджеры с каждым днем все больше и больше интегрируются в нашу жизнь. Это невольно наводит на мысль о «бесшовной» интеграции мгновенных сообщений и бизнес инструментов. Размышляя на этот счет, под наш исследовательский порыв попал популярный в России мессенджер Telegram и CRM Битрикс24.
Нам захотелось присылать информацию о созданном лиде в Битриксе в групповой чат Telegram. Мы написали небольшой скрипт на .php и адаптировали его на Linux – машине. Что из этого получилось, спешим рассказать :)
Попробовать Битрикс24
Бот в Телеграме
Итак, первым делом создаем бота в Телеграме. В нашей базе уже есть пошаговый материал по созданию бота, поэтому, нажмите на кнопку ниже и пройдите по ссылке. Выполните все шаги, которые указаны в пункте «Создание бота в Telegram» - это займет примерно 5 минут. Как сделаете, переходим к следующему пункту.
Создание бота
Скрипт обработки
Все ли получилось на этапе ранее? У вас должен быть токен вида 331754110:AAHkMNalOz5I_Schh2kvj7ONhRcE8HuKV-c и ID (идентификатор) группового чата. Если все на месте, то вашему вниманию предлагается сам скрипт (комментарии по ходу скрипта после двойного слеша //):
<?php
$token = "Ваш_токен"; // тут вводим ваш токен;
$chat_id = "ID_чата"; // указываем идентификатор группового чата
$lead_name=$_GET['name']; //получает методом GET название лида, ответственного, источник и его идентификатор;
$lead_respons=$_GET['respons'];
$lead_source=$_GET['source'];
$lead_link=$_GET['link'];
$lead_link1 = "https://ваш_домен_битрикс.bitrix24.ru/crm/lead/show/$lead_link/"; // данную конструкцию мы используем для того, чтобы корректно сформировать и отправить ссылку на лида в Telegram;
#Оправляем в телеграм
$hello = "<b>Здравствуйте, коллеги!</b>"; // формируем элементы массива (сообщения), который будем отправлять в сторону Telegram – API;
$hello_1 = "";
$message = "В CRM Битрикс24 добавлен новый лид - ";
$repons = "Ответственный - ";
$src= "Источник - ";
$link = "Ссылка - ";
$arr = array( // формируем сам массив;
$hello => $hello_1,
$message => $lead_name,
$repons => $lead_respons,
$src => $lead_source,
$link => $lead_link1,
);
foreach($arr as $key => $value) {
if ($key == "Ссылка - ") { $txt .= "".$key." ".$value."%0A";} else {
$txt .= "".$key." ".$value."%0A";
}};
fopen("https://api.telegram.org/bot{$token}/sendMessage?chat_id={$chat_id}&parse_mode=html&text={$txt}","r"); // отправляем данные в сторону API Телеграма;
Скачать скрипт
После загрузки скрипта по ссылке, смените его расширение на .php
Подставляем свои данные, сохраняем скрипт как bitrixtelegram.php и закидываем его в WEB - директорию вашего сервера (сервера в вашей сети). На нашем сервере мы используем web – сервер Apache на базе CentOS – наша директория /var/www/html/.
Важно! Скрипт должен быть доступен по web из внешней сети (Битрикс24 будет обращаться к нему из бизнес – процесса). Мы рекомендуем использовать https, засекьюрить директорию, внутри которой будет находиться скрипт (например, дать ей имя v2I7TD9w3zo9QR7vg6ApNwDVvJOj9XbO61OJKdIyxI6d0. Тем самым, полный путь до директории будет /var/www/html/v2I7TD9w3zo9QR7vg6ApNwDVvJOj9XbO61OJKdIyxI6d0). Помимо этого, рекомендуем ограничить подключение к этой директории фильтрацией по IP (на уровне web – сервера и фаервола/маршрутизатора на уровне L3).
После этого, в консоли сервера, в случае Linux, даем команды (путь к файлу скрипта у вас может отличаться):
chmod 755 /var/www/html/v2I7TD9w3zo9QR7vg6ApNwDVvJOj9XbO61OJKdIyxI6d0/bitrixtelegram.php
dos2unix /var/www/html/v2I7TD9w3zo9QR7vg6ApNwDVvJOj9XbO61OJKdIyxI6d0/bitrixtelegram.php
Адаптация в бизнес – процесс в Битрикс24
Да – да, мы будем использовать вебхуки (Webhook). Это отличное средство, которое позволяет внедрять кастомные сценарии в обработку любой сущности в рамках Битрикс24. По факту, Битрикс просто будет кидать GET - запрос.
Переходим к настройке. Открываем CRM → Настройки → Автоматизация → Бизнес - процессы → Лид → Добавить шаблон:
Даем имя шаблону и указываем параметры запуска – «При добавлении». Внутри самого бизнес процесса, из правой палитры инструментов перетаскиваем элемент Webhook:
В настройка вебхука, в поле в хендлер копируем следующую конструкцию:
https://telegram.merionet.ru/ v2I7TD9w3zo9QR7vg6ApNwDVvJOj9XbO61OJKdIyxI6d0/ bitrixtelegram.php?name={=Document:TITLE}&respons={=Document:ASSIGNED_BY_PRINTABLE}&source={=Document:SOURCE_ID}&link={=Document:ID}
Где:
https://telegram.merionet.ru - хостовая часть, на которой расположился наш скрипт;
v2I7TD9w3zo9QR7vg6ApNwDVvJOj9XbO61OJKdIyxI6d0 - директория в корне web – сервера, в которой лежит скрипт;
bitrixtelegram.php - сам скрипт;
?name={=Document:TITLE}&respons={=Document:ASSIGNED_BY_PRINTABLE}&source={=Document:SOURCE_ID}&link={=Document:ID} - параметры, которые мы будем передавать в скрипт, а именно – имя лида, источник, ответственный и ID - лида;
Проверяем :) Вручную добавляем лид в CRM:
И вот что ждет нас в Telegram: