Re: [Users] x86 32bit VEs on x86-64 OpenVZ
On Thu, Apr 22, 2010 at 07:24:44AM +0200, Zeeshan Ali Shah wrote: > Linux 2.6.26-2-openvz-amd64 #1 SMP Thu Feb 11 01:40:09 UTC 2010 i686 > GNU/Linux > > actually the program i want to install has dependency with 32 bit OS which > is why i created the new VM but it seems that this guest is still showing > the 64bit kernel . No, it does not. It clearly shows "i686" above. In fact, you could achieve a similar effect by running your program through the "setarch" program, like: $ setarch i386 uname -m i686 This would not require OpenVZ at all, but instead it'd require that you have 32-bit libraries installed on your system (you probably do) as these will likely be needed for your program (what the kernel says is likely of less importance). Anyway, you can indeed do this with OpenVZ as well, and you get better isolation in this way. Alexander ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] x86 32bit VEs on x86-64 OpenVZ
but why it says, 2.6.26-2-openvz-amd64 ? Zeeshan On Thu, Apr 22, 2010 at 9:03 AM, Solar Designer wrote: > On Thu, Apr 22, 2010 at 07:24:44AM +0200, Zeeshan Ali Shah wrote: > > Linux 2.6.26-2-openvz-amd64 #1 SMP Thu Feb 11 01:40:09 UTC 2010 i686 > > GNU/Linux > > > > actually the program i want to install has dependency with 32 bit OS > which > > is why i created the new VM but it seems that this guest is still > showing > > the 64bit kernel . > > No, it does not. It clearly shows "i686" above. > > In fact, you could achieve a similar effect by running your program > through the "setarch" program, like: > > $ setarch i386 uname -m > i686 > > This would not require OpenVZ at all, but instead it'd require that you > have 32-bit libraries installed on your system (you probably do) as > these will likely be needed for your program (what the kernel says is > likely of less importance). > > Anyway, you can indeed do this with OpenVZ as well, and you get better > isolation in this way. > > Alexander > ___ > Users mailing list > Users@openvz.org > https://openvz.org/mailman/listinfo/users > ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] x86 32bit VEs on x86-64 OpenVZ
On Thu, Apr 22, 2010 at 11:24:10AM +0200, Zeeshan Ali Shah wrote: > but why it says, 2.6.26-2-openvz-amd64 ? That's your kernel version string that got into the kernel at its compile time. It won't be changing when you switch the "personality" for a program or for an entire container to 32-bit, and that's OK. Your kernel is clearly capable of running both 64- and 32-bit programs (in other words, it's been compiled with 32-bit syscall emulation support). The "amd64" in the version string should not concern you. It's just a string. It could as well say "zilog80" or whatever if the person compiling the kernel wanted so, which would not affect the kernel's operation in any way. Alexander ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
[Users] quota file not compatible between OpenVZ 32 and 64 bits.
Hi, we have a two node Red Hat 5.4 cluster with openVZ. They use 32bit kernel but because hardware is 64bit, our intention is to migrate them to 64 bit operating system. We have tried the migration on a test cluster, migrating first only one of the nodes. After some tests, we have realized that quota file differs between versions, so to start the same VE in the other node, quota file must be droped an re-created. Could you confirm this? Any tip to workaround this? Thanks. Frank -- Aquest missatge ha estat analitzat per MailScanner a la cerca de virus i d'altres continguts perillosos, i es considera que està net. ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] quota file not compatible between OpenVZ 32 and 64 bits.
On Thu, Apr 22, 2010 at 11:47:41AM +0200, frank wrote: > we have a two node Red Hat 5.4 cluster with openVZ. They use 32bit > kernel but because hardware is 64bit, our intention is to migrate them > to 64 bit operating system. We have tried the migration on a test > cluster, migrating first only one of the nodes. After some tests, we > have realized that quota file differs between versions, so to start the > same VE in the other node, quota file must be droped an re-created. > > Could you confirm this? Confirmed. > Any tip to workaround this? You need to drop the old quota files - just move them out of the way. You also need to install a 64-bit build of vzquota before trying to start your containers up with the new kernel. If your host system lacks /lib64, you need to add that too. With all of these bits in place, it should work - it did with a similar upgrade for us. Alexander ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] x86 32bit VEs on x86-64 OpenVZ
is there any other way i can confirm the 32 bit version ? Zeeshan On Thu, Apr 22, 2010 at 11:44 AM, Solar Designer wrote: > On Thu, Apr 22, 2010 at 11:24:10AM +0200, Zeeshan Ali Shah wrote: > > but why it says, 2.6.26-2-openvz-amd64 ? > > That's your kernel version string that got into the kernel at its > compile time. It won't be changing when you switch the "personality" > for a program or for an entire container to 32-bit, and that's OK. > Your kernel is clearly capable of running both 64- and 32-bit programs > (in other words, it's been compiled with 32-bit syscall emulation > support). The "amd64" in the version string should not concern you. > It's just a string. It could as well say "zilog80" or whatever if the > person compiling the kernel wanted so, which would not affect the > kernel's operation in any way. > > Alexander > ___ > Users mailing list > Users@openvz.org > https://openvz.org/mailman/listinfo/users > ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
[Users] Vzmigration nightmare, ssh bug
Hi All, I had a terrible time migrating containers from one hardware not to another. I ran into the ssh bug with the public key not being accepted error: error: RSA_public_decrypt failed: error:0407006A:lib(4):func(112):reason(106) It was so random, migrating 50 containers, some would work and some migrations would prompt for the ssh password, truley random. I had to migrate some containers several times before the ssh session would establish and complete. I have 4 hardware nodes running Debian Etch with 2.6.18-14-fza-686-bigmem kernel with: libssl0.9.80.9.8c-4etch9 ssh4.3p2-9etch3 openssh-server 4.3p2-9etch3 These are the lates versions in the etch repository. So no upgrade was available. The strange thing is while migration between HN 1 & 2 was very problematic, migration between HN 4 & 5 worked as expected. All 4 nodes were built on the same day, same hardware and all have matching package versions and configuration. Does anyone have a workaround for this issue? Would upgrading to Lenny fix this problem? Could I just update SSH and SSL from the Lenny repository, would that resolve this? Any insight will be appreciated. Thanks. JR -- JR Richardson Engineering for the Masses ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
[Users] fs capacity difference
I know I am going to feel stupid for asking this but Hardware node and container are Centos 5.4 Kernel is ovzkernel-2.6.18-164.15.1.el5.028stab068.9 On the hardware node [r...@d3 ~]# df -h FilesystemSize Used Avail Use% Mounted on /dev/mapper/vg00-lvol00 3.9G 1.6G 2.2G 43% / /dev/md0 99M 42M 52M 45% /boot tmpfs1013M 0 1013M 0% /dev/shm /dev/mapper/vg00-lvol01 2.0G 744M 1.3G 37% /vz/private/3251 Inside the container [r...@d3srv ~]# df -h FilesystemSize Used Avail Use% Mounted on /dev/simfs2.0G 1.5G 524M 75% / none 1013M 4.0K 1013M 1% /dev Why is the fs 37% filled on the hardware node and 75% filled on the container Richard ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] fs capacity difference
Because if you see how much is your AVAILABLE space on each container hardware node has 2.2GB free and the container has 524mb free the size of the HD vary on both containers. Ing. Alejandro M. --- Hospedaje Web y Servidores Dedicados http://www.dedicados.com.mx --- ven...@dedicados.com.mx --- El 22/04/2010 04:06 p.m., Richard Ray escribió: I know I am going to feel stupid for asking this but Hardware node and container are Centos 5.4 Kernel is ovzkernel-2.6.18-164.15.1.el5.028stab068.9 On the hardware node [r...@d3 ~]# df -h FilesystemSize Used Avail Use% Mounted on /dev/mapper/vg00-lvol00 3.9G 1.6G 2.2G 43% / /dev/md0 99M 42M 52M 45% /boot tmpfs1013M 0 1013M 0% /dev/shm /dev/mapper/vg00-lvol01 2.0G 744M 1.3G 37% /vz/private/3251 Inside the container [r...@d3srv ~]# df -h FilesystemSize Used Avail Use% Mounted on /dev/simfs2.0G 1.5G 524M 75% / none 1013M 4.0K 1013M 1% /dev Why is the fs 37% filled on the hardware node and 75% filled on the container Richard ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] fs capacity difference
Why is the fs 37% filled on the hardware node and 75% filled on the container Your quota files are out of date. A very common cause of this, would be copying files directly into /vz/private/3251 from the HN. Copying directly into a VE's directory will bypass the quota calculation. For copying files from the HN into a VE, I use SFTP or similar. Seems silly to SFTP to what's basically localhost, but it does avoid hosing your quotas. -- HostGIS, Open Source solutions for the global GIS community Greg Allensworth - SysAdmin, Programmer, GIS Person, Security Network+ Server+ A+ Security+ Linux+ PHP PostgreSQL MySQL DHTML/JavaScript/AJAX "No one cares if you can back up — only if you can recover." ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] fs capacity difference
On Thu, 22 Apr 2010, Gregor at HostGIS wrote: Why is the fs 37% filled on the hardware node and 75% filled on the container Your quota files are out of date. A very common cause of this, would be copying files directly into /vz/private/3251 from the HN. Copying directly into a VE's directory will bypass the quota calculation. For copying files from the HN into a VE, I use SFTP or similar. Seems silly to SFTP to what's basically localhost, but it does avoid hosing your quotas. That is good to know but I did not do that The container is a vzdump restore The container dump that I used does not show a difference between it and the hardware node How do I get the quota back in sync Richard ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] fs capacity difference
Richard Ray wrote: That is good to know but I did not do that The container is a vzdump restore Oh, okay. Dunno about that one then. How do I get the quota back in sync Shut down the VE. Rename or delete its quota file in /var/vzquota Start it up. The quota will be recalculated as it starts. Restarting to fix quotas is kind of unpleasant, but it's the method I know. Perhaps someone can suggest a way of recalculating the quota file without restarting? -- HostGIS, Open Source solutions for the global GIS community Greg Allensworth - SysAdmin, Programmer, GIS Person, Security Network+ Server+ A+ Security+ Linux+ PHP PostgreSQL MySQL DHTML/JavaScript/AJAX "No one cares if you can back up — only if you can recover." ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
Re: [Users] Vzmigration nightmare, ssh bug
Hi, On 22.04.2010 16:36, JR Richardson wrote: > I had a terrible time migrating containers from one hardware not to > another. I ran into the ssh bug with the public key not being > accepted error: > > error: RSA_public_decrypt failed: error:0407006A:lib(4):func(112):reason(106) > > It was so random, migrating 50 containers, some would work and some > migrations would prompt for the ssh password, truley random. I had to > migrate some containers several times before the ssh session would > establish and complete. > > The strange thing is while migration between HN 1 & 2 was very > problematic, migration between HN 4 & 5 worked as expected. All 4 > nodes were built on the same day, same hardware and all have matching > package versions and configuration. > That points to hardware problems, either in your HNs or your network. I once had to debug randomly failing SSH sessions, and it turned out to be a faulty ethernet switch which corrupted data, but auto-corrected the checksums of the ethernet packets, and this caused SSH to abort in various stages. Can you use ssh reliably between HN 1+2? If yes, try running scp of a large file in both directions 100 times or so. The best idea is to copy the same file back and forth, so errors will accumulate. Compute the checksum of the file after each copy. I had SSH corrupt data in a tunnel and the SSH connection stayed stable although the tunneled data was clearly corrupt. Admittedly this was due to a faulty ethernet switch, but still I had expected SSH to abort the connection or at least ensure the integrity of my data, especially because the corruption was hardware failure and not a determined attacker. And yes, sometimes one machine in a batch of identical machines corrupts data, or one ethernet port corrupts data and all others are OK. Regards, Carl-Daniel -- http://www.hailfinger.org/ ___ Users mailing list Users@openvz.org https://openvz.org/mailman/listinfo/users
