...
Original
...
draft
...
by
...
Hari
...
Kannan
This is the requirement/functional
...
specification
...
for
...
a
...
feature
...
to
...
allow
...
users
...
to
...
append
...
the
...
display
...
name
...
of
...
a
...
guest
...
VM
...
to
...
the
...
internal
...
name
...
(the
...
name
...
with
...
which
...
cloudstack
...
creates
...
the
...
VM
...
on
...
the
...
actual
...
hypervisor)
...
of
...
a
...
guest
...
VM.
...
This
...
feature
...
follows
...
a
...
request
...
from
...
the
...
field
...
that
...
admins
...
preferred
...
to
...
have
...
this
...
facility
...
to
...
locate
...
guest
...
VMs
...
easily
...
when
...
fielding
...
customer
...
calls.
...
This
...
helps
...
especially
...
in
...
vmware
...
deployments
...
(vCenter).
...
https://issues.apache.org/jira/browse/CLOUDSTACK-778
...
Default : false
Behavior: If set to true, and the mgmt server restarted, all new guest VMs that are created with a display name value set to a valid string compliant with RFC 952, will have their instance names on the hypervisor platform in the form i-userid-vmid-display_name
None. The changes will be transparent to the existing API to create a guest VM.
The reason we append the display name to the internal name of the VM instead of completely overwriting the instance name with the display name is to preserve the functionality provided by existing vmsync scripts. vmsync is the feature that allows the Cloudstack mgmt server to know the current state of a VM (whether it is up or down). Cloudstack has naming conventions for the VMs that it creates/manages on hypervisors. Router VMs always are named in the format r-value-value. The CPVMs follow the convention v-value-value. SSVMs are named s-value-value, and guest VMs are named i-value-value. vmsync scripts collect information about VMs using this naming convention, and push this data back to the management server periodically (every minute, by default).