[one-users] tune 'onevm saveas' behavior for OpenVZ
knawnd at gmail.com
knawnd at gmail.com
Thu Jul 28 10:15:09 PDT 2011
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.
> 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.
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
>>
More information about the Users
mailing list