Open Stack

On Fri, 2020-10-30 at 17:23 +0000, Stephen Finucane wrote:
> On Fri, 2020-10-30 at 11:56 -0500, vladimir franciz blando wrote:
> > Hi,
> > I edited the  libvirt xml (virsh edit...) file of a running Windows
> > server instance because I changed the video model type from cirrus to
> > vmvga so it can support a higher resolution on a console (cirrus
> > supports up to 1280 only).
> > After editing, i "soft-rebooted" the instance and the new
> > configuration sticks.  That's awesome.
> 
> Please don't do this :) You shouldn't change things about an instance
> behind nova's back. It breaks resource tracking and can cause all sorts
> of horribleness.

if you have support form an openstack vendor like redhat editing the domain
xml also make that vm unsupported until its restroed to the way nova generated.
it might also make other issue caused as a resulted unsupported.
so unless you are self supporting you cloud be very carful with doing this.
> 
> > But when you do a "hard-reboot" it will revert back to the original
> > config.
> 
> Hard reboot builds configuration from scratch, dumping the existing
> XML. This is built from the same things used when you first create the
> instance (flavor + extra specs, image + metadata, host-level config,
> ...).
> 
> What you want is the 'hw_video_model' image metadata property. Set this
> and rebuild your instance:
> 
>         openstack image set --property hw_video_model=vmvga $IMAGE
this is the supported way to change this value ^
it will take effect for new instances.
>         openstack server rebuild $SERVER $IMAGE
and this is the only supported api action that can also change this value.
however i dont think rebuilding to the same image will update the image metadata.
you currenlty need to rebuild to a new image. this is due to an optiomisation we
have to avoid needing to go to the scheuler if we use the same image.

the unsupported way to change this without rebuilding the instance is to add
img_hw_video_model=vmvga to the system metadata table for that instance.

if your cloud is supported by a vendor this will also invalidate your suport
in all likely hood as db modificaiton generally are unsupported without an exception.
if you can rebuild the guest that is the best approch but it wont work for boot form volume
instances and it willl destory all data in the root disk of all other instances.

> 
> Note that rebuild is a destructive operation so be sure you're aware of
> what this is doing before you do it.
> 
> Stephen
> 
> > I also tried to do a "shut-down" then "start" again, but it still
> > reads the original config.  Not sure where it  is reading the config
> > from...
> > 
> > Regards
> > Vlad
> 
>