On Mon, January 16, 2012 13:05, James B. Byrne wrote:
How is it even possible for an application running under a httpd service on one guest to see anything at all besides the VirtIO storage assigned to that guest?
Has anyone else encountered this anomaly?
I just cloned a guest instance. The clone prototype was set up with a single VirtIO disk of 8Gbs, divided into a 500 Mb boot and a ~7.1Gb root partition. The root partition was entirely assigned to the basic vg and two lv were created, one for swap and one for the actual root partition.
When the guest was cloned there was only one VirtIO disk of 8 Gb assigned to it and this was cloned and given a new name.
When I look at the newly cloned guest instance with pvdisplay this is what I see:
# pvdisplay Couldn't find device with uuid umrIn6-Np0c-NC4Z-MuUo-5TBj-IKRE-XBU0De. --- Physical volume --- PV Name /dev/vda2 VG Name vg_vm_centos_6 PV Size 7.32 GiB / not usable 3.00 MiB Allocatable yes (but full) PE Size 4.00 MiB Total PE 1874 Free PE 0 Allocated PE 1874 PV UUID djM23m-6Yeb-BQ2x-gPh9-ORMt-dX2i-Ou9xBQ
--- Physical volume --- PV Name unknown device VG Name vg_vm_centos_6 PV Size 31.25 GiB / not usable 3.97 MiB Allocatable yes (but full) PE Size 4.00 MiB Total PE 7999 Free PE 0 Allocated PE 7999 PV UUID umrIn6-Np0c-NC4Z-MuUo-5TBj-IKRE-XBU0De
When I look at it using vgdisplay then this is what I see:
# vgdisplay Couldn't find device with uuid umrIn6-Np0c-NC4Z-MuUo-5TBj-IKRE-XBU0De. --- Volume group --- VG Name vg_vm_centos_6 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 10 VG Access read/write VG Status resizable MAX LV 0 Cur LV 4 Open LV 2 Max PV 0 Cur PV 2 Act PV 1 VG Size 38.57 GiB PE Size 4.00 MiB Total PE 9873 Alloc PE / Size 9873 / 38.57 GiB Free PE / Size 0 / 0 VG UUID qa6jwq-5gTp-6mMH-IWl9-OrEK-HjWc-pbaFsa
What is going on and how do I fix this? The size of the ghost pv (31Gb) is showing up as the size of the clone's vg whereas the pv for the cloned instance is only 8Gb.
I am only using virt-manager to manage disk storage for these guests and I have no idea why or how this mismash is happening. Any ideas?
This behaviour has to be related to the fact that the volume group name does not change when guests are cloned. I do not know where the confusion originates but doing xmldumps from virsh shows that all of the guests only have their own VirtIO disks assigned to them so the cross linking is happening elsewhere and the vg name seems the likely place.
However, I am at a loss as to how to avoid this. It does not appear that an option to rename the volume group is given when cloning from virt-manager. Is there a way to do this when the guest is cloned?
On 01/16/2012 09:42 PM, James B. Byrne wrote:
This behaviour has to be related to the fact that the volume group name does not change when guests are cloned. I do not know where the confusion originates but doing xmldumps from virsh shows that all of the guests only have their own VirtIO disks assigned to them so the cross linking is happening elsewhere and the vg name seems the likely place.
However, I am at a loss as to how to avoid this. It does not appear that an option to rename the volume group is given when cloning from virt-manager. Is there a way to do this when the guest is cloned?
It looks like it is an remnant of the old UUID, since device is "unkonwn"...
-
James B. Byrne -
Ljubomir Ljubojevic