Почему увеличиваются диски виртуальных машин vmware vsphere?
 

Я задал размеры виртуальных дисков вирт.машин для windows серверов - 110 Gb и 40 Gb.
Сервера установились на эти диски, но почему-то диски выросли в размере и стали 126,11 Gb и 44,11Gb.

Т.е захватилось больше пространства, чем я планировал(а его и так мало)

Почему так получается?

Если 30 Gb задаю, то захватывается 32,11 Gb. Все время странная дробная часть 0,11.
Такое впечатление, что размер жесткого виртуального диска увеличивается на заданный размер оперативной памяти.

возможно, служебная информация? это внешний размер, при внутреннем заданном?

не пытайтесь пересказывать то, чего не понимаете

перепишите буква в букву то, что вас смущает и укажите (буква в букву) откуда берёте эти значения

и с какого перепуга это "Сетевые технологии"?

Одна программа считает 1 Гб = 1000 Мбайт, другая программа считает 1 Гб = 1024 Мбайт. Поэтому и получается разница.

Я тоже так подумал, но цыферки не совпали. Близко, но например 30 бинарных должно быть 32,21 десятичных с округлением.

Там могут быть нюансы в виде округления 1024*1024*1024 или 1024*1024*1000 или 1024*1000*1000. Смотря как считает конкретная реализация алгоритма.
И ещё вот.

А какие это тогда технологии по-вашему? Какой раздел?

Еще раз повторяю: я задал размеры дисков при создании вирт.машин в vmware 6.5 ровными: 30, 40, 110 Гб
А когда машины windows создались то они заняли больше пространства: 32.11, 44,11, 126,11 Гб
что показывается в списке вирт.машин в веб-клиенте и что следует из остатка свободного места на диске vmware.

Естественно такой феномен могут объяснить только те, кто работал с этой версией vmware.
Неужели никто не пользуется?
На округление из-за 1024 не тянет.
Исходя из объема ОЗУ каждой машины диск вроде увеличивается на объем ОЗУ почему-то плюс загадочные 0,11 во всех случаях.

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

неправда - теперь вы говорите другое просто не понимаете о чём говорите

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

Дисковое пространство на самом гипервизоре занято не только виртуальными дисками - там и конфиги, и логи. Да и сами файлы виртуальных дисков - это не голый дамп диска, а ещё и метаданные. Вы не можете создать диск совершенно произвольного размера, диск имеет геометрию - секторы, головки, цилиндры. Хотя они и виртуальны, их количество должно быть целым. Сама ФС у VMware заточена под хранение больших файлов, там размер блока от 1 до 8 мебибайтов. Т.е. даже самый крохотный файл занимает не меньше мебибиайта на диске. Короче, ВМ снаружи всегда больше, чем внутри. Впрочем, это обычно не проблема, т.к. для нормальной рабы у вас всегда должен быть запас дискового пространство. А если дисковая подсистема не совсем дохлая, то лучше выделять тонкие диски, а не толстые.

Диски создаются по-умолчанию thick provisioned lazily zeroed, т.е. "Все пространство такого диска выделяется в момент создания, при этом блоки не очищаются от данных, которые находились там ранее".
Если бы они были thin (тонкие), увеличивающиеся по мере работы, то я бы не спрашивал.

Еще Disk mode: Dependent, т.е. весь диск включается в снапшот, но это к размеру не относится.
Я снапшоты не делаю, и так мало места.

Это новые единицы - мебибайты?

Это, чтоб грохнулось в один день Х из-за переполнения?

Может расскажете, как создавать в vmware в вм секторы, головки, цилиндры, количество которых целое? :)

https://ru.wikipedia.org/wiki/%D0%94...%D0%BA%D0 %B8

В целом, зря злорадствуешь. Так обидно признать что чего-то не знаешь?

они и так создаются целыми, это ваши хотелки 30, 40, 110 Гб не всегда точь в точь соответствуют геометрии, поэтому диски получаются несколько больше

одно с другим связано очень косвенно и как следствие решается другими средствами
дисковое пространство может занимать RAM, снапшоты и другие файлы

большинство решений по резервному копированию ВМ базируются на снапшотах - бэкапы вы тоже не планируете делать?

добро пожаловать в будущее
этим "новым единицам" уже больше 20 лет

Это только для тех, кто жирует на йобибайтных пространствах или в лок сети vmware разворачивает и считает себя крутым.
Нормальные крутые люди работают в стесненных обстоятельствах на 500 Гб на слабом и-нете с десятком вм и выкручиваются.
Бэкапы я делаю самого эксклюзивного для восстановления.

Объяснение про блоки, логи, головки тут не катит, потому что прибавка составляет ровно ОЗУ(RAM) + 0,11 на разных вм.
Но как-то нигде я не встречал объяснения этому.

:laugh:

Как должна начинаться инструкция для русских: "Итак, у вас не получилось"
Например, цитата из kb1003755:
...и, видимо, не занимаются глупостями типа последовательного изучения документации

Отчасти для этого и предназначен thin provisioninig - внутри ВМ всё равно должно быть свободное пространство для нормальной работы ФС. И с десятка машин можно наскрести "пространство для манёвра", спокойно поочерёдно создавать снапшоты перед обновлениями, для резервного копирования и т.п. Но нормальные крутые люди не таковы - это будет слишком просто. Нужно специально создать себе сложность. ССЗБ.

RAM -> .vswp file creation, 0,11 - logs, can be adjusted.

LUN - это то, что показывается в Storage(Capacity-Provisioned-Free)?

LUN как таковой не показывается в Storage
но в статье подразумевается примерно это