Re: EXT4 Fs corruption
Hi Bram, What is your hypervisor? -Wei On Tuesday, 16 May 2023, Bram Gillemon wrote: > Hi, > > i'm having some issues with filesystems that are having filesystem > corruption when fstrim is triggered by systemd. > > When searching the internet i found some posts mentioning i should disable > the storage cache. Anyone else who has noticed this problem? > > How can i change the cache mode on the created disk offerings? Is it > enough to just update the table in the database and reboot the servers? > > Kind Regards, > Bram
Re: How to create network based on DefaultL2NetworkOfferingConfigDriveVlan?
Hi Stephan, thank you so much! Using API and defining one account with 'domain admin' role in domain, the L2 network was created and is working fine! Thanks! :) Em sex., 26 de mai. de 2023 às 08:50, Stephan Bienek escreveu: > Hello Jeorge, > > indeed you have to be root admin to deploy a network with SpecifyVlan = > true > I experienced the same challenge as you did - the network will be owned by > the root domain, even tough providing a domain (without an account). > > In my case it perfectly works when i define the domain AND an admin > account of this domain - the network is owned by the domain and account > correctly. > > Are you sure you defined the Domain AND the right account (not user) of > the domain? > Did you try via API / Cloudmonkey? > > Best regards, > Stephan > > > Jorge Luiz Correa hat am 26.05.2023 > 13:24 CEST geschrieben: > > > > > > Hi all! How can I use the network offering > > DefaultL2NetworkOfferingConfigDriveVlan? I would like to create a new L2 > > network to be used by domain TEST, with vlan id 2123. DHCP will be > > external. I need to use ConfigDrive to be able to set VM hostname and > > password and Vlan to define the vlan id for the network. > > > > Using a domain admin account in TEST domain I can't create that network > > because I can't choose the vlan id. If I use ROOT Admin to create I can > > inform the vlan id but, even choosing the domain TEST, after creation the > > new network has Domain=ROOT and Account=admin. I've already tried to > inform > > the domain and one account from TEST domain (as say help, 'account that > > will own the network') but no success. Inside the TEST domain I can't see > > the new network. > > > > As a workaround I've created a new network offering using shared, with > > vlan, then enabled just UserData : ConfigDrive as provider. So, I could > > create a new network as ROOT admin, configure the vlan id and the domain. > > But I guess this is not the right way, I had to configure gateway, start > > and end ip addresses, but none of these make sense, they are not used. > > > > Appreciate any help! > > :) > > > > -- > > Jorge Luiz Corrêa > > Embrapa Agricultura Digital > > > > echo "CkpvcmdlIEx1aXogQ29ycmVhCkFu > > YWxpc3RhIGRlIFJlZGVzIGUgU2VndXJhbm > > NhCkVtYnJhcGEgQWdyaWN1bHR1cmEgRGln > > aXRhbCAtIE5USQpBdi4gQW5kcmUgVG9zZW > > xsbywgMjA5IChCYXJhbyBHZXJhbGRvKQpD > > RVAgMTMwODMtODg2IC0gQ2FtcGluYXMsIF > > NQClRlbGVmb25lOiAoMTkpIDMyMTEtNTg4 > > Mgpqb3JnZS5sLmNvcnJlYUBlbWJyYXBhLm > > JyCgo="|base64 -d > > > > -- > > __ > > Aviso de confidencialidade > > > > Esta mensagem da > > Empresa Brasileira de Pesquisa Agropecuaria (Embrapa), empresa publica > > federal regida pelo disposto na Lei Federal no. 5.851, de 7 de > dezembro > > de 1972, e enviada exclusivamente a seu destinatario e pode conter > > informacoes confidenciais, protegidas por sigilo profissional. Sua > > utilizacao desautorizada e ilegal e sujeita o infrator as penas da > lei. > > Se voce a recebeu indevidamente, queira, por gentileza, reenvia-la ao > > emitente, esclarecendo o equivoco. > > > > Confidentiality note > > > > This message from > > Empresa Brasileira de Pesquisa Agropecuaria (Embrapa), a government > > company established under Brazilian law (5.851/72), is directed > > exclusively to its addressee and may contain confidential data, > > protected under professional secrecy rules. Its unauthorized use is > > illegal and may subject the transgressor to the law's penalties. If you > > are not the addressee, please send it back, elucidating the failure. > -- __ Aviso de confidencialidade Esta mensagem da Empresa Brasileira de Pesquisa Agropecuaria (Embrapa), empresa publica federal regida pelo disposto na Lei Federal no. 5.851, de 7 de dezembro de 1972, e enviada exclusivamente a seu destinatario e pode conter informacoes confidenciais, protegidas por sigilo profissional. Sua utilizacao desautorizada e ilegal e sujeita o infrator as penas da lei. Se voce a recebeu indevidamente, queira, por gentileza, reenvia-la ao emitente, esclarecendo o equivoco. Confidentiality note This message from Empresa Brasileira de Pesquisa Agropecuaria (Embrapa), a government company established under Brazilian law (5.851/72), is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you are not the addressee, please send it back, elucidating the failure.
Re: EXT4 Fs corruption
Hi Bram, I cannot comment on this problem, but updating the cache method of your disk offerings in the database, then stop *and* start or (reboot forced=true) is sufficient to change the way your virtualisation software handles the disk image. Met vriendelijke groet / Kind regards, Ruben Bosch CLDIN > On 29 May 2023, at 20:52, Bram Gillemon wrote: > > Hi, > > does anyone have an idea on what the best approach would be to change these > values? > > i'm running cloudstack 4.18.0.0 > > Kr, > Bram > >> On 16 May 2023, at 14:38, Bram Gillemon wrote: >> >> Hi, >> >> i'm having some issues with filesystems that are having filesystem >> corruption when fstrim is triggered by systemd. >> >> When searching the internet i found some posts mentioning i should disable >> the storage cache. Anyone else who has noticed this problem? >> >> How can i change the cache mode on the created disk offerings? Is it enough >> to just update the table in the database and reboot the servers? >> >> Kind Regards, >> Bram >
Re: EXT4 Fs corruption
Hi, does anyone have an idea on what the best approach would be to change these values? i'm running cloudstack 4.18.0.0 Kr, Bram > On 16 May 2023, at 14:38, Bram Gillemon wrote: > > Hi, > > i'm having some issues with filesystems that are having filesystem corruption > when fstrim is triggered by systemd. > > When searching the internet i found some posts mentioning i should disable > the storage cache. Anyone else who has noticed this problem? > > How can i change the cache mode on the created disk offerings? Is it enough > to just update the table in the database and reboot the servers? > > Kind Regards, > Bram
Re: ACS upgrade to Log4J2 version 2.19
Hi João, I'm using the latest mbx as from https://github.com/shapeblue/mbx there is no private fork/version that I'm using. I did a quick test against 4.19/main EL8 packages from latest main branch from today and they're deploying okay for me. I'm using mbx on a NUC9 i7 based mini-pc server with Ubuntu 22.04 + KVM. Regards. From: João Jandre Paraquetti Sent: Friday, May 26, 2023 20:04 To: d...@cloudstack.apache.org ; users@cloudstack.apache.org Subject: Re: ACS upgrade to Log4J2 version 2.19 Hi Rohit, > PR has issues with intermittent Github Actions failures (which I'm not sure are due to the PR or generally - this needs to be investigated and fixed). While simulator-based Github Actions smoketests appear to pass, and perhaps the PR works in your environment, it doesn't work with actual environments with both BO/Trillian and mbx. In actual env, systemvms not starting and I could reproduce Joao's volume issue, which doesn't happen with 4.18 pkgs using mbx or Trillian/BO (so I think the PR isn't stable yet). I see Daan has also found and has reported other issues. The issues reported by you happened to me even when using packages from main. MBX has the same behavior with both packages (main and my PR). Maybe you are using a different version of MBX that is not the one in github? > Since this is a rather large PR change, it would also require some manual testing of the logs and upgrade tests and for the community to commit efforts towards that. It's possible more runtime issues are found with different hypervisors/storages, so it's important the PR tests exhaustively all the supported hypervisors, and at least NFS and local storages (scaleio, ceph, storpool, linbit etc. would be great too). Due to this, this can potentially take more time and effort to stablise it, and maybe far away to consider merging. The manual testing has already been done by at least 3 people. With multiple hypervisors and plugins. As always, further testing is welcome. About upgrading and supporting the community, I am happy to help review PRs and point people in the right direction, I also can try my best to respond questions in the ML regarding log4j2. As for the log4j2 configuration upgrade, the new configs will have the same names and same paths as the old ones, this upgrade has already been tested. All that users must do when installing the new packages is answer 'yes' when questioned about upgrading the log4j config. Best regards, João Jandre (JoaoJandre) On 26/05/2023 06:19, Rohit Yadav wrote: > João, Daniel, Daan, All, > > I've reviewed and tested the PRhttps://github.com/apache/cloudstack/pull/7131 > using packages Daan uploaded onhttps://download.cloudstack.org/testing/7131/ > (thanks Daan!) and added my comment on the PR. > > PR has issues with intermittent Github Actions failures (which I'm not sure > are due to the PR or generally - this needs to be investigated and fixed). > While simulator-based Github Actions smoketests appear to pass, and perhaps > the PR works in your environment, it doesn't work with actual environments > with both BO/Trillian and mbx. In actual env, systemvms not starting and I > could reproduce Joao's volume issue, which doesn't happen with 4.18 pkgs > using mbx or Trillian/BO (so I think the PR isn't stable yet). I see Daan has > also found and has reported other issues. > > Since this is a rather large PR change, it would also require some manual > testing of the logs and upgrade tests and for the community to commit efforts > towards that. It's possible more runtime issues are found with different > hypervisors/storages, so it's important the PR tests exhaustively all the > supported hypervisors, and at least NFS and local storages (scaleio, ceph, > storpool, linbit etc. would be great too). Due to this, this can potentially > take more time and effort to stablise it, and maybe far away to consider > merging. > > We also need some plan on how we support users esp for upgrades and other > developers in the community. Reflecting on this, here's what I propose we > should do once the PR is ready for testing, passes testing and community > guidelines for merging: > >* Figure out and document manual/semi/automated steps that users should > take while upgrading to future ACS version which has this PR. For example, > the packages post-install script could figure out a way wherein old log4j xml > config is renamed/backed-up and new only is installed in a way that it > continues to log in the same file/path so as not to disrupt a normal user's > expectation of CloudStack logging (the log file paths and logging format). >* We need an upgrade documentation PR as for admin users. >* Anybody with a private plugin/integration would likely be impacted by > them. But the authors can build support on dev@ ML and support them, esp >
