You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by "svenknockaert (via GitHub)" <gi...@apache.org> on 2025/10/11 07:35:41 UTC

Re: [D] Failed to create volume from template on ceph storage [cloudstack]

GitHub user svenknockaert edited a discussion: Failed to create volume from template on ceph storage

We are experiencing an issue when creating a template from an instance’s volume.
In the GUI, the process seems to complete successfully — the status shows as “ready.”
However, when this image is then used to deploy (and start) a new instance, an error appears:
```
Error
Unable to start a VM [587b6b50-9b00-4604-b0e6-992e7013b110] due to [Unable to create a deployment for VM instance {"id":447,"instanceName":"i-71-447-VM","state":"Starting","type":"User","uuid":"587b6b50-9b00-4604-b0e6-992e7013b110"}].
```

The root cause of the problem is likely visible in the database:

Here is a working entry from the database:
```
+-------------+----+----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+-----------------------------------------------------+------+
| template_id | id | install_path                                                   | local_path                                                                                           | error_str                                           | url  |
+-------------+----+----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+-----------------------------------------------------+------+
|         237 | 67 | template/tmpl/2/237/916c05d8-fe0a-3290-a77b-0823c041db3d.qcow2 | /mnt/SecStorage/1609b869-700e-3b63-876b-3c8abfd394d6/template/tmpl/2/237/dnld2323592655182356492tmp_ | Install completed successfully at 9/19/25, 10:30 AM | NULL |
+-------------+----+----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+-----------------------------------------------------+------+
```

But with my last attempts i get (not working entry):

```
+-------------+----+----------------------------------------------------------------+------------+-----------+------+
| template_id | id | install_path                                                   | local_path | error_str | url  |
+-------------+----+----------------------------------------------------------------+------------+-----------+------+
|         260 | 87 | template/tmpl/2/260/b12973d6-5c82-4b6d-bfa4-e552b9ece7ff.qcow2 | NULL       | NULL      | NULL |
+-------------+----+----------------------------------------------------------------+------------+-----------+------+
1 row in set (0.00 sec)
```

You can see that the “local_path” field is no longer populated, and there is also no successful error_str entry.
However, the secondary storage is accessible to the CloudStack Management Server, and the template has indeed been copied to the secondary storage (as shown by the install_path).

What could be the reason why CloudStack no longer defines a local_path, causing instance deployments based on that template to fail?

Using Cloudstack 4.20.1.0

UPDATE:
-----------

In the meantime, I know that it has nothing to do with the "local_path" field, because when I convert a volume from an existing Linux instance (e.g. Rocky) to a template, that works fine. I can then deploy new instances from it perfectly. 

However, the problem occurs when converting the volume to a template of a Windows 11 instance. The Windows 11 instance was installed via the Windows ISO installation and works fine, and all virtio drivers are installed. The Windows 11 instance is UEFI secure, but that's also the case with the working Rocky Linux template, so it has nothing to do with the UEFI capabilities (I suppose). 

In the logs I see the following: 

```
com.cloud.exception.InsufficientServerCapacityException: 
Unable to create a deployment for VM instance ... 
Scope=interface com.cloud.dc.DataCenter; id=1
```

So I don't really understand the problem since it is definitely possible to run Windows 11 instances with UEFI Secure. 
But deploying instances based on the template (on the same KVM hosts) doesn't work. 

Does anyone have an idea why deploying instances from a Windows 11 template doesn't work?


GitHub link: https://github.com/apache/cloudstack/discussions/11791

----
This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscribe@cloudstack.apache.org


RE: EXTERNAL: Re: [D] Failed to create volume from template on ceph storage [cloudstack]

Posted by Marc Van der Sypt <MV...@bbtk-abvv.be.INVALID>.
Hi Sven,

Did you use Windows 11 24H2 or 25H2? Could you also try with Windows 11 22H2 or 23H2 to see if you have the same issue? I had a similar experience with winsrvr 2025 and reverted to 2022 for now

Marc

-----Original Message-----
From: svenknockaert (via GitHub) <gi...@apache.org>
Sent: zaterdag 11 oktober 2025 9:36
To: users@cloudstack.apache.org
Subject: EXTERNAL: Re: [D] Failed to create volume from template on ceph storage [cloudstack]


GitHub user svenknockaert edited a discussion: Failed to create volume from template on ceph storage

We are experiencing an issue when creating a template from an instance’s volume.
In the GUI, the process seems to complete successfully — the status shows as “ready.”
However, when this image is then used to deploy (and start) a new instance, an error appears:
```
Error
Unable to start a VM [587b6b50-9b00-4604-b0e6-992e7013b110] due to [Unable to create a deployment for VM instance {"id":447,"instanceName":"i-71-447-VM","state":"Starting","type":"User","uuid":"587b6b50-9b00-4604-b0e6-992e7013b110"}].
```

The root cause of the problem is likely visible in the database:

Here is a working entry from the database:
```
+-------------+----+----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+-----------------------------------------------------+------+
| template_id | id | install_path                                                   | local_path                                                                                           | error_str                                           | url  |
+-------------+----+----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+-----------------------------------------------------+------+
|         237 | 67 |
| template/tmpl/2/237/916c05d8-fe0a-3290-a77b-0823c041db3d.qcow2 |
| /mnt/SecStorage/1609b869-700e-3b63-876b-3c8abfd394d6/template/tmpl/2/2
| 37/dnld2323592655182356492tmp_ | Install completed successfully at
| 9/19/25, 10:30 AM | NULL |
+-------------+----+----------------------------------------------------------------+------------------------------------------------------------------------------------------------------+-----------------------------------------------------+------+
```

But with my last attempts i get (not working entry):

```
+-------------+----+----------------------------------------------------------------+------------+-----------+------+
| template_id | id | install_path                                                   | local_path | error_str | url  |
+-------------+----+----------------------------------------------------------------+------------+-----------+------+
|         260 | 87 | template/tmpl/2/260/b12973d6-5c82-4b6d-bfa4-e552b9ece7ff.qcow2 | NULL       | NULL      | NULL |
+-------------+----+----------------------------------------------------------------+------------+-----------+------+
1 row in set (0.00 sec)
```

You can see that the “local_path” field is no longer populated, and there is also no successful error_str entry.
However, the secondary storage is accessible to the CloudStack Management Server, and the template has indeed been copied to the secondary storage (as shown by the install_path).

What could be the reason why CloudStack no longer defines a local_path, causing instance deployments based on that template to fail?

Using Cloudstack 4.20.1.0

UPDATE:
-----------

In the meantime, I know that it has nothing to do with the "local_path" field, because when I convert a volume from an existing Linux instance (e.g. Rocky) to a template, that works fine. I can then deploy new instances from it perfectly.

However, the problem occurs when converting the volume to a template of a Windows 11 instance. The Windows 11 instance was installed via the Windows ISO installation and works fine, and all virtio drivers are installed. The Windows 11 instance is UEFI secure, but that's also the case with the working Rocky Linux template, so it has nothing to do with the UEFI capabilities (I suppose).

In the logs I see the following:

```
com.cloud.exception.InsufficientServerCapacityException:
Unable to create a deployment for VM instance ...
Scope=interface com.cloud.dc.DataCenter; id=1 ```

So I don't really understand the problem since it is definitely possible to run Windows 11 instances with UEFI Secure.
But deploying instances based on the template (on the same KVM hosts) doesn't work.

Does anyone have an idea why deploying instances from a Windows 11 template doesn't work?


GitHub link: https://github.com/apache/cloudstack/discussions/11791

----
This is an automatically sent email for users@cloudstack.apache.org.
To unsubscribe, please send an email to: users-unsubscribe@cloudstack.apache.org

PENSEZ À LA SÉCURITÉ : cet e-mail a été envoyé par une adresse externe au SETCa-BBTK. Ne cliquez pas sur les liens ou les annexes, sauf si l'expéditeur est connu.
DENK VEILIG: deze email werd verzonden door een adres extern aan BBTK-SETCa. Klik niet op links of bijlages, tenzij de afzender bekend is.
+++ SETCa-BBTK e-mail disclaimer – www.setca.org/email +++