Редактировать: Обновление 1 октября 2013 г. - Некоторые из моих первоначальных ответов с тех пор устарели.
Я не уверен, что вы все еще активны на этом сайте или что вы это увидите, но я хотел, чтобы вы знали, что я прочитал этот вопрос сегодня, и это меня очаровало, и поэтому я провел весь день (когда я должен был работал) изучал внутренности Hyper-V и Windows и даже копался в самих понятиях виртуализации в надежде, что я буду готов ответить на ваш вопрос.
Позвольте мне в предисловии сказать, что я рассматриваю Hyper-V как платформу виртуализации, потому что именно там у меня больше всего опыта. Несмотря на то, что, как мы знаем, могут существовать определенные принципы виртуализации, от которых нельзя отказаться, Microsoft, VMware и Xen имеют разные стратегии разработки своих гипервизоров.
Это первое, что делает ваш вопрос сложным. Вы задаете свой вопрос так, как будто он не зависит от гипервизора, хотя на самом деле это не так. Например, Amazon EC2 использует гипервизор Xen, а показатель «CPU Steal Time», который вы видите в выходных данных topкоманды, выпущенной из виртуальной машины Linux, работающей на этом гипервизоре, является результатом служб интеграции, установленных в этой гостевой ОС. (или инструменты с поддержкой виртуализации в гостевой системе) в сочетании с данными, предоставленными этим конкретным гипервизором.
Прежде всего, позвольте мне ответить прямо на ваш вопрос: нет никакой возможности увидеть изнутри виртуальной машины под управлением Windows, сколько времени процессоры, принадлежащие физической машине, на которой работает гипервизор, тратят на выполнение других задач, если только конкретные виртуальные инструменты / сервисы или инструменты виртуализации для вашего конкретного гипервизора устанавливаются в гостевой виртуальной машине иконкретный гипервизор, на котором работает гость, предоставляет эти данные гостю. Даже гость Windows, работающий на гипервизоре Hyper-V, не будет иметь немедленного доступа к информации о времени, которое физические процессоры на гипервизоре выполняли для других целей. (Процитируем voretaq7, то, что «разрушает четвертую стену».) Несмотря на то, что клиентские и серверные операционные системы Windows, работающие как виртуализированные гости в Hyper-V с правильными установленными службами / инструментами интеграции, используют «просветления» (которые буквально являются ядром изменения кода, сделанные специально для виртуальных машин), которые значительно увеличивают их производительность при использовании ресурсов физического хоста, суть в том, что гипервизор не имеетпредоставить гостевой ОС больше информации, чем она хочет. Это означает, что гипервизору не нужно сообщать гостевой виртуальной машине, что еще он делает, кроме обслуживания этой виртуальной машины ... если только он этого не хочет. И эта информация о том, что еще делают физические процессоры, необходима для получения метрики с точки зрения виртуальной машины, такой как «CPU Steal Time: процент времени, в течение которого vCPU ожидает физического CPU».
Как может гостевая ОС знать об этом, если она даже не осознает, что она фактически виртуализирована?
Другими словами, без правильных инструментов интеграции установленных на гостевой, гостевая операционная система не будет даже знать , что его процессор фактически v CPU. Он даже не будет знать, что существует другая сила, которая «кража» циклов ЦП вне его, поэтому такой метрики на гостевой ВМ не будет.
VMware начал предоставлять эти данные гостям Windows, а также ESXi 5.0. Инструменты интеграции VMware также необходимо обновить на гостевой. Вот ссылка ; они называют его «CPU Stolen Time».
Гипервизор, такой как Hyper-V, не предоставляет гостям прямой доступ к физическим ресурсам, таким как физические процессоры или процессорные ядра. Вместо этого гипервизор предоставляет им виртуальные устройства vDevs, такие как виртуальные ЦП.
Яркий пример того, почему: скажем, гостевая ОС виртуальной машины выполняет вызов для сброса TLB (буфера преобразования в сторону просмотра), который является физическим компонентом физического ЦП. Если бы гостевой ОС было разрешено очищать весь TLB на физическом процессоре, это отрицательно сказалось бы на производительности всех других виртуальных машин, которые также использовали этот же физический TLB. В случае Windows этот вызов в гостевой ОС преобразуется в вызов «hypercall» или «просветленный», который интерпретируется гипервизором, так что очищается только тот раздел TLB, который относится к этой виртуальной машине.
(Интересно, что это намекает мне на то, что гостевые виртуальные машины, которые не имеют надлежащих инструментов и / или служб интеграции, могут иметь возможность влиять на производительность всех других виртуальных машин на том же хосте, но это полностью выходит за рамки этого раздела .)
Все это говорит о том, что вы все еще можете обнаружить на хосте Hyper-V время, которое виртуальный процессор потратил на ожидание, пока реальный процессор станет доступным, чтобы его можно было запланировать для запуска. Но вы можете видеть эти данные только на гипервизоре Windows Hyper-V. Если это возможно увидеть в других гипервизорах, я настоятельно призываю других рассказать нам, как это увидеть в этом гипервизоре, а также, если он открыт для гостей. (Редактировать 01.10.2013 Спасибо evilensky за то, что вы сделали именно это!)
Моим тестовым компьютером был Hyper-V Server 2012, который является бесплатной версией Server 2012, на которой работают только Core и роль Hyper-V. Он практически такой же, как и любой Windows Server 2012 с Hyper-V.
Запустите Perfmon на своем родительском разделе, он же физический хост. Загрузите этот счетчик:
Hyper-V Hypervisor Virtual Processor\CPU Wait Time Per Dispatch\*
Вы заметите, что будет экземпляр этого счетчика для каждой виртуальной машины в этом гипервизоре, а также _Total. Microsoft определяет этот счетчик Perfmon:
Среднее время (в наносекундах), потраченное на ожидание отправки виртуального процессора на логический процессор.
Очевидно, вы хотите, чтобы это число было как можно ниже. Для компьютеров ожидание почти никогда не бывает полезным.
Другие счетчики производительности на гипервизор , который вы хотите исследовать это Hyper-V Hypervisor Root Virtual Processor\% Guest Run Time, % Hypervisor Run Timeи % Total Run Time. Эти счетчики предоставляют вам проценты, которые можно использовать для определения таких фактов, как, например, сколько времени «реальные» процессоры тратят на выполнение других операций, помимо обслуживания виртуальной машины или всех виртуальных машин.
Итак, в заключение, метрика, которую вы ищете в гостевой виртуальной машине, зависит от гипервизора, на котором она работает, от того, выбирает ли этот гипервизор данные о том, как он проводит свое время, кроме обслуживания этой виртуальной машины, и от того, является ли гость ОС имеет подходящие инструменты / службы / драйверы интеграции виртуализации, чтобы быть в курсе, чтобы гипервизор делал эти данные доступными.
Я не знаю ни одного гостя Windows, с установленными или нет инструментами интеграции, чтобы узнать, сколько времени (в секундах или процентах) хост VM провел на его обслуживании или не обслуживал его в соответствии с общим временем физического процессора. (Редактирование 01.10.2013: ESXi 5.0 или новее предоставляет эти данные гостевой виртуальной машине с помощью инструментов интеграции. Тем не менее, в Hyper-V все еще ничего.)
Xen paravirtualрежиме, который является паравиртуализированным доменом (т.е. не полная виртуализация, гостевая ОС модифицирована для работы на хосте), где доступно время кражи , по сравнению с Windows / FreeBSD. / ... запущенные гостиXen HVM, которые являются эмулированным аппаратным доменом (то есть гостевая ОС не модифицируется для запуска на хосте), где, по-видимому, это не так - поэтому определенный отрицательный ответ, думаю, это то, что имеет значение. Правильно ли я вас понял, что это может быть добавлено в конце концов?FWIW, я только что просмотрел счетчики Perfmon сервера Windows 2008r2, работающего под Hyper-V, и не увидел ничего, связанного со временем кражи (или вообще с виртуализацией).
источник