Hi there,
I'm a long time user of Xen virtualisation and have been evaluating 
OpenVZ as a replacement for certain applications.

OpenVZ appears to be technically superior under certain conditions and I 
hope to iron out the issues that I have come across.

The main issue confronting me at this time is scalability of management; 
OpenVZ may scale well with respect to performance and resource usage but 
at this time I don't see it scaling well when it comes to management of 
virtual machines.

I am sure that I must be missing something obvious since its a pretty 
basic issue. I've searched extensively for some info on this but found 
nothing.

The problem?

Numeric rather than symbolic identification of virtual machines.

When I start a domU (a Xen virtual machine) in Xen I direct 'xm create' 
at the config file the name of which corresponds to the name of that domU.

When I list currently running machines in Xen I see a listing of the 
names of the Xen domUs and their corresponding numeric IDs.

When I create a logical volume for a Xen domU I create that volume based 
on the name of the corresponding Xen instance.

In each case I try to ensure consistency by making the names of the Xen 
domUs correspond to the hostnames of the servers which those domUs are 
running. Host foo is on the domU named foo and is in a logical volume 
named foo. To start domU foo I run 'xm create 
/etc/xen/domains/foo.conf'. This scales well and makes things very nice 
and obvious.

OpenVZ seems to do away with symbolic names referring in all instances 
to numeric ids, a bit like not using DNS but putting an IP address into 
a URL.

I have an awful feeling that when the pager goes off at 2am the person 
on call, bleary-eyed and tired, will make some horrible mistake when 
trying to mentally map numeric identifiers to server hostnames. This is 
what I mean by 'not scaling well'. Use of numeric identifiers may work 
ok when there is only one or two, but when there may be a dozen things 
will get out of hand.

I am sure that there must be a way to use symbolic names instead of 
numbers in OpenVZ but I can't for the life of me find out how.

Thanks!

See vzctl set --name

Steve Wray wrote:
> Hi there,
> I'm a long time user of Xen virtualisation and have been evaluating
> OpenVZ as a replacement for certain applications.
>
> OpenVZ appears to be technically superior under certain conditions and
> I hope to iron out the issues that I have come across.
>
> The main issue confronting me at this time is scalability of
> management; OpenVZ may scale well with respect to performance and
> resource usage but at this time I don't see it scaling well when it
> comes to management of virtual machines.
>
> I am sure that I must be missing something obvious since its a pretty
> basic issue. I've searched extensively for some info on this but found
> nothing.
>
> The problem?
>
> Numeric rather than symbolic identification of virtual machines.
>
> When I start a domU (a Xen virtual machine) in Xen I direct 'xm
> create' at the config file the name of which corresponds to the name
> of that domU.
>
> When I list currently running machines in Xen I see a listing of the
> names of the Xen domUs and their corresponding numeric IDs.
>
> When I create a logical volume for a Xen domU I create that volume
> based on the name of the corresponding Xen instance.
>
> In each case I try to ensure consistency by making the names of the
> Xen domUs correspond to the hostnames of the servers which those domUs
> are running. Host foo is on the domU named foo and is in a logical
> volume named foo. To start domU foo I run 'xm create
> /etc/xen/domains/foo.conf'. This scales well and makes things very
> nice and obvious.
>
> OpenVZ seems to do away with symbolic names referring in all instances
> to numeric ids, a bit like not using DNS but putting an IP address
> into a URL.
>
> I have an awful feeling that when the pager goes off at 2am the person
> on call, bleary-eyed and tired, will make some horrible mistake when
> trying to mentally map numeric identifiers to server hostnames. This
> is what I mean by 'not scaling well'. Use of numeric identifiers may
> work ok when there is only one or two, but when there may be a dozen
> things will get out of hand.
>
> I am sure that there must be a way to use symbolic names instead of
> numbers in OpenVZ but I can't for the life of me find out how.
>
> Thanks!
>
>
>

Kir Kolyshkin wrote:
> See vzctl set --name
>   

Well thats a nice start.

Now, to follow on from that great progress, how do I get it so that the 
directory where the root filesystem lives corresponds to the name I set 
instead of the numeric VEID?

Thanks!


> Steve Wray wrote:
>   
>> Hi there,
>> I'm a long time user of Xen virtualisation and have been evaluating
>> OpenVZ as a replacement for certain applications.
>>
>> OpenVZ appears to be technically superior under certain conditions and
>> I hope to iron out the issues that I have come across.
>>
>> The main issue confronting me at this time is scalability of
>> management; OpenVZ may scale well with respect to performance and
>> resource usage but at this time I don't see it scaling well when it
>> comes to management of virtual machines.
>>
>> I am sure that I must be missing something obvious since its a pretty
>> basic issue. I've searched extensively for some info on this but found
>> nothing.
>>
>> The problem?
>>
>> Numeric rather than symbolic identification of virtual machines.
>>
>> When I start a domU (a Xen virtual machine) in Xen I direct 'xm
>> create' at the config file the name of which corresponds to the name
>> of that domU.
>>
>> When I list currently running machines in Xen I see a listing of the
>> names of the Xen domUs and their corresponding numeric IDs.
>>
>> When I create a logical volume for a Xen domU I create that volume
>> based on the name of the corresponding Xen instance.
>>
>> In each case I try to ensure consistency by making the names of the
>> Xen domUs correspond to the hostnames of the servers which those domUs
>> are running. Host foo is on the domU named foo and is in a logical
>> volume named foo. To start domU foo I run 'xm create
>> /etc/xen/domains/foo.conf'. This scales well and makes things very
>> nice and obvious.
>>
>> OpenVZ seems to do away with symbolic names referring in all instances
>> to numeric ids, a bit like not using DNS but putting an IP address
>> into a URL.
>>
>> I have an awful feeling that when the pager goes off at 2am the person
>> on call, bleary-eyed and tired, will make some horrible mistake when
>> trying to mentally map numeric identifiers to server hostnames. This
>> is what I mean by 'not scaling well'. Use of numeric identifiers may
>> work ok when there is only one or two, but when there may be a dozen
>> things will get out of hand.
>>
>> I am sure that there must be a way to use symbolic names instead of
>> numbers in OpenVZ but I can't for the life of me find out how.
>>
>> Thanks!
>>
>>
>>

Steve Wray wrote:
> Kir Kolyshkin wrote:
>> See vzctl set --name
>>   
>
> Well thats a nice start.
>
> Now, to follow on from that great progress, how do I get it so that
> the directory where the root filesystem lives corresponds to the name
> I set instead of the numeric VEID?
No standard way.

I guess you can create a symlink; something like this:
vzctl set $VEID --name $VENAME --save
(cd /vz/root && ln -s $VEID $VENAME)

Same for /vz/private if you need it.
>
> Thanks!
>
>
>> Steve Wray wrote:
>>  
>>> Hi there,
>>> I'm a long time user of Xen virtualisation and have been evaluating
>>> OpenVZ as a replacement for certain applications.
>>>
>>> OpenVZ appears to be technically superior under certain conditions and
>>> I hope to iron out the issues that I have come across.
>>>
>>> The main issue confronting me at this time is scalability of
>>> management; OpenVZ may scale well with respect to performance and
>>> resource usage but at this time I don't see it scaling well when it
>>> comes to management of virtual machines.
>>>
>>> I am sure that I must be missing something obvious since its a pretty
>>> basic issue. I've searched extensively for some info on this but found
>>> nothing.
>>>
>>> The problem?
>>>
>>> Numeric rather than symbolic identification of virtual machines.
>>>
>>> When I start a domU (a Xen virtual machine) in Xen I direct 'xm
>>> create' at the config file the name of which corresponds to the name
>>> of that domU.
>>>
>>> When I list currently running machines in Xen I see a listing of the
>>> names of the Xen domUs and their corresponding numeric IDs.
>>>
>>> When I create a logical volume for a Xen domU I create that volume
>>> based on the name of the corresponding Xen instance.
>>>
>>> In each case I try to ensure consistency by making the names of the
>>> Xen domUs correspond to the hostnames of the servers which those domUs
>>> are running. Host foo is on the domU named foo and is in a logical
>>> volume named foo. To start domU foo I run 'xm create
>>> /etc/xen/domains/foo.conf'. This scales well and makes things very
>>> nice and obvious.
>>>
>>> OpenVZ seems to do away with symbolic names referring in all instances
>>> to numeric ids, a bit like not using DNS but putting an IP address
>>> into a URL.
>>>
>>> I have an awful feeling that when the pager goes off at 2am the person
>>> on call, bleary-eyed and tired, will make some horrible mistake when
>>> trying to mentally map numeric identifiers to server hostnames. This
>>> is what I mean by 'not scaling well'. Use of numeric identifiers may
>>> work ok when there is only one or two, but when there may be a dozen
>>> things will get out of hand.
>>>
>>> I am sure that there must be a way to use symbolic names instead of
>>> numbers in OpenVZ but I can't for the life of me find out how.
>>>
>>> Thanks!
>>>
>>>
>>>

Kir Kolyshkin wrote:
> Steve Wray wrote:
>   
>> Kir Kolyshkin wrote:
>>     
>>> See vzctl set --name
>>>   
>>>       
>> Well thats a nice start.
>>
>> Now, to follow on from that great progress, how do I get it so that
>> the directory where the root filesystem lives corresponds to the name
>> I set instead of the numeric VEID?
>>     
> No standard way.
>
> I guess you can create a symlink; something like this:
> vzctl set $VEID --name $VENAME --save
> (cd /vz/root && ln -s $VEID $VENAME)
>
> Same for /vz/private if you need it.
>   
I did find that after one has created a virtual machine configuration 
one can edit its config file and add:

VE_ROOT="/var/lib/vz/root/vz1"
VE_PRIVATE="/var/lib/vz/private/vz1"

for example. I have yet to figure out the 'vzctl create' commands 
though; they appear to require an OS template tarball. While I dropped a 
root filesystem tarball into the required place, vzctl create didn't 
like it. I'll keep plugging away.

OpenVZ looks pretty good for performance scaleability but what I'd love 
to see is better management scaleability.

If there are any tools which abstract away some of the detail for 
management of multiple virtual machines I'd like to know. I did try 
easyvz (http://sourceforge.net/projects/easyvz) but there were problems 
with the python dependencies. I run Debian Etch; when I tried to run the 
gui there were issues with strange characters in the python script.



>> Thanks!
>>
>>
>>     
>>> Steve Wray wrote:
>>>  
>>>       
>>>> Hi there,
>>>> I'm a long time user of Xen virtualisation and have been evaluating
>>>> OpenVZ as a replacement for certain applications.
>>>>
>>>> OpenVZ appears to be technically superior under certain conditions and
>>>> I hope to iron out the issues that I have come across.
>>>>
>>>> The main issue confronting me at this time is scalability of
>>>> management; OpenVZ may scale well with respect to performance and
>>>> resource usage but at this time I don't see it scaling well when it
>>>> comes to management of virtual machines.
>>>>
>>>> I am sure that I must be missing something obvious since its a pretty
>>>> basic issue. I've searched extensively for some info on this but found
>>>> nothing.
>>>>
>>>> The problem?
>>>>
>>>> Numeric rather than symbolic identification of virtual machines.
>>>>
>>>> When I start a domU (a Xen virtual machine) in Xen I direct 'xm
>>>> create' at the config file the name of which corresponds to the name
>>>> of that domU.
>>>>
>>>> When I list currently running machines in Xen I see a listing of the
>>>> names of the Xen domUs and their corresponding numeric IDs.
>>>>
>>>> When I create a logical volume for a Xen domU I create that volume
>>>> based on the name of the corresponding Xen instance.
>>>>
>>>> In each case I try to ensure consistency by making the names of the
>>>> Xen domUs correspond to the hostnames of the servers which those domUs
>>>> are running. Host foo is on the domU named foo and is in a logical
>>>> volume named foo. To start domU foo I run 'xm create
>>>> /etc/xen/domains/foo.conf'. This scales well and makes things very
>>>> nice and obvious.
>>>>
>>>> OpenVZ seems to do away with symbolic names referring in all instances
>>>> to numeric ids, a bit like not using DNS but putting an IP address
>>>> into a URL.
>>>>
>>>> I have an awful feeling that when the pager goes off at 2am the person
>>>> on call, bleary-eyed and tired, will make some horrible mistake when
>>>> trying to mentally map numeric identifiers to server hostnames. This
>>>> is what I mean by 'not scaling well'. Use of numeric identifiers may
>>>> work ok when there is only one or two, but when there may be a dozen
>>>> things will get out of hand.
>>>>
>>>> I am sure that there must be a way to use symbolic names instead of
>>>> numbers in OpenVZ but I can't for the life of me find out how.
>>>>
>>>> Thanks!
>>>>
>>>>
>>>>

Steve Wray wrote:
> Kir Kolyshkin wrote:
>> Steve Wray wrote:
>>  
>>> Kir Kolyshkin wrote:
>>>    
>>>> See vzctl set --name
>>>>         
>>> Well thats a nice start.
>>>
>>> Now, to follow on from that great progress, how do I get it so that
>>> the directory where the root filesystem lives corresponds to the name
>>> I set instead of the numeric VEID?
>>>     
>> No standard way.
>>
>> I guess you can create a symlink; something like this:
>> vzctl set $VEID --name $VENAME --save
>> (cd /vz/root && ln -s $VEID $VENAME)
>>
>> Same for /vz/private if you need it.
>>   
> I did find that after one has created a virtual machine configuration
> one can edit its config file and add:
>
> VE_ROOT="/var/lib/vz/root/vz1"
> VE_PRIVATE="/var/lib/vz/private/vz1"
>
> for example.
Both VE_ROOT and VE_PRIVATE can be set in vzctl create (--root and
--private options). If you want to change those values later (either by
using vzctl set or by editing a configuration file) you also have to
move the existing directories (otherwise it won't make sense) --
something like this:

vzctl stop $VE
vzctl umount $VE
mv /vz/private/$VE $NEW_VE_PRIVATE
rmdir /vz/root/$VEID
mkdir $NEW_VE_ROOT
vzctl set $VE --root $NEW_VE_ROOT --private $NEW_VE_PRIVATE

Now, if you need those symlinks, move them as well. vzlist -oname $VEID
should tell you the name of your VE if you want to script this operation.
> I have yet to figure out the 'vzctl create' commands though; they
> appear to require an OS template tarball.
Yep. There are a lot of such tarballs available from
http://download.openvz.org/template/precreated/
http://download.openvz.org/template/precreated/contrib/
> While I dropped a root filesystem tarball into the required place,
> vzctl create didn't like it.
Well, it should be a normal root filesystem tar.gz file, better having
Linux distro at the beginning of a filename (this is how vzctl guesses
which distro is it -- for distro-dependent operations like IP
configuration). So you'd better name your tarball like
debian-4-${whatever}.tar.gz

Other problems that may be with your tarball are:
 - it's tar.bz2 tarball
 - it's missing some really required stuff like system libs or /sbin/init
 - it's not a root filesystem, for example all the filenames are
prefixed with /root or smth.

Finally, in some cases you need to do some modifications; those should
be described in http://wiki.openvz.org/Physical_to_VE.
> I'll keep plugging away.
>
> OpenVZ looks pretty good for performance scaleability but what I'd
> love to see is better management scaleability.
>
> If there are any tools which abstract away some of the detail for
> management of multiple virtual machines I'd like to know. I did try
> easyvz (http://sourceforge.net/projects/easyvz) but there were
> problems with the python dependencies. I run Debian Etch; when I tried
> to run the gui there were issues with strange characters in the python
> script.
>
OpenVZ is more of a virtualization technology with good CLI. If you are
looking for a high-level GUI, you'll have to develop one, or join some
other team developing GUI for OpenVZ (those should be listed at
http://wiki.openvz.org/Control_panels), or use Virtuozzo which comes
with a few GUIs.

Steve Wray wrote:
> Kir Kolyshkin wrote:
>> See vzctl set --name
>>   
>
> Well thats a nice start.
>
> Now, to follow on from that great progress, how do I get it so that 
> the directory where the root filesystem lives corresponds to the name 
> I set instead of the numeric VEID?
>
> Thanks!

There seems to be a slight inconsistency across the tool set here.

vzctl does respect the given 'name' however vzquota does not appear to 
and seems to require the numeric id.

Steve Wray wrote:
> Steve Wray wrote:
> There seems to be a slight inconsistency across the tool set here.
> vzctl does respect the given 'name' however vzquota does not appear to 
> and seems to require the numeric id.

Quite true. Did you check the bugtracker for the project, or log that as 
a bug? I'd love to see that fixed!


-- 
Gregor Mosheh / Greg Allensworth
System Administrator, HostGIS cartographic development & hosting services
http://www.HostGIS.com/

"Remember that no one cares if you can back up,
  only if you can restore." - AMANDA

Gregor Mosheh wrote:
> Steve Wray wrote:
>> Steve Wray wrote:
>> There seems to be a slight inconsistency across the tool set here.
>> vzctl does respect the given 'name' however vzquota does not appear
>> to and seems to require the numeric id.
>
> Quite true. Did you check the bugtracker for the project, or log that
> as a bug? I'd love to see that fixed!
>
>
Can you tell me the use case for that? I mean, I never use vzquota
directly; it's vzctl that calls it whenever needed.

I guess you use vzquota show or vzquota stat and want to use VE name
instead of ID, is that right?

On 16/08/2007 6:14 AM, Steve Wray wrote:
>
>
> vzctl does respect the given 'name' however vzquota does not appear to 
> and seems to require the numeric id.
>
>

I have a similar issue with scripts that need to convert from the VEID 
or VE Name to either the VEID, the VE Name, or host name.

I've written this simple script to do the conversions for me.  It's 
handy in scripts, but may be useful where your list of VE's is too large 
to simply scan the vzlist for the information you need.

/usr/local/bin/vmid
- - - - - - - -
#!/bin/bash

if [ "${1}" == "" ]; then
  echo "$0 {veid|name} [-i|-n|-h]"
  echo "        -i returns id \(default\)"
  echo "        -n returns name"
  echo "        -h returns host name"
  exit 1
fi

case "$2" in
  "" | "-i")
    PARM=veid
    ;;
  "-n")
    PARM=name
    ;;
  "-h")
    PARM=hostname
    ;;
  *)
    echo Bad parameter $2
    exit 1
    ;;
esac

VM_ID=`vzlist -o ${PARM} -H -N ${1} | sed -e "s/ //g"`

if [ "${VM_ID}" == "" ]; then
  VM_ID=`vzlist -o ${PARM} -H ${1} | sed -e "s/ //g"`
fi

if [ "${VM_ID}" == "" ]; then
  exit 1
else
  echo ${VM_ID}
  exit 0
fi
- - - - - - - -


Since my scripts can be passed either the veid or the vename, I might 
code something like this:

ping $(vmid $1 -h)

more practically I use it to access things like the config files that 
are named according to the VEID.

Steve

Kir Kolyshkin wrote:
> Gregor Mosheh wrote:
>   
>> Steve Wray wrote:
>>     
>>> Steve Wray wrote:
>>> There seems to be a slight inconsistency across the tool set here.
>>> vzctl does respect the given 'name' however vzquota does not appear
>>> to and seems to require the numeric id.
>>>       
>> Quite true. Did you check the bugtracker for the project, or log that
>> as a bug? I'd love to see that fixed!
>>
>>
>>     
> Can you tell me the use case for that? I mean, I never use vzquota
> directly; it's vzctl that calls it whenever needed.
>
> I guess you use vzquota show or vzquota stat and want to use VE name
> instead of ID, is that right?
>   

Well, on the basis that consistency is a Good Thing, yes.

I'm only just getting started with OpenVZ so am unsure of the real use 
case for this. But I am busily finding the things that confuse, confound 
or seem inconsistent :)

Thanks!

Steve Wray wrote:
> Kir Kolyshkin wrote:
>> Gregor Mosheh wrote:
>>  
>>> Steve Wray wrote:
>>>    
>>>> Steve Wray wrote:
>>>> There seems to be a slight inconsistency across the tool set here.
>>>> vzctl does respect the given 'name' however vzquota does not appear
>>>> to and seems to require the numeric id.
>>>>       
>>> Quite true. Did you check the bugtracker for the project, or log that
>>> as a bug? I'd love to see that fixed!
>>>
>>>
>>>     
>> Can you tell me the use case for that? I mean, I never use vzquota
>> directly; it's vzctl that calls it whenever needed.
>>
>> I guess you use vzquota show or vzquota stat and want to use VE name
>> instead of ID, is that right?
>>   
>
> Well, on the basis that consistency is a Good Thing, yes.
>
> I'm only just getting started with OpenVZ so am unsure of the real use
> case for this. But I am busily finding the things that confuse,
> confound or seem inconsistent :)
>
OK, I filed a bug for vzquota with minor severity, it will eventually be
fixed:
http://bugzilla.openvz.org/show_bug.cgi?id=668

> OK, I filed a bug for vzquota with minor severity, it will eventually be
> fixed:
> http://bugzilla.openvz.org/show_bug.cgi?id=668

Thanks again, Kir. OpenVZ is about the greatest thing we've ever found, 
and we're SO glad for it.

-- 
Gregor Mosheh / Greg Allensworth
System Administrator, HostGIS cartographic development & hosting services
http://www.HostGIS.com/

"Remember that no one cares if you can back up,
  only if you can restore." - AMANDA