Your Mission Critical Applications Deserve Real Backup Validation!

accident disaster steam locomotive train wreck

Photo by Pixabay on

Every organisation knows how important data protection is. However still most of the organisations never test their backups. Why? Because it is complex issue. However if you do not test how do you know that you can really survive from disasters?

Modern Approach for Data Protection

First step for Data Protection is of course thinking it in modern ways. Even that most of the restores from backups are still individual files and/or folders your organisation has to prepare for bigger disasters. What if half of your 500 VM production environment is hit by ransomware attack? How do you really survive from these types of disasters? Restore times with so called legacy backups might take days, even weeks. Can your business survive without access to these VMs for weeks, propably not.

Data protection depends upon timely backups, fast global search, and rapid recovery. Cohesity DataProtect reduces your recovery point objectives to minutes. Unique SnapTree technology eliminates chain-based backups and delivers instantaneous application or file-level recovery, with a full catalog of always-ready snapshots even at full capacity. With this approach it can dramatically reduce recovery time.

However even modern data protection is not enough if you don’t know that you really have something to recover to. Most of the modern technologies handle file system level data integrity but still there is no way to really know that your backups are fully recoverable without testing them.

From Data Protection to Recovery Testing

Typically organisations approach recovery testing with either just recovering single (or multiple) virtual machines. This of course makes sure that you can recover individual VMs but it doesnt ensure that you can recover something that is truly working. Some backup vendors implement recovery testing, but still it is mostly just VMs or some basic uptime testing.

Other way to do this is manually restore application setups and do manual testing. This is very costly because it requires lot’s of manual work, and also introduces several risks. However it enables your organisation to really test application workflows with proper testing. Do you really get answer from your 3-layer web application, can you get answers to your DB queries etc. What if you could take this method of running complex testing but without any need for manual labour?

Automating Recovery Testing

Because modern hypervisor platforms are API driven it is pretty easy to automate things on VM level. When you add API driven data protection platform, like Cohesity, you can automate full recovery testing with very complex testing. This is a issue I hear from most of my Service Provider customers – but also from bigger enterprise customers. How to automate complex recovery testing? Lets see….

Cohesity Backup Validation Toolkit

To make things simpler, you can download Cohesity Backup Validation toolkit from here and with minimal scripting knowledge it is easy to automate validation process.

After downloading it is time to create some config-files. Lets start with environment.json -file. This file contains connection information for both Cohesity, and VMware vSphere environments. Create file with content:

        "cohesityCred": "./cohesity_cred.xml",
        "vmwareServer": "",
        "vmwareResourcePool": "Resources",
        "vmwareCred": "./vmware_cred.xml"

After this we need to create actual config.json -file containing information about each virtual machine we are about to test.

This file also defines tests per VM so it is very easy to define multiple tests but only use selected per VM. Script also enables you to attach VM to needed test network, and change IP address to different for testing purpose so you don’t need to test with overlapping production IPs, or create siloed networking for VMware.

Note that VMs don’t need to be protected with same protection job making this more scalable since propably you have different job for web frontends and actual backend databases.

    "virtualMachines": [
            "name": "Win2012",
            "guestOS": "Windows",
            "backupJobName": "VM_Job",
            "guestCred": "./guestvm_cred.xml",
            "VmNamePrefix": "0210-",
            "testIp": "",
            "testNetwork": "VM Network",
            "testSubnet": "24",
            "testGateway": "",
            "tasks": ["Ping","getWindowsServicesStatus"]
            "name": "mysql",
            "guestOS": "Linux",
            "linuxNetDev": "eth0",
            "backupJobName": "VM_Job",
            "guestCred": "./guestvm_cred_linux.xml",
            "VmNamePrefix": "0310-",
            "testIp": "",
            "testNetwork": "VM Network",
            "testSubnet": "24",
            "testGateway": "",
            "tasks": ["Ping","MySQLStatus"]

And then final step is to create actual credential files. To prevent having usernames and password in configuration files in plaintext format we can use  simple powershell script to create these. You can have one shared credential file for all VMs, or you can have one per VM. Note that these users must have administrator level access to VMs to change IP network to test network.

To create credential files you can use included createCredentials.ps1 script which will create only one guestvm_cred.xml file but if you want to create more you can just simply run simple powershell command:

Get-Credential | Export-Clixml -Path guestvm_more.xml

Since this file is encrypted it can be only accessed with same user who created file, so make sure that you create credential files with same user you are using for running testing scripts.

So How Does it Work?

Here is an example run to clone two virtual machines (one Linux and one Windows) and run different set of tests on each VM.

First script gets configuration files and connects to Cohesity cluster and VMware vSphere vCenter environments. Then it will start clone process for VMs



and after clone process is done it will move to actual validation phase where we will first check that clone task is in success state and actual VMware VM’s are powered on with VMware Tools running in VMs cloned.


When VMs are up and VMware Tools are running we will run test per VM to ensure that we can push scripts trough VMware Tools. Next task is to move VMware VM to correct VM Network and then change IP configuration for each VM.


After moving VMs to correct network we will run tests for each VM


and after running tests we will clean clones automatically from Cohesity and VMware environment



This automation toolkit is not officially provided by Cohesity. Any bugs can be reported to me directly. There are some limitations with this toolkit:

You can use it only for VMware environments running vCenter

You can run tests only against Linux and Windows virtual machines and Windows machines need to have PowerShell installed.

Hope that this simple toolkit helps you to automate your organisations backup validations!

VMware vCenter plugin for IBM’s XIV/SVC/Storwize v7000

IBM released version 2.5.1 of  it’s Storage Management Console for VMware vCenter while ago. Installation is quite simple and after this adding new vdisks for VMware infrastructure is quite easy. New version supports XIV, SVC and Storwize V7000 as per the versions on the following table:

Product Firmware version
IBM XIV® Storage System 10.1.0 to 10.2.4x
IBM Storwize® V7000 6.1 and 6.2
IBM System Storage® SAN Volume Controller (SVC) 5.1, 6.1 and 6.2

Direct download link for software is here.

Installation needs to be done to vCenter Windows-machine. Currently vSphere 5 is not supported, but hopefully it will be soon. Installation asks few questions about userid’s etc.

After installation you need to restart your vSphere Client and check that IBM’s plugin is enabled

After installation you need to connect plugin to your storage, in my example I will connect it to Storwize v7000. Click “Add”  to start storage system adding wizard.

Select brand of storage you are connecting. If you want to add multiple brands or multiple storages you need to add them one by one.

Next wizard asks connection settings for storage. Enter ip-address or hostname of storage, username and select private key which you have connected to selected user. If your key uses passphrase enter it also.

Note that keys need to be in openssh-format. If you created your keys with putty key generator you need to convert your key to correct one. First import key you have created and then export key in OpenSSH-format.

Last step is to select mdisk-groups you want to access from plugin. Note that v7000 gives mdisk group name by default in format mdiskgrpX. You should change names ones that explain better features of group, I usually use format of  disktype_speed_size_number (for example SAS_15k_600gb_1).

After this you are able to create and present new vdisks from vCenter rather than creating and mapping new vdisks from v7000/SVC/XIV GUI and then creating VMFS after this. Creating new disks is quite easy, just select correct mdisk group and clicl “New Volume”. After this you get window like below where you fill necessary details and after that you just select hosts/clusters where you want to map this volume.

Kohti korkeampaa käytettävyyttä replikoinnilla

Nykyisissä virtualisoiduissa ympäristöissä törmätään usein haasteelliseen tilanteeseen jossa tietty virtualisoitu palvelin on niin tärkeä että sen käytettävyyttä halutaan parantaa. VMwaren uusi vSphere-ympäristö toi HA:n lisäksi uuden ominaisuuden Fault Tolerance (FT) jolla voidaan varmistaa että tietty virtualikone on aina käytettävissä. Ongelma on kuitenkin se että tällä menetelmällä kone voidaan varmentaa vain tietyn klusterin sisällä ja asiakkaat haluavat usein että koneita varmennetaan toiseen konesaliin/lokaatioon. VMwarella on tähän oma tuote nimeltä Site Recovery Manager, mutta tuote edellyttää alla olevan infran osalta tiettyjä asioita, kuten sitä että käytettävä peilaus toteutetaan levyjärjestelmätasolla (joka luonnollisesti lisää kustannuksia). Tuote on kuitenkin erinomainen ratkaisu suurien konesaliympäristöjen varmentamiseen ja luonnollisesti tämän tarpeen kasvaessa markkinoille on tullut useita kolmannen osapuolen tuotteita. Keskityn tässä artikkelissa Vizioncoren tuotteeseen nimeltä vReplicator (Quest on ostanut Vizioncoren joten tuote kulkee myös nimellä Quest vReplicator) joka voidaan ostaa joko yksittäin tai vEssentials-nimisessä paketissa jossa mukaan tulee myös mm. virtualikoneiden varmuuskopiointiin tuote.

Mikä vReplicator on ja mitä sillä voi tehdä?

Kuvitellaampa tilanne jossa halutaan varmistaa tietyn virtualikoneen käytettävyys olemassa olevasta ESX/ESXi-koneesta toiseen ESX/ESXi-koneeseen joka sijaitsee toisessa kaupungissa. Yksi tapa toteuttaa tämä on esim. ottamalla koneesta snapshot ja kopioimalla  kaikki tavarat toiseen palvelimeen. Jos konesalien välillä oleva yhteys ei ole nopea kuituyhteys menee tähän prosessiin valtavan pitkä aika, vaikka kone ei olisi kuin muutamia gigatavuja (Usein kuitenkin korkean käytettävyyden koneet ovat tietysti suurempia ja näin aika vain kasvaa). Edellä mainitulla tekniilla kone voitaisiin hyvin kopioida esim. kerran yössä, mutta mitä jos halutaan pitää toisessa lokaatiossa mahdollisimman ajantasaista versiota, esim. vain tunnin vanhaa? Tässä tapauksessa edellä mainittu tekniika ei valitettavasti vain toimi koska jo pelkkä snapshot+siirto vie reilusti enemmän aikaa.

Ongelmaan on useita lähetysmistapoja ja tietysti tässä vaiheessa herää kysymys siitä miten vReplicatorilla tämä ongelma voidaan ratkaista tehokkaammin? Vizioncoren vReplicator on ESX/ESXi-ympäristöön asennettava sovellus joka hoitaa tehokkaasti virtualikoneen virtualilevyn replikoinnin toiseen lokaatioon. Sovellus toimii siten, että ensimmäisellä kerralla koneesta otetaan täysi replika (tähän menee luonnollisesti aikaa) ja kun tuo on valmistunut seuraavilla kerroilla siirretään vain muuttuneet tiedot.  Tämä tapa säästää sekä tietoliikennekapasiteettia että siirtoon kuluvaa aikaa ja näin RTO/RPO-arvot saadaan mahdollisimman pieniksi.

vReplicator on erittäin helppo ja nopea asentaa ja se ei vaadi erillisiä agentteja tai clientteja asennettavaksi yhteenkään ESX/ESXi-koneeseen eikä myöskään virtualikoneisiin. Kun vReplicator on asennettu ei muita asennuksia tarvita vaan jatkossa kaikki ympäristön virtualikoneet ovat liitettävissä palvelun piiriin. Tuotteella voidaan myös kopioida useita virtualikoneita, useista eri ESX/ESXi-koneista yhteen keskitettyyn kohteeseen, joka tarjoaa erinomaisen tavan toteuttaa katastrofivarmennusta. Näiden lisäksi tuote helpottaa katastrofivarmennuksen käyttöönottoa koska käytetyn alustan ei tarvitse olla yhteneväistä lähde- ja kohde-ympäristöissä.

Miltä vReplicator näyttää

Vizioncoren vReplicator on selkeä Windows-sovellus jonka käyttöönotto ja operointi on erittäin yksinkertaista. Asennuksen jälkeen vReplicator-palveliemelle määritellään ESX/ESXi-palvelimet joita ympäristöstä löytyy jonka jälkeen replikoinnin käyttöönotto tapahtuu vain valitsemalla lähde ja kohde.

Alla kuvankaappaus tuotteen käyttöliittymästä jossa on ajossa replikointityö:

Miten vReplicator toimii käytännössä?

Ylempänä kerroin tuotteen toiminnallisuudesta jo yleisellä tasolla. Alla oleva kaaviokuva avaa tarkemmin tuotteen toimintaperiaatetta:

Kuten kaaviokuvasta käy hyvin selville tärkein osa replikoinnin toimivuudessa on vReplicator-palvelin josta on yhteydet sekä lähde- että kohde-ympäristöön. vReplicator-palvelin komentaa vSphere-ympäristön vCenter-palvelinta ja käyttää replikoinnissa hyväkseen snapshot-toiminnallisuutta. Kun snapshot on otettu vertaa vReplicator-palvelin eroavaisuuksia lähde- ja kohde-koneissa tiedostotasolla ja replikoi muuttuneet blokit automaattisesti kohteena olevan virtualikoneen virtualilevylle.

Yhteenveto. Toimiiko tuote kuten luvataan?

Tiivistäen voin ehdottomasti sanoa että toimii. vReplicator oli erittäin helppo tuote käyttöönotettavaksi ja tarjoaa erinomaisen tavan toteuttaa replikointia kustannustehokkaasti ilman peilattuja levyjärjestelmiä ja kalliita kuituyhteyksiä konesalien välillä. Tuotteesta on saatavilla ilmainen kokeiluversio jonka asentamista suosittelen varauksetta, näin pystyt itse toteamaan täyttääkö tuote yrityksenne tarpeet vai onko kenties VMwaren oma Site Recovery Manager parempi. En kuitenkaan lähde vertailemaan tuotteita keskenään, koska lähtökohdilta ja tarpeiltaan ne on tarkoitettu aivan eri tyyppiseen varmentamiseen ja kummallakin on selkeästi omat tarpeensa markkinoilla.

Virtuaalikoneiden varmistaminen VMwaren Data Recoveryllä


VMware toi Data Recovery-nimisen tuotteensa markkinoille jo vSphere-päivityksen yhteydessä mutta ensimmäisen version suuret ongelmat rajoittivat tuotteen käyttöönottoa useissa yrityksissä. Nyt VMware on päivittänyt Data Recoveryä ja se alkaa olemaan tuotteena sitä jollaiseksi sen olisi alun perinkin pitänyt tehdä.

Tuotteen idea on yksinkertainen; VMware Data Recovery on ns. appliance-pohjainen varmistuspalvelin jonka asentamisen jälkeen voidaan vSphere-ympäristön virtuaalikoneista ottaa image-tason varmuuskopiot ja näistä varmuuskopioista voidaan tarvittaessa palauttaa koko kone tai vain yksittäisiä tiedostoja (Tämä vaatii tuen, tällä hetkellä Windows sekä Linuxista RedHat ovat tuettuja). Data Recovery sisältää myös datan de-duplikoinnin, joka tarkoittaa että samaa tietoa ei tallenneta varmistuspalvelimen levyille kuin kertaalleen. Varmistukset otetaan incremental-kopioina joten varmistusajossa varmistetaan vain muuttuneet tiedostot ja näin voidaan pienentää varmistukseen käytettävää aikaa merkittävästi.

VMware Data Recovery ei tue datan varmistusta nauhajärjestelmiin vaan toimii ainoastaan levyvarmistuspohjaisesti. Applikaatio tukee FC, NAS sekä lokaalia levyä joka mahdollistaa luonnollisesti hyvinkin monenlaiset käyttökohteet, suosittelen kuitenkin joko FC:n kautta näytettyä LUNia tai dedikoitua NAS-järjestelmää.


VMware Data Recoveryn käyttöönotto on todella helppoa. Hommaa varten tarvitaan olemassa oleva vSphere-ympäristö sopivalla lisenssillä, itse tuoteen käyttöoikeus on jo vSphere Essentialissa mukana.

Ennen käyttöönottoa on varmistettava että seuraavat portit on sallittu tietoliikennelaitteissa:

  • VDR käyttää vCenterin webservices-rajapintaa, tämä tarvitsee auki portit 80 ja 443
  • VDR:n varmistuskoneen plugin ja tiedostotason palautus (FLR, File Level Restore) vaatii yhteyden VDR-applianceen porttiin 22024
  • VDR-appliance ottaa yhteyttä VMware ESX:n tai ESXi:n porttiin 902

VDR vaatii käyttöoikeuksia sekä vCenteriin että varmistettaviin virtuaalikoneisiin, joten tätä varten tulisi tehdä käyttäjätunnus ja antaa sille tarvittavat oikeudet. Seuraavat käyttöoikeudet vaaditaan jokaiseen varmistettavaan virtuaalikoneeseen:

  • VirtualMachine->Configuration->Disk change tracking
  • VirtualMachine->Provisioning->Allow read-only disk access
  • VirtualMachine->Provisioning->Allow VM download
  • VirtualMachine->State->Create snapshot
  • VirtualMachine->State->Remove snapshot

Sekä seuraavat käyttöoikeudet itse VDR-applianceen:

  • Datastore->Allocate space
  • VirtualMachine->Configuration->Add new disk
  • VirtualMachine->Configuration->Change resource
  • VirtualMachine->Configuration->Remove disk
  • VirtualMachine->Configuration->Settings

Ja vielä lisäksi käyttäjällä on oltava seuraava käyttöoikeus koko ympäristöön:

  • Global->License

Kun käyttäjätunnukset on luotu voidaan siirtyä itse ympäristön asentamiseen. Lataa tarvittava asennus-cd VMwaren sivustolta tunnuksillasi. Käynnistä vCenter-koneella CD-levyltä asennus ja valitse Data Recovery Client Plug-In. Seuraa asennuksen ohjeita, kun asennus on päättynyt voit ottaa vSphere Clientillä yhteyden ja asentaa työasemaasi plug-inin valitsemalla vSphere Clientistä Plugins -> Manage Plugins. Kun tämä on asentunut tulee sinun käynnistää vSphere client uudelleen jotta voit ottaa asennetun lisäosan käyttöön.

Seuraavaksi asennetaan itse VDR-appliance. Avaa vSphere Clientistä File -> Deploy OVF Template. Valitse Deploy from File ja hae asennus cd:ltä hakemistosta X:VMwareDataRecovery-ovf (Jossa X on siis CD-asemasi tunnus) tiedosto VmwareDataRecovery_OVF10.ovf. Valitse haluamasi kohde, klusteri sekä datastorage, haluamasi levymuoto sekä aseta aikavyöhyke properties-välilehdeltä. Lopuksi tarkista että valinnat ovat haluamasi ja paina Finish jolloin vSphere alkaa asentaa VDR-palvelinta.

Kun itse VDR-palvelin on asennettu voidaan siihen lisätä varmistuslevy suoraan levyjärjestelmästä käyttäen VMwaren RDM-toiminnallisuutta jossa virtuaalikone kirjoittaa suoraan sille tarjottuun LUNiin ja tarjoaa näin paremman suorituskyvyn kuin virtuaalilevyllä.

Seuraavassa osassa näytän miten VDR-palvelimelle tehdään tarvittavat perusasetukset sekä miten palvelin määritellään suorittamaan varmistuksia.

Miten siirtää virtuaalikoneita vSpheren ja vCloud Directorin välillä

VMwaren julkistettua VMworld 2010 tapahtumassa vCloud Director tuotteen pilvipalveluiden rakentamiseen törmäsin testailuissani ongelmaan virtuaalikoneiden migroinnin suhteen; miten koneita voidaan siirtää olemassa olevasta vSphere-ympäristöstä uuteen vCloudiin tai päinvastoin.

Artikkeli ei käsittele miten koneita siirretään fyysisesti vaan antaa esimerkin siitä miten koneita siirretään loogisesti näiden kahden tuotteen välillä, vCloud tietysti pyörii vSpheren päällä, eli tässä puhutaan hallinnallisesta näkökulmasta. Yleisesti dokumentteja lukemalla voisi kuvitella että loppujen lopuksihan virtuaalikone pyörii ESX/ESXi:n päällä mutta jos yrität migroida tälläistä konetta ESX/ESXi-palvelimelle joka ei ole vCloudiin kytkettynä huomaat että tämä ei ole mahdollista vaan seurauksena on seuraava virhe:

Järjestelmän tarkoituksena on luonnollisesti pitää vCloudin sisäiset virtuaalikoneet ympäristössä joka on liitetty vCloudiin jotta niiden hallinta onnistuu vCloud Directorilla.

Virtuaalikoneen siirto vSphere-ympäristöstä vCloud-ympäristöön

Jos haluat siirtää virtuaalikoneen vSphere-ympäristöstäsi uuteen vCloud-ympäristöön on tämä helpointa tehdä suoraan vCloud Directorin kautta avaamalla Organization -> My Cloud -> vApps jonka jälkeen valitaan “Import from vSphere”  kuvake työkaluvalikosta.

Tämän jälkeen saat uuden ikkunan jossa valitset virtuaalikoneen olemassa olevan vSpheren inventaariosta sekä valitset haluatko siirtää vai kopioida koneen. Lopuksi hetken odottelun jälkeen sinulla on kone migroituna vCloud-ympäristöön.

Virtuaalikoneen siirto vCloud-ympäristöstä vSphere-ympäristöön

Jos yrität siirtää konetta vSphere-ympäristöön huomaat että tämä ei onnistu koska vCloud-ympäristön koneet on sidottu vCloud-ympäristöön liittämällä niihin tietoa vCenterin tietokantaan. Tämän tarkoituksena on eritellä vSphere-ympäristön koneet niistä jotka on sidottu vCloud-ympäristöön. Tietuekenttä jolla sitominen on tehty alkaa tekstillä “system.service.vmware.vsla” jota seuraa uniikki vCloud Directorin järjestelmätunnus. Voidaksesi siis siirtää koneita vCloud-ympäristöstä takaisin vSphere-ympäristöön tulee tämä tietue poistaa. Poistaminen voidaan tehdä kahdella tavalla joista jälkimmäinen tapa on mielestäni huomattavasti helpompi ja parempi.

1. Avataan vCenterin mobiili-käyttöliittymä ja poistetaan sitä kautta tietuekentän tiedot käsin.  Tämä voidaan tehdä alla olevan kuvan mukaisesti valitsemalla “RemoveCustomFieldDef”:

2. Vaihtoehtoisesti voit vain suorittaa virtuaalikoneelle unregister-komennon vSphere-clientillä jonka jälkeen palautat koneen takaisin avaamalla datastore browserin sekä hakemalla tätä kautta koneen vmx-tiedoston ja valitsemalla sen kohdalla “Add to inventory”. Tämän jälkeen sinulla on kone vain vSphere-ympäristössä ilman että koneeseen on liitetty vCloud-määrityksiä.

Linux ja LVM virtuaalikoneissa

Nykyiset Linux-käyttöjärjestelmät tarjoavat erinomaisen skaalautuvuuden virtuaalikoneissa tukemalla esim. levyjärjestelmissä loogisia levyvolyymejä joka mahdollistaa käyttöjärjestelmän levyjen kasvatuksen ja pienennyksen lennossa. VMware vSphere tukee suurinta osaa markkinoiden Linux-käyttöjärjestelmistä vaikka virallinen tuki onkin vain suosituimmille distribuutioille. Tämän kirjoituksen aiheena on näyttää esimerkeillä miten LVM-järjestelmät toimivat Linuxilla, erityisesti virtuaalisissa ympäristöissä. Alhaalla esimerkkikuva siitä mitä LVM:llä tarkoitetaan:

Jos tarkoituksenasi on käyttää koko lisätty levy kasvattamaan loogista volyymiä suosituksena on että levyä ei osioida ollenkaan vaan levy lisätään LVM:n fyysisenä volyyminä. Levyä voidaan toki lisätä koneisiin myös sellaisenaan ja jättää käyttämättä LVM:ää mutta tämä ei ole suositeltavaa koska LVM tarjoaa paljon hyviä ominaisuuksia sekä skaalautuvuutta jatkon kannalta sekä lisäksi käytännössä kaikki modernit Linux-järjestelmät tarjoavat oletuksena LVM:ää asennuksen yhteydessäkin.

Miten liitän uusia levyjä ilman uudelleenkäynnistystä?

Heti kun olet luonut vSphere-clientillä uuden virtuaalilevyn virtuaalikoneelle voidaan uusi levy ottaa käyttöön helposti Linux-käyttöjärjestelmään. Linux kuitenkin vaatii että SCSI-väylä skannataan uudelleen ja näin uudet lisätyt levyt löytyvät. Valitettavasti tähän ei ainakaan minulla ole suoraan antaa helppoa tapaa ilman komentorivi-työskentelyä. Käynnistääksesi SCSI-väylän skannauksen anna alla oleva komento (vaihda X-kohta host-tekstin perästä oikean SCSI-väyläsi mukaiseksi):

# echo "- - -" > /sys/class/scsi_host/hostX/scan

Voit tarkistaa dmesg-komennolla mitä levyjä löydettiin etsimällä “Attached scsi disk”-viestiä

# dmesg | grep Attached
sd 0:0:X:0: Attached scsi disk sdb

Kun uusi levy on lisätty Linuxille luodaan LVM:lle fyysinen volume, volume group sekä looginen volume sekä lopuksi tiedostojärjestelmä.

# pvcreate /dev/sdb
Physical volume “/dev/sdb” successfully created

# vgcreate datavg /dev/sdb
Volume group “datavg” successfully created

# lvcreate -n datalv1 -l+100 datavg
Logical volume “datalv1” created

# mkfs.ext3 /dev/datavg/datalv1

Ensimmäisessä vaiheessa luotiin levylle fyysinen volume jonka jälkeen luotiin uusi volume group nimeltä “datavg”. Seuraavaksi luotiin datalv1-niminen looginen volume jonka kooksi annettiin 100% datavg:n koosta. Jotta voit käyttää uutta volumea luotiin sinne ext3-tiedostojärjestelmä jonka jälkeen levy on valmis käyttöönotettavaksi.

Olemassa olevan levyn kasvatus

Kun virtuaalilevyä on kasvatettu vSphere-clientilla tulee levyn muutokset skannata myös Linuxin puolella jotta lisätty osuus levystä voidaan ottaa käyttöön. Voidaksesi tehdä tämän tulee sinun tietää käyttämäsi levyn SCSI ID. Alla esimerkki jolla skannaus tehdään Linuxin puolella (korvaa devices-kohdan jälkeinen 0:0:1:0 oikealla id:llä)

# echo 1 > /sys/bus/scsi/devices/0:0:1:0/rescan

Voit käyttää dmesg-komentoa tarkistaaksesi että muutos on otettu onnistuneesti käyttöön. Löydät tämän etsimällä tekstiä “capacity change”.

# dmesg | tail -n 10 | grep change
sdb: detected capacity change from 8589934592 to 17179869184

Lopuksi itse tiedostojärjestelmä tulee kasvattaa vastaamaan muuttunutta levykokoa

# resize2fs /dev/sdb

Olemassa olevan volumen ja tiedostojärjestelmän kasvatus ilman partitiointia

Jotta muutokset tulevat voimaan tulee sinun suorittaa LVM:n fyysiselle volumelle rescan jolla muutokset havaitaan (vaihda sdb käyttämääsi oikeaan levyyn)

# pvresize /dev/sdb

Seuraavaksi laajennetaan looginen volume vastaamaan kasvanutta kokoa.

# lvextend -l+100 /dev/VolGroup01/LogVol00

Lopuksi ajetaan itse tiedostojärjestelmälle resize jotta uusi koko on käytettävissä.

# resize2fs /dev/VolGroup01/LogVol00