You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by "Werner, Mark" <Ma...@unisys.com> on 2018/12/20 00:45:13 UTC
Import VMs into CloudStack
Hi,
I am curious to know if I am doing migrations of workloads into a virtual
infrastructure, in this case KVM, that is managed by CloudStack, and I
perform the migrations directly to the hypervisor('s), is there a way then
to register or import those migrated VM instances into the CloudStack
environment / inventory so that CloudStack is aware of them and can manage
them?
Thanks,
Mark Werner | Senior Systems Engineer | Cloud & Infrastructure Services
Unisys | Mobile Phone 586.214.9017 | <ma...@unisys.com>
mark.werner@unisys.com
11720 Plaza America Drive, Reston, VA 20190
<http://www.unisys.com/>
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is for use only by the intended recipient. If you received this
in error, please contact the sender and delete the e-mail and its
attachments from all devices.
<http://www.linkedin.com/company/unisys> <http://twitter.com/unisyscorp>
<https://plus.google.com/+UnisysCorp/posts>
<http://www.youtube.com/theunisyschannel>
<http://www.facebook.com/unisyscorp> <https://vimeo.com/unisys>
<http://blogs.unisys.com/>
Re: Import VMs into CloudStack
Posted by Nicolas Vazquez <Ni...@shapeblue.com>.
Hi Mark,
As Andrija mentioned that is not possible yet. However, it is possible that as a part of the future Backup and Recovery framework: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Backup+and+Recovery+Framework some backup vendor plugins would require to import a restored VM into CloudStack. That mechanism could be exposed on the CloudStack API too, allowing to import existing VMs into CloudStack.
Regards,
Nicolas Vazquez
________________________________
From: Andrija Panic <an...@gmail.com>
Sent: Thursday, December 20, 2018 4:49:44 AM
To: users
Subject: Re: Import VMs into CloudStack
Hi Mark,
unfortunately that is not possible (not in an official way at least) - since CloudStack is keeping tons of meta-data (info about VM hardware and such) in DB.
For simpler VMs, you could *experiment* with deploying brand new VM with (empty) appropriate disk sizes, shutdown VM, then go and replace QCOW2 files on your NFS storage with original volumes, but again this is all hacking and is not really guarantied to work - MAC and IP address would certainly change etc, perhaps underlying hardware for VM and you would need to play with drivers potentially (for sure if Windows VMs) - not the best approach - but is possible to work.
Normal way would be to export original ROOT (system/OS, say, /dev/vda) volume of your VM as qcow2 files to some web server (optionally RAW format, but that is both inefficient and might have its issues) and then register it as template inside CloudStack and finally deploy new VM in regular way - still some play with drivers etc might be needed, possible mount points (if not used UUID of volume in /etc/fstab), change MAC address of VM (i.e. delete udev rules for network, reboot VM), etc.
For data volumes (i.e. vdb and onwards) you would just upload qcow2 file as Volume to CloudStack - and attach it to your VM (this "attach" is "lazy" attach - meaning when you power on VM very first time (or you hot-plugged the volume during VM running...) CloudStack will move the qcow2 data file that you uploaded, from Secondary NFS to Primary Storage - and this move (qemu-img convert) takes time obviously...so you are not confused why it's so long for the first time.
Just in case you have some Windows VMs - you would probably need to initialize HAL again (google this or ping me if needed) - especially if changing from emulated/IDE stuff to VirtIO (otherwise you will get nice BSOD as usual with driver issues)
CloudStack is an awesome stuff, just give it a try.
Hope that helps
Andrija
Nicolas.Vazquez@shapeblue.com
www.shapeblue.com
Amadeus House, Floral Street, London WC2E 9DPUK
@shapeblue
On Thu, 20 Dec 2018 at 01:45, Werner, Mark <Ma...@unisys.com>> wrote:
Hi,
I am curious to know if I am doing migrations of workloads into a virtual infrastructure, in this case KVM, that is managed by CloudStack, and I perform the migrations directly to the hypervisor(‘s), is there a way then to register or import those migrated VM instances into the CloudStack environment / inventory so that CloudStack is aware of them and can manage them?
Thanks,
Mark Werner | Senior Systems Engineer | Cloud & Infrastructure Services
Unisys | Mobile Phone 586.214.9017 | mark.werner@unisys.com<ma...@unisys.com>
11720 Plaza America Drive, Reston, VA 20190
[unisys_logo]<http://www.unisys.com/>
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all devices.
[Grey_LI]<http://www.linkedin.com/company/unisys> [Grey_TW] <http://twitter.com/unisyscorp> [Grey_GP] <https://plus.google.com/+UnisysCorp/posts> [Grey_YT] <http://www.youtube.com/theunisyschannel> [Grey_FB] <http://www.facebook.com/unisyscorp> [Grey_Vimeo] <https://vimeo.com/unisys> [Grey_UB] <http://blogs.unisys.com/>
--
Andrija Panić
Re: Import VMs into CloudStack
Posted by Andrija Panic <an...@gmail.com>.
Hi Mark,
unfortunately that is not possible (not in an official way at least) -
since CloudStack is keeping tons of meta-data (info about VM hardware and
such) in DB.
For simpler VMs, you could *experiment* with deploying brand new VM with
(empty) appropriate disk sizes, shutdown VM, then go and replace QCOW2
files on your NFS storage with original volumes, but again this is all
hacking and is not really guarantied to work - MAC and IP address would
certainly change etc, perhaps underlying hardware for VM and you would need
to play with drivers potentially (for sure if Windows VMs) - not the best
approach - but is possible to work.
Normal way would be to export original ROOT (system/OS, say, /dev/vda)
volume of your VM as qcow2 files to some web server (optionally RAW format,
but that is both inefficient and might have its issues) and then register
it as template inside CloudStack and finally deploy new VM in regular way -
still some play with drivers etc might be needed, possible mount points (if
not used UUID of volume in /etc/fstab), change MAC address of VM (i.e.
delete udev rules for network, reboot VM), etc.
For data volumes (i.e. vdb and onwards) you would just upload qcow2 file as
Volume to CloudStack - and attach it to your VM (this "attach" is "lazy"
attach - meaning when you power on VM very first time (or you hot-plugged
the volume during VM running...) CloudStack will move the qcow2 data file
that you uploaded, from Secondary NFS to Primary Storage - and this move
(qemu-img convert) takes time obviously...so you are not confused why it's
so long for the first time.
Just in case you have some Windows VMs - you would probably need to
initialize HAL again (google this or ping me if needed) - especially if
changing from emulated/IDE stuff to VirtIO (otherwise you will get nice
BSOD as usual with driver issues)
CloudStack is an awesome stuff, just give it a try.
Hope that helps
Andrija
On Thu, 20 Dec 2018 at 01:45, Werner, Mark <Ma...@unisys.com> wrote:
> Hi,
>
>
>
> I am curious to know if I am doing migrations of workloads into a virtual
> infrastructure, in this case KVM, that is managed by CloudStack, and I
> perform the migrations directly to the hypervisor(‘s), is there a way then
> to register or import those migrated VM instances into the CloudStack
> environment / inventory so that CloudStack is aware of them and can manage
> them?
>
>
>
> Thanks,
>
>
>
> *Mark Werner* | Senior Systems Engineer | Cloud & Infrastructure Services
>
> Unisys | Mobile Phone 586.214.9017 | mark.werner@unisys.com
>
> 11720 Plaza America Drive, Reston, VA 20190
>
> [image: unisys_logo] <http://www.unisys.com/>
>
>
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is for use only by the intended recipient. If you received
> this in error, please contact the sender and delete the e-mail and its
> attachments from all devices.
>
> [image: Grey_LI] <http://www.linkedin.com/company/unisys> [image:
> Grey_TW] <http://twitter.com/unisyscorp> [image: Grey_GP]
> <https://plus.google.com/+UnisysCorp/posts>[image: Grey_YT]
> <http://www.youtube.com/theunisyschannel>[image: Grey_FB]
> <http://www.facebook.com/unisyscorp>[image: Grey_Vimeo]
> <https://vimeo.com/unisys>[image: Grey_UB] <http://blogs.unisys.com/>
>
>
>
--
Andrija Panić