[pve-devel] [PATCH] Use block storage migration for migration of KVM machines with local based storages

[Kamil Trzciński]

It was not very clear. Currently it works like for backups: vm is started
in pause mode.

On Wed, Nov 5, 2014 at 9:30 AM, Alexandre DERUMIER <aderumier at odiso.com>
wrote:

> >>- for stopped VM start it for migration
>
> I don't have reviewed the code yet, but is the VM started only in case of
> local storage (non-shared)?
>
> Because it don't make sense to start the vm and do memory migration, if
> the vm is stopped and storage is shared.
>
>
> Also, if the vm is stopped and storage is local, we can start the vm in
> pause mode (like for backup).
> Alternativily, I think it could be possible to start an nbd server on
> target node and use qemu-img convert to copy the disk. (vm offline)
>
>
>
>
>
>
> ----- Mail original -----
>
> De: "Daniel Hunsaker" <danhunsaker at gmail.com>
> À: "Kamil Trzciński" <ayufan at ayufan.eu>
> Cc: pve-devel at pve.proxmox.com
> Envoyé: Mercredi 5 Novembre 2014 01:48:15
> Objet: Re: [pve-devel] [PATCH] Use block storage migration for migration
> of KVM machines with local based storages
>
>
> On Nov 3, 2014 4:13 AM, "Kamil Trzcinski" < ayufan at ayufan.eu > wrote:
> >
> > - for stopped VM start it for migration
> This may not always be desired. For example, I often create VMs on one
> node, but don't want them to spin up until they're on another node. I
> create/maintain templates on an internal node which connects via OpenVPN to
> the public nodes, so my workflow makes more sense with create locally,
> migrate, then start, since my internal system isn't configured anywhere
> close to how my external systems are. Some of these systems wouldn't even
> start internally, since they rely on the host being set up how the external
> nodes are, and the internal node isn't set up that way.
> I guess what I'm saying is it would be good to at least have a node-level
> option to disable this step (starting VMs before migration is a sane
> default, just let me opt out). The more granularity the better, but there
> does come a point where options become excessive, so per-VM or
> per-migration disable might be overkill.
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>



-- 
Kamil Trzciński

ayufan at ayufan.eu
www.ayufan.eu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.proxmox.com/pipermail/pve-devel/attachments/20141105/d4da6f9c/attachment.htm>