On Sun, Sep 10, 2017 at 4:21 PM, David Edelsohn <dje....@gmail.com> wrote:
> On Sun, Sep 10, 2017 at 10:42 PM, Jeffrey Walton <noloa...@gmail.com> wrote:
>> Hi David,
>>
>>> The system was configured to maximize diskspace and flexibility.  It
>>> now is supporting six, separate VMs.  The disk array was configured as
>>> a single physical volume, mapped to a single logical volume, that then
>>> is partitioned into virtual I/O devices mapped to the VMs, which then
>>> are formatted for AIX filesystems.  It's a lot of virualization
>>> layers. I already have increased the disk queues in the AIX VMs, which
>>> increased performance relative to the initial installation.  Also, the
>>> VIOS was slightly under-sized for the current amount of usage, but I
>>> have avoided rebooting the entire system to adjust that.
>>
>> I can't speak for others, but if GCC119 needs a reboot then do it.
>
> The issue is not rebooting gcc119 AIX VM or wiping out the AIX /home
> filesystem. To expand the VIOS partition I need to reboot the
> hypervisor host and all of the AIX partitions, which is more difficult
> to schedule. Also, there does not appear to be a mechanism to squeeze
> down the physical volume on the disk array and carve out new devices.
>
> Thanks, David

Hello, I hope I'm not adding too much noise to the list. Thank you
both for your consideration. I think I understand the problem a bit
better now. Close to the full capacity of the machine seems to be
exposed to the VM, which made me overlook that it might be a VM. (To
host AIX for testing the current setup makes sense.)

I hope it doesn't seem like I do not appreciate the services offered;
I realize (at least I hope) that I am extremely privileged to use the
machines that make up the GCC CF. Hopefully my surprise at the results
of running the commands I did seems reasonable.

In any case, my computations on that machine are proceeding now; at
least as well as they can.

Respectfully,
     R0b0t1

Reply via email to