KVM migration with direct attached storage 1.4b2

J

jshinall

New Member
Sep 24, 2009
4
0
1
Quick question about KVM migration between two hosts, one of which has a direct attached Dell MD1000 array. The array on that host is set up as a separate volume group in LVM, and I set it up through the web interface, choosing add new LVM group and selecting "pve-large" as the base VG.

Both hosts in the cluster are at 1.4b2 (as such I completely understand this is not meant to be used on production systems and any problems are all mine :P)

Anyway, I was trying to migrate a KVM virtual machine from one host to another, and when I use the web interface, this is the output:
/usr/bin/ssh -t -t -n -o BatchMode=yes 10.227.110.89 /usr/sbin/qmigrate 10.227.110.91 201
Oct 14 12:24:05 starting migration of VM 201 to host '10.227.110.91'
Oct 14 12:24:05 copying disk images
Volume group "pve-large" not found
Oct 14 12:24:05 Failed to sync data - command '/sbin/vgchange -aly pve-large' failed with exit code 5
Oct 14 12:24:05 migration aborted
Connection to 10.227.110.89 closed.
VM 201 migration failed - Connection refused

I am trying to migrate from a host named virt3 to a host named virt1.

So, it appears to me that since pve-large is directly attached to the first host and isn't able to be shared with virt3, it won't do the migration.

I have already worked around that using vzdump on virt3, then scp the dump to virt1, where I use qmrestore to bring it back up. While this works fine, I was just wondering if there was some way to specify offline transfers to transfer to the internal directory storage on virt1 instead of trying to do shared storage migration? Basically, I would like to be able to say 'migrate from virt3 to virt1 using virt1's internal storage as the target storage'.

Please don't take this as a demand, just a polite inquiry to the feasibility of this sort of feature.

Here is the output of vgs, pvs, and lvs:
virt1:~# vgs
VG #PV #LV #SN Attr VSize VFree
pve 3 3 0 wz--n- 5.46T 0
pve-large 1 1 0 wz--n- 10.91T 5.05T
virt1:~# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
data pve -wi-ao 5.33T
root pve -wi-ao 96.00G
swap pve -wi-ao 31.00G
vm-101-disk-1 pve-large -wi-ao 5.86T
virt1:~# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 pve lvm2 a- 1.82T 0
/dev/sdb pve lvm2 a- 1.82T 0
/dev/sdc pve lvm2 a- 1.82T 0
/dev/sdd pve-large lvm2 a- 10.91T 5.05T

Thank you for your time, and feel free to yell at me if I have a completely ridiculous sort of setup here!
 
jshinall said:
Quick question about KVM migration between two hosts, one of which has a direct attached Dell MD1000 array. The array on that host is set up as a separate volume group in LVM, and I set it up through the web interface, choosing add new LVM group and selecting "pve-large" as the base VG.

Both hosts in the cluster are at 1.4b2 (as such I completely understand this is not meant to be used on production systems and any problems are all mine :P)

Anyway, I was trying to migrate a KVM virtual machine from one host to another, and when I use the web interface, this is the output:
/usr/bin/ssh -t -t -n -o BatchMode=yes 10.227.110.89 /usr/sbin/qmigrate 10.227.110.91 201
Oct 14 12:24:05 starting migration of VM 201 to host '10.227.110.91'
Oct 14 12:24:05 copying disk images
Volume group "pve-large" not found
Oct 14 12:24:05 Failed to sync data - command '/sbin/vgchange -aly pve-large' failed with exit code 5
Oct 14 12:24:05 migration aborted
Connection to 10.227.110.89 closed.
VM 201 migration failed - Connection refused

I am trying to migrate from a host named virt3 to a host named virt1.

So, it appears to me that since pve-large is directly attached to the first host and isn't able to be shared with virt3, it won't do the migration.

I have already worked around that using vzdump on virt3, then scp the dump to virt1, where I use qmrestore to bring it back up. While this works fine, I was just wondering if there was some way to specify offline transfers to transfer to the internal directory storage on virt1 instead of trying to do shared storage migration? Basically, I would like to be able to say 'migrate from virt3 to virt1 using virt1's internal storage as the target storage'.

Please don't take this as a demand, just a polite inquiry to the feasibility of this sort of feature.

Here is the output of vgs, pvs, and lvs:
virt1:~# vgs
VG #PV #LV #SN Attr VSize VFree
pve 3 3 0 wz--n- 5.46T 0
pve-large 1 1 0 wz--n- 10.91T 5.05T
virt1:~# lvs
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
data pve -wi-ao 5.33T
root pve -wi-ao 96.00G
swap pve -wi-ao 31.00G
vm-101-disk-1 pve-large -wi-ao 5.86T
virt1:~# pvs
PV VG Fmt Attr PSize PFree
/dev/sda2 pve lvm2 a- 1.82T 0
/dev/sdb pve lvm2 a- 1.82T 0
/dev/sdc pve lvm2 a- 1.82T 0
/dev/sdd pve-large lvm2 a- 10.91T 5.05T

Thank you for your time, and feel free to yell at me if I have a completely ridiculous sort of setup here!
Click to expand...

if you want to live migrate, the storage needs to be shared (NFS, iSCSI or DRBD as a special device). as far as I see your storage is not shared, therefore the second node cannot use it.
 
I had a similar problem few hours ago. I had 2 servers one with 1.4Beta1 (pve1) and another one with 1.3 (pve2) not in a cluster config.

I upgraded (pve2) from 1.3 to 1.4beta2 and created the cluster with pve1 1.4Beta1 as master.

Then upgraded pve1 from 1.4beta1 to 1.4beta2.

After that, it took a couple of hours to sincronize iscsi & LVM configurations from pve1 to pve2. I was about to reinstall pve2 with beta2 where I began to be able to use the new volumes created using the web ui on the Cluster.
 
You must log in or register to reply here.
Top Bottom