Often in a given scenario of use case, the practitioner would perform some capacity planning and cater for the computing resources needed at a slightly higher amount, to give some buffer or leeway. However, we might run to an event where the computing resources is over subscribed. In the setup of the management server for CloudStack 4.2, we might run to an event that requires the engineer to increase the hard disk capacity for both the primary and secondary storage. Assuming having to physical access to the physical blade servers, adding more hard disk capacity can be as simple as plugging more hard disks. provisioning gets complicated when storage is virtualized, and with the virtual machine created in the hypervisor with XenServer 6.2.
The following steps are necessary to resize by increasing the hard disk capacity of a virtual machine residing in XenServer 6.2 as the hypervisor.
First, power off the VM. I like to create a backup of my VM before I perform anything drastic. At such, any awkward situation that requires a save, the backup is to the rescue. To resize hard disk of the VM, From XenCenter, select the corresponding VM and click properties. Change the size of the hard disk accordingly. Here the size is increased to 28GB.
Then, restart the corresponding VM. From here, we will be using the "fdisk" commands on centos6 to manipulate the VM's resources.
Take a look of the VM's hard disk with "fdisk -l" or "fdisk /dev/xvda"
Observe the total capacity of this newly resize hard disk, and also the location of the device created. note that in centos6, /dev/xvda2 is not automatically resize to the new capacity.
The trick here is to create a new primary partition called "/dev/xvda3", and then allocate the subsequent capacity form 1046 onwards to 30064771072. All these can be done with the "fdisk suite of command". use the "m" for the menu of the fdisk.
After creating the new partition, verify the new partition. All these are not done yet. The partition tables need to be written out.
This is not the end of resizing the hard disk for a VM in XenServer 6.2 hypervisor yet.
The unique-ness of centos6 as compared to ubuntu when it comes to disk management, centos6 requires the linux volume group "VolGroup" to be extended with the new physical device "/dev/xvda3". then the centos6 "home" folder that is residing at "/dev/VolGroup/lv_root" need to be extended with the newly acquired physical volume.
note the +20G parameter used caused some errors, because of insufficient disk blocks.
That is not the end of it yet. The file system is not updated with the latest disk capacity and need to be resized with command "resize2fs".
A final check to ensure the newly created hard disk capacity is available.
Wednesday, December 4, 2013
Tuesday, December 3, 2013
[CC] your own private cloud with cloudstack4.2 xenserver6.2 on minimal hardware
There are scenarios that would benefit from the use of a private cloud.
using cloudstack to launch a VM, follow by SSH into the newly created VM.
dashboard of cloudstack
In a hypothetical situation, I have a bunch of data that is deemed privileged, worthy only on a private cloud. The data need to be sanitized, polished, processed, and finally visualized. The data is too hefty to be process on my laughing stock (i7, 8GB ram, 500GB hdd, on a 32bit OS), and it requires some very serious computing horse power to be leveraged on; using very popular open source, scalable, and distributed computing methodology, such as Apache Hadoop. I could follow the "how" on setting up for my thesis project using Apache Storm running off many virtual machines (VM) hosted on public cloud Amazon Web Services (AWS) EC2; all in all risking of data leakages (from human error).
Definitely need to push out the boat on setting up a private cloud for such scenario. However, the luxury of having a cloud computing center aka data center at yours disposal (yours truly is indeed privy in this), is out of reach to many. Very much like the previous mentioned, it is the need to experiment the performance of a software on many virtual machines require cloud computing, privy data just made it a private cloud. The lack of access to data center however, should not be the hampering factor to write some interesting algorithms to be used on a distributed computing infrastructure.
Definitely need to push out the boat on setting up a private cloud for such scenario. However, the luxury of having a cloud computing center aka data center at yours disposal (yours truly is indeed privy in this), is out of reach to many. Very much like the previous mentioned, it is the need to experiment the performance of a software on many virtual machines require cloud computing, privy data just made it a private cloud. The lack of access to data center however, should not be the hampering factor to write some interesting algorithms to be used on a distributed computing infrastructure.
In another hypothetical scenario, you may have only a single high performance blade, but the department staff requires access to this computing power on an ad hoc basis. In the good old days, staff would block off the physical blade for a time frame, install whatever software that is necessary to run the task and wipe out of after use. This methodology however come with a few caveats. For starters, lets think through a few of them. 1. assuming the full computing capability of the blade is not harnessed by 1 staff's software. 2. the blade is mutually exclusive, blocking other staff from accessing the computing power. 3. virtualizing the blade itself is not sufficient, staff's computing requirement is elastic. There must be a way for staff to manage their own virtual machines. Stemming from this 3 points, a cloud computing infrastructure fits the bill. whether to make it a public or private or hybird cloud, it is up to the department's plan for the lonely blade server.
The questions come begging: how to setup a private cloud?!
two software components at the minimum
1. cloud infrastructure management, in this example, the CloudStack4.2
2. hypervisor aka virtual machine monitor (VMM), in this example XenServer6.2
two "hardware" component at the minimum
1. a "computer" to run the CloudStack4.2, for managing the VMs.
2. a "computer" to run the XenServer6.2, for provisioning the VMs.
I double quoted the "computer" due to the way this private cloud experiment is setup. I have adopted a virtualized hypervisor, which is the Xen-In-Xen feature courtesy of XenServer6.2, and also a virtual machine to run CloudStack. So, I do not physically own any "hardware" for my private cloud setup. cool huh!
Each of the components and it's associated procedure to setup is worthy of a post by it self. There will be more post in the future, detailing the setting up of CloudStack4.2, XenServer6.2, administrating the VMs, and also my attempt at virtualizing a hypervisor in a virtualized hypervisor, the Xen-In-Xen-In-Xen approach. It sounds pretty much "inception-ish" attempt!
Before we go into the gruesome details of setting up a private cloud, some dangling carrots (screenshots of my private cloud setup)
using cloudstack to launch a VM, follow by SSH into the newly created VM.
7 easy steps to launch a VM from cloudstack.
dashboard of cloudstack
Subscribe to:
Posts (Atom)