[ClusterLabs] Antw: Re: Antw: Re: design of a two-node cluster

[Digimer]

On 08/12/15 08:35 AM, Ulrich Windl wrote:
>>>> "Lentes, Bernd" <bernd.lentes at helmholtz-muenchen.de> schrieb am 08.12.2015 um
> 13:10 in Nachricht <012101d131b1$5ec1b2e0$1c4518a0$@helmholtz-muenchen.de>:
>> Ulrich wrote:
>>
>>>
>>>>>> "Lentes, Bernd" <bernd.lentes at helmholtz-muenchen.de> schrieb
>>> am
>>>>>> 08.12.2015 um
>>> 09:13 in Nachricht <00a901d13190$5c6db3c0$15491b40$@helmholtz-
>>> muenchen.de>:
>>>> Digimer wrote:
>>>>
>>>>>>>> Should I install all vm's in one partition or every vm in a
>>>>>>>> seperate partition ? The advantage of one vm per partition is
>>>>>>>> that I don't need a cluster fs, right ?
>>>>>>>
>>>>>>> I would put each VM on a dedicated LV and not have an FS
>>> between
>>>>> the
>>>>>>> VM and the host. The question then becomes; What is the PV? I
>>> use
>>>>>>> clustered LVM to make sure all nodes are in sync, LVM-wise.
>>>>>>
>>>>>> Is this the setup you are running (without fs) ?
>>>>>
>>>>> Yes, we use DRBD to replicate the storage and use the /dev/drbdX
>>>>> device as the clustered LVM PV. We have one VG for the space (could
>>>>> add a new DRBD resource later if needed...) and then create a
>>>>> dedicated LV per VM.
>>>>> We have, as I mentioned, one small LV formatted with gfs2 where we
>>>>> store the VM's XML files (so that any change made to a VM is
>>>>> immediately available to all nodes.
>>>>>
>>>>
>>>> How can i migrate my current vm's ? They are stored in raw files (one
>>>> or two).
>>>> How do I transfer them to a naked lv ?
>>>
>>> For migration the image must be available on both nodes (thus gfs2).
>>>
>>>>
>>
>> Hi Ulrich,
>>
>> the migration i meant is the transition from my current setup (virtual
>> machines in raw files in a partition with filesystem) to the one
>> anticipated in the cluster (virtual machines in blank logical volumes
>> without fs). How can I do that ? And can I expand my disks in the vm
>> afterwards if necessary ?
> 
> You can copy the images with rsync or similar while the VMs are down. Then you'll have the same filesystem layout. If you want to change the partition sizes, I'd suggest to create new disks and partitions, the mount the partitions on old and new system, and then rsync (or similar) the _files_ from OLD to NEW. Some boot loaders may need some extra magic. If you use LVM, you might just add another disk to the VM, then make that disk a PV and add it to the VG. Then you can expand your LVs inside the VM.
> 
>> But the "other" migration (live-migration of vm's) is of course also
>> interesting. Digimer wrote if I have my vm in a blank logical volume
>> without fs, which is placed on a SAN, I can live-migrate because the
>> process of live-migration takes care about the access to the lv and I
>> don't need a cluster fs, just cLVM.
> 
> If logical volume means LUN (disk), I'd agree. If you mean LVM LV, I'd be very careful, especially when changing the LVM configuration. If you never plan to change LVM configuration, you could consider partitioning your disk with GPT with one partition for each VM.
> 
> Regards,
> Ulrich

This approach is to do it from the VM's level, and it is not needed. The
VM does need to be stopped, yes, but you can simple go from a raw format
to the LV using dd, in my experience.

-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?