Some minor bugs ...

[marotori]

Hello,

I am not sure where to report these -or if they are already known?

1. vzmigrate option in gui does not allow you to do a 'non online' migration. But you can from the CLI?
2. after extended periods of running - the left had box on the gui looses the ability for the scroll bar to function. A refresh of the whole page resolves it.
3. if you have lots of notes... the should be natural case sorted. e.g. cloud10 should not display before cloud2.

All minor things

 

[tom]

Hello,

I am not sure where to report these -or if they are already known?

1. vzmigrate option in gui does not allow you to do a 'non online' migration. But you can from the CLI?

works here. but note, the container cannot run if you do a offline migration.

2. after extended periods of running - the left had box on the gui looses the ability for the scroll bar to function. A refresh of the whole page resolves it.

yes, a known minor issue in some cases, related to some extjs problems with some browsers.

3. if you have lots of notes... the should be natural case sorted. e.g. cloud10 should not display before cloud2.

All minor things

 

[marotori]

Hello,

I get the fact that is has to be offline to migrate. No issue there.

However... in previous version you could achieve a migration and it would shutdown & start the box automatically between first and final syncs. Any reason why this has been removed?

I personally find that option more reliable. When you are syncling large file systems - the live migrate - option is not always so successfull

 

[dietmar]

Any reason why this has been removed?

Because stop/migrate/start is not an atomic action. So we think it is better to let the user stop/start the VM.

 

[marotori]

I get the logic of this - but it does not always work.

Consider a problem that alerted me to this issue:

A client has 180GB or storage in a container. Any attempt to 'live migrate' the node fails with an error. Checksumming failed.

So.. the only solution is to stop the live container (which has allot of websites on it); and migrate it. On a 1GB link this level of downtime is not really acceptable.

At the moment - the only solution is to manually do what vzmigrate used to do. Rsync.. power down node.. rsync.. copy config. All rather slow and messy - and requires being on hand to make sure I am there when the second rsync runs to power up the node again!

To me.. it simply makes sense to allow the option in the CLI command. No need in the gui.. but atleast allow techie users the option?

This will also make life easier later.

Consider. At some point you will release a new kernel version. In my experience live migrations between different kernel versions is risky. So how do we migrate nodes when we want to do an upgrade? Or is the plan to upgrade.. reboot.. and hope?

Rob

 

[dietmar]

Any attempt to 'live migrate' the node fails with an error. Checksumming failed.

Well, the plan is that this does not fail.

 

[marotori]

Well, the plan is that this does not fail.

That is good to hear

What about the situation that.. occationally.. processes will not migrate properly?

I usually find the issue is things like mail servers under virtualmin.

They migrate - but just dont seem to work after migration? Simply restarting the service solves it - but not ideal.

Btw.. thanks for the time and effor you are putting into this product! It is superb

Rob