Re: multiple vms with same PCI passthrough
On 8/18/20 3:09 PM, Laine Stump wrote: On 8/17/20 8:40 PM, Daniel Black wrote: This, for 4 pci devices, confused libvrtd in the meantime however it was still functional. Aug 18 10:31:27 grit libvirtd[106082]: internal error: failed to get number of host interfaces: unspecified error - errors in loading some config files Aug 18 10:31:55 grit libvirtd[106082]: internal error: failed to get number of host interfaces: unspecified error - errors in loading some config files Aug 18 10:32:17 grit libvirtd[106082]: internal error: failed to get number of host interfaces: unspecified error - errors in loading some config files Aug 18 10:32:32 grit libvirtd[106082]: internal error: failed to get number of host interfaces: unspecified error - errors in loading some config files Unless you are assigning network devices, those errors are unrelated (and even then I'm not sure how they would be related). Those errors are saying that the very old and mysterious augeas + xslt parser of ifcfg files in the netcf package encountered an error while parsing said files. You *might* be able to get a better idea of the source of the problem by running "NETCF_DEBUG=1 ncftool list --all", but in the end it's not going to affect assignment of devices to guests using Oh, I just noticed that you're running on ubuntu. That means the error is coming from an equally old and mysterious augeas + xslt parser of */etc/network/interfaces*, not ifcfg files. The same comment otherwise applies though.
Re: multiple vms with same PCI passthrough
On 8/17/20 8:40 PM, Daniel Black wrote: This, for 4 pci devices, confused libvrtd in the meantime however it was still functional. Aug 18 10:31:27 grit libvirtd[106082]: internal error: failed to get number of host interfaces: unspecified error - errors in loading some config files Aug 18 10:31:55 grit libvirtd[106082]: internal error: failed to get number of host interfaces: unspecified error - errors in loading some config files Aug 18 10:32:17 grit libvirtd[106082]: internal error: failed to get number of host interfaces: unspecified error - errors in loading some config files Aug 18 10:32:32 grit libvirtd[106082]: internal error: failed to get number of host interfaces: unspecified error - errors in loading some config files Unless you are assigning network devices, those errors are unrelated (and even then I'm not sure how they would be related). Those errors are saying that the very old and mysterious augeas + xslt parser of ifcfg files in the netcf package encountered an error while parsing said files. You *might* be able to get a better idea of the source of the problem by running "NETCF_DEBUG=1 ncftool list --all", but in the end it's not going to affect assignment of devices to guests using
Re: KVM guest VM IP address
On 8/18/20 9:10 AM, Kaushal Shriyan wrote:
Hi,
I am trying to find out the IP address of the KVM guest virtual machine.
#virsh dumpxml newsoftlinedrupalpoc | grep "mac address" | awk -F\' '{
print $2}'
52:54:00:2c:7e:ff
[root@baseserver1 ~]# arp -an | grep 52:54:00:2c:7e:ff
[root@baseserver1 ~]# virsh domifaddr newsoftlinedrupalpoc
Name MAC address Protocol Address
---
[root@baseserver1 ~]#
It is not showing anything. I manually configure the IP
using /etc/sysconfig/network-scripts/ifcfg-eth0
ONBOOT=yes
IPADDR=192.168.0.189
PREFIX=24
GATEWAY=192.168.0.10
DNS1=8.8.8.8
DNS2=8.8.4.4
This is expected. If you use static IP then libvirt spawned dnsmasq is
not involved in any way and thus libvirt doesn't know what IP address
the domain has. And by default, virsh will use '--source lease' which
means libvirt tries to get the info from the dnsmasq (well, some JSON
that dnsmasq is updating, whatever).
You can try '--source agent' if you have a guest agent configured. And
if domain has done some traffic maybe it's still in the host's ARP table
and thus '--source arp' might work too. But I'd say this is the least
reliable way because entries in the ARP table time out.
Michal
Re: ipv6 NAT; accept_ra errors and about network choice
Hi,
Sorry for the delay.
On Tue, 11 Aug 2020 23:52:46 -0400
Laine Stump wrote:
> On 8/10/20 11:23 PM, Ian Wienand wrote:
> > Hello,
> >
> > Firstly THANK YOU for the IPv6 NAT support merged in 6.5. It has been
> > almost impossible to get IPv6 into a VM on a laptop that switches
> > between wifi and wired (dock) connections, because you can not add a
> > wifi interface to a bridge. I know NAT is against the IPv6 end-to-end
> > xen but it makes this "just work" for the vast majority of people like
> > me who need to ssh/curl/talk to ipv6 only hosts!
> >
> > So I installed 6.6.0 from the virt-preview repos on Fedora 32 to
> > eagerly test it out.
> >
> > My network config looks like
> >
> >
> >network
> > ...
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > The first problem I hit was trying to start that network:
> >
> > error: internal error: Check the host setup: enabling IPv6 forwarding
> > with RA routes without accept_ra set to 2 is likely to cause routes
> > loss. Interfaces to look at: wlp4s0
> >
> > wlp4s0 is my wifi card that is configured by NetworkManager in a
> > completely unremarkable fashion. By default it gets an ipv6 via SLAAC
> > from my router. This feels a bit like the unresolved bug [1] which
> > says that systemd-networkd is handling the RA's in userspace for
> > ... reasons [2]. It's unclear to me if NetworkManager is doing
> > similar.
>
> Yes, and yes. The only reason I haven't done something about this is
> that I'm undecided *what* to do. On one hand it seems many (most)
> systems are handling RAs with a userspace process, so it doesn't matter
> that it's disabled in the kernel. On the other hand, the person who
> added this check must have had a valid reason for going to the trouble
> of adding it (rather than just documenting that you needed to set
> accept_ra to 2 for some set of interfaces (I forget right now exactly
> which ones, and I'm trying to wind my brain down for the end of the day,
> so don't want to go look it up :-)
The check comes from commit 00d28a78b5d1 ("network: check accept_ra
before enabling ipv6 forwarding"), and it's there because the accept_ra
flag works like this (from Documentation/networking/ip-sysctl.txt):
0 Do not accept Router Advertisements.
1 Accept Router Advertisements if forwarding is disabled.
2 Overrule forwarding behaviour. Accept Router Advertisements
even if forwarding is enabled.
Now, as libvirt enables IPv6 forwarding via
/proc/sys/net/ipv6/conf/all/forwarding (in my opinion, this could be
limited to the interfaces involved), router advertisements would start
being discarded on all interfaces if this is '1'.
Another half-baked idea I was thinking about is: if there's at least one
address on a given interface with the 'noprefixroute' flag, that means
they are added by userspace. In that case,
virNetDevIPCheckIPv6ForwardingCallback() could set data->hasRARoutes to
false, and if userspace is explicitly handling RAs, don't worry at all
about accept_ra -- 0 is fine if it was set e.g. by NetworkManager.
Otherwise, just go ahead and set it to 2, we're not conflicting with
anything that would set addresses from RAs (other than the kernel).
> I can see 3 possibilities:
>
> 1) completely remove the check, with the idea that while it was a good
> thing at the time, it's now obsolete.
>
> 2) have a config item (in /etc/libvirt/network.conf (which doesn't
> currently exist) maybe?) to let people manually disable the check.
>
> 3) try to make libvirt's code intelligent, and look for clues that RAs
> are handled elsewhere (someone would need to figure out what those
> "clues" are).
Yes, addresses with 'noprefixroute' should be a safe choice: userspace
agents need to create routes separately anyway, but it won't be set if
the kernel is setting up those addresses.
> > I feel like this must be a red-herring. My wired interface has the
> > same setting of 0
> >
> > $ cat /proc/sys/net/ipv6/conf/enp0s31f6/accept_ra
> > 0
> >
> > and is similarly just a very standard auto-configured NetworkManager
> > interface. When I "net-start" the network whilst on wifi libvirt
> > doesn't seem to care about that interface (I presume it only looks at
> > the active one?). When I dock and turn off wifi, ipv6 connectivity
> > continues to work through enp0s31f6, so I don't think the accept_ra
> > really matters in this case.
>
> Because you're using NetworkManager. I've confirmed with [some NM
> person, I forget who or in what venue] that NM handles RAs itself, so
> accept_ra should be turned off in the kernel (it's not harmful if it's
> on as far as I know, it just does nothing useful)
>
> >
> > I feel like this message is incorrect, and being as I've done nothing
> > special to my underlying interfaces probably going to be wrong for a
> > lot of
KVM guest VM IP address
Hi,
I am trying to find out the IP address of the KVM guest virtual machine.
#virsh dumpxml newsoftlinedrupalpoc | grep "mac address" | awk -F\' '{
print $2}'
52:54:00:2c:7e:ff
[root@baseserver1 ~]# arp -an | grep 52:54:00:2c:7e:ff
[root@baseserver1 ~]# virsh domifaddr newsoftlinedrupalpoc
Name MAC address Protocol Address
---
[root@baseserver1 ~]#
It is not showing anything. I manually configure the IP
using /etc/sysconfig/network-scripts/ifcfg-eth0
ONBOOT=yes
IPADDR=192.168.0.189
PREFIX=24
GATEWAY=192.168.0.10
DNS1=8.8.8.8
DNS2=8.8.4.4
CentOS Linux release 7.6.1810 (Core)
virt-install --version
1.5.0
virsh version
Compiled against library: libvirt 4.5.0
Using library: libvirt 4.5.0
Using API: QEMU 4.5.0
Running hypervisor: QEMU 1.5.3
Am I missing something? Thanks in advance and I look forward to hearing
from you.
Best Regards,
