cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-9025) Unable to deploy VM instance from template if template spin from linked clone snapshot
Date Sat, 06 Jan 2018 08:56:04 GMT


ASF subversion and git services commented on CLOUDSTACK-9025:

Commit 1d0f2128f62ff32b9cff27f6de1ed711563b656b in cloudstack's branch refs/heads/master from
[;h=1d0f212 ]

[CLOUDSTACK-9025][CLOUDSTACK-10128] solve problems of templates created based on snapshots

The first PR(#1176) intended to solve #CLOUDSTACK-9025 was only tackling the problem for CloudStack
deployments that use single hypervisor types (restricted to XenServer). Additionally, the
lack of information regarding that solution (poor documentation, test cases and description
in PRs and Jira ticket) led the code to be removed in #1124 after a long discussion and analysis
in #1056. That piece of code seemed logicless (and it was!).  It would receive a hostId and
then change that hostId for other hostId of the zone without doing any check; it was not even
checking the hypervisor and storage in which the host was plugged into.

The problem reported in #CLOUDSTACK-9025 is caused by partial snapshots that are taken in
XenServer. This means, we do not take a complete snapshot, but a partial one that contains
only the modified data. This requires rebuilding the VHD hierarchy when creating a template
out of the snapshot. The point is that the first hostId received is not a hostId, but a system
VM ID(SSVM). That is why the code in #1176 fixed the problem for some deployment scenarios,
but would cause problems for scenarios where we have multiple hypervisors in the same zone.
We need to execute the creation of the VHD that represents the template in the hypervisor,
so the VHD chain can be built using the parent links.

This commit changes the method,
Command). From now on we replace the hostId that is intended to execute the “copy command”
that will create the VHD of the template according to some conditions that were already in
place. The idea is that starting with XenServer 6.2.0 hotFix ESP1004 we need to execute the
command in the hypervisor host and not from the SSVM. Moreover, the method was improved making
it readable and understandable; it was also created test cases assuring that from XenServer
6.2.0 hotFix ESP1004 and upward versions we change the hostId that will be used to execute
the “copy command”.

Furthermore, we are not selecting a random host from a zone anymore. A new method was introduced
in the HostDao called “findHostConnectedToSnapshotStoragePoolToExecuteCommand”, using
this method we look for a host that is in the cluster that is using the storage pool where
the volume from which the Snaphost is taken of. By doing this, we guarantee that the host
that is connected to the primary storage where all of the snapshots parent VHDs are stored
is used to create the template.

Consider using Disabled hosts when no Enabled hosts are found

This also closes #2317

> Unable to deploy VM instance from template if template spin from linked clone snapshot
> --------------------------------------------------------------------------------------
>                 Key: CLOUDSTACK-9025
>                 URL:
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: XenServer
>    Affects Versions: 4.5.2
>         Environment: XenServer 6.5
>            Reporter: Anshul Gangwar
>            Assignee: Anshul Gangwar
>            Priority: Critical
>             Fix For: 4.6.0
> As default, CloudStack create linked clone snapshot for VM instance . When we take a
snapshot for the VM, and create a template based on such snapshot, CloudStack only download
incremental VHD as template file, as a result, the VM instance fail to deploy as it is incomplete.

This message was sent by Atlassian JIRA

View raw message