cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alena Prokharchyk (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (CLOUDSTACK-7194) deployvirtualmachine command hypervisor argument inconsistent
Date Mon, 04 Aug 2014 21:24:12 GMT

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-7194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Alena Prokharchyk resolved CLOUDSTACK-7194.
-------------------------------------------

    Resolution: Fixed

Fixed with:

commit 05d056bb90c80a42a8be087bdac5f0ed93bc3462
Author: Alena Prokharchyk <alena.prokharchyk@citrix.com>
Date:   Mon Aug 4 13:39:53 2014 -0700

    CLOUDSTACK-7194: deployVm Api, "hypervisor" parameter:
    * is respected only when vm is deployed from ISO, or hypervisorType is not set on the
template record
    * if parameter passed when vm is deployed from template having hypervisor info set, validate
that these 2 parameters are the same instead of silently defaulting the final value to the
one set on the template


> deployvirtualmachine command hypervisor argument inconsistent
> -------------------------------------------------------------
>
>                 Key: CLOUDSTACK-7194
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7194
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: API
>    Affects Versions: 4.5.0
>         Environment: Observed running basic BVT against KVM hosts
>            Reporter: Alex Brett
>            Assignee: Alena Prokharchyk
>
> The deployvirtualmachine API command takes a hypervisor argument. When used with an ISO,
this argument has an effect and restricts which type of hypervisor the instance gets deployed
to.
> When used with a template however, it is the hypervisor type of the template that matters.
As such you can call deployvirtualmachine giving it a hypervisor argument of "XenServer",
but a template that is deployed against a KVM host, and the resulting instance will be running
on KVM. In fact you can even give it an argument of "XenServer" when you don't have any XenServer
hosts, and it will still work properly.
> There is however some validation performed on the hypervisor argument - for example if
you attempt to deploy a virtual machine from a KVM based template, specifying a hypervisor
type of "XenServer", and attempt to specify a rootdisksize override (as in the integration.smoke.test_deploy_vm_root_resize
automated tests), you get this error back:
> {noformat}
> Hypervisor XenServer does not support rootdisksize override
> {noformat}
> This is very inconsistent - my suggestion to make this more sensible therefore would
be to do one of the following:
> * Validate the hypervisor argument against the hypervisor of the template, and return
an error if they differ
> * Ignore (or perhaps don't accept) the hypervisor argument when deploying from a template,
and ensure all validation etc is performed using the hypervisor parameter of the template



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message