Recent content by loucypher

Swap is 2 GiB, but has no effect, since the system never uses that. Using KVM, I have a running system, with 1 CPU, 1.2 GiB RAM and 2 GiB swap space (still not used): only with an OpenVZ container the application can't run (even with 2 CPU and 2 GiB RAM); with PVE 1.8 the OpenVZ container was...

I used up to 2 CPUs (don't have more, the server has an AMD Neo N36L, dual core, 1.3 GHz) and up to 2 GiB RAM. Looks like Java eats up any advantage of having a sleek OS... I start having the bad feeling I'll have to drop PVE 2.1, or SVN Edge, or both. Note however that server load has never...

I had a previous installation of PVE 1.8, of an OpenVZ container with the base Debian 6, running a CollabNet Subversion Edge server. To perform an update to PVE 2.1 I backed up the container on an NFS resource, and everything went fine on restore. I restarted then the SVN Edge console (a Java...

Fine, that's what I needed! Maybe the default behavior ain't that useful for every case: if I had a 2 TiB disk, root size would be like hundreds of GiB? IMHO it would be proper to set a cap on maximal (default) root space. Lou

Oh thanks, I saw the directories, but at first I thought they were for other internal data: as I moved my backups in there, it all worked. Maybe that info should be included in the upgrade wiki? Lou

I noted right now that root partition size, in a PVE 2.1 installation, is quite generous: in my case almost 37 GB. Looking at the summary I see that used space (on a fresh installation) is well below 1 GB, so I wonder what are the needs for preallocating so much space -- that in my case (small...

I made a backup of two OVZ from PVE 1.8 on an NFS share, and all went fine: after the backup they were listed correctly from the web console, and on the destination machine. Now, I reinstalled from scratch PVE 2.1 on that same original server, but when I attach the remote NFS storage, I can't...