[ovirt-users] Re: Update single node environment from 4.3.3 to 4.3.5 problem
Il Ven 23 Ago 2019, 18:00 Gianluca Cecchi ha scritto: > On Fri, Aug 23, 2019 at 5:06 PM Dominik Holler wrote: > >> >> >> >> Gianluca, can you please share the output of 'rpm -qa' of the affected >> host? >> > > here it is output of "rpm -qa | sort" > > https://drive.google.com/file/d/1JG8XfomPSgqp4Y40KOwTGsixnkqkMfml/view?usp=sharing > Anything useful from list of pages for me to try? Thanks Gianluca > > ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/UO2B577KN5NETNCPAQDCBNRCTZAX7IIP/
[ovirt-users] TASK [ovirt.hosted_engine_setup : Get local VM IP] Problem
hi guys, ı waiting this part when I try to install with hosted-engine --deploy command.have you got any knowledge about that.My environment(hyper-v running nested vm on azure and rhev running on hyper-v) [ INFO ] changed: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Create local VM] [ INFO ] changed: [localhost] [ INFO ] TASK [ovirt.hosted_engine_setup : Get local VM IP] ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/A5FHXA7BHPN7ICJS6ORCRIBY6NOFWOZE/
[ovirt-users] Migration from bare metal engine to hosted doesn't seem to work at all in 4.3.2
Hi all, I'm trying to migrate from an ovirt bare metal instance to the hosted appliance. The instructions here: https://www.ovirt.org/documentation/self-hosted/chap-Migrating_from_Bare_Metal_to_an_EL-Based_Self-Hosted_Environment.html are at best murky, and at worst quite wrong, and I'm looking for some help. The instructions say "You must answer No to the following question so that you can restore the BareMetal-Engine backup file on HostedEngine-VM before running engine-setup. Automatically execute engine-setup on the engine appliance on first boot (Yes, No)[Yes]? No" Makes complete sense, except this question is not asked at all. Some research on the internet says we should be able to do this via append-answers: [environment:default] OVEHOSTED_VM/cloudinitExecuteEngineSetup=bool:False Except this doesn't work either. When the appliance deploys the engine is setup and already running. How do I take a backup file, and a backup log, and deploy them into a hosted engine? Clint ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/D3VVB6YFWQMJGVFL5PNEBJSXMZTZAEQW/
[ovirt-users] Re: attach untagged vlan internally on vm
Ernest,you need to understand how things work under to hood to answer your question. If the traffic needs to pass through the NIC or not matters here. How things work: For any VM network, a bridge is created on the host and the vNIC from VM/s are connected to it using a tap device. When one defines a non vlan network, the bridge is created over the NIC directly, passing all traffic (tag and non tag alike). When a vlan network is defined, the bridge is created over a VLAN interface and that VLAN interface is defined over the NIC, therefore, only traffic with the specific vlan tag is forwarded from the nic through the vlan interface to the bridge (and from there to the vNIC/s). When there is a combination (VLAN + non VLAN networks), the traffic for the VLAN networks is forwarded as mentioned above, anything else, including non-tag and tag traffic, is forwarded to the non-vlan network (this is why you can call it also a trunk network). Now, if the traffic between your VM/s is local and will never go out (including needed control traffic), it does not matter on what the bridge is defined on (on a vlan or nic directly). This means, if you define a special network A, as vlanned or not, it will not matter for the traffic between two tap devices connected to the same network. Traffic that comes from one tap device can pass to the other tap device, ignoring VLAN/s. [vnic]--trunk--[bridge]--trunk--[vnic] | +--[nic/vlan]--[external-switch] If you want to make sure traffic does not get out, define the network as a VLAN which does not exists on the external switch. On Fri, Aug 23, 2019 at 5:53 PM Tony Pearce wrote: > May be I misunderstand but no need for any tag on same layer 2 network > > On Fri., 23 Aug. 2019, 22:15 Ernest Clyde Chua, < > ernestclydeac...@gmail.com> wrote: > >> Good day. >> yes the VMs and the firewall on the same L2 network also the firewall is >> hosted in oVirt along side the VMs, currently there is no external switch >> connected to the nic and i would like to know if it is possible to pass tag >> internally. >> >> >> On Fri, Aug 23, 2019 at 9:21 PM Tony Pearce wrote: >> >>> Have the VM and the firewall on the same L2 network. Configure the VM >>> with a default gateway of the interface of the firewall. >>> >>> Is it what you're looking for? >>> >>> On Fri., 23 Aug. 2019, 21:15 Ernest Clyde Chua, < >>> ernestclydeac...@gmail.com> wrote: >>> Good day. sorry if i got you guys confused. for clarity: i have a server with two nic, currently one nic is connected to public network and the other one is disconnected. And i have a vm that will be the firewall of other vm inside this standalone/selfhosted ovirt. then i am figuring out how can i pass the vlan ids on the vm or is it possible. On Fri, 23 Aug 2019, 7:46 PM Dominik Holler wrote: > > > On Thu, Aug 22, 2019 at 1:18 PM Miguel Duarte de Mora Barroso < > mdbarr...@redhat.com> wrote: > >> On Wed, Aug 21, 2019 at 9:18 AM wrote: >> > >> > good day >> > currently i am testing oVirt on a single box and setup some tagged >> vms and non tagged vm. >> > the non tagged vm is a firewall but it has limitations on the >> number of nic so i cannot attach tagged vnic and wish to handdle vlan >> tagging on it >> > >> > is it possible to pass untaged franes internally? >> >> I think it would fallback to the linux bridge default configuration, >> which internally tags untagged frames with vlanID 1, and untags them >> when exiting the port. Unless I'm wrong (for instance, we change the >> bridge defaults), this means you can pass untagged frames through the >> bridge. >> >> Adding Edward, to keep me honest. >> >> >> > I am unsure if I got the problem. > If you connect an untagged logical network to a vNIC (virtual NIC of a > VM), all untagged Ethernet frames will be forwarded from the host > interface > (physical NIC or bond). > If no tagged logical network is attached to this host interface, VLAN > tag filtering is not activated and even tagged Frames would be forwarded > to > the vNC. > > Does this answer the question? > > > >> >> >> > ___ >> > Users mailing list -- users@ovirt.org >> > To unsubscribe send an email to users-le...@ovirt.org >> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> > oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> > List Archives: >> https://lists.ovirt.org/archives/list/users@ovirt.org/message/HYFSLS5QM5DKBYWFF44NCB4E3CD5GKH4/ >> ___ >> Users mailing list -- users@ovirt.org >> To unsubscribe send an email to
[ovirt-users] Re: Need to enable STP on ovirt bridges
It seems that according to https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.0/html/installation_guide/sect-firewalls the ports of interest are: 16514/TCP 49152 - 49216/TCP Best Regards, Strahil NikolovOn Aug 25, 2019 08:48, Strahil wrote: > > Curtis, > > Do you have enough space to run tcpdump (port not 22) on both hosts and on > the small VM you have done previously - and then start the migration? > > Best Regards, > Strahil NikolovOn Aug 24, 2019 22:15, "Curtis E. Combs Jr." > wrote: > > > > I applied a 90Mbs QOS Rate Limit with 10 set for the shares to both > > interfaces of 2 of the hosts. My hosts names are swm-01 and swm-02. > > > > Creating a small VM from a Cinder template and running it gave me a test > > VM. > > > > When I migrated from swm-01 to swm-02, swm-01 immediately became > > unresponsive to pings, SSH'es, and to the ovirt interface which marked > > it as "NonResponsive" soon after the VM finished. The VM did finish > > migrating, however I'm unsure if that's a good migration or not. > > > > Thank you, Strahil. > > > > On Sat, Aug 24, 2019 at 12:39 PM Strahil wrote: > > > > > > What is your bandwidth threshold for the network used for VM migration ? > > > Can you set a 90 mbit/s threshold (yes, less than 100mbit/s) and try to > > > migrate a small (1 GB RAM) VM ? > > > > > > Do you see disconnects ? > > > > > > If no, try a little bit up (the threshold) and check again. > > > > > > Best Regards, > > > Strahil NikolovOn Aug 23, 2019 23:19, "Curtis E. Combs Jr." > > > wrote: > > > > > > > > It took a while for my servers to come back on the network this time. > > > > I think it's due to ovirt continuing to try to migrate the VMs around > > > > like I requested. The 3 servers' names are "swm-01, swm-02 and > > > > swm-03". Eventually (about 2-3 minutes ago) they all came back online. > > > > > > > > So I disabled and stopped the lldpad service. > > > > > > > > Nope. Started some more migrations and swm-02 and swm-03 disappeared > > > > again. No ping, SSH hung, same as before - almost as soon as the > > > > migration started. > > > > > > > > If you wall have any ideas what switch-level setting might be enabled, > > > > let me know, cause I'm stumped. I can add it to the ticket that's > > > > requesting the port configurations. I've already added the port > > > > numbers and switch name that I got from CDP. > > > > > > > > Thanks again, I really appreciate the help! > > > > cecjr > > > > > > > > > > > > > > > > On Fri, Aug 23, 2019 at 3:28 PM Dominik Holler > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Fri, Aug 23, 2019 at 9:19 PM Dominik Holler > > > > > wrote: > > > > >> > > > > >> > > > > >> > > > > >> On Fri, Aug 23, 2019 at 8:03 PM Curtis E. Combs Jr. > > > > >> wrote: > > > > >>> > > > > >>> This little cluster isn't in production or anything like that yet. > > > > >>> > > > > >>> So, I went ahead and used your ethtool commands to disable pause > > > > >>> frames on both interfaces of each server. I then, chose a few VMs > > > > >>> to > > > > >>> migrate around at random. > > > > >>> > > > > >>> swm-02 and swm-03 both went out again. Unreachable. Can't ping, > > > > >>> can't > > > > >>> ssh, and the SSH session that I had open was unresponsive. > > > > >>> > > > > >>> Any other ideas? > > > > >>> > > > > >> > > > > >> Sorry, no. Looks like two different NICs with different drivers and > > > > >> frimware goes down together. > > > > >> This is a strong indication that the root cause is related to the > > > > >> switch. > > > > >> Maybe you can get some information about the switch config by > > > > >> 'lldptool get-tlv -n -i em1' > > > > >> > > > > > > > > > > Another guess: > > > > > After the optional 'lldptool get-tlv -n -i em1' > > > > > 'systemctl stop lldpad' > > > > > another try to migrate. > > > > > > > > > > > > > > >> > > > > >> > > > > >>> > > > > >>> On Fri, Aug 23, 2019 at 1:50 PM Dominik Holler > > > > >>> wrote: > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > On Fri, Aug 23, 2019 at 6:45 PM Curtis E. Combs Jr. > > > > >>> > wrote: > > > > >>> >> > > > > >>> >> Unfortunately, I can't check on the switch. Trust me, I've > > > > >>> >> tried. > > > > >>> >> These servers are in a Co-Lo and I've put 5 tickets in asking > > > > >>> >> about > > > > >>> >> the port configuration. They just get ignored - but that's par > > > > >>> >> for the > > > > >>> >> coarse for IT here. Only about 2 out of 10 of our tickets get > > > > >>> >> any > > > > >>> >> response and usually the response doesn't help. Then ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives:
[ovirt-users] Re: Health Warning: Cinnamon toxic when adding EL7 nodes as oVirt hosts
Hi, On Thu, Aug 22, 2019 at 3:29 PM wrote: > > Hi Didi, thanks for the attention! > > I created a clean slate test using four identical (Atom J5005 32GB RAM, 1TB > SSD) boxes and virgin SSDs. > > Three-node hosted-engine using oVirt node 4.3.5 (August 5th) image. > > Tested adding an n+1 compute node with the same current oVirt image, which > worked fine (after a long serious of trouble with existing CentOS machines). > > Since EL7 seems to have equal standing as oVirt nodes, I couldn't quite > believe that it fails always. I tried to isolate if there was something > specific in my way of setting up the CentOS nodes that caused the failure. > > So I started with a clean sheet CentOS 7 an another clean SSD. > > CentOS 1810 ISOs, developer workstation install variant, storage layout > identical to the oVirt recommended, updated to the latest patches. > > Added oVirt repo, cockpit oVirt dashboard, ssl key etc. with all the proper > reboots > > Test 1: Add 4th node as host to three-node cluster. Works like a charm, > migrate a running VM back and forth, activate maintenance and remove 4th host > > Experiment 1: Add epel "yum install epe-release", yum install yumex, pick > Cinnamon in Yumex (or basically yum groupinstall cinnamon) I assume this was successful. Did you check what packages were actually installed? Especially which were updated? > > Test 2: Try to add 4th node again: Immediate failure with that message in the > management engine's deploy log. Before doing that, did you try disabling/removing full epel repo (only leaving enabled the parts enabled by ovirt-release* package)? > > Experiment 2: yum erase group cinnamon; yum autoremove; reboot > > Test 3: Add 4th node again: Success! (Adding Cinnamon afterwards, no problem, > re-install seems likely to fail) > > Yes, I saw that bug report. Noticed it was REHL8 and... wasn't sure it would > be related. > > And, like you, I can't really fathom why this would happen: I compared packet > versions on both sides, oVirt nodes and CentOS for everyone involved and they > seemed identical for everything. After installing Cinnamon? > > I had installed the yum priorities plugin and made sure that the "full" epel > repository had prio 99 while the oVirt repos had 1 to ensure that oVirt would > win out in case of any potential version conflict... This helps if there is a *conflict*, not sure it does much if epel has a newer version. > > As I understand it, this log on the engine lists actions performed via an ssh > connection on the to-be host, and that OTOPI might actually be gathering > packages through some time of y miniyum to then deploy on the to-be host in > the next step. Didn't understand "through some time of y miniyum". ovirt-host-deploy, which what is ran on the host at that point, is based on otopi, and otopi has a yum plugin, and a miniyum module that it uses, and these indeed try to install/update packages. This is optional - if you want to prevent that, check "OFFLINE" section in: https://github.com/oVirt/ovirt-host-deploy/blob/master/README > > So I don't know if the Python context of this is the normal Python 2 context > of the to-be host, or a temporary one that was actually created on-the-fly > etc. Somehow I never found the 200 page oVirt insider bible .-) Such a thing does not exist, and if it did, it will quickly become out-of-date, and quickly get worse over time. If you search around, you actually can find parts of it scattered around, as blog posts, 'deep dive' videos, conference presentations, etc. Part of these is indeed out-of-date :-(, but at least you can rather easily see when they were posted an which version was documented. And of course, you have the source! :-) > > If you can help me with some context, perhaps I can dig deeper and help > filing a better bug report. At the moment it seems so odd and vage, I didn't > feel comfortable. I'd start with: 1. Check host-deploy logs. You can find them on the engine machine (copied from the host) in /var/log/ovirt-engine/host-deploy. Compare failed and successful ones, especially around 'yum' - it should log the list of packages it's going to update etc. 2. Compare 'rpm -qa' between a failed and a working setup. Also 'yum list all'. > > Can't see any attach buttons, so I guess I may have to fiddle with my > browser's privacy settings.. You mean attach to your email to the mailing list? Not sure you should see, but it's anyway considered better these days to upload somewhere (dropbox, google drive, some pastebin if it's just log snippets) and share a link. This applies to mails to the list. If you open a bug in bugzilla, please do attach everything directly. Thanks and best regards, -- Didi ___ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct:
