There probably isn't anything besides a little time and effort stopping you from growing the partitions. You should be able to use regular Linux tools to extended these partitions (if need be creating a new VMDK and copying each partition to it and expanding it to the desired size.)

Something you could try in a lab environment at least.

A bootable Linux live CD with most if not all of the required tools to accomplish this can be found here: http://gparted.org/



On 2015-03-24 11:21, Tim Frazee wrote:
I would agree. you cant take a 2.5k template and grow it out to a 10k
user template and get the same result. partA and partB are not going
to grow.

On Tue, Mar 24, 2015 at 9:40 AM, Justin Steinberg
<[email protected]> wrote:

So we all agree that expanding an existing vdisk isn't the same as
installing from a larger OVA template.

That being said, the documentation about multiple vdisk systems
seems to no longer apply.  Starting with the 9.1 OVA templates,
even the 10k user template is a single 1x110GB disk.     9.0 was
the last CM OVA template version to have 2x80GB vdisk config for the
7500 and 10k user templates.

Does anyone know whether there are any other settings such as DB
performance settings that are different between OVA templates, or is
it just simply vCPU, vRAM, vDISK size.     If it is just the vDisk
size, I'm leading towards staying on my current expanded vdisk
template until a time in the future where the active/user partition
needs to be larger to accommodate a newer software version.

Justin

On Mon, Mar 23, 2015 at 2:17 PM, Anthony Holloway
<[email protected]> wrote:

Ryan, you replied to Tim, but I think Justin is the one who really
needs to read your reply.  His method to move from one OVA to the
next may not have resulted in what he expected.

On Mon, Mar 23, 2015 at 12:45 PM Ryan Ratliff (rratliff)
<[email protected]> wrote:

It’s expected that only the common partition grows if you expand
the vDisk.  The feature is there because some versions of UCM
require more space available in that partition than others.


http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/upgrade/10_0_1/CUCM_BK_U4214F9D_00_upgrade-guide-cucm-100/CUCM_BK_U4214F9D_00_upgrade-guide-cucm-100_chapter_011.html#CUCM_TK_C9AFC8CC_00
[1]

You need to change the disk size changes only if you need additional
space to complete the upgrade. The disk space requirements are
specified in the Readme file for the OVA template.

Expanding the disk size to add space to the common partition will
not increase the user capacity of your system. If you need to extend
the user capacity of your system, you must migrate from a
single-disk to a multi-disk virtual machine
So if you really need to go from a 2500 user deployment to a 7500
user one you should DRS, rebuild, restore so your active and
inactive partitions get sized accordingly.

-Ryan

On Mar 23, 2015, at 10:28 AM, Tim Frazee <[email protected]> wrote:

unknown. installer still does a hardware check.

while testing my moh problem, I used an 8.6 ova to deploy the old
10k template, made the one OS tweak to the image, then installed
10.5(2) on it. successful install.

On Sun, Mar 22, 2015 at 9:43 AM, NateCCIE . <[email protected]>
wrote:

I wonder what the difference is between expanding and installing on
120G from the beginning, since there is the report of it only
growing the common partition.

On Sat, Mar 21, 2015 at 9:03 AM, Tim Frazee <[email protected]>
wrote:

the resize cop file is for 9x only, 10 has it built in. I'm running
around with a tac case to address a stock 9x or 10x 7.5 to 10k user
build that results with a 110G disk. doesn't leave much space for
those 500 moh sources.....

if you shut the image down and increase from 110 to at least 112G,
the boot process grows the common partition out.

as a standard, any of our 10x installs for large clients, we are
growing the disk out to 120G just to be safe.

On Fri, Mar 20, 2015 at 3:50 PM, Erick <[email protected]> wrote:

The VMware disk reallocation worked for us also going from 80gig
 to 110gig for 10.5. Were on. 9.1 prior. 

The readme in the download link Is pretty good but doesn't say
outright what to increase it to. 

High level steps , 

Make sure you have a good backup

Install the cop file 
Shutdown the vm
Change virtual disk from 80G to 110G
Save /OK settings 
Power on VM

It will reboot a few times while extending disk then come up fine /
normal . 

Sent from my iPhone

On Mar 20, 2015, at 9:34 AM, Justin Steinberg
<[email protected]> wrote:

So in the CUCM 10.5 download section for the Utilities, it seems to
have combined the common cleanup COP file and the VMware Disk Size
Reallocation.

There is a COP file title 'VMWARE DISK SIZE REALLOCATION COP
FILE&#39; but the actual file
is CISCOCM.FREE_COMMON_SPACE_V1.3.K3.COP.SGN

The actual reallocation cop file isn't part of the CUCM 10.5
download, I had to go back into an older version to file that COP. 
So that is why I was thinking in 10.5 all you would need to do is
change the size of the vDisk in VMware and restart CUCM 10.5.

Is there an official document on the process to follow for this
change ?

Justin

On Fri, Mar 20, 2015 at 10:12 AM, Roger Wiklund
<[email protected]> wrote:
I have.

Went from 2500 to 7500 on CUCM 10.5(1).

You need to download the VMware Disk Size Reallocation COP file for
10.5. Worked like a charm.


http://www.cisco.com/web/software/282204704/18582/CleanupCommonCOPfilev1.3.pdf
[2]

http://www.cisco.com/web/software/282204704/18582/ciscocm.vmware_disk_size_reallocation_v1.0.pdf
[3]

On Fri, Mar 20, 2015 at 2:28 PM, Justin Steinberg
<[email protected]> wrote:
Has anyone successfully expanded the virtual disk size of CUCM
VMs without
rebuild/DRS?



I have an install where CM 10.5 is using the 2500 user template
and we want
to increase to 7500 users.  The 2500 OVA is 1 vCPU, 4GB,
1x80GB.    The 7500
OVA is 2vCPU, 6 GB, 1x110GB.    In the past, the older 7500
user CM versions
had two virtual 80 GB disks, however since 9.1 the 7500 user is a
single 110
GB disk.   It seems like with a single virtual disk it would be
easier to
expand an existing VM without rebuild.



There are several bugs on the topic:

https://tools.cisco.com/bugsearch/bug/CSCug63058 [4]

https://tools.cisco.com/bugsearch/bug/CSCuc58936 [5]



In older CM versions there was a COP file to assist with allowing
the VM to
use more disk when the vdisk was increased.  However, now I
believe that it
is just built in to CM to use more disk on reboots if it detects
a vdisk
change instead of needing to run the OVA.



There is still conflicting documentation on the topic, so I will
probably
open a TAC case but curious if anyone has dealt with this before?


Justin



_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip [6]


_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip [6]

 _______________________________________________
 cisco-voip mailing list
 [email protected]
 https://puck.nether.net/mailman/listinfo/cisco-voip [6]

 _______________________________________________
 cisco-voip mailing list
 [email protected]
 https://puck.nether.net/mailman/listinfo/cisco-voip [6]

 _______________________________________________
 cisco-voip mailing list
 [email protected]
 https://puck.nether.net/mailman/listinfo/cisco-voip [6]

 _______________________________________________
 cisco-voip mailing list
 [email protected]
 https://puck.nether.net/mailman/listinfo/cisco-voip [6]

_______________________________________________
 cisco-voip mailing list
 [email protected]
 https://puck.nether.net/mailman/listinfo/cisco-voip [6]



Links:
------
[1]
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/upgrade/10_0_1/CUCM_BK_U4214F9D_00_upgrade-guide-cucm-100/CUCM_BK_U4214F9D_00_upgrade-guide-cucm-100_chapter_011.html#CUCM_TK_C9AFC8CC_00
[2]
http://www.cisco.com/web/software/282204704/18582/CleanupCommonCOPfilev1.3.pdf
[3]
http://www.cisco.com/web/software/282204704/18582/ciscocm.vmware_disk_size_reallocation_v1.0.pdf
[4] https://tools.cisco.com/bugsearch/bug/CSCug63058
[5] https://tools.cisco.com/bugsearch/bug/CSCuc58936
[6] https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip

Reply via email to