[openstack-dev] [nova] Would an api option to create an instance without powering on be useful?
I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on. This would involve an api change, and a hopefully very small change in drivers to support it. Technically I don't see it as an issue. However, is it a change we'd be willing to accept? Is there any good reason not to do this? Are there any less esoteric workflows which might use this feature? Matt -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG Phone: +442070094448 (UK) __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Fri, Nov 30, 2018 at 7:07 AM Matthew Booth <mbooth@redhat.com> wrote:
I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on.
This would involve an api change, and a hopefully very small change in drivers to support it. Technically I don't see it as an issue.
However, is it a change we'd be willing to accept? Is there any good reason not to do this? Are there any less esoteric workflows which might use this feature?
If you upload an image of said VM which you don't boot, you'd really be accomplishing the same thing, no? Unless you want to be in a state where you want the VM to be there but sitting in SHUTOFF state
Matt -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG
Phone: +442070094448 (UK)
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
-- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser@vexxhost.com W. http://vexxhost.com __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On Fri, 2018-11-30 at 09:40 -0500, Mohammed Naser wrote:
On Fri, Nov 30, 2018 at 7:07 AM Matthew Booth <mbooth@redhat.com> wrote:
I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on.
This would involve an api change, and a hopefully very small change in drivers to support it. Technically I don't see it as an issue.
However, is it a change we'd be willing to accept? Is there any good reason not to do this? Are there any less esoteric workflows which might use this feature?
If you upload an image of said VM which you don't boot, you'd really be accomplishing the same thing, no?
Unless you want to be in a state where you want the VM to be there but sitting in SHUTOFF state
i think the intent was to have a vm ready to go with ips/ports, volumes exctra all created so you can quickly start it when needed. if that is the case another alternitive which might be more public cloud freidly form a wallet perspecitve would be the ablity to create a shelved isntace. that way all the ports ectra would be logically created but it would not be consumeing any compute resources.
Matt -- Matthew Booth Red Hat OpenStack Engineer, Compute DFG
Phone: +442070094448 (UK)
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
On 11/30/2018 07:06 AM, Matthew Booth wrote:
I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on.
This would involve an api change, and a hopefully very small change in drivers to support it. Technically I don't see it as an issue.
However, is it a change we'd be willing to accept? Is there any good reason not to do this? Are there any less esoteric workflows which might use this feature?
It's similar to the node import use case from Ironic. I can see use cases for registering pre-created instances (or creating batches of instance records from previously non-OpenStack-managed workloads). Lots of corner cases would need to be fleshed out, though. I know at Oath we've got some pretty nasty code to register non-OpenStack baremetal workloads with OpenStack and make sure they cannot be scheduled and are not reimaged/cleaned by Ironic. So, I'm generally supportive of the idea. But devil's in the details of course. :) Best, -jay
On 11/30/18 6:06 AM, Matthew Booth wrote:
I have a request to do $SUBJECT in relation to a V2V workflow. The use case here is conversion of a VM/Physical which was previously powered off. We want to move its data, but we don't want to be powering on stuff which wasn't previously on.
This would involve an api change, and a hopefully very small change in drivers to support it. Technically I don't see it as an issue.
However, is it a change we'd be willing to accept? Is there any good reason not to do this? Are there any less esoteric workflows which might use this feature?
I don't know if it qualifies as less esoteric, but I would use this for OVB[1]. When we create the "baremetal" VMs there's no need to actually power them on since the first thing we do with them is shut them down again. Their initial footprint is pretty small so it's not a huge deal, but it is another potential use case for this feature. 1: https://openstack-virtual-baremetal.readthedocs.io/en/latest/introduction.ht... __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
participants (5)
-
Ben Nemec
-
Jay Pipes
-
Matthew Booth
-
Mohammed Naser
-
Sean Mooney