Op 04-09-2023 om 17:13 schreef Granwille Strauss:
Hi
Thank you, in our case, we start our VMs at 60 GB, clients then can
upgrade to 120 GB as the next upgrade. However, clients also have the
option to "Downgrade" back to 60 GB based on their package. Would kinda
not make sense to prohibit
Hi all,
These days I’m working on a new feature to enable OAuth2 logins in CloudStack
assuming corresponding account/user is already created in CloudStack. Currently
I’ve made it work with Google and Github.
I’m here to ask for any suggestions or quick information on how you are using
OAuth
Hi
Thank you, in our case, we start our VMs at 60 GB, clients then can
upgrade to 120 GB as the next upgrade. However, clients also have the
option to "Downgrade" back to 60 GB based on their package. Would kinda
not make sense to prohibit clients from doing that, from a legal POV. So
this
Hi,
Normally cloud providers create vm templates with small size (e.g. 10GB).
When create vm from the template, user can override the root disk size so
that vm have a larger size (e.g. 60GB)
If the vm template has cloud-init installed, it can detect the new disk
size and auto-grow the partition
I believe most do not allow shrinkage, simples. :)
At least the likes of Digitalocean and Hetzner do not.
Instead how you could juggle storage flexibly is by adding or removing
data volumes and within the VM use them with LVM.
HTH
On 2023-09-04 15:50, Granwille Strauss wrote:
Hi Wido
Hi Wido
Thank you. Yes, I only shrink it inside the VM. But still Cloudstack
volume shows 120GB and within the VM lsblk command shows that 120 GB is
available. Since I cannot shrink the volume, how do most providers take
care of this issue? I mean it would be awkward if a client see they can
Top job!
PS: I know technically we cover this by invoking "-R" in the docs
example, but do you think the issue warrants dropping few words in there
to underline the issue? Something like "do note the -R switch which
backs up the MySQL database routines"
On 2023-09-04 15:22, Rohit Yadav
Wei pointed out privately to me that it's already in our docs at
https://docs.cloudstack.apache.org/en/latest/upgrading/upgrade/upgrade-4.17.html#database-preparation
My bad, I didn't notice it earlier :)
Regards.
From: Nux
Sent: Monday, September 4, 2023
Cheers Rohit,
I'm for including the routines bit in the release or upgrade notes. We
haven't had such a gotcha until now, even though it's not strictly
within scope.
Regards
On 2023-09-04 14:03, Rohit Yadav wrote:
+1 (binding)
Upgraded a multi-zone (edge and core) KVM env with NFS, local
Op 04-09-2023 om 13:08 schreef Granwille Strauss:
Hi Wido
I mounted a live ISO to the VM, booted into the ISO and went into
recover mode, had to unmount the / partition of the VM, and then proceed
to resize it via parted and write changes. Rebooted via and detatched
the ISO and now VM
+1 (binding)
Upgraded a multi-zone (edge and core) KVM env with NFS, local storage and
Linstor storage from 4.18.0.0 to 4.18.1.0. Post upgrade tested VM deployment as
root admin and normal user account.
I hit the issue of procedures not found as I had moved my DB from one host to
another and
Hi Wei
As far as I understand, you have resized the disk inside the VM to 60GB,
right ?
- Yes, I have resized the partitions in VM back to 60 GB.
However, the allocated disk size of the VM should be still 120GB, not 60GB.
You can verify it by `qemu-img info -U /mnt//`
- Yes, in VM
Hi,
As far as I understand, you have resized the disk inside the VM to 60GB,
right ?
However, the allocated disk size of the VM should be still 120GB, not 60GB.
You can verify it by `qemu-img info -U /mnt//`
Shrinking a QCOW2 image is possible, but complicated. It is currently not
Hi Wido
I mounted a live ISO to the VM, booted into the ISO and went into
recover mode, had to unmount the / partition of the VM, and then proceed
to resize it via parted and write changes. Rebooted via and detatched
the ISO and now VM shows 60 GB correctly. However, in Cloudstack, still
Op 04/09/2023 om 09:18 schreef Granwille Strauss:
Thank you. Can you confirm if this behaviour is expected? Or am I
experiencing a bug?
What exactly? You did this resize manually outside the knowledge of
cloudstack, am I correct?
How did you do this live/recovery method?
Wido
On
Hi,
it looks like your VirtualRouter is failing to deploy and the virtual machine
you are trying to deploy is depending on the successful deployment of the
virtual router:
For the virtualrouter:
"No clusters found having a host with enough capacity, returning"
2023-09-04 14:53:18,705 DEBUG
Hi,
It looks like there was not enough memory.
-Wei
On Mon, 4 Sept 2023 at 11:08, Technology Mail
wrote:
> Hello,
>
> Unable to deploy vm instance,
>
> My server is alam 8.
>
> 1. MGMT+NFS
> 2. KVM
>
> +
>
> Unable to start a VM [55d71859-ae54-4e12-8de3-8f84fe9627bf] due to
>
Hello,
Unable to deploy vm instance,
My server is alam 8.
1. MGMT+NFS
2. KVM
+
Unable to start a VM [55d71859-ae54-4e12-8de3-8f84fe9627bf] due to
[Unable to create a deployment for VM instance
Hi Jorge,
I think this is not possible currently, you could open an enhancement request?
-Jithin
From: Jorge Luiz Correa
Date: Friday, 1 September 2023 at 4:39 PM
To: users@cloudstack.apache.org
Subject: Restricting instance deletion to the creator.
Is there any way (global configuration,
Hi Ricardo,
UDP is restricted currently since HAproxy won’t support it. This is based on
https://github.com/apache/cloudstack/pull/4501
You may review and report an issue/improvement in Git Hub.
-Jithin
From: Kuasar
Date: Friday, 25 August 2023 at 5:05 AM
To: users@cloudstack.apache.org
Thank you. Can you confirm if this behaviour is expected? Or am I
experiencing a bug?
On 9/4/23 09:00, Wido den Hollander wrote:
Op 04-09-2023 om 08:20 schreef Granwille Strauss:
Hi
I managed to resize the VM itself back to 60 GB via live/recovery
method. However, now in Cloudstack it
Op 04-09-2023 om 08:20 schreef Granwille Strauss:
Hi
I managed to resize the VM itself back to 60 GB via live/recovery
method. However, now in Cloudstack it still says the volume remains 120
GB and when I want to shrink it I am presented with the errors from my
previous reply. Is there a
Hi
I managed to resize the VM itself back to 60 GB via live/recovery
method. However, now in Cloudstack it still says the volume remains 120
GB and when I want to shrink it I am presented with the errors from my
previous reply. Is there a way around this? Such as making a database
change.
23 matches
Mail list logo
