yahoo-eng-team team mailing list archive

[Luo Gangyi <luogangyi@xxxxxxxxxxxxxxx>]

Public bug reported:

nova rescue do not actual works in a lot of situation.

Although nova rescue generate the right libvirt.xml (at least in my
opinion), the virtual machine OS do not use the rescue disk to boot. It
still use the origin disk to boot(I tested it in icehouse,Juno,Kilo).

I am not sure it is the bug of libvirt/qemu or it is because of the
wrong configuration of OS inside VM.

How to reproduce：

1. Download a image(for
example,http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2)
and upload it to glance.

2. Create an instance by using above image.

3. touch a file in the instance.

4. nova rescue [instance-id]

You can see the file you touch is still there, which indicates the OS of
the VM still boot from the original disk.

If you use #df -h ,you wiil file the OS is using /dev/vdb1 as root file
system.

===========
I think the possible reason is /etc/fstab use disk UUID as block device name, and all the instance from one image share the same UUID, which confuse OS when it has two disk with same UUID.

If I use /dev/vda1 instead of UUID , it seems work correctly.

** Affects: nova
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1460536

Title:
  nova rescue do not actual work

Status in OpenStack Compute (Nova):
  New

Bug description:
  nova rescue do not actual works in a lot of situation.

  Although nova rescue generate the right libvirt.xml (at least in my
  opinion), the virtual machine OS do not use the rescue disk to boot.
  It still use the origin disk to boot(I tested it in
  icehouse,Juno,Kilo).

  I am not sure it is the bug of libvirt/qemu or it is because of the
  wrong configuration of OS inside VM.

  How to reproduce：

  1. Download a image(for
  example,http://cloud.centos.org/centos/7/images/CentOS-7-x86_64-GenericCloud.qcow2)
  and upload it to glance.

  2. Create an instance by using above image.

  3. touch a file in the instance.

  4. nova rescue [instance-id]

  You can see the file you touch is still there, which indicates the OS
  of the VM still boot from the original disk.

  If you use #df -h ,you wiil file the OS is using /dev/vdb1 as root
  file system.

  ===========
  I think the possible reason is /etc/fstab use disk UUID as block device name, and all the instance from one image share the same UUID, which confuse OS when it has two disk with same UUID.

  If I use /dev/vda1 instead of UUID , it seems work correctly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1460536/+subscriptions