[one-users] tune 'onevm saveas' behavior for OpenVZ

Tue Aug 23 04:58:29 PDT 2011

Dear Nikolay,

comments inline,

On Thu, Jul 28, 2011 at 7:15 PM,  <knawnd at gmail.com> wrote:
> Dear Tino,
>
> please, see my comments inline.
>
> Tino Vazquez wrote on 27/07/11 17:28:
>>
>> Dear Nikolay,
>>
>> First of all, apologies for the long delay in the reply, we were
>> really bussy with the 3.0 release.
>
> I perfectly understand your priorities, so no problem here.
>
>> We are more than happy to provide support for this integration, we will
>> try our best to keep this
>> snappy.
>
> just for clarity what I am currently trying to implement. For the moment I
> am trying to realize the work of OpenVZ VMs in the following ONE
> configuration: image repository is located on non-shared FS and images are
> copied over ssh. Oneadmin user's home dir is also non-shared. Only OpenVZ
> venet network device is used inside VMs (veth has not been tested yet and
> thus a network bridges on cluster nodes are not used, see [1 - 3]).
>
>> The problem you are facing is similar to the one posed by VMware,
>> where disks are multiple files that can be packed in a folder. This
>> problem is solved in 2.2 and also 3.0.
>
> Initially a OS image for OpenVZ based VM is a tarball (i.e. a single file)
> with whole root file system. But during OpenVZ VM creation the root tree is
> extracted from such OS image into particular dir which becomes root fs for
> corresponding VM. So taking that into account as well as the image
> repository implementation in OpenNebula version 2.2.1 (i.e. impossibility to
> register a folder but only a single file) one can make the following
> conclusions:
> 1) OpenVZ OS images (they are called OS templates in OpenVZ jargon) can be
> register in ONE Image Repository and used for OpenVZ VM creation.
> 2) It shouldn't be too hard to make 'onevm saveas' command works as well as
> enabling "SAVE" sub-attribute for DISK attribute since both of these
> features are triggered upon VM shutdown and the only additional step what
> needs to be done is to archive OpenVZ VM working dir and  replace disk.0
> with that archive before registering it in ONE Image Repository.
> 3) A persistent image feature can't be easily implemented despite of
> OpenNebula version since a different objects are used to create VM (from a
> single file - OS image/template) and to run it (a dir).
> So I would propose just to implement a functionality mentioned in item 2 of
> the list above (onevm saveas and SAVE sub-attribute).
>
>>  If it is ok with you, we can tackle both, although I think the 3.0
>> integration is the way to go.
>
> I agree that we should give a preference for 3.0 version. But if we are
> talking about the implementation provided by 'onevm saveas' and SAVE
> sub-attribute i.e. registration of a single file but not a whole dir then I
> guess a necessary changes suit both OpenNebula versions (2.2.1 and 3.0).
>
>> Let's go first for the 2.2, since it is the one you are using.
>
> probably what I wrote above answers your questions below but let me comment
> on them anyway
>
>> The problem is more general that the save_as I think. If you are using
>> the image repository, in order to register an image you should
>> register a folder.
>> In VMware driver, this is solved with a new command
>> (onevmware) for 2.2, and using a prefix in 3.0 (the 3.0 features a new
>> Image Catalog driver, when it sees the vmware:// prefix it copies the
>> whole directory). If you did not tackle this, maybe we can leave it
>> for 2.2 as it is now (that is, not supporting the image catalog, how
>> do you specify the disks now?
>
>> do you set the path in DISK=[SOURCE=""]
>> and then treat it from a custom made transfer manager?). What do you
>> think?
> right now I am registering OpenVZ OS template in ONE image repository
> e.g.
> $ cat centos-5.x86.one.img
> NAME          = "centos-5-x86"
> PATH          = "/srv/cloud/one/one-2.1.8/var/images/centos-5-x86.tar.gz"
> PUBLIC        = YES
> DESCRIPTION   = "CentOS 5 x86 OpenVZ template"
>
>  and refer to it in VM description file by image name as
> DISK = [ IMAGE  = "centos-5-x86" ]
>
> There is a strong requirement: OS image name for OpenVZ VM has to be the
> same as OpenVZ template filename excluding extension (e.g. NAME is
> centos-5-x86 for OpenVZ OS template file centos-5-x86.tar.gz).
>
>> Regarding you question, the file to modify I think it would be
>> $ONE_LOCATION/lib/ruby/ImageRepository.rb, line 136. Now it is doing a
>> move, so it may work.
>> Did you try this? What error message do you get?
>
> No, I haven't tried it since it doesn't make a sense to try without tuning
> it as it was described above. Let me briefly explain.
> For the moment the implemented procedure for OpenVZ VM creation is the
> following:
> 1) a file with OS image mentioned in OpenNebula VM description file is
> transferred  to Cluster node (CN) in $VM_DIR/<VMID>/images dir with file
> name disk.0.
> 2) OpenVZ hypervisor expects all OS images file be placed in one dir defined
> in /etc/vz/vz.conf file. So there is no way to create VM by specifying a
> custom (e.g. absolute) path to OpenVZ OS image. All OpenVZ OS images must be
> in defined dir. The OS image can be chosen by its filename. For that purpose
> a $SCRIPTS_REMOTE_DIR/vmm/ovz/deploy script makes a symlink with a filename
> specified by user in NAME attribute of OpenNebula image description file to
> $VM_DIR/<VMID>/images/disk.0 in dir where OpenVZ hypervisor expects to find
> required OS image (by default it's is /vz/template/cache). So it looks like
> /vz/template/cache/centos-5-x86.tar.gz -> $VM_DIR/<VMID>/images/disk.0.
> 3) $VM_DIR/<VMID>/images/disk.0 file is used only to create new VM. During
> that procedure the content of that file is extracted to another predefined
> but configurable dir (by default it is /vz/private/<VMID>). When VM is
> running it uses the content of that dir and not $VM_DIR/<VMID>/images/disk.0
> file i.e. that file is not updated/modified by running VM but a files in
> /vz/private/<VMID> dir are.
> That's why it doesn't make a sense to try 'onevm saveas' command without
> modifying appropriate OpenNebula code/scripts since that command would save
> original  disk.0 file which exact copy is already registered in ONE Image
> Repository.

Ok, I get it now, so you need to package the copy directory rather
than the original.

>
>> Please get back with your plans for 2.2 and 3.0 and we will move on,
>> we can provide help with the ruby scripting.
>
> So for now I would like to make a 'onevm saveas' command work with OpenVZ
> VMs as well as if the SAVE sub-attribute is set to yes for OpenNebula 2.2.1.
> As far as I understand both these features trigger
> $ONE_LOCATOIN/share/hooks/image.rb script. So in order to achieve a desired
> behavior a command like 'tar -czf $VM_DIR/<VMID>/images/disk.0 -C
> /vz/private/<VMID>/ *' must be executed in the beginning of that hook
> (image.rb) what would replace the original disk.0 file. Is that correct?
> I would appreciate any help on that.

Yes, this seems like a good approach. Have you tried it out? It look fine to me.

Regards, and many thanks for the detailed emails (it does help a long
way in understanding the issue ;))

-Tino

--
Constantino Vázquez Blanco, MSc
OpenNebula Major Contributor
www.OpenNebula.org | @tinova79

>
> Please, let me know if more info is needed.
>
> [1] http://wiki.openvz.org/Venet
> [2] http://wiki.openvz.org/Veth
> [3] http://wiki.openvz.org/Differences_between_venet_and_veth
>
> Best regards,
> Nikolay.
>>
>> Hope it helps,
>>
>> -Tino
>>
>>
>> --
>> Constantino Vázquez Blanco, MSc
>> OpenNebula Major Contributor
>> www.OpenNebula.org | @tinova79
>>
>>
>>
>> On Mon, Jul 18, 2011 at 6:50 PM,<knawnd at gmail.com>  wrote:
>>>
>>> Dear OpenNebula developers,
>>>
>>> I need some help to tune the behavior of 'onevm saveas' command in case
>>> of
>>> OpenVZ  VMs.
>>> The only change needs to be made in its current behavior is to archive a
>>> root dir of particular OpenVZ VM and register that archive as a new OS
>>> image
>>> in ONE image repository since OpenVZ VM filesystem is not a single file
>>> but
>>> a directory on the host server (for more details see [1]).
>>> I am not sure what file(s) needs to be modified: $ONE_LOCATION/bin/onevm
>>> (771 - 836 lines) or/and $ONE_LOCATION/share/hooks/image.rb.
>>> Could you, please, help me with the implementation of described
>>> functionality since I have no experience in ruby programming?
>>>
>>> For the time being I am using stable version of OpenNebula 2.2.1.
>>> Please, let me know if more info needs to be provided.
>>>
>>> Regards,
>>> Nikolay.
>>>
>>> [1] http://wiki.openvz.org/WP/What_are_containers
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opennebula.org
>>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>>
>