Hello, this is a repost from forum:
I've been evaluating cloudmin as a new platform for our VPS business and in requirements for that we are looking for easy way to migrate existing customer (server panel) to cloudmin via "add instance".
Our setup is using Debian Linux with libvirt (which should not be a problem) and LVM based images, presetned to guests as "xvda". Inside the guest servers customers are doing custom partitions and custom filesystems (yes we have jfs/drbd/ocfs users).
What is a stopping us is cloudmin disk naming: all newly created servers are utilizing pygrub/pvgrub (which is just fine), but disk is presented to guest as "sda1" which is the huge stopper for us, because we have already uniform LVM setup with single "xvda" drive and custom partition inside (none of our business as provider). As far as we could see from evaluation of cloudmin everything is a very big go, but that disk naming is preventing us from going further into actual deployment.
Is there any way to point cloudmin to provide xen guests with single "xvda" at creation time thru template without any manual intervention? We could not find a switch for that. Seems like "sda1" is hardcoded somewhere in "xen-type-lib.pl".
And yes, I am aware that this could disable features like automatic backups and disk resize.
Comments
Submitted by JamieCameron on Sat, 01/15/2011 - 16:56 Comment #1
Cloudmin should be able to handle virtual disks on imported VMs with the xvda naming already .. but there may be bugs, as depending on how the VM was created the disks can appear as hda, sda or xvda.
Could you explain in more detail where Cloudmin is showing the wrong device name exactly? Is it in the Xen .cfg file, /etc/fstab or elsewhere?
Submitted by bogdan on Sun, 01/16/2011 - 02:52 Comment #2
Hello,
I've found a way to handle disk naming on imported Xen instances. However, problem persisted thru creating a new template from existing server using xvda naming (whole disk) and then creating a new Xen instance from that template. Disk name somehow reverted back to sda1, plus throwing a bunch of errors about unable to mount guest image (i guess it tried to change IP, pass, etc). Server was eventually created but without correct IP and password.
So that's two issues for us: 1. Hardcoded sda1 naming for new guests (even from xvda template) 2. Unable to mount whole disks. Maybe instead of trying to mount whole disk (wrong) mount /dev/vg/newisntance you can utilize kpartx in this way: # kpartx -a /dev/vg/newinstance # mount stuff # kpartx -d /dev/vg/newinstance
Thanks, Bogdan
Submitted by JamieCameron on Sun, 01/16/2011 - 11:55 Comment #3
Are you using HVM virtual machines, or just para-virtualization?
I'd be interested to see the exact config files in which sda is being incorrectly used, and also the error message about the disk mounting.