Hello,
We're playing around with some KVM Virtual Machines to test cloning, moving, etc.. before trying on production VMs.
We created an image to rapidily generate test VM's.
When trying to resize one of those test VM's filesystem from 2GB to 4 GB, we've got this message :
".. update failed : lvextend -L4194304k \/dev\/VolGroup00\/test555_company_net_img failed : Snapshot origin volumes can be resized only while inactive: try lvchange -an"
So we did lvchange -an /dev/VolGroup00/test555_company_net_img, but then, we've got this other message, not reassuring att all :
"Warning - this disk cannot be safely resized. Cloudmin does not know what type of filesystem this disk contains, and so cannot properly resize it. This is most likely because the disk is not mounted on the virtual system."
So we did lvchange -ay and rebooted to check the VM. It was alright...
Another VM wich was created from the same image, and moved on another KVM host was able to be resized without any error.
Any clue ?
Comments
Submitted by JamieCameron on Wed, 12/01/2010 - 12:43 Comment #1
This could be an issue with the LV being a snapshot source or dest.
Was this VM a clone, or has a clone been created from it?
Submitted by mcordas on Wed, 12/01/2010 - 13:38 Pro Licensee Comment #2
Yes, a clone was created from this VM. The clone was then moved on another KVM host and resized successfully.
Submitted by JamieCameron on Wed, 12/01/2010 - 14:05 Comment #3
It seems like the LV for the clone might still exist. If you login to the host system and run :
lvdisplaycan you still see the clone's logical volume?
Submitted by mcordas on Wed, 12/01/2010 - 14:54 Pro Licensee Comment #4
Yes, it's still there.
Removed the snapshot and it solved the problem.
So, for the future, of we clone a VM, it will always be imposible to resize the original VM while the clone is still there ?
Submitted by JamieCameron on Wed, 12/01/2010 - 14:59 Comment #5
Normally Cloudmin will remove that snapshot for you when an VM is moved to a new host, assuming that they don't share a common storage pool.
If you create a new test clone and then move it, does the same thing happen?
Submitted by mcordas on Wed, 12/01/2010 - 15:55 Pro Licensee Comment #6
I'll try and keep you in touch.
Cheers.
Submitted by JamieCameron on Thu, 12/02/2010 - 10:45 Comment #7
Ok, let me know what happens ..
Submitted by mcordas on Fri, 12/10/2010 - 04:51 Pro Licensee Comment #8
Hello, Yes the same happens.
In fact, when we clone a Live VM, the clone has a snapshot as Filesystem. When we move it to another host, then it gets a "real" LVM volume. The original snapshot on the first host is never deleted. We have to remove it manually.
It's not a really big issue, but so you know.
Submitted by JamieCameron on Fri, 12/10/2010 - 11:46 Comment #9
Ok, I see the cause of this now .. Cloudmin isn't cleaning up the /dev/mapper entries for the disk image after it is moved and before it is deleted, which causes the LV deletion to fail. I will fix this in the next Cloudmin release (5.2).
Submitted by Issues on Fri, 12/24/2010 - 12:50 Comment #10
Automatically closed -- issue fixed for 2 weeks with no activity.