Back-up for virtual environments (TSMVE) is still underestimated by IBM!

When you are using IBM equipment there is a big chance that you will use IBM related software to manage the environment. In a large  environment you can use IBM Tivoli Storage Manager (TSM) for Virtual Environments to make back-ups of your virtual machines. IBM says that:

Tivoli® Storage Manager software provides a wide range of storage management capabilities from a single point of control, helping companies ride the information tidal wave.

Early this year they’ve added a new product to the Tivoli Storage Manager, IBM storage management software called IBM Tivoli Storage Manager for Virtual Environments (TSMVE). This is their product for making back-ups and to recover virtual machines.

You would think that a big company like IBM jumped on the train of virtualisation when it was leaving the train station but in my opinion that’s not what they have done!

Read more

Was once an enthusiastic PepperByte employee but is now working elsewhere. His blogs are still valuable to us and we hope to you too.

Replacing a network card of a DC (Virtual Machine)

When you want to replace the old virtual network card for a VMXNET3 network card of a Domain controller (DC) and when the DC is also DNS server (AD integrated) and the only one in the domain you may encounter some problems.  Yesterday i replace the old network card for a VMXNET3 adapter in a DC that was the only DC in the Domain (yes i hear you 1 DC = no DC ) and i encounter the following errors on the server:

 DC error 4007 DC error 4015 DC error 6702

Read more

Was once an enthusiastic PepperByte employee but is now working elsewhere. His blogs are still valuable to us and we hope to you too.

Lab Manager, CAG and Firewall the challenge

Lab manager is a product that is not been made for a WAN connection and the security that you want for safety. But it can work. Don get me wrong. Yes the connection of lab manager is secure because it is over port 443. Is it? 

For internal use we have build a playground for testing new products and to use for demo’s. But as small as it is (2 ESX hosts) we like it to be secure and be able to use it at a customer site ( for the demo part ). And when you work at a company where most of the employees adore Citrix product the choice of a Citrix Access Gateway (CAG) was  easily made. So the setup for the environment in it simplistic form is looking like the drawing below


Read more

A trained Field Service Engineer who grew into the position of senior consultant at PepperByte. Enjoys the challenge of coming up with solutions for clients for their complex IT issues. Has plenty of experience with Microsoft, Citrix, RES and VMware products.

Core qualities
Professional, enthusiastic, pragmatic, sociable

Cycling, HiFi, going to concerts

Job description
Senior Consultant

VMware vSphere ESXi 4.1 Stops During Instalation Booting: MBI-0x00010128, entry=0x0040024a

My vSphere ESXi 4.1 stopped during booting form the ISO file  :   Booting: MBI-0x00010128, entry=0x0040024a.  I had made a ISO with a custom KS.CFG file for scripted installation.


I havened seen this message before but i did some digging and found out the the ISO file was corrupted. I build a new one and it the problem was gone.

This error looks very simulate to Booting: MBI=0x00100d8, entry=0x00100212 this error indicates that the hardware you are trying to use is not on the HCL list of VMware  

Was once an enthusiastic PepperByte employee but is now working elsewhere. His blogs are still valuable to us and we hope to you too.

vMotion Error at 78% with NFS storage

When I add a new host (ESX4.1) in my VMware Cluster and i wanted to do a vMotion to the new host  a got a error at 78%. The popup box says :

A general system error occurred sources detected that destination failed.

when i ask my friend Google a got  a hit at vmfaq. It says that:

“This error message indicates that the shared storage is not available equally to both host involved in the VMotion event.”.

Read more

Was once an enthusiastic PepperByte employee but is now working elsewhere. His blogs are still valuable to us and we hope to you too.

Een corrigerende trap tegen je ESX-bak en hij draait weer als een zonnetje :)

Tijdens mijn beheer werkzaamheden liep ik tegen het probleem aan dat VirtualCenter op een taak bleef hangen op één taak en alle andere taken, zoals “maintenaince mode”, “power down”, “migrate”, etc. er achter werden ge-queued. Hierdoor kon ik dus eigenlijk niks meer met VirtualCenter. Ook werdt VirtualCenter onwijs traag, en was het dus elke keer hopen dat hij toch nog doorliep.

Ik hoor jullie denken: “Nou dan doe je toch, rechtermuisklik –> cancel”. Dat had ik dus ook al bedacht, maar maakte ook geen verschil. Neutral

Dan komt hier de oplossing:
1. Op de ESX-server waar de niet meer reagerende VM’s op draaien voer je het commando “service mgmt-vmware restart” uit, of je reboot de betreffende esx-server.
2. In de services van windows waar je VirtualCenter op draait, zoek je naar de services van “VMware VirtualCenter” en restart je de service.

En dan kan je nu weer knallen als voorheen Green with Envy

Started his working life as a system manager at a health care organization. Is now a dedicated technical consultant at PepperByte. Specialist in virtualization and security.

Core qualities
Eager to learn, punctual, fun, loyal, patient

Socializing, watching television series and sports

Job description
Technical Consultant


Bij het maken van een technisch ontwerp voor een klant wordt vaak het één en ander geroepen over beschikbaarheidspercentages van een nieuwe infrastructuur of nieuwe systemen. Zware kost?

Ja en nee, beschikbaarheidspercentages hangen samen met veel interne en externe factoren. Zo zal er voor het schrijven van een technisch ontwerp altijd inzicht moeten zijn of de beschikbaarheid geldt voor de keten van componenten tussen een systeem waar een beschikbaarheidspercentage op af wordt gegeven. Vaak zal worden gesteld: “deze applicatie dient 99,8%, 24/7 beschikbaar dienen te zijn”. Leuk, totdat je je PepperByte blocnote erbij pakt en gaat rekenen…. 99,8% op 24/7: hoeveel uur mag de desbetreffende applicatie er dan uitliggen? Een simpele rekensom helpt daarmee: downtime = (total available hours + 0,25) – ((total available hours + 0,25) / availability%). Dus in ons voorbeeld (99,8% op 24/7) is de downtime: (8760 (24 uur * 365 dagen) + 0,25 (overhead voor het schikkeljaar)) – ((8760 + 0,25) / 99,8%) = 17,52 uren.

17,5 uren op een jaar, nou dat is wel te halen op deze applicatie! Maar dan komt de keten van componenten nog. Concreet betekent dit dat alle systemen vanaf de klant tot aan de applicatie dienen te functioneren! Dus dan heb je het over netwerkinfrastructuur (mogelijkheid om vanaf een ander locatie te werken? waar beleg je dit in de SLA – dus houden we het in dit voorbeeld puur op de backend infrastructuur, dus puur de core netwerkfunctionaliteiten van-en-naar de MER), database server, applicatie server, data opslag locatie. En dan heb ik het nu alleen nog over een traditionele server-client infrastructuur. Wanneer je Server Based Computing gebruikt zal dus ook de Farm beschikbaar moeten zijn en wanneer je het zaakje hebt gevirtualiseerd zal je dus (bijvoorbeeld) de ESX omgeving en SAN mee moeten tellen.

Zo worden die 17,52 uur toch echt een hele dure grap; want om deze beschikbaarheid te halen heb je een heel stevig argument voor een twin center omgeving… Mijn advies? Berg je blocnote op en vraag de klant of het beschikbaarheidspercentage voor deze applicatie aangepast dient te worden Wink

Voor nu,


Is interested in everything connected to technology. Has a passion for cloud, virtualization and software development. Always finds appropriate IT solutions for customers that match their needs strategically, technically and financially.

Core qualities

Quick thinker, result driven, ambitious, customer-friendly, enthusiastic

Running, listening to music, good food and doing fun things with family

Job description
CTO PepperByte, LoadGen, and BlueParq