Re: [Users] Template creation [Debian 8 minimal 32-bit missing]

[Scott Dowdle]

Greetings,

- Original Message -
> I believed that OpenVZ team was releasing scripts and/or procedures of
> their supported templates generation.

Yes for Virtuozzo 7 but not, so far as I know, for OpenVZ Legacy.  I hope I'm 
wrong on that.

TYL,
-- 
Scott Dowdle
704 Church Street
Belgrade, MT 59714
(406)388-0827 [home]
(406)994-3931 [work]
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Template creation [Debian 8 minimal 32-bit missing]

[Scott Dowdle]

Greetings,

- Original Message -
> Is there any script that allows me to reproduce same as
> "debian-8.0-x86_64-minimal" template but for an x86 only version?

Unfortunately the build system for official OpenVZ Legacy OS Templates is not 
public so no.  I'm guessing you care more about finding a minimal 32-bit Debian 
OS Template than building it yourself, right?  That begs the question... why 
there isn't a 32-bit version?

Anyone?  Can we get one built please?

If the answer is no, then we can move on into a discussion on how to build an 
OS Template.  It really isn't that difficult, but if we are lucky, they can 
just add the 32-bit version to their list.

TYL,
-- 
Scott Dowdle
704 Church Street
Belgrade, MT 59714
(406)388-0827 [home]
(406)994-3931 [work]
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Template creation [Debian 8 minimal 32-bit missing]

[Narcis Garcia]

I believed that OpenVZ team was releasing scripts and/or procedures of
their supported templates generation.


El 05/04/16 a les 17:46, Scott Dowdle ha escrit:
> Greetings,
> 
> - Original Message -
>> Is there any script that allows me to reproduce same as
>> "debian-8.0-x86_64-minimal" template but for an x86 only version?
> 
> Unfortunately the build system for official OpenVZ Legacy OS Templates is not 
> public so no.  I'm guessing you care more about finding a minimal 32-bit 
> Debian OS Template than building it yourself, right?  That begs the 
> question... why there isn't a 32-bit version?
> 
> Anyone?  Can we get one built please?
> 
> If the answer is no, then we can move on into a discussion on how to build an 
> OS Template.  It really isn't that difficult, but if we are lucky, they can 
> just add the 32-bit version to their list.
> 
> TYL,
> 
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

[Users] Virtuozzo 7 bridged network

[Alexander Pyhalov]

Hello.

Previously we used something like
NETIF="ifname=eth0,bridge=br100,mac=E2:18:28:65:35:AA,host_ifname=veth118.0,host_mac=00:18:51:89:A9:D7"
to configure bridged networks for containers.
Now this evidently doesn't work.

I've tried to follow Virtuozzo 7 documentation (where bond0.100 is 
interface for vlan 100 over bond0).


# prlsrvctl net add vlan100 -t bridged -i bond0.100
Failed to add Virtual Network vlan100: Operation failed. Failed to 
execute the operation.


What am I doing wrong? How am I supposed to configure bridged network 
for container?


I've tried to follow 
https://lists.openvz.org/pipermail/users/2016-February/006788.html, but 
it doesn't work for me, prlsrvctl net list doesn't see the network after 
modification.


--
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

[Users] Template creation

[Narcis Garcia]

Hello;
Is there any script that allows me to reproduce same as
"debian-8.0-x86_64-minimal" template but for an x86 only version?

Thanks.
___
Users mailing list
Users@openvz.org
https://lists.openvz.org/mailman/listinfo/users

Re: [Users] Performance degradation on 042stab113.X

[Vasily Averin]

Dear Karl,

it is good surprise for me, and I cannot explain why this happen.

Probably following fix was help you:
042stab113.18:
* force charge swapin readahead pages if in ub0 (PSBM-44857)

Backup on host triggered memory reclaim activity inside containers,
and we had few reports about hard node lockups in such situation.

I expected it isn't your case because your node was not hang completely,
but probably it improves performance for your testcase too.

First wave of tests on 042stab114.5 kernel was finished successfully 
and at present we did not detected any new issues.
The testing is still in progress and many other tests was not executed yet,
however seems we broke nothing during our re-base,
and I hope this kernel will be good for production too.

We have finished re-base to rhel6u8 beta kenrel too,
first kernel was started successfully and passed validation on my test node.
We've noticed 2 issues only:
- first one was minor re-base-relates issue, one of our patches was corrected
- second one was critical bug in RHEL kernel, 
I've escalated it to Red Hat and they have fixed it already. 
All developers loves early bugreports from beta testers :).

So I prepare 115.2 kernel with these bugfixes and going to publish it 
today-tomorrow.

Thank you,
Vasily Averin.

On 04.04.2016 22:11, Karl Johnson wrote:
> Hi Vasily,
> 
> I've upgraded two nodes last week from 113.12 to 113.21 and it seems
> better. Backups last weekend took the same time as it was on <=108.8.
> I'll still keep an eye on this and also on the development of 115 in
> OpenVZ Jira.
> 
> Thanks!
> 
> Karl
> 
> On Thu, Mar 31, 2016 at 4:13 AM, Vasily Averin  > wrote:
> 
> On 30.03.2016 18:38, Karl Johnson wrote:
> > Hi Vasily,
> >
> > I do indeed use simfs / ext4 / cfq. Only a backup of each containers
> > private areas is done with vzdump and then transferred to a backup
> > server with ncftpput. Compressing the data is OK while transferring
> > the dump over local network peak the load so the issue is with (read)
> > IO. I’m trying to find out why it was fine before and cause problem
> > now. Those nodes are in heavy production so it’s hard to do testing
> > (including downgrading kernel).
> 
> Few lists of blocked processes taken on alt+sysrq+W "magic sysrq" key can 
> be useful,
> it allows to see who is blocked, and it allows to see dynamic of process,
> but it does not explain who causes this traffic jam.
> 
> I'm sorry, but another ways of troubleshooting are much more destuctive.
> Moreover even kernel crash dump does not guarantee success in your case.
> It allows to see whole picture with all details,
> but it does not allow to understand the dynamic of process.
> 
> > Thanks for all the information on futur roadmap. I’m glad that the
> > work as already begun on RHEL 6.8 rebase. I read the beta technical
> > notes last week and some upgrades seem great. Do you consider
> > 042stab114.5 stable even if it’s in the testing repo? I might try it
> > tomorrow and see how it goes.
> 
> In fact we do not know yet.
> 
> 114.x kernels includes ~30 new patches from Red Hat and ~10 our ones,
> and we had few minor rejects only during re-base.
> At the first glance it should not cause problems,
> but first 114.x kernel was crashed on boot,
> and 114.4 was crashed after CT suspend-resume.
> In both cases we was need to re-work our patches.
> 
> 042stab114.5 kernel work well on my test node right now,
> but it is not ready for production yet and requires careful re-testing.
> So if you have some specific workload, we would be very grateful
> for any testing and bugreports.
> It allows us to know about hidden bugs before release.
> 
> thank you,
> Vasily Averin
> 
> > Regards,
> >
> > Karl
> >
> > On Wed, Mar 30, 2016 at 5:48 AM, Vasily Averin    >> wrote:
> >
> > Dear Karl,
> >
> > thank you for explanation.
> > however some details are still not it clear.
> >
> > I believe you use simfs containers (otherwise you can do not worry 
> about PSBM-34244,
> > using of 113.12 kernels also confirms it)
> > but it isn't clear how exactly you backup your nodes.
> > Do you dump whole partition with containers or just copy containers 
> private areas somehow?
> > What filesystem you have on partition with containers.
> > What is backup storage in your case?
> >
> > Anyway seems you do not freeze filesystem with containers before 
> backup.
> > This functionality was broken in RHEL6 kernels quite long time,
> > and Red Hat fixed it in 2.6.32-504.x and 573.x kernels.
> >
> >