OpenVZ Forum - RDF feed
type: channel
items: suspend/resume instead of stop/start from vz init script
items: Re: suspend/resume instead of stop/start from vz init script

suspend/resume instead of stop/start from vz init script
type: item
description: Hi, Is there any logical reason why to not dump/restore a container when issuing a "service vz stop|start" command? Iy would make sense that it would be much quicker as no longer do we have hundreds of processes across the containers starting up. The other benefit is that the VPS's do not even see a reboot and maintain their "uptime" as the uptime command reports. Perhaps there could be an option in /etc/vz/vz.conf whether to do the dump/restore or stop/start variations. I'm open for arguments on why this is a bad idea. Thanks, Matt
creator: TheWiseOne
date: 2008-05-14T15:12:20-00:00

Re: suspend/resume instead of stop/start from vz init script
type: item
description: Hi Matt, Matt Ayres wrote: > Is there any logical reason why to not dump/restore a container when > issuing a "service vz stop|start" command? Iy would make sense that it > would be much quicker as no longer do we have hundreds of processes > across the containers starting up. The other benefit is that the VPS's > do not even see a reboot and maintain their "uptime" as the uptime > command reports. > > Perhaps there could be an option in /etc/vz/vz.conf whether to do the > dump/restore or stop/start variations. > > I'm open for arguments on why this is a bad idea. 1) suspend should write dump file to disk. This dump file can be a quite large and it's write will be not faster than usual stop. Restore take a some time too. IMHO we have measured these times -- and found that suspend/resume is not faster than stop/start. I would suggest you to re-check this experiment on your nodes, it would be very interesting for us to see some real numbers from real life. 2) suspend/resume is a bit more risky operations than usual stop/start, especially after kernel update. Also I would note that in this case some paramters (uname for example) will be changed and it can lead to the troubles in some userspace applications. On the other hand I tend to agree, this option can be useful for some scenarios, however I right now I'm not ready to contrive some understandable example. Do you probably able to describe the situation where this way will give us some significant benefits? thank you, Vasily Averin
creator: Vasily Averin
date: 2008-05-15T06:34:56-00:00