OpenVZ Forum


Home » General » Support » *BUG REPORTED* Migration problem with 2.6.18-028stab035
*BUG REPORTED* Migration problem with 2.6.18-028stab035 [message #14826] Wed, 11 July 2007 12:22 Go to next message
draga is currently offline  draga
Messages: 20
Registered: July 2007
Junior Member
Hello. As suggested, I've upgraded my kernels to stab035.
Now the problem with online migration is:

root@desktop:~# vzmigrate -r no --keep-dst --online -v 192.168.5.200 2000
OPT:-r
OPT:--keep-dst
OPT:--online
OPT:-v
OPT:192.168.5.200
Starting online migration of VE 2000 on 192.168.5.200
OpenVZ is running...
    Loading /etc/vz/vz.conf and /etc/vz/conf/2000.conf files
    Check IPs on destination node: 192.168.200.101
Preparing remote node
    Copying config file
2000.conf                          100% 2043     2.0KB/s   00:00    
Warning: too large value for VMGUARPAGES=9223372036854775807:9223372036854775807 was truncated
Saved parameters for VE 2000
Warning: too large value for OOMGUARPAGES=6144:9223372036854775807 was truncated
Warning: too large value for PRIVVMPAGES=9223372036854775807:9223372036854775807 was truncated
Warning: too large value for PHYSPAGES=0:9223372036854775807 was truncated
    Creating remote VE root dir
    Creating remote VE private dir
    VZ disk quota disabled -- skipping quota migration
Syncing private
Live migrating VE
    Suspending VE
Setting up checkpoint...
        suspend...
        get context...
Checkpointing completed succesfully
    Dumping VE
Setting up checkpoint...
        join context..
        dump...
Can not dump VE: Device or resource busy
unsupported netdevice tun0
Checkpointing failed
Error:  Failed to dump VE
Resuming...


-.-.-.-.-.-.

so it seems I have a different kind of problem now.
tun device has been loaded on both the HNs.
Any suggestion?

Thank you!

[Updated on: Thu, 12 July 2007 04:30] by Moderator

Report message to a moderator

Re: Migration problem with 2.6.18-028stab035 [message #14831 is a reply to message #14826] Wed, 11 July 2007 12:34 Go to previous messageGo to next message
Vasily Tarasov is currently offline  Vasily Tarasov
Messages: 1345
Registered: January 2006
Senior Member
As I understand you're using tun device inside VE. The migration of VE with tun device is not supported at the moment. ;(

If tun device is not necessary in VE - just don't use it.
But if it is in VE deliberately... Do use tun device in VE deliberately? What for?

Thanks,
Vasily.
Re: Migration problem with 2.6.18-028stab035 [message #14839 is a reply to message #14831] Wed, 11 July 2007 14:34 Go to previous messageGo to next message
draga is currently offline  draga
Messages: 20
Registered: July 2007
Junior Member
Oh, that's why it fails.
I need the tun because the server acts as a openvpn server for many clients AND connects using openvpn to a router (so it's not important where the VE is, just that it can reach that router).
I think I can try to turn openvpn off, migrate and then turn it back on. But at that point perhaps it would be better to do an offline migration...do you think it will be supported in the future?

Thank you!

Vasily Tarasov wrote on Wed, 11 July 2007 14:34

As I understand you're using tun device inside VE. The migration of VE with tun device is not supported at the moment. ;(

If tun device is not necessary in VE - just don't use it.
But if it is in VE deliberately... Do use tun device in VE deliberately? What for?

Thanks,
Vasily.

Re: Migration problem with 2.6.18-028stab035 [message #14854 is a reply to message #14839] Wed, 11 July 2007 22:11 Go to previous messageGo to next message
draga is currently offline  draga
Messages: 20
Registered: July 2007
Junior Member
Well, partially solved: the machine performs a "vzctl exec veid /etc/init.d/openvpn stop" before the dump and a "start" before resuming. It works and the machine migrates.
The problem is that all the vpn connections are truncated (that means nearly all the VE's connections) but it's better than nothing.
Even if I don't think I'll use the online migration too much for my slow channel migrations: moving 500+ MB of ram is quite slow and you can avoid any advantage. I've tried passing a "-C" to ssh and things go better but it's still rather slow while it's good in LAN (also with wireless).
But I still hope to see tun support in online migration! Smile

[Updated on: Wed, 11 July 2007 22:12]

Report message to a moderator

Re: Migration problem with 2.6.18-028stab035 [message #14858 is a reply to message #14854] Thu, 12 July 2007 04:30 Go to previous messageGo to next message
Vasily Tarasov is currently offline  Vasily Tarasov
Messages: 1345
Registered: January 2006
Senior Member
Hello,

I filled the bug report http://bugzilla.openvz.org/show_bug.cgi?id=642 about the problem with tun device. It is really necessary to implement the migration of tun device! Smile

As concerns moving 500Mb RAM... Do you really have so thick VE? Wink
Well, ususally the dump file is not so large. You can check it by performing:
vzctl chkpnt VEID --dumpfile <file>
ls -lh <file>
Usually the most time-consuming part of migrating is syncing of private area. You can compress this data by adding "-z" option to rsync in vzmigrate script, as we already discussed...

Summary: Do you really think that the dump file is so big? (500+ Mb)

HTH,
Vasily

Re: Migration problem with 2.6.18-028stab035 [message #14863 is a reply to message #14858] Thu, 12 July 2007 06:37 Go to previous messageGo to next message
draga is currently offline  draga
Messages: 20
Registered: July 2007
Junior Member
Vasily Tarasov wrote on Thu, 12 July 2007 06:30

Hello,

I filled the bug report http://bugzilla.openvz.org/show_bug.cgi?id=642 about the problem with tun device. It is really necessary to implement the migration of tun device! Smile




Great! It would be wonderful. Removed the tun devices I can migrate perfectly so it's great.

Quote:



As concerns moving 500Mb RAM... Do you really have so thick VE? Wink
Well, ususally the dump file is not so large. You can check it by performing:
vzctl chkpnt VEID --dumpfile <file>
ls -lh <file>



mmm...I'll see. I just notices it needed something like 10 minutes to be transferred via wireless (3/4 minutes using the -C option of scp so there's a gain...maybe the dump could be gzipped Smile)

Quote:


Usually the most time-consuming part of migrating is syncing of private area. You can compress this data by adding "-z" option to rsync in vzmigrate script, as we already discussed...




Yes, I did so. The private area takes some time to migrate but the good thing is that the machine is working so it's not a problem for me.

Quote:



Summary: Do you really think that the dump file is so big? (500+ Mb)

HTH,
Vasily




I'll check the dimensions. Yes, it's a thick machine! Smile
I'd like to move all the services to separate VEs, in time. But I'll need a long time to do it! Smile

Thank you!
Re: Migration problem with 2.6.18-028stab035 [message #14970 is a reply to message #14863] Sun, 15 July 2007 21:24 Go to previous message
draga is currently offline  draga
Messages: 20
Registered: July 2007
Junior Member
I've been performing some tests BUT not with online migration: having to bring down/up the tun/tap devices brings more problems than rebooting the machine.
It works perfectly...really really good. Now I hope you'll implement the tun/tap live migration and I will be one of the happiest administrators of the world Smile
Previous Topic: *SOLVED* VEs with different subnets
Next Topic: *SOLVED* Out of socket memory
Goto Forum:
  


Current Time: Sat Nov 16 14:26:01 GMT 2024

Total time taken to generate the page: 0.03140 seconds