Сжатие диска qcow2

Если vm создавалась с диском 30 Гб, то даже если вы видите, что реально внутри vm файлы занимают 10 Гб, для хоста все равно диск vm будет занимать 30 Гб. А если изначально vm создавалась с диском 300 Гб, а потом реально там занято не более 50 Гб, то что, эффективно хранить 250 Гб пустоты? Проверим, реально ли (и насколько) оптимизировать размер диска QCOW2 виртуальной машины.

На всякий случай — мы не переразбиваем диск — если изначально диск создавался 30 Гб для vm, то внутри vm он так и останется 30 Гб!

Идея простая: забить неиспользованное место на диске изнутри vm (т.к. хост может некорректно понять, где внутри диска vm действительно занятое место, а где — пустота). А потом обнуленные области хост спокойно «отрежет». Это работает и с Windows, и с Linux.

Путь есть vm (Windows 7, один диск) с диском qcow2, 30 Гб:

# virt-install —network bridge:br0 —name vm1 —description=’Windows 7′ —ram=1024 —vcpus=1 —disk path=/vms/vm1.iso,size=30,format=qcow2,bus=virtio —graphics vnc,password=12345 —cdrom /data/vms-iso/Windows-7-64-prof-from-orig-dvd.iso —boot cdrom,hd,menu=on
# ls -l —block-size=M /vms
-rw——-. 1 qemu qemu 30725M Jun 28 16:32 vm1.iso

Реально занято 10 Гб (по проводнику в vm1).

В гостевой vm Windows запускаем утилиту SDelete (сайт MS):

# qemu-img convert -c -O qcow2 /vms/vm1.iso /vms/vm1-test-optimized.iso
# qemu-img convert -O qcow2 /vms/vm1.iso /vms/vm1-test-optimized-no-compressed.iso

# ls -l —block-size=M /vms
total 127913M
-rw——-. 1 root root 30725M Jun 28 16:42 vm1.iso
-rw-r—r—. 1 qemu qemu 4811M Jun 28 17:27 vm1-test-optimized.iso
-rw-r—r—. 1 root root 10345M Jun 28 17:26 vm1-test-optimized-no-compressed.iso

Сжатый (-c, compress) диск занял половину от реальной емкости vm, несжатый — 10 Гб, т.е. номинал.

ЗЫ: полагаю, что сжатый диск все же даст большую нагрузку на CPU/диску в дальнейшем, но насколько накладные расходы будут выше, сказать не могу. Если у вас есть сведения/мнения, очень welcome их выразить вслух.

Источник

Убрать неиспользованное место qcow2

Доброго времени суток!

Есть хост с квм и в нем виртуальная машина с Вин2К8Р2 в файле qcow2. Сам виртуальный диск Вин2К8Р2 на 150Г. Файл 75Г. Винда показывает, что занято порядка 40Г. Есть ли методы сжать именно файл до вот этих реально занятых 40Г при сохранении размера виртуального диска? У вмваре у меня получалась такая фигня.

Перегонка qcow2 -> raw и обратно ничего не дает.

Нужно чтобы ОС (венда в твоём случае) как-то обозначила неиспользуемые блоки на виртуальном диске. Ну или хотя бы занулила их. В линуксе для этого есть discard (смотри команду TRIM для SSD). Не помню точно с какой версии qemu это поддерживает, но поддержка точно есть.

В твоём случае я бы загрузил внутри виртуалки systemrescuecd (или какой-нибудь другой livecd, не суть важно) и прошёлся по файловым системам ntfswipe’ом. А затем просто qemu-img convert из qcow2 снова в qcow2, он должен нули автоматически убирать.

Ещё нагугливается вот такая штука: http://libguestfs.org/virt-sparsify.1.html, но я не пробовал.

а вот такая штука не пойдет?

если бы файл был бы raw-формата (а не qcow2) — то наверно помогло бы:

а вот файлы qcow2-формата — даж не знай что внутри них..

команда fstrim — не сработает на линуксе.

тримить придётся на гостевой (вирутальной) Виндовой машине както

а уже только потом делать на хостовом линуксе:

C virt-sparsify не поехало. Итоговый образ имеет тот же размер, что и начальный.

Очевидно действительно нужно как-то метить неиспользумое место в самой винде.

2k8r2 сама умеет ужимать диск (хреново, правда, но умеет). В оснастке диспетчера дисков щелкни по диску и выбери «Shrink».

В плане? Shrink сжимает раздел (том). Я говорю а файле с образом вирт.машины. Разделы в образе сжимать не надо. Файл с образом так и должен остаться динамически расширяемым.

C virt-sparsify не поехало. Итоговый образ имеет тот же размер, что и начальный.

А ты как именно смотрел? Если оно действительно «sparsify», то вывод ls не изменится.

метод с ntfswipe поехал. итог 36Г файл и он даже загрузился. Но очень долго. Не сильно промышленное решение, но зато работает.

qemu-img convert -c -O qcow2 source.qcow2 target.qcow2

-c indicates that target image must be compressed (qcow format only)

сами пробывали? в моем случае экономия 200М всего. На 75Г это вообще копейки. А обрабатывается наверное больше часа.

qemu-img convert умеет убирать нули. значит надо забить неиспользованное место нулями. в винде для этого есть sfill. в линуксе- dd if=/dev/zero. заполняем нулями файл вм пока не закончится место,стираем файл, вырубаем вм и делаем qemu-img convert

это понятно. но в этом методе нет преимуществ перед ntfswipe.

этот метод действует с 2007го года, когда я его первый раз попробовал, он надежен и не имеет багов

Источник

squashfs записать в qcow

Есть директория
Хочу сжать ее в squashfs и подключить этот образ к qemu
Т.е. образ должен быть в итоге squashfs.qcow или squashfs.raw.img,
без разделов толко с ro squashfs внутри,
чтобы монтировать так mount /dev/sdb

поделитесь однострочником
проблема я не знаю как превратить его в qcow, в raw img нет проблем вроде бы

Qemu-KVM, удалил образ ВМ, а он работает.

На тестовом стенде поднял ВМ, шлюз в Интернет (образ — inet-gw.qcow2). Проверяю на тестовых тачках, в инет ходят, всё работает как задумывалось.
Далее, настраиваю бэкапы системы, конфигов, логов и т.д. — проверяю, работает. Кидаю в крон.
Пакую образ

Нет образа!
Оставляю на неделю.
Сегодня проверяю, всё работает и бэкапы создаются, и внутри бэкапов логи растут.

Как сиё работает, физически образа нет же? %)

Sparse file qcow2 разный размер

Имеется несколько виртуальных дисков в формате qcow2, с максимальным размером в 100G. Понятно, что это спарс файлы, которые команда ls видит совершенно по идиотски, как если бы они в самом деле занимали 100G.

Эти чудесные команды показывают занимаемый на самом деле размер 4G.

Проблема в следующем. Я копирую файл, который как бы 100G, по факту 4G, на другой физический диск, где свободного места 20G и …*опа. Файловые менеджеры, например double-commander показывают, что на диске осталось 0 места. Это ну охренеть как неудобно!

Теперь, если я делаю клон диска qcow2, то получаю диск, который команда ls -l видит как 4G, а qemu-img видит и как 4G и как 100G. Очень хороший диск и отображается он так как надо.

Какого хрена происходит? Что именно я не знаю? Как сделать, чтобы ls показывала истинный размер файла? Почему клоны отображаются нормально? Очень неудобно создавать диск виртуалки, а потом делать его клон лишь для того, чтобы с ним работать по человечески. Можно как-то изменить какие-то его атрибуты?

Слепить блочное устройство с маппингом файлов в партиции.

Что-то типа такого:

ЧЯДНТ при бекапе CentOS 7?

У меня на /dev/sda2 стоит на XFS CentOS 7 в дуалбуте к основному Debian 9. Решил снять бекап:

Но размер бекапа почему-то сильно больше того, что я ожидал:

При этом, как я помню, там была виртуалка, которой как раз был выделен диск в 12G, но он динамический же:

Или причина в чём-то другом?

В чём я вообще ошибся?

osimg.ru — автоматически собираемые образы Linux

Настроил автоматическую еженедельную сборку виртуалок последних версий дистрибутивов:

• Arch Linux
• CentOS 7
• Debian 9
• Ubuntu 18.04

Во всех самых распространенных форматах:

• QEMU Qcow2
• VirtualBox VDI
• Hyper-V VHDX
• VMware VMDK

Удобно для тестирования софта, установщиков, скриптов.
В отличии от https://www.osboxes.org/ — образы минималистичные, без графики.
Плюс прямые ссылки и раздача через CDN на хороших скоростях. Можно скачивать утилитами curl/wget.

Интересно ваше мнение: какие ОС добавить, каких пакетов не хватает, настроек? Может найдете ошибки или обнаружите что что-то не работает.

Какой тип образа лучше использовать в ВМ Proxmox?

Всем доброго времени суток.

Раньше никогда не задумывался, но всегда наступает время когда ты углубляешься в документацию потому что в этот раз тебя никуда не торопят. Имеется небольшой кластер Proxmox (6 нод) и появилось время и желание развернуть Zabbix мониторинг.

И что-то я уперся в то какой тип образов мне лучше использовать для данной задачи. Почитал про qcow2, raw и в голове всё перемешалось.

Как я понимаю плюсы в использовании qcow2 это возможность создания снапшотов, что удобно при начальной настройке. Но, пишут, что нецелесообразно использовать для БД. А она будет нужна. Т.е. по идее можно поставить ОС на .qcow2, а диск для БД прикрутить отдельно и сделать его .raw. Или все эти извращения не стоят ничего и можно использовать то, с чем привык работать?

2 диска в одной виртуалке на qemu-kvm

Приветствую!
Был виндовый сервер с двумя HDD. В системе виделись как C: и D:. С обоих сделаны образы server_c.qcow2 и server_d.qcow2.
А вот как теперь их соединить в одну, что бы в одной виртуалке виделись так же как C: и D: ?

Как извлечь образ диска из снапшота .vma в proxmox через командную строку?

Добрый день! Есть ряд снапшотов из которых нужно вытащить qcow2 образ, но не могу понять как.

распаковываю снапшот с помощью vma extract и получаю .raw образ

форматирую его с помощью qemu-img в qcow2, получаю неполноценный образ qcow2, к которому видимо нужно дорастить размер, как у оригинального образа, вот тут собственно и затык, как это сделать?

qmrestore выполняет все ровно, но он не подходит, потому как подразумевается создание виртуальной машины с конфигурацией и прочим хламом, а мне необходимо получить только оригинальный образ qcow2, который запихан в .vma. Спасибо.

Проблема с разрежёнными файлами .qcow2 для KVM в Debian 9

Всем привет. Подскажите как решить проблему — на свеже установленную Debian 9 был установлен Whonix под виртуалку KVM, по этой инструкции https://www.whonix.org/wiki/KVM/Installation_Screenshots Но появилась проблема ввиде разрежённых файлов .qcow2, которые после распаковки весят 100ГБ каждый (хотя по факту 2-3ГБ) После переноса их в /var/lib/libvirt/images , если перезапустьтить основную ОС, то вместо окна ввода пароля юзера вылазит ошибка Xsession: warning: unable to write to /tmp: Xsession may exit with an error

Если эти .qcow2 удалить, то проблема исчезает. Да и сама виртуалка виснет во время загрузки, скорей всего из-за нехватки места на винте.

Даже не знаю что может быть не так, по мануалу всё установилось без проблем. В чем может быть проблема?

Внезапно упал диск qcow2

Сегодня чуть не поседел.

На KVM стоит win2003x86Ю, на нем sql2000. Работал вроде нормально (неделю). Сегодня утром во время загрузки в sql базы 1с, виртуалка тупо упала. При попытке перезапустить ругалась на поврежденный qcow2 образ системного диска. К счастью восстановился диск через qemu-img check -r all.

Но какая причина этому? Образ лежит на sas ssd raid1 в виде файла. Режим кэширования none.

kpartx и qcow2

Пытаюсь просмотреть тома в диске ВМ, но получаю:

Proxmox to ESXi

Есть бэкап виртуалкки с убунтой из proxmox в vma.gz .
Нужно его портировать в esxi.
Виртуальный диск был в qcow2.
Это реально ?

Оживление XFS на qcow2 образе.

Всем здрасьте. Есть Debian сервер с софтовым RAID1. На этом сервере крутилась виртуалочка (qemu-kvm) с qcow2 образом подключенным как virtio.

Месяцев этак 3-4 назад один из жестких из рейда приказал долго жить, md его пометил как fault, и все бы ничего, но за происходяшим никто не следил, и примерно с пару месяцев назад сбоить начал и оставшийся жестак из рейда (для него smart вроде еще более менее, но в kern.log постоянно unrecoverable IO error сыпятся).

Кульминацией стало то, что система внутри виртуалки сказала «С ФС какой-то холищит, я ее отрублю, сделайте с ней что-нибудь а потом пробуйте подключить обратно». Оной ФС является XFS (виртуалка развертывалась из iso файла выданного одной конторой, внутри тот же Debian x64 с XFS home разделом, в котором был расположен целевой софт со всеми своими приблудами).

Намедни это все всплыло, виртуалка была потушена, мертвый жестак из рейда заменен и рейд засинкан с тем что еще живо (опять же при синхронизации жесткий-источник ругался, как черт, вышеупомянутыми IO error’ами, так что данные походу битые в итоге).

Ну и собственно пробовал вчера вечером извлечь хоть какую-то информацию из образа (qcow2) виртуалки. Ничего не вышло:

Подключал с помощью qemu-nbd разделы из образа к /dev/nbd*, etx4 на / монтируется норм. А вот XFS на /home не монтируется говорит:

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

Отдаю себе отчет, что скорее всего все скажут «Ага не делаете бэкапы — страдайте падлы», но может есть у кого мыслишки что еще можно попробовать сделать перед тем, как окончательно махнуть шашкой.

Чем сейчас модно делать бэкап хранилища ВМ в KVM?

Всем по привету).
Чем пользуетесь при создании резервных копий qcow2 хранилища в системе виртуализации KVM? Чтобы VM’s останавливать не нужно было и делать всё на «горячую».
Пока такого решения не нашёл, кроме как Remus. Может есть что то лучше?

Как починить qcow2 диск?

Добрый день. Гипервизор PROXMOX. Была виртуальная машина с Windows Server 2003. После перезагрузки windows не грузиться пишет «boot failed not a bootable disk» Формат диска qcow2. Подскажите как вытащить инфу или починить?

qcow2 vs raw

Есть хостовая машина(Centos 7) на ней есть пару виртуальных машин, основная задача виртуальных машин это резервное копирование.

Когда делается полный бекап на одной из виртуальных машин, дисковая подсистема на хостовой машине нагружается на 92%.

Формат дисков на виртуальной машине raw

На хостовой системе Soft Raid mdadm level 5 (4 disk)

Если я переведу с raw в qcow2 есть шанс что нагрузка на дисковую подсистему немного снизится?

Почему qcow2 образ такой большой ?

На диске 200 гиг лежит 2 образа по 150 гиг. Как такое возможно ? При этом mc показывает свободных еще 50 гигов, а thunar показывает 0 байт.

Все это очень печально, потому что я не могу узнать реальный размер образов. А мне надо сделать бекап одного из них. По ssh FARом забирал, на приемном диске не хватило места, хотя там только одна винда установлена.

qcow2 верхом на zvol для kvm без кеша.

По мотивам данной темы — zol , не всё так хорошо. (комментарий) решил поизвращаться и накатить виртуалку (kvm) на формат qcow2, который в свою очередь будет натянут поверх тома zvol, чтобы иметь двухуровневую возможность снятия снапшотов виртуалки (снапшоты на уровне qcow и на уровне zfs).

создаем зеркальный пул:

создаем блочное устройство под виртуалку (том zvol):

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

далее ставлю виртуалку:

все удачно установилось. смотрю сколько виртуалка отожрала у массива:

запускаю virt-manager и вижу странность, он показывает, что под виртуалку отдан диск формата qcow2 размером 10G, хотя под qcow давалось лишь часть в 8G, fdisk в самой виртуалке показывает честные 8G, почему это так? и еще насоветуйте GUI для создания снапшотов виртуалок посредством qcow2, как я понимаю в моем virt-manager (версия 0.9.1) такой возможности нет?

Вопрос по созданию шаблона виртуальной машины в qcow2

Никак не могу понять методологию работы с шаблонами виртуальных машины qcow2 в KVM

Пару вопросов:
1)Допустим, есть у меня некий дистрибутив в формате qcow2 размером 200mb , я хочу его постоянно допоить под разные цели. Совсем не ясно, как задавать желаемый размер диска , если для одной инсталляции он 50GB а для другой это 200GB.

2)Каким образом создать шаблон со своей настроенной определенным образом ОС в формате qcow2, чтобы его размер был самым минимальным, а не 50Gb или 100Gb

3)Как тогда работают всякие ”облачные” хостинги, которые явно раскатывают тебе ОС из шаблона весом не 100GB..

Источник