New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
@BronzeByte, Yup -- I'm just wondering how it actually ties into LVM to monitor the writes when using Xen, with KVM it can do it via QEMU I believe. I can poke at the libvirt code and figure that out though.
@jeff_lfcvps The downtime (1 to 5 seconds on a node with 60 VMs) is needed to sync the memory (ram) of the vps. VMware and other need this downtime too. Only VMware FT with only one vCPU can do this without any downtime. I think libvirt can do it with all supported virtualizations, but i only used it with kvm.
We have an internal network (1gbit/s) for migrations and do it very often to load balancing our nodes. Libvirt syncs with fullspeed (110MB/s)..None of our customers had recognized a migration.
Test it out, it works perfect here. I think a downtime around 1 to 5 secs ist ok, the customers don´t recognize this downtime.
Looks good :-)
I think the only catch with virsh migrate is that the LV Group name needs to be the same in both the source and the destination server?
Yes correct, lv must exist on both nodes with the same name. We have on all nodes the same configuration, so no problem here.
@soluslabs sorry we all miss the Thanks button!
The lack of disk resizing is a huge issue because customers cant upgrade their disks without downtime then. Adding a 2nd disk is not a solution.
Users who want live upgrades/downgrades of CPU/RAM/HDD without any downtime or reboot should just stay with OpenVZ.
1) Libvirt creates on the remote node a new vm with the same config.
2) Libvirt takes a snapshot of the hdd.
3) Libvirt copy the whole disk from the snapshot to the remote node.
4) Libvirt syncs the ram between both nodes.
5) Libvirt halt the vm, copy differentes to the new node. (Around 5 seks..)
6) Libvirt resume the vm of the new host.
You can test it easy:
1) Create the same lvm drive on the remote host.
2) Firing this command: virsh migrate --live --domain kvmXXX qemu+ssh://10.0.0.xxx/system --copy-storage-all --verbose --persistent --undefinesource --change-protection
This is all fine and good until it runs into an issue and just fails. We ran a test using virsh migrate in --live mode and 2 of the 14 tests failed with disk errors on the destination. That tells me it's not the solution we need. Live is all well and good but it's more prone to fail.
So from this (plus watching the video), it's not using live migration? When the VM has been copied, it'll just boots the VM on the destination node?
That is correct. The VM in the video is transferred offline in non automation mode. You do however have the option of a snapshot live migration but the failure rate is higher for obvious reasons.
Also if automation mode is on it will auto boot the VM on the destination, change VNC ports if theres a clash etc... and clean up the source node. But this will only happen if there were no errors.
That´s not correct. Today we migrated 30 VMs between the nodes. We using it longer than 6 months und all works fine. Nothing fails..if it not work probably why proxmox should using it without problems? When the migration fails, you must do nothing! The VM stays on the old node and is online. Start migrating again, but we don´t have any issues.
A cold migration isn´t a solution, that can you done with 3 commands..A solution for migration between nodes must work without the customer noticing.
A cold migration isn´t a solution, that can you done with 3 commands..A solution for migration between nodes must work without the customer noticing.
Ok then i'm lying. We decided not to use a function available to us that could save us a lot of hard work just because we wanted to?
We tested it with the the stock version of libvirt in C5 and C6, on both versions there are bugs.
I'm sorry but i'm not going to take a higher risk of losing users data if i don't have to.
You don´t lose any data on live migration. The source lv exist on the old node after a migration. Add the same delete dialog to the migration process and you have a secure live migration solution.
I can only say what i see, live migration works fine on proxmox, onapp and our mini script (php script on CentOS 6) for live migration of an vps.
Virsh (libvirt) have some nice features, proxmox and onapp using all virsh migrate --live, why not solusvm? I don´t see any issues with live migration on onapp or proxmox..
I have different LV group names on each node :S
vgrename ? I haven't tried it myself, don't know if it works on volume groups that are currently in use.
Thats fine. Only the LV name must be the same. Our solution does everything from creating, deleting and checking in either live or offline mode.
Do your migration process support live migration without shared storage?
Yeah, that´s bad. We using an template with the same configuration on all our nodes. You can rename it, but you need same work to reboot all VMs and edit solusvm node configuration.
Great there's an option for live migration.
Yeah, I'm not sure I want to do this on live servers... I don't like unnecessary downtime.
I'll keep it in mind for my next nodes though
Nice, but v1.14 is still not out, so I can't use it
Yes theres an option to just switch the hypervisor. I think its in the video.
Of course, it's always been there.
@soluslabs Nice! You do you implement live migration without share storage and libvirt?
Yeah
These are the options for data migration
And these are the options for shared storage migration (The vm data will be left alone)
Oh and don't forget the live network throttling
Nothing worse than starting a migration and it saturating the network.
Looks nice, well done! Any screenshots from the backup solution?
Waiting for the beta, i´ll have to migrate 50 VMs in the next days
@soluslabs When is this going to be released?
Soon: gyazo.com/3d75aae7750e765751ba2cc6fd11e641
Will bulk migrations be possible or implemented 'soon' after?
Yeah that would be a good idea!
I'm putting an ETA on v1.14 for Monday 18th March. That will give us 1 week from now to have a clean up and make any final changes.
A whole week?...
To confirm, we will have live KVM migrations?