Yes follow the steps described on https://pve.proxmox.com/wiki/Proxmox_VE_2.0_Cluster#Remove_a_cluster_node
and you should be good. Be sure that you exported everything (vm's, backups and so on).
use
pvecm expected 1
ont the remaining node to have quorum and be able to remove the node.
Looks good to me.
So what does
mount /ehdd
output?
-------
EDIT:
For NTFS you maybe shouldn't use the "defaults" option in fstab, use "permission" instead.
Or to be really specific use : uid=1000,umask=0022
Where uid is the user id from the owner of the disk and umask is the right mask for...
No, I also doesn't see it. How do you mounted your disk in /ehdd?
http://www.debiantutorials.com/how-to-add-a-new-hard-disk-or-partition-using-uuid-and-ext4-filesystem/ may help, you can also skip the formatting part if you already have a valid formatted external disk (jump right to step 4).
Add a Storage (NFS or iSCSI) which points to your desired backup location (Datacenter->Storage->Add). Now, when you're making a backup job select the added remote storage as destination.
You could also make a backup job (Datacenter->Backup), so you automate things and doesn't have to worry about it.
What does
findmnt
return? Is your external disk mounted correctly?
VZDump makes some temporary files when you're backing up a running vm, to look if that's the problem use the vzdump command in a shell, you can take the command from the log output:
vzdump 109 --remove 0 --mode snapshot...
Tried it today on PVE3.4 with the
$ uname -a
Linux pve 3.10.0-11-pve #1 SMP Tue Jul 21 08:59:46 CEST 2015 x86_64 GNU/Linux
Kernel and it works, at least I can write and delete as much as I want without running into problems yet.
So it's sure worth a try, but keep in mind that you will loose...
I understand that the situation is, at least, uncomfortable to you. I'll take a look into the changes from 2.6.32-26-pve and when there is a relative quick fix I'll patch it.
I wonder a bit why nobody else got trouble from GFS2, as packages which get into the enterprise repository are deployed...
I got some news, I successfully (at least some simple test are working), ported GFS2 to the Proxmox VE 4beta, as I wanted to see how the status with PVE and GFS2 is now on a current kernel and it is alot easier to do that than to dig into 2.6.32 changes.
So if you're planning to update your PVE...
Hey I can reproduce your problem, even with lock_nolock (so without fencing), testet with 2.6.32-39-pve kernel...
The problem already showed up on the OpenVZ bug tracker, and also some other trackers, and was less or more marked as wont fix (at least in the OpenVZ one) and seems to persist...
Look at: http://serverfault.com/a/591015
And please note that writing in English in this community forum increases the chance that someone helps you highly.
So I tried your code and it works for me, tried it with root and with a testvnc user which only had the PVEVMUser permission.
Hmm, strange...
Sorry if I'm asking again, but you use exactly this API-client code...
Looks good to me. I'm using 4.0beta but as far as I know there weren't any changes regarding the Authentication or noVNC.
Can you please test it once with the root user? So we can see if it's a permission problem or something else.
Ok some additional changes to the setCookie function where needed to guarantee that it works in most situations:
public function setCookie() {
if (!$this->check_login_ticket()) {
throw new PVE2_Exception("Not logged into Proxmox host. No Login access ticket found or ticket...
You can't connect to the web gui anymore? Which version of Proxmox do you have? (run "pveversion --verbose" in a shell to get detailed infos)
#EDIT: saw your post to late, so not needed anymore, but which Proxmox VE version are you running?
Last time I tested everything and it worked without...
The user which wants to see the noVNC console need to have the VM.Console permission. The predefined role "PVEVMUser" has it for example.
Are your sure the user you use has these permissions?
Yes, when you read my whole post you see the problem.
Proxmox noVNC uses a Cookie which includes the ticket (Authorization) of your session, generated by the webUI.
So if you want to let an user connect to noVNC without forcing him to long in into the WebUi you have to set this cookie manually...
When you want to know how you can contribute, take a look at http://pve.proxmox.com/wiki/Developer_Documentation#Git_commands_summary
That GitHub proxmox repo isn't the offical git repo, use this one https://git.proxmox.com/ (hasn't any fancy webview), and AFAIK it isn't controlled by proxmox...
Use a bash script to relink uname, as a dirty workaround?
backup your old uname from /bin/uname then save this as the new /bin/uname
#!/bin/bash
setarch x86_64 uname "$@"
should work for your purpose.
Sorry about that, I over read that with pwconv... (fixed the typo above).
password from normal user should be changeable with:
passwd -r files username
Duh, haven't really a clue here, maybe anyone else has...
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.