Re: [PVE-User] offline VM migration node1->node2 with local storage

Re: [PVE-User] offline VM migration node1->node2 with local storage

[Roland]

Hello,

to pick up this older one:

>>On 2/16/20 11:28 AM, Roland @web.de wrote:
>/> why do i need to have the same local storage name when migrating a vm />>/from node1 to node2 in dual-node cluster with local disks ? />>//>>/i'm curious that migration is possible in online state (which is much />>/more complex/challenging task) without a problem, but offline i get />/> "storage is not available on selected target" (because there are />/> differenz zfs pools on both machines) />
>This is because offline and online migration use two very different
>mechanism.
>AFAIK Qemu NBD is used for online migration and ZFS send->recv is used
>for offline migration.

i had a closer look on offline-migration, and apparently zfs send->recv is only
being used with ZVOLS, the default for VMs on ZFS.
for normal (qcow/raw...) files on any filesystem (even zfs), pvesm export/import
is being used.

this is working straightforward and apparently, it seems there is missing
appropriate logic inside proxmox including missing parameterization in the webgui
(and probably error handling etc..) !?

for example, on the target system i can open a "receiver" like this:
# pvesm import ${TARGETDS}:100/vm-100-disk-0.qcow2 qcow2+size tcp://10.16.37.0/24 -with-snapshots 1 -allow-rename 1

where on the source i can send the data like this:
# /sbin/pvesm export ${SOURCEDS}:100/vm-100-disk-0.qcow2 qcow2+size - -with-snapshots 1|mbuffer -O 10.16.37.55:60000

so we apparently see, what's being needed exists at the base level...

>>//>>/i guess there is no real technical hurdle, it just needs to get />>/implemented appropriatley !? />
>There is a patch in the works to make different target storages possible
>for offline migration.

has there been any progress on this in the meantime ?

regards
Roland

Re: [PVE-User] offline VM migration node1->node2 with local storage

[Roland privat]

thanks, very nice feature! 

hope it will be available in webgui one day, though.

roland

> 
> Am 26.03.2021 um 17:15 schrieb Fabian Grünbichler <f.gruenbichler@proxmox.com>:
> 
> 
>> Roland <devzero@web.de> hat am 26.03.2021 16:29 geschrieben:
>> 
>> 
>> Hello,
>> 
>> to pick up this older one:
>> 
>>>>> On 2/16/20 11:28 AM, Roland @web.de wrote:
>>> /> why do i need to have the same local storage name when migrating a vm />>/from node1 to node2 in dual-node cluster with local disks ? />>//>>/i'm curious that migration is possible in online state (which is much />>/more complex/challenging task) without a problem, but offline i get />/> "storage is not available on selected target" (because there are />/> differenz zfs pools on both machines) />
>>> This is because offline and online migration use two very different
>>> mechanism.
>>> AFAIK Qemu NBD is used for online migration and ZFS send->recv is used
>>> for offline migration.
>> 
>> i had a closer look on offline-migration, and apparently zfs send->recv is only
>> being used with ZVOLS, the default for VMs on ZFS.
>> for normal (qcow/raw...) files on any filesystem (even zfs), pvesm export/import
>> is being used.
>> 
>> this is working straightforward and apparently, it seems there is missing
>> appropriate logic inside proxmox including missing parameterization in the webgui
>> (and probably error handling etc..) !?
>> 
>> for example, on the target system i can open a "receiver" like this:
>> # pvesm import ${TARGETDS}:100/vm-100-disk-0.qcow2 qcow2+size tcp://10.16.37.0/24 -with-snapshots 1 -allow-rename 1
>> 
>> where on the source i can send the data like this:
>> # /sbin/pvesm export ${SOURCEDS}:100/vm-100-disk-0.qcow2 qcow2+size - -with-snapshots 1|mbuffer -O 10.16.37.55:60000
>> 
>> so we apparently see, what's being needed exists at the base level...
>> 
>>>> //>>/i guess there is no real technical hurdle, it just needs to get />>/implemented appropriatley !? />
>>> There is a patch in the works to make different target storages possible
>>> for offline migration.
>> 
>> has there been any progress on this in the meantime ?
> 
> for compatible storages and setups (e.g., snapshots/replication impose further restrictions since that is hard to carry across different storage types/formats), --targetstorage should allow both live and offline migration and switching storages in one go. you can provide either a single targetstorage, or mappings of source to target storages, or a combination (which means the single storage is used as fallback for storages for which no explicit mapping exists).
> 

Re: [PVE-User] offline VM migration node1->node2 with local storage

[Fabian Grünbichler]

> Roland <devzero@web.de> hat am 26.03.2021 16:29 geschrieben:
> 
>  
> Hello,
> 
> to pick up this older one:
> 
> >>On 2/16/20 11:28 AM, Roland @web.de wrote:
> >/> why do i need to have the same local storage name when migrating a vm />>/from node1 to node2 in dual-node cluster with local disks ? />>//>>/i'm curious that migration is possible in online state (which is much />>/more complex/challenging task) without a problem, but offline i get />/> "storage is not available on selected target" (because there are />/> differenz zfs pools on both machines) />
> >This is because offline and online migration use two very different
> >mechanism.
> >AFAIK Qemu NBD is used for online migration and ZFS send->recv is used
> >for offline migration.
> 
> i had a closer look on offline-migration, and apparently zfs send->recv is only
> being used with ZVOLS, the default for VMs on ZFS.
> for normal (qcow/raw...) files on any filesystem (even zfs), pvesm export/import
> is being used.
> 
> this is working straightforward and apparently, it seems there is missing
> appropriate logic inside proxmox including missing parameterization in the webgui
> (and probably error handling etc..) !?
> 
> for example, on the target system i can open a "receiver" like this:
> # pvesm import ${TARGETDS}:100/vm-100-disk-0.qcow2 qcow2+size tcp://10.16.37.0/24 -with-snapshots 1 -allow-rename 1
> 
> where on the source i can send the data like this:
> # /sbin/pvesm export ${SOURCEDS}:100/vm-100-disk-0.qcow2 qcow2+size - -with-snapshots 1|mbuffer -O 10.16.37.55:60000
> 
> so we apparently see, what's being needed exists at the base level...
> 
> >>//>>/i guess there is no real technical hurdle, it just needs to get />>/implemented appropriatley !? />
> >There is a patch in the works to make different target storages possible
> >for offline migration.
> 
> has there been any progress on this in the meantime ?

for compatible storages and setups (e.g., snapshots/replication impose further restrictions since that is hard to carry across different storage types/formats), --targetstorage should allow both live and offline migration and switching storages in one go. you can provide either a single targetstorage, or mappings of source to target storages, or a combination (which means the single storage is used as fallback for storages for which no explicit mapping exists).