OpenVZ to KVM convert

[hotwired007]

hi guys, ive got 6 OpenVZ boxes that i need to convert to KVM - they're all Debian 6 Standard 6.04 i386 template based.

I've used the search and all i ahve come up with is other people asking the same question but not really getting an answer - im looking for a step by step guide - otherwsie i'll help build one

the 4 OpenVZ boxes arent complicated boxes, 2 x BIND boxes, 1 zennos, 3 LAMP (1 Phpmotion, 1 mediawiki, and 1 custom osticket install)

Is it basically going to be a case of rebuilding the linux installs and transfering the data?

 

[tom]

hi guys, ive got 6 OpenVZ boxes that i need to convert to KVM - they're all Debian 6 Standard 6.04 i386 template based.

I've used the search and all i ahve come up with is other people asking the same question but not really getting an answer - im looking for a step by step guide - otherwsie i'll help build one

the 4 OpenVZ boxes arent complicated boxes, 2 x BIND boxes, 1 zennos, 3 LAMP (1 Phpmotion, 1 mediawiki, and 1 custom osticket install)

Is it basically going to be a case of rebuilding the linux installs and transfering the data?

yes. install new KVM VM´s and transfer the data and settings step by step.

 

[hotwired007]

Hi guys - seeing as this is a follow up to the original post i'd reply here...

With the others i basically rebuilt a KVM and then dropped the data onto them...

I now have only 1 OpenVZ container that i need to convert to KVM - my mediawiki server.

I've not had much luck with backup/restore - this function in my wiki seems broken (amongst other things!) and getting hold of the 1.15 mediawiki with the squeeze update and getting it installed and working is becoming a headache! (i suspect this is what i'm going to have to do to fix the wiki and then upgrade to 1.20.2)

Surely there is a simple way of migrating the whole server from the OpenVZ to KVM? is there a script or something? i found this post: http://www.robthomson.me.uk/2011/02/10/migrating-openvz-to-kvmzenvmware/ and i'm just making a backup of the wiki to try it...

 

[Cyberco Ltd]

Hi,

Excuse my ignorance, but may I ask what the incentive is to convert from OpenVZ to KVM as OpenVZ appears to be a faster, lighter solution?

Thanks,

Hi guys - seeing as this is a follow up to the original post i'd reply here...

With the others i basically rebuilt a KVM and then dropped the data onto them...

I now have only 1 OpenVZ container that i need to convert to KVM - my mediawiki server.

I've not had much luck with backup/restore - this function in my wiki seems broken (amongst other things!) and getting hold of the 1.15 mediawiki with the squeeze update and getting it installed and working is becoming a headache! (i suspect this is what i'm going to have to do to fix the wiki and then upgrade to 1.20.2)

Surely there is a simple way of migrating the whole server from the OpenVZ to KVM? is there a script or something? i found this post: http://www.robthomson.me.uk/2011/02/10/migrating-openvz-to-kvmzenvmware/ and i'm just making a backup of the wiki to try it...

 

[hotwired007]

Live migration and the ability to run the VMs from my iSCSI SAN rather than an NFS share.

 

[kotakomputer]

Excuse my ignorance, but may I ask what the incentive is to convert from OpenVZ to KVM as OpenVZ appears to be a faster, lighter solution?

Instead ... I do KVM and Xen to OpenVZ
If u use Linux then better use OpenVZ, which in my experience:
1. very fast to install
2. need no manually set IP, subnet mask, gateway and dns after OS installed
3. able to login to vps guest w/o guest password
4. able to change vps guest password
5. performance faster than kvm
6. able to change ram, cpu and hdd w/o restart vps guest
7. prevent guess to change network stuff like ip, dns, etc

 

[hotwired007]

I agree with all the benefits but i want to have it in a KVM running from my iSCSI share

 

[mo_]

mmh you could mount the iscsi volume to the host and then stick your openvz containers in there that way. while this doesnt allow for instant live migration, I dont think you actually need instant migration for openvz since the containers are so tiny that they transfer over the network in under 30 seconds anyhow. Instead what I did was remove the --delete part from the rsync command that is being called when a openvz migration happens. that way you get to keep the containers files on the node being migrated FROM and thus if you later migrate back, rsync doesnt have to transfer all the files but only those that have changed. this brings down over the network migration speeds to be more like around 5-10 seconds, which in my opinion is well worth it since this allows for muss more flexibility as far as storage is concerned.

Just something to consider. If this is acceptable/relevant for you, I could dig up the rsync "changes" I mentioned.

 

[mir]

Just a thought.

Has anybody tried to have a VZ with a very limited disk size and then the data mounted on a share storage? Will it then be able to migrate an still keep access to the share data storage?

If the above is yes I guess one could have a say 1 GB disk for system and a x size shared storage disk for data. This kind of container should be possible to "live" migrate in as little as 2 - 5 sec. Suspension for 2 - 5 sec should in most situation happen without any notice to clients.

 

[mo_]

I have setup a fileserver where the actual files are residing on a SAN. access to the storage is done with a bind mount happening with openvz's premount/postumount/etc scripts. I know that an offline migration of this machine works like a charm, but I have never even tried to live migrate it, which I guess I could do some night when its not being used (like... right now)

EDIT: actually... thinking about it and investigating, I dont think this would/could work since theres no distinct migration-related action script for containers and I dont want to "hot test" this with production data since if even parts of my scripts were being called then the SAN volume would be mounted on two servers, i.e. the perfect recipe for corrupt data

If you had the data stored in a remote NFS however... now I can imagine that to work.

An offline migration "only" adds the boot time of the container to the migration duration, so I dont think you would break 10 seconds of service downtime with an offline migration

 

[mir]

An offline migration "only" adds the boot time of the container to the migration duration, so I dont think you would break 10 seconds of service downtime with an offline migration

There is a big difference between offline migration and online migration in that way that every open connection is kept, eg. users are not required to make a new connection after migration.

QeD. offline migration will always be noticed by connected users while online migration will merely be interpreted as network digestion or a temporarily slow connection.

- - - Updated - - -

EDIT: actually... thinking about it and investigating, I dont think this would/could work since theres no distinct migration-related action script for containers and I dont want to "hot test" this with production data since if even parts of my scripts were being called then the SAN volume would be mounted on two servers, i.e. the perfect recipe for corrupt data

If you had the data stored in a remote NFS however... now I can imagine that to work.

Found this interesting note: http://openvz.org/Vzmigrate_filesystem_aware

 

[mo_]

that does seem interesting, albeit apparantly fairly outdated since its been last updated june '12 and is version 3.2.
nontheless, his changes might be worth picking up, but like I said, for all the environments Ive seen so far, offline migrations are a viable option so that this wouldnt rank high on my personal priority list :/