VMware thin disk je velký

Jozef · « **kdy:** 06. 11. 2014, 08:13:14 »

Ahoj,

mam vmware server esxi 5.5 a vytvoril som si novy virtualny disk, s tym ze je to "thin" disk a dal som mu velkost 900GB.
Moj problem spociva v tom, ze to naozaj je 900GB subor a to sa mi nepaci(musim to zalohovat a 900GB je vela). Ked som nasledne nakonfiguroval a spustil ghettoVCB tak to aj naozaj odzalohovalo 900GB. Prosim poradte mi niekto skuseny co sa s tym sa robit.

Dakujem a prajem prijemny den

Jozef

Reklama

Withy14 · « **Odpověď #1 kdy:** 06. 11. 2014, 09:25:35 »

Ahoj, nejjednodušší je vzít VMWare Convertion tool a překonvertovat, složitější je migrovat to v datastorech (musí být dva):

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2014832

Překonvertoval bych ti to, kdybys byl třeba z Brna (de to i v shellu, ale ty příkazy sou tak nestandardní, ýe to snad není ani dokumentované, možná jo).

Jozef · « **Odpověď #2 kdy:** 06. 11. 2014, 09:42:27 »

Comu ale naozaj nerozumiem, preco konvertovat thin disk, na thin disk? Je to neaka ficura, alebo bug?

Kazdopadne dakujem za napad, idem to skusit s tym vmware converter-om, a uvidime ...

Lol Phirae · « **Odpověď #3 kdy:** 06. 11. 2014, 09:47:39 »

Vůbec nerozumím problému. Ten disk je plnej? Jinaks asi nevytvořil thin disk.

P. · « **Odpověď #4 kdy:** 06. 11. 2014, 09:53:02 »

Mám za to, že ghettoVCB vyrobí i z thin disku thick zálohu...

Reklama

Jozef · « **Odpověď #5 kdy:** 06. 11. 2014, 09:59:54 »

Toto je vystup z "dryrun"

Citace

/vmfs/volumes/527d87d4-6bd1f2ef-a701-28802390c80c # /opt/ghettoVCB-master/ghettoVCB.sh -f /opt/ghettoVCB-master/vms_to_backup -d
dryrun
Logging output to "/tmp/ghettoVCB-2013-11-16_19-43-22-210625.log" ...
2013-11-16 19:43:22 -- info: ============================== ghettoVCB LOG START ==============================

2013-11-16 19:43:22 -- info: CONFIG - VERSION = 2013_26_11_2
2013-11-16 19:43:22 -- info: CONFIG - GHETTOVCB_PID = 210625
2013-11-16 19:43:22 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/nas
2013-11-16 19:43:22 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2013-11-16 19:43:22 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2013-11-16_19-43-22
2013-11-16 19:43:22 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2013-11-16 19:43:22 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2013-11-16 19:43:22 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2013-11-16 19:43:22 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2013-11-16 19:43:22 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2013-11-16 19:43:22 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2013-11-16 19:43:22 -- info: CONFIG - LOG_LEVEL = dryrun
2013-11-16 19:43:22 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2013-11-16_19-43-22-210625.log
2013-11-16 19:43:22 -- info: CONFIG - ENABLE_COMPRESSION = 0
2013-11-16 19:43:22 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2013-11-16 19:43:22 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2013-11-16 19:43:22 -- info: CONFIG - ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP = 0
2013-11-16 19:43:22 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2013-11-16 19:43:22 -- info: CONFIG - VM_SHUTDOWN_ORDER =
2013-11-16 19:43:22 -- info: CONFIG - VM_STARTUP_ORDER =
2013-11-16 19:43:22 -- info: CONFIG - RSYNC_LINK = 0
2013-11-16 19:43:22 -- info: CONFIG - EMAIL_LOG = 0
2013-11-16 19:43:22 -- info:
2013-11-16 19:43:23 -- dryrun: ###############################################
2013-11-16 19:43:23 -- dryrun: Virtual Machine: FSRV
2013-11-16 19:43:23 -- dryrun: VM_ID: 1
2013-11-16 19:43:23 -- dryrun: VMX_PATH: /vmfs/volumes/datastore1/FSRV/FSRV.vmx
2013-11-16 19:43:23 -- dryrun: VMX_DIR: /vmfs/volumes/datastore1/FSRV
2013-11-16 19:43:23 -- dryrun: VMX_CONF: FSRV/FSRV.vmx
2013-11-16 19:43:23 -- dryrun: VMFS_VOLUME: datastore1
2013-11-16 19:43:23 -- dryrun: VMDK(s):
2013-11-16 19:43:23 -- dryrun: FSRV.vmdk 900 GB
2013-11-16 19:43:23 -- dryrun: INDEPENDENT VMDK(s):
2013-11-16 19:43:23 -- dryrun: TOTAL_VM_SIZE_TO_BACKUP: 900 GB
2013-11-16 19:43:23 -- dryrun: ###############################################

2013-11-16 19:43:23 -- info: ###### Final status: OK, only a dryrun. ######

A toto je konkretna zaloha:

Citace

/vmfs/volumes/527d87d4-6bd1f2ef-a701-28802390c80c # /opt/ghettoVCB-master/ghettoVCB.sh -f /opt/ghettoVCB-master/vms_to_backup
Logging output to "/tmp/ghettoVCB-2013-11-16_19-51-30-212272.log" ...
2013-11-16 19:51:31 -- info: ============================== ghettoVCB LOG START ==============================

2013-11-16 19:51:31 -- info: CONFIG - VERSION = 2013_26_11_2
2013-11-16 19:51:31 -- info: CONFIG - GHETTOVCB_PID = 212272
2013-11-16 19:51:31 -- info: CONFIG - VM_BACKUP_VOLUME = /vmfs/volumes/nas
2013-11-16 19:51:31 -- info: CONFIG - VM_BACKUP_ROTATION_COUNT = 3
2013-11-16 19:51:31 -- info: CONFIG - VM_BACKUP_DIR_NAMING_CONVENTION = 2013-11-16_19-51-30
2013-11-16 19:51:31 -- info: CONFIG - DISK_BACKUP_FORMAT = thin
2013-11-16 19:51:31 -- info: CONFIG - POWER_VM_DOWN_BEFORE_BACKUP = 0
2013-11-16 19:51:31 -- info: CONFIG - ENABLE_HARD_POWER_OFF = 0
2013-11-16 19:51:31 -- info: CONFIG - ITER_TO_WAIT_SHUTDOWN = 3
2013-11-16 19:51:31 -- info: CONFIG - POWER_DOWN_TIMEOUT = 5
2013-11-16 19:51:31 -- info: CONFIG - SNAPSHOT_TIMEOUT = 15
2013-11-16 19:51:31 -- info: CONFIG - LOG_LEVEL = info
2013-11-16 19:51:31 -- info: CONFIG - BACKUP_LOG_OUTPUT = /tmp/ghettoVCB-2013-11-16_19-51-30-212272.log
2013-11-16 19:51:31 -- info: CONFIG - ENABLE_COMPRESSION = 0
2013-11-16 19:51:31 -- info: CONFIG - VM_SNAPSHOT_MEMORY = 0
2013-11-16 19:51:31 -- info: CONFIG - VM_SNAPSHOT_QUIESCE = 0
2013-11-16 19:51:31 -- info: CONFIG - ALLOW_VMS_WITH_SNAPSHOTS_TO_BE_BACKEDUP = 0
2013-11-16 19:51:31 -- info: CONFIG - VMDK_FILES_TO_BACKUP = all
2013-11-16 19:51:31 -- info: CONFIG - VM_SHUTDOWN_ORDER =
2013-11-16 19:51:31 -- info: CONFIG - VM_STARTUP_ORDER =
2013-11-16 19:51:31 -- info: CONFIG - RSYNC_LINK = 0
2013-11-16 19:51:31 -- info: CONFIG - EMAIL_LOG = 0
2013-11-16 19:51:31 -- info:
2013-11-16 19:51:34 -- info: Initiate backup for FSRV
2013-11-16 19:51:34 -- info: Creating Snapshot "ghettoVCB-snapshot-2013-11-16" for FSRV
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/datastore1/FSRV/FSRV.vmdk'...
Clone: 99% done.
2013-11-16 19:59:03 -- info: Removing snapshot from FSRV ...
2013-11-16 19:59:03 -- info: Backup Duration: 7.48 Minutes
2013-11-16 19:59:03 -- info: Successfully completed backup for FSRV!

2013-11-16 19:59:05 -- info: ###### Final status: All VMs backed up OK! ######

2013-11-16 19:59:05 -- info: ============================== ghettoVCB LOG END ================================

Vsimnite si prosim tento riadok:

Citace

Destination disk format: VMFS thin-provisioned

Myslim, ze toto je prave ten problem: ...

Citace: P. 06. 11. 2014, 09:53:02

Mám za to, že ghettoVCB vyrobí i z thin disku thick zálohu...

Lol Phirae · « **Odpověď #6 kdy:** 06. 11. 2014, 10:09:05 »

Ano. Takže nic nekonvertuj a najdi si zálohovací nástroj, který není rozbitý.

2X4B-523P · « **Odpověď #7 kdy:** 06. 11. 2014, 10:57:30 »

vygooglil jsem toto:

https://serverfault.com/questions/372526/move-vmware-esxi-vm-to-new-datastore-preserve-thin-provisioning

vmkfstools -i "/vmfs/volumes/source_datastore/Some VM/Some VM.vmdk" -d thin "/vmfs/volumes/destination_datastore/Some VM/Some VM.vmdk"

řekl bych, že nejlepší způsob, jak to zmenšit je komprese, alokovaná část, kde nejsou data by měla být vyplněna nulami... jinak thin s dynamickou alokací se vyhýbám, když dojde místo, tak rozšiřování souboru zpomaluje...

Withy14 · « **Odpověď #8 kdy:** 06. 11. 2014, 11:01:32 »

Na tom KB je tvorba thinu na thick a naopak. VMWare Converter je zadarmo a nevidím důvod, proč jej nepoužít, nehledě na to, že je na tyto operace přímo stavěný. Radit nějaký zálohovací nástroj, který stejně nemusí umět vytvořit vmdk (vhd..., nebo jiný formát, kterému VMWare rozumí) mi nepříjde jako vhodné řešení, navíc tak jako tak bude potřebovat prostor jak na tu thick, tak i na tu thin.

Lol Phirae · « **Odpověď #9 kdy:** 06. 11. 2014, 11:05:18 »

Citace: Withy14 06. 11. 2014, 11:01:32

Na tom KB je tvorba thinu na thick a naopak. VMWare Converter je zadarmo a nevidím důvod, proč jej nepoužít, nehledě na to, že je na tyto operace přímo stavěný.

Coooo? Nevím, jestlis pochopil problém?!? On chce zálohovat thin volume. Takže s tvým konvertorem pokaždé zbytečně zazálohuje 900GB, což bude trvat hodiny, a pak to "zkonvertuje"? Sorry, ale tohle je totálně na palici.

Jozef · « **Odpověď #10 kdy:** 06. 11. 2014, 13:38:37 »

Citace: 2X4B-523P 06. 11. 2014, 10:57:30

vygooglil jsem toto:

https://serverfault.com/questions/372526/move-vmware-esxi-vm-to-new-datastore-preserve-thin-provisioning

vmkfstools -i "/vmfs/volumes/source_datastore/Some VM/Some VM.vmdk" -d thin "/vmfs/volumes/destination_datastore/Some VM/Some VM.vmdk"

řekl bych, že nejlepší způsob, jak to zmenšit je komprese, alokovaná část, kde nejsou data by měla být vyplněna nulami... jinak thin s dynamickou alokací se vyhýbám, když dojde místo, tak rozšiřování souboru zpomaluje...

Dalsi zarazajuci poznatok:

Kód: [Vybrat]

/vmfs/volumes/527d87d4-6bd1f2ef-a701-28802390c80c # vmkfstools -i "/vmfs/volumes/datastore1/FSRV/FSRV.vmdk" -d thin "/vmfs/volum
Destination disk format: VMFS thin-provisioned
Cloning disk '/vmfs/volumes/datastore1/FSRV/FSRV.vmdk'...
Clone: 100% done.

Mi "vykuzlil" opat 900GB subor

Problem bude asi niekde inde...

Pajk · « **Odpověď #11 kdy:** 06. 11. 2014, 14:13:29 »

Pokud vím, tak na úrovni ls -l v "linux" shellu ESXi jsou všechny soubory vidět jako plná velikost, zrovna tak je taky ten shell a jeho cp,mv zpracovávají. Pouze vSphere client (a možná ty vmkfstools, ty nepoužívám) mi ukazuje velikost a používanou velikost a cut/paste z jednoho datastore do druhého v tom clientu kopíruje reálně použitou velikost, free nástroj pro zálohování s respektováním thin real used size neznám ... Just my 2cents

David1234 · « **Odpověď #12 kdy:** 06. 11. 2014, 16:44:05 »

Je na tom disku nějáký systém? Nevyplnil ho nulama?

2X4B-523P · « **Odpověď #13 kdy:** 06. 11. 2014, 20:21:30 »

Citace: Jozef 06. 11. 2014, 13:38:37

Citace: 2X4B-523P 06. 11. 2014, 10:57:30
vygooglil jsem toto:

https://serverfault.com/questions/372526/move-vmware-esxi-vm-to-new-datastore-preserve-thin-provisioning

vmkfstools -i "/vmfs/volumes/source_datastore/Some VM/Some VM.vmdk" -d thin "/vmfs/volumes/destination_datastore/Some VM/Some VM.vmdk"

řekl bych, že nejlepší způsob, jak to zmenšit je komprese, alokovaná část, kde nejsou data by měla být vyplněna nulami... jinak thin s dynamickou alokací se vyhýbám, když dojde místo, tak rozšiřování souboru zpomaluje...

Dalsi zarazajuci poznatok:
Kód: [Vybrat]
/vmfs/volumes/527d87d4-6bd1f2ef-a701-28802390c80c # vmkfstools -i "/vmfs/volumes/datastore1/FSRV/FSRV.vmdk" -d thin "/vmfs/volum Destination disk format: VMFS thin-provisioned Cloning disk '/vmfs/volumes/datastore1/FSRV/FSRV.vmdk'... Clone: 100% done.
Mi "vykuzlil" opat 900GB subor Problem bude asi niekde inde...

ano, pokud vytvořím dynamický thin, tak bude mít velikost podle toho, kolik obsahuje dat a půjde s ním jako s dynamickým pracovat... pokud si ale už na začátku vytvořím thin jednotku se statickou velikostí, ani nejlepší zálohovaci software mi z něj dynamický neudělá, neví kde jsou data...

Jozef · « **Odpověď #14 kdy:** 07. 11. 2014, 08:17:41 »

Nuz Pani, vitazom sa stava:

Citace: Pajk 06. 11. 2014, 14:13:29

Pokud vím, tak na úrovni ls -l v "linux" shellu ESXi jsou všechny soubory vidět jako plná velikost, zrovna tak je taky ten shell a jeho cp,mv zpracovávají. Pouze vSphere client (a možná ty vmkfstools, ty nepoužívám) mi ukazuje velikost a používanou velikost a cut/paste z jednoho datastore do druhého v tom clientu kopíruje reálně použitou velikost, free nástroj pro zálohování s respektováním thin real used size neznám ... Just my 2cents

Ano, skutocne mi ls -l v ESXi shell uvadza velkost 900GB:

Kód: [Vybrat]

~ # ls -lah /vmfs/volumes/nas/FSRV/FSRV-2013-11-17_19-57-09/
total 8980640
drwxr-xr-x    1 root     root        4.0K Nov  7  2014 .
drwxr-xr-x    1 root     root        4.0K Nov  7  2014 ..
-rw-------    1 root     root      900.0G Nov  7  2014 FSRV-flat.vmdk
-rw-------    1 root     root         518 Nov  7  2014 FSRV.vmdk
-rwxr-xr-x    1 root     root        2.7K Nov  7  2014 FSRV.vmx
-rw-r--r--    1 root     root          30 Nov  7  2014 STATUS.ok
~ #

A dokonca i nas:

Kód: [Vybrat]

[~] # ls -lah /share/Public/FSRV/FSRV-2013-11-17_19-57-09/
drwxr-xr-x    2 admin    administ      4.0k Nov  7 08:04 ./
drwxr-xr-x   12 admin    administ      4.0k Nov  7 07:54 ../
-rw-------    1 admin    administ    900.0G Nov  7 08:02 FSRV-flat.vmdk
-rw-------    1 admin    administ       518 Nov  7 08:02 FSRV.vmdk
-rwxr-xr-x    1 admin    administ      2.7k Nov  7 07:54 FSRV.vmx*
-rw-r--r--    1 admin    administ        30 Nov  7 08:04 STATUS.ok
[~] #

Lenze ked som sa nas*al a zaslo to az tak daleko, ze zo zufalstva som si povedal, tak nech to aspon vidim ako to "zhavaruje" a spustil som asi 10x zalohu, tak sa ku podivu nestalo nic

a veselo sa zalohuje dalej.
Takze to teraz vyzera tak ako keby na 4TB disk voslo 9TB i viac. Cize to v skutocnosti ma len tu velkost aku zaberaju obsadene data, skoda len, ze neviem ako zistit skutocny stav co je trochu frustrujuce, no dokazem s tym zit...

Cize ponaucenie znie:
"Neverte vsetkemu co vidite", alebo "To co vidis nemusi byt nutne to co se deje"

Ak by niekto mal vysvetlenie (akoze neake urcite existuje a ma to svoj dovod preco to tak je) velmi rad by som vedel ako to naozaj je.

Dakujem vsetkym, ktory sa zapojili do diskusie a prajem aj dnesny krasny den

Jozef

VMware thin disk je velký

Jozef

VMware thin disk je velký

Reklama

Withy14

Re:VMware thin disk je velký

Jozef

Re:VMware thin disk je velký

Lol Phirae

Re:VMware thin disk je velký

P.

Re:VMware thin disk je velký

Reklama

Jozef

Re:VMware thin disk je velký

Lol Phirae

Re:VMware thin disk je velký

2X4B-523P

Re:VMware thin disk je velký

Withy14

Re:VMware thin disk je velký

Lol Phirae

Re:VMware thin disk je velký

Jozef

Re:VMware thin disk je velký

Pajk

Re:VMware thin disk je velký

David1234

Re:VMware thin disk je velký

2X4B-523P

Re:VMware thin disk je velký

Jozef

Re:VMware thin disk je velký