aha.
if it hasnt gotten out of boot yet, its not really started, so shutdown doesnt apply.
'stop' does in fact work, when its still in bios, apologies!
only convenient to have on the GUI because some of us want to delegate sub-access to customers to control their own micro-cloud (quote unquote) of images, etc, without giving root away...
yes of course. pressing it a 2nd time gave a log entry for it - curiously the 2nd attempt had the fail msg come up first while the first attempt was still spinning. eventually they both went to 'fail' (though the first one
might have only failed once I killed it from the cmd line actually..)...
how can this be extended to subusers of the VM in the web interface who are given group control over a collection of VMs?
this would be fine if hardware could be removed after it gets stuck in BIOS, but it seems to not be possible, even after CTRL-ALT-DEL (hmm, maybe more hardware can be added...
And how do you shutdown a VM that's stuck waiting for a TFTPboot/failed boot? doesnt the virt bios accept ACPI signals?
TASK ERROR: VM quit/powerdown failed - got timeout
aha. I suppose the ultimate issue is rsync cant copy deleted files, even if we can get at the content via /proc/*/fd - no way to drop it in the right place in the filesystem for the migrated container to find without some kinda hacky support in the OpenVZ kernel. Actually Im quite suprised that...
few comments down in that thread I posted on the bug: https://bugzilla.openvz.org/show_bug.cgi?id=2242#c33
more specifically: https://bugzilla.openvz.org/attachment.cgi?id=1886&action=diff
maria has even more links to deleted files in /tmp for some reason (not that it matters, any more than zero is an issue). it's still better than mysql :)
however, im not always aware and can't vette every piece of software my customers will run, so migratability could be an issue without this...
in an ideal world of cooperative under-one-person/design's control yes, that'd be great, but I support multiple different customers with various versions of mysql and debian etc etc. It's a big mixed bag. Any proper virtualization/containerization environment can support these disparate servers...
some technical elements brought here from http://forum.proxmox.com/threads/11983-OpenVZ-Ploop-support
bug is caused by mysql keeping FH's open on unlinked files: https://bugzilla.openvz.org/show_bug.cgi?id=2242
a patch is out for that.
However, I suspect think this will not work with rsync...
I dont think that would work - cant just suspend mysql, you need to completely shut it down. The reason is because this is the actual bug:
https://bugzilla.openvz.org/show_bug.cgi?id=2242#c26
summary: mysql keeps filehandles open on unlinked (deleted) files. [facepalm]
There's a patch to the...
Right now im under the belief that use of ploop for containers would solve the mysql migration issue by providing an actual filesystem image where inodes map to the same files on any host once live-migrated (vs living on the very different filesystems of the hosts). If im wrong, then we can...
Where we at with this? Seems no replies in a couple months and this is a major blocking issue.
Put simply "cannot migrate typical LAMP server" which is 80% of my installs (and probably the world), and never mind if mysql is actually writing at the time or recently, it just has to be running to...
Central storage: meant NFS or the like. Complexifies things needlessly in my environment.
Backup speed isnt a big deal to me right now (backing up with rsync to an old recycled target with --link-dest is pretty fast, even across 10M files (Im using linux-vserver right now) -but isnt quite a...
Im interested in ploop because of the journaling IO loads affecting other containers, as well as the snapshotting abilities. Not to mention the live migration iterative loop which uses FAM/inotify style logging (like constant data replicator) to track what was modified during the initial copy...
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.