moving virtual system's disk doesn't update xen config

here are the steps:

1. shutdown the virtual system
2. go to Resources > Manage disks
3. click on the disk name (LVM disk)
4. on the bottom there is form to move the LVM partition to another VG

note that i create 2 VGs on the same server node.

the disk move went fine, i think it's just not updating the xen config file.

i'm using centos 6 and install cloudmin using the GPL installer

xen version 4.2.4

i checked again and actually cloudmin did change the disk configuration in the .cfg file to the correct LVM partition. however when i boot the virtual system i get the same error:

Error: Device 51714 (vbd) could not be connected. /dev/vg1/vm01_swap does not exist

note: i move back the LVM to vg0, below is the new .cfg:

===CFG=== memory = 1024 maxmem = 4096 name = 'vm01' vif = ['ip=192.168.1.80,mac=00:16:3e:94:C2:83'] address = '192.168.1.80' netmask = '255.255.255.0' disk = ['phy:/dev/vg0/vm01_img,xvda1,w','phy:/dev/vg0/vm01_3_img,xvda2,w'] kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz" extra = "(hd0)/boot/grub/grub.conf" vcpus = 2 ===END===

strangely if i start the virtual system from console by running xm create vm01.cfg, it boot just fine.

i noticed strange thing, when i'm shutting down virtual system either from cloudmin or through xm shutdown command, the virtual system is still listed on xm list

Name ID Mem VCPUs State Time(s) Domain-0 0 1024 1 r----- 7640.8 vm01 1024 2 13.8

if i moved the disk to other LVM partition and did delete the vm by running "xm delete vm01", i can boot the virtual system from cloudmin just fine.

but if i didn't delete the vm by running command "xm delete vm01" i will get the error.

so i think the solution is to delete the virtual system from xend management after shutdown, but i find this strange as on my other installation (non cloudmin), shutdown also remove the vm from xend management

i think this is a new feature of xen 4.2, it save the vm in xend managed domain so when you shutdown the vm it will still listed in xend and you can start it again with "xm start" command. unfortunately this command didn't re-read the .cfg file so in the case that a disk is moved to another LVM VG xend didn't know.

running xm create from console give error:

Error: VM name 'vm01' already exists

on the XL command list there is "config-update" option, but i can't find it on XM command. so you need to do xm delete vm01 to have xend re-read the config file.

i read on http://wiki.xenproject.org/wiki/Xen_4.2_Feature_List and it says that xend is formally deprecated, is there any plan on updating cloudmin to use XL toolstack instead of XM?

is it possible to call this commands from the API? or can you implement it on next update please?

yes, that how i did to have the vm started and updated with the new configuration. i did "xm create" instead of "xm new"

it's also necessary to do "xm delete" everytime a virtual system get reset/reinstalled using different architechture 32-bit to 64-bit and vice versa..

this also needed in the case the template is using different disk device, for example "Debian Lenny 64 bit base OS" is using "sda" as the disk while "Centos 6 64 bit base OS" is using "xvda"

update:

after reading an article, i found out that 'xm new' means creating xend managed domU while 'xm create' is creating xend UN-managed domU.

so to have the config .cfg file re-read every time virtual system is started, the virtual system have to be created using 'xm create' command

Hi Jamie,

when will the next Cloudmin released? any ETA?

i have updated to 7.8 and it seems that changing settings on a virtual system still isn't applied without me manually run "xm delete " manually and restart it.

see reply number 2 for the moving LVM disk part.

the problem is not only for that moving LVM, but everything that changes the config file (.cfg) is not applied even you restart the virtual system because the vs (virtual system) is started with xm new command which is Xen domain managed. the next time you start/reboot the vs, xen will not re-read the config file as it's managed and already inside xen domain managed list (xm list)

try change the amount of virtual CPU, reset image from 32-bit to 64-bit, change IP address, it will not work.

this can be solved either by replacing xm new with xm create or execute xm delete before xm new

this happens on newly installed server (fresh install of centos 6 64-bit and cloudmin)

Jamie, did you find solution for this problem? have you tested it?

memory change doesn't have problem because it doesn't require reboot and changed on-the-fly.. but changes like disk size and reinstall from 32-bit to 64-bit OS (and vice versa) doesn't work

i suggest to make the "reboot system" under "system state" to always re-read the config file before re-starting the virtual system.

for example when i change the virtual cpu settings, i'm offered to reboot the virtual system, if i click the reboot button the settings is applied. but if i prefer to do the reboot later on and use the "reboot system" under "system state", the changes on virtual cpu settings doesn't seems to be applied.

on second thought, i think it should be made to re-read the config every time the virtual system is re/booted

about the HDD, it's not the disk size changing that i'm talking about, but LVM partition changes. on my test server i have 2 Volume Group (VG) if i move the disk of a virtual system to another VG, the config is changed but not re-read on reboot/boot so the virtual system boot is failed.

any update on this Jamie?

let me test it and i'll give you feedback

it seems to work fine now..