» VMware ESX Server и VMware Infrastructure

Fader

Цитата:

Если бы все было так просто я бы не спрашивал. Мне необходимо использовать именно исошку (нет физ. доступа к вирт. хосту), следовательно нужен x64-драйвер CD-привода.

Погоди, я чего-то не понимаю... А кто мешает положить исошку через то же WINSCP прямо на ESX а потом подмонтировать сдром как datastore file?

Serjevski

Не все так просто. Почитай еще раз внимательно 39-ую страницу чтобы понять смысл проблемы.

Alexey777555

Цитата:

Кстати, а как создать копию (не бэкап) вертуальной машины ?

Clone

ahel
Насколько мне известно функция "clone" доступна только через VMware Virtual Center. У меня этот пакет не стоит. Я сделал проще - скопировал образ диска виртуальной машины, а при создании новой указал его как исходный.

Коллеги, а никто не сталкивался с таким сообщением "EXT2-fs warning: maximal mount count reached, running e2fsck is recommended"?

Что с ним делать? На суппорте сказано что вроде как можно игнорировать если возникает во время работы, но не сотит игнорировать если возникает при загрузке... ссылка

Но может кто поподрорбней объяснит как от него избавиться?

to Serjevski


Цитата:

Коллеги, а никто не сталкивался с таким сообщением "EXT2-fs warning: maximal mount count reached, running e2fsck is recommended"?

Что с ним делать? На суппорте сказано что вроде как можно игнорировать если возникает во время работы, но не сотит игнорировать если возникает при загрузке... ссылка

Но может кто поподрорбней объяснит как от него избавиться?

Да, на это можно не обращать внимание, исправлено в версии ESX 3.0.2

можно еще здесь почитать
http://www.vmware.com/community/thread.jspa?threadID=52555&tstart=0

Народ а никто не подскажет как сделать так, чтобы при переносе с одного сервера на другой сохранялись слепки (snapshots) системы?? А то делаю их, а при переносе сохраняется только последняя версия ОС с последним снимком((

Здравствуйте! Проблема такая: При подключении к хосту выдает ошибку "Filed to configure management account" перед этим выдает предупреждение "The host is already being managet by IP address: 10.1.0.7". собственно случилось все после переноса центра с машины 10.1.0.7 на другую, я так понимаю где-то осталась ссылка на старый сервер центра управления VMWare. Старый сервер безнадежно потерян, удалить правильно не получится. Подскажите где удалить... Или как быть... Спасибо

2asnissa

а IP-адрес старого (безнадёжно потеренного) сервера в новый подставить не пробовал?

У меня 2 хоста и один был удачно удален и заного добавлен в новый центр... Так что если поменять iP то другой хост слетит, кроме того н аэтом сервере еще много чего крутится...

НАрод, подскажите плиз. ПРОблема следующего характера. Есть два VMware ESX servera 3.0.0. Один установлен на Dell друго на HP ProLiant. На Dell создаю виртуальную машину ( в данному случае Windows XP Pro) все работает отлично, единственное требуется активировать систему. Я делаю snapshot этой машины. И с помощью VMware Virtual Machine Importer перегоняю машину с одного сервера на другой, так как они в разных подсетях. Так вот, когда я включаю эту машину на ProLiantе но у меня выскакивает сообщение Changed BIOS UUID from номер UUID to новый номер UUID. И потом появляется окно:

If virtual machine has been copied? you should create a new UUID. If it has been moved you should keep its old identifier. If you are not sure create a new UUID. What do you want to do??
И далее предлагается 5 вариантов ответа: Create, Keep, Always create, always keep, cancel. Какой бы я вариант не выбирал получается один результат, меня просят активировать винду немедленно, в противном случае происходит log off. ПОдскажите что делать. Как сделать так, чтобы виртуальная машину не зависела от аппаратной платформы. Иначе вся прелесть терятся((((

vecialfor
я так понимаю, это проблема винды - она думает, что попала на другое железо и ведет себя соотв образом. В Workstation даже сообщение на эту тему мелькало в такой же ситуации(когда спрашивала, что делать с UUID виртуалки). А почему нельзя сделать так, чтобы винда активации не просила?

Michigun

хм. а вот интересно, что так сильно меняется в виртуальном железе при переносе между хостами? Технически ведь этого не должно быть: на то и виртуализация, чтобы железо было идентичным...

CPU, вроде, VM видит реальный [more]Assuming you are utilizing a processor that meets the requirements
of ESX server, your guest will see the same type of physical processor
that’s installed on the host. The VMkernel is capable of accepting
processor calls and handing it straight to the physical processors of
the host with limited virtualization overhead. By presenting the host
processor type to the guest, the VMkernel does not need to perform
any conversions to ensure compatibility between the physical and
hardware layer. This simply means that the processor is NOT
accessed through on emulation layer. And that if your host has an MP
or DP type processor then that’s what is presented to the guest.
It’s important to note that not all registers of the physical CPU are
presented by the VMkernel. While VMware is fairly tight-lipped
about these registers, one that is known for sure is processor serial
numbers. Applications that are licensed to a serial number of a
processor or group of processors will not function within VMware.[/more]

От CPU мелкомягкий алгоритм якобы не зависит. Более всего он зависит от сетевух. Якобы.

[гадая на кофейной гуще] Может быть, Importer удаляет виртуальные сетевухи, а потом добавляет новые? Может быть, алгоритм чувствителен и к перетыканию карточек в пустые слоты (с точки зрения гостевой оси это то же самое)?

Цитата:

И с помощью VMware Virtual Machine Importer перегоняю машину с одного сервера на другой, так как они в разных подсетях.

При переносе/копировании VM создается новый MAC-адрес у сетевухи. [more]...for every vNIC that gets created and assigned
to a virtual machine, a unique MAC address is created. This MAC
address gets stored in the VMX file for the virtual machine in which
it is created. VMware utilizes several mechanisms when verifying the
uniqueness of the MAC addresses that are assigned. The first, and
most obvious, mechanism is the use of unique 3 bytes
Organizationally Unique Identifiers (OUIs). These OUIs ensure a
VMware vNIC receives a MAC address that is completely unique
from any other network card vendor. VMware has the following
OUIs registered:
00:0c:29
00:50:56
00:05:69
Unless you have machines that have been upgraded from ESX 1.5,
there is a good chance that you will not see the 00:05:69 OUI in use
on any virtual machines.
The second mechanism for ensuring each vNIC receives a unique
MAC address is by utilizing the UUID of the virtual machine. Each
virtual machine has a unique UUID number that is based on several
factors. An algorithm is calculated against this UUID and the remaining
3 bytes of the MAC address are generated. Even when utilizing
this algorithm, VMware cannot guarantee the uniqueness of the MAC
address. To combat a MAC address conflict scenario, ESX performs
an integrity check and if a conflict is detected, a new MAC is generated.
ESX performs integrity checks until a unique MAC address is
generated. Once generated, the MAC address is written to the VMX
file of the virtual machine the vNIC is configured for and will not
change unless the path to the VMX file for the virtual machine
changes.[/more]

то есть виндовая активация привязывается к маку? Что ж, логичное предположение, и согласуется с имеющимися данными.

То есть, надо следить за сохранностью маков и всегда восстанавливать прежние при переносе подверженных дезактивации (С) виртуалок.

То есть, если заводишь такую систему в виртуалке - сразу фиксируй маки на случай переноса.

хм... а если перед переносом "запаковать" винду sysprep'ом ?

LevT

Цитата:

То есть, если заводишь такую систему в виртуалке - сразу фиксируй маки на случай переноса.

- а каким образом то фиксировать?

2 vecialfor

Все гораздо проще и сложнее =) одновременно. Вопрос при переносе не столько в маках... Даже у виртуальных устройств ESX есть вполне реальные серийные номера. Винда привязывается именно на серийники. Железо остается то-же самое но меняется его серийник, соответственно винда просит повторить активацию. Активацию можно вылечить раз и навсегда при помощи WPAkill или установив винду с корпоративным лицензированием (VLС). Чисто теоретически, можно заставить и ESX назначить устройствам одинаковые серийники, однако мне было проще поставить корпоративку или поюзать WPAkill.

P.S. одинаковые маки назначать искренне не советую, может выйти боком.

Michigun

Цитата:

А почему нельзя сделать так, чтобы винда активации не просила?

- сделать то можно, просто на то она и виртуализация, чтобы от аппаратуры не зависеть, вот и хотелось бы выяснить, что происходит)


Добавлено:
Shammer

Цитата:

WPAkill.

- я так понимаю это устройство убивает требование активации?


Добавлено:
Shammer


Цитата:

установив винду с корпоративным лицензированием (VLС).

- ее покупать надо или такой способ подойдет, который на форуме одном нашел
"А не проще VLK серийник ввести и юзать корпорейт версию?

Береш прожку Mskey4in1 - генерялка ключей (в и-нете найти не сложно)
Дальше RockXP или keyfinger - им меняешь ключ в установленной системе.
Вуаля, винды "лицензионные", ломать или активировать не надо. Винапдейт работает без проблем. "



Добавлено:
P.S. И еще один очень важный вопрос. Как сделать так, чтобы при переносе виртуальной машины с одного сервера на другой сохранялись ее snapshots??

Здравствуйте! Проблема такая: При подключении к хосту выдает ошибку "Filed to configure management account" перед этим выдает предупреждение "The host is already being managet by IP address: 10.1.0.7". собственно случилось все после переноса центра с машины 10.1.0.7 на другую, я так понимаю где-то осталась ссылка на старый сервер центра управления VMWare. Старый сервер безнадежно потерян, удалить правильно не получится. Подскажите где удалить... Или как быть... Спасибо

Цитата:

- сделать то можно, просто на то она и виртуализация, чтобы от аппаратуры не зависеть, вот и хотелось бы выяснить, что происходит)

Активации требует OEM-версия операцтонной системы, которая на ESX-сервере, если говорить о чистоте лицензирования, крутиться не должна по определению, т.к. привязывается к железяке.

Если, имея ОЕМ-лицензию, мы хотим запускать систему в виртуальной машине, то, во-первых, мы должны в течении 90 дней после приобретения ОЕМ-лицензии дополнительно приобрести Software Assurance (SA), и, во-вторых, запускать виртуальную машину на той же самой железяке. Т.е. всё равно, гонять виртуалку между различными железяками будет нельзя. НО, покупая SA вы получаете версию не требующую активации. Т.е. юридически запрещено, а фактически это делать можно. Причем, в данном случае правила лицензирования не обязывают вас ставить операционную систему на само железо. Другими словами связка OEM+SA может смело (с точки зрения чистоты лицензирования) запускаться в виртуальной машине и под линуксом. (Но, юридически гонять машины между разными железяками нельзя.)

Таким образом, происходит следующее, чтобы использовать технологию виртуализации с помощью ESX-сервера (т.е. чтобы от аппаратуры не зависеть), необходимо правильно выбрать модель лицензирования - корпоративную. И использовать корпоративные ключи.

CHIRT



Цитата:

Таким образом, происходит следующее, чтобы использовать технологию виртуализации с помощью ESX-сервера (т.е. чтобы от аппаратуры не зависеть), необходимо правильно выбрать модель лицензирования - корпоративную. И использовать корпоративные ключи.

- я так понимаю ее отдельно заказывать надо корпоративку то)



P.S. НАРОД ооочень надо, как сохранить snapshots при перегоне виртуальной машины с одного сервера на другой???Плиз подскажите)

2 vecialfor

Прислушайся к CHIRT он истину глаголит. =)


Цитата:

- я так понимаю это устройство убивает требование активации?

Примерно так. Только это программа =) широко известная в узких кругах.


Цитата:

- сделать то можно, просто на то она и виртуализация, чтобы от аппаратуры не зависеть, вот и хотелось бы выяснить, что происходит)

Она и не зависит от аппаратуры. Но у разных виртуальных хардов - разные серийники. Осознал ? =) ОЕМ и Retail версии винды не имеют явного права свободно перемещаться между разными компьютерами, пусть даже эти компьютеры с идентичным железом. Это право имеет только корпоративная версия (VLC).


2 asnissa

Извини за правду-матку но, ты просто "чудо у перьях".
Планирование, аккуратность, резервирование, проверка и осторожность - запиши эти замечательные слова и прежде чем чтото сделать, вспомни их.

Явной информации по твоей теме не нашел, но есть предположение: устанавливаешь центр снова на IP 10.1.0.7 , присоединяешь к нему хосты или еще чего шаманишь, потом выводишь хосты из управления этого центра как положено по инструкции и потом удаляешь центр с IP 10.1.0.7. Потом все будет нормально.

Или сноси ESX"ы нафиг, и инсталь их с нуля. Установка и базовое конфигурирование ESX"а у меня занимают 15 - 20 минут.

Добавлено:
2 Serjevski


Цитата:

Коллеги, а никто не сталкивался с таким сообщением "EXT2-fs warning: maximal mount count reached, running e2fsck is recommended"?

Я сталкивался и забил на него.


Цитата:

grace period VC -- 14 дней

Если я правильно понял эту цитату, то имеется в виду период работы сервера ESX, если не доступен сервер лицензий =)

Цитата:

Если я правильно понял эту цитату, то имеется в виду период работы сервера ESX, если не доступен сервер лицензий =)

Это так, но если севак с ESX работает в данный момент, если перезагрузишь, то вирьмашины не стартуют.

2Shammer


Цитата:

ОЕМ и Retail версии винды не имеют явного права свободно перемещаться между разными компьютерами, пусть даже эти компьютеры с идентичным железом. Это право имеет только корпоративная версия (VLC).

Уточню относительно операционных систем:

1. Retail - единственный вариант лицензирования, при котором перемещаться между компами можно (естественно при условии сноса сиситемы со старого компа).
2. OEM и корпоратив - перемещать систему между компами нельзя.
3. OEM - требует активации.
4. Retail и корпоратив - не требует активации.
5. OEM - установка только на новые компьютеры.
6. Retail и корпоратив - установка на любые компьютеры.

Сухой остаток:

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

Дальше:

Чтобы соблюсти чистоту лицензирования и при этом иметь возможность переносить виртуалки с одного ESX-сервера на другой необходимо приобрести SA для корпоратива, т.к. во-первых, SA можно переносить на другой комп, а, вторых для SA существует опция Windows Vista Enterprise Centralized Desktop for Software Assurance (VECD for SA).
[more]Windows Vista Enterprise Centralized Desktop for Software Assurance (VECD for SA)

Windows Vista Enterprise Centralized Desktop (VECD) for Software Assurance is an optional purchase available only to those customers who have Windows Software Assurance coverage. Eligible customers may acquire VECD for SA for any Windows desktop with active Software Assurance coverage. The VECD for SA subscription provides customers the right to run the latest version of the Windows desktop operating system made available during the term of their SA coverage .

Windows Vista Enterprise Centralized Desktop for Software Assurance is the version of Windows designed to help medium and large size organizations deploy Windows using virtualization technology in a network-centralized deployment architecture. Generally, customers may not move Windows Vista Enterprise Centralized Desktop from the licensed device to another device. However, if a customer reassigns Software Assurance coverage to a replacement device, as permitted under their license agreement, the right to use Vista Enterprise Centralized Desktop will apply to that new device. For details on when Software Assurance coverage may be reassigned to a replacement desktop, customers should refer to their license agreement.[/more]

Shammer
<i> Но у разных виртуальных хардов - разные серийники. Осознал ? =) </i>


Ты утверждаешь, что причина слета активации - именно смена серийников хардов при перемещении виртуалок между хостами?

LevT
Shammer
По моему, винда позволяет за раз изменение не более трех железок. А что она воспринимает за смену железок, и что из этого делается при переносе ВМ - вопрос открытый.
В смысле что именно - открытый, а то, что что то изменяется(те же маки например) это наверняка.

Цитата:

If virtual machine has been copied? you should create a new UUID. If it has been moved you should keep its old identifier. If you are not sure create a new UUID. What do you want to do??

Такая ситуация может возникнуть не только при перемещении между хостами с отличающимся железом. Буквально на днях у нас возникла таже ситуация при падении виртуальной машины в процессе миграции в пределах однотипного железа - оба хоста HP BL 35 p. Причем, виртуальная машина на SUSE 9.