[PVE-User] New Kernel - 2.6.32-16 (2.6.32-79) - pvetest

[David Black]

I didn't try mysql, but the NFS lock files were a problem for me, even without it - thinking just some always-started app in the boot process (besides mysql) also held locks. 

NFS lock files are a particular problem for something like OpenVZ that uses the native filesystem for storage, while being able to virtually move the CT OS image from one host (NFS client) to another (and without the OS image's awareness it was moved). If OpenVZ can't itself control their creation, it seems to me they have to be ignored. As someone suggested, the nolock mount option may help. It's not as bad as it sounds to run w/o locks BTW - many NFS servers implement only advisory locking anyway, so if another process tried to clobber a "locked" file, it wouldn't be prevented. 

Dave 

----- Original Message -----

> From: David Black [mailto:proxmox at 1000.relay.net]
> Sent: Donnerstag, 18. Oktober 2012 12:07
> To: Martin Maurer
> Cc: proxmoxve (pve-user at pve.proxmox.com)
> Subject: Re: [PVE-User] New Kernel - 2.6.32-16 (2.6.32-79) - pvetest

> OpenVZ live migration with the CTs on NFS storage now appears to
> work! Several live migrates back and forth between two nodes running
> the new kernel completed without errors - first time I've been able
> to do that.

> [Martin Maurer]
> I tested with a simpel Debian 6 container. It sorks, but as soon as I
> start mysql I see the issue described in
> https://bugzilla.proxmox.com/show_bug.cgi?id=71
> _______________________________________________
> pve-user mailing list
> pve-user at pve.proxmox.com
> http://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-user
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.proxmox.com/pipermail/pve-user/attachments/20121018/396ed306/attachment.htm>