Re: VirtIO disk 'leakage' across guests?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



If I log on to the newly cloned guest and I try and rename
the vg used by that instance I see this:

[root@vm-centos-6 ~]# vgrename vg_vm_centos_6 vg_vm_renamed
  Couldn't find device with uuid
umrIn6-Np0c-NC4Z-MuUo-5TBj-IKRE-XBU0De.
  Cannot change VG vg_vm_centos_6 while PVs are missing.
  Consider vgreduce --removemissing.
[root@vm-centos-6 ~]# vgreduce vg_vm_centos_6 --removemissing
  Couldn't find device with uuid
umrIn6-Np0c-NC4Z-MuUo-5TBj-IKRE-XBU0De.
  WARNING: Partial LV lv_pgsql needs to be repaired or
removed.
  WARNING: Partial LV lv_backups needs to be repaired or
removed.
  WARNING: There are still partial LVs in VG vg_vm_centos_6.
  To remove them unconditionally use: vgreduce
--removemissing --force.
  Proceeding to remove empty missing PVs.

The xmldump for this guest instance contains this:

  <devices>
    <emulator>/usr/libexec/qemu-kvm</emulator>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw' cache='none'/>
      <source dev='/dev/vg_vhost01/lv_vm_test-vg-rename'/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00'
slot='0x05' function='0x0'/>
    </disk>
    <disk type='block' device='cdrom'>
      <driver name='qemu' type='raw'/>
      <target dev='hdc' bus='ide'/>
      <readonly/>
      <alias name='ide0-1-0'/>
      <address type='drive' controller='0' bus='1' unit='0'/>
    </disk>
    <controller type='ide' index='0'>
      <alias name='ide0'/>
      <address type='pci' domain='0x0000' bus='0x00'
slot='0x01' function='0x1'/>


The /dev entries for this vm guest are these:

[root@vm-centos-6 ~]# ll /dev/vg_vm_centos_6/*
lrwxrwxrwx. 1 root root 7 Jan 16 15:36
/dev/vg_vm_centos_6/lv_root -> ../dm-0
lrwxrwxrwx. 1 root root 7 Jan 16 15:36
/dev/vg_vm_centos_6/lv_swap -> ../dm-1


Searching for the missing uuid I find these files:

# find /etc -print | xargs grep
'umrIn6-Np0c-NC4Z-MuUo-5TBj-IKRE-XBU0De'
/etc/lvm/archive/vg_vm_centos_6_00005-1429183950.vg:
             id = "umrIn6-Np0c-NC4Z-MuUo-5TBj-IKRE-XBU0De"
/etc/lvm/archive/vg_vm_centos_6_00002-807578735.vg:
             id = "umrIn6-Np0c-NC4Z-MuUo-5TBj-IKRE-XBU0De"
/etc/lvm/archive/vg_vm_centos_6_00004-1687335328.vg:
             id = "umrIn6-Np0c-NC4Z-MuUo-5TBj-IKRE-XBU0De"
/etc/lvm/archive/vg_vm_centos_6_00003-650133889.vg:
             id = "umrIn6-Np0c-NC4Z-MuUo-5TBj-IKRE-XBU0De"
/etc/lvm/archive/vg_vm_centos_6_00006-1907108135.vg:
             id = "umrIn6-Np0c-NC4Z-MuUo-5TBj-IKRE-XBU0De"
/etc/lvm/backup/vg_vm_centos_6:                 id =
"umrIn6-Np0c-NC4Z-MuUo-5TBj-IKRE-XBU0De"

Looking in the files of /etc/lvm/archive created by the
vgrename command shows a complete mess of lvs from
different vm guests non of which have anything in common
with the test vm guest, other than they all share the same
volume group name.

Evidently, cloning vm instances for the purpose of setting
up a new vm guest to run with other vms cloned from the
same prototype is not a good idea,

-- 
***          E-Mail is NOT a SECURE channel          ***
James B. Byrne                mailto:ByrneJB@xxxxxxxxxxxxx
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3


-- 
***          E-Mail is NOT a SECURE channel          ***
James B. Byrne                mailto:ByrneJB@xxxxxxxxxxxxx
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3

_______________________________________________
CentOS-virt mailing list
CentOS-virt@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos-virt


[Index of Archives]     [CentOS Users]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [X.org]     [Xfree86]     [Linux USB]

  Powered by Linux