[00:00.000 --> 00:12.560]  What I wanted to talk with you today is about how to identify networks inside the guest
[00:12.560 --> 00:18.840]  itself, because there are in some cases where there is a problem, we want to define a network
[00:18.840 --> 00:25.440]  and inside the guest we don't know to where we are connected exactly, so this is the talk.
[00:25.440 --> 00:31.680]  My name is Eddie, I am working at Red Hat today on a project called Kuvert, I think
[00:31.680 --> 00:36.280]  there was a talk here about it before.
[00:36.280 --> 00:45.240]  Let's see, has anyone worked with Kuvert or knows it?
[00:45.240 --> 00:51.040]  This is a very, very quick, does anyone know about Kubernetes?
[00:51.040 --> 00:57.760]  Kubernetes is everyone else, so Kubernetes is the baseline, I would say, so it has,
[00:57.760 --> 01:04.440]  if you know it, it has something called pods, it's like the smallest part of it, in pods
[01:04.440 --> 01:13.640]  there we run containers, now if we want to work with virtual machines then we can install
[01:13.640 --> 01:20.520]  Kuvert, it's an add-on to Kubernetes, this is more or less how it looks, Kubernetes is
[01:20.520 --> 01:25.360]  like a management system and Kuvert is an add-on to this management system that manages
[01:25.360 --> 01:36.080]  VMs, it does this using LiveVirt and KMU and everything KMU runs inside the pod and
[01:36.080 --> 01:46.440]  the pod runs the guest and they share the same network, this is one of their, why we
[01:46.440 --> 01:53.000]  created it on Kuvert or on Kubernetes is to share the same network, so we can expand
[01:53.000 --> 01:58.720]  the pods or we can work with VMs when we are not able to work with pods.
[01:58.720 --> 02:05.640]  So in the regular or the classic way to run a virtual machine is we usually have one network
[02:05.640 --> 02:13.080]  and it's called usually ETH0, if anyone raised the VM this is what they will get, but if
[02:13.080 --> 02:20.760]  you want to have multiple networks then we have a little problem because we can have
[02:20.760 --> 02:29.320]  ETH0, ETH1, ETH2 and we can continue on like that and the main problem with it is that
[02:29.320 --> 02:35.560]  this is not assured, like if you do a reboot to the machine the next time it boots it does
[02:35.560 --> 02:42.160]  not have to be the same order, so you could have ETH0 connected to some red network and
[02:42.240 --> 02:50.640]  the next reboot it will be called ETH1 and it will be connected to the blue network and
[02:50.640 --> 03:00.080]  the reason for that is that the scheme of ETHN is based on the detection of the device
[03:00.080 --> 03:05.840]  while the operations system boots, so it can detect it, it's like it's random, it doesn't
[03:05.840 --> 03:17.360]  have to be the same order, so what can we do about it, so I guess the most direct way to handle
[03:17.360 --> 03:24.240]  something like that is from the management system, in our case it's COVID but we can do that in any
[03:24.240 --> 03:29.920]  management system, from the management system we can pass information inside the guest and tell it
[03:30.720 --> 03:36.320]  to what you are connected to, what are these networks exactly, so we're going to go over
[03:36.960 --> 03:49.360]  each option and see what they are, so the way to configure COVID is very similar to
[03:49.360 --> 03:56.720]  how we configure Kubernetes, we have an object and in this object we configure the parameters,
[03:56.720 --> 04:04.960]  I just took a snippet of the networking parts because this is what we don't want to get into
[04:04.960 --> 04:12.960]  too many details, so in the definition of virtual machine instance we define the interface that
[04:12.960 --> 04:20.320]  it should have and the interfaces have the masquerade and the bridge that you see, these are
[04:20.320 --> 04:26.320]  actually two interfaces, the masquerade and the bridge is the binding way, we don't need to talk
[04:26.320 --> 04:34.080]  about it in this talk but what is important here that this is like a classic way, this is the default
[04:34.080 --> 04:44.080]  thing to define two things, it will use the default ethn in this case you will see, so when we define
[04:44.080 --> 04:54.160]  these two if we go into the guest we'll see eth0 and eth1, if this is like for the explanation
[04:55.120 --> 05:02.720]  we can go inside the pod that was created for us, where the virtual machine runs actually,
[05:03.520 --> 05:10.000]  where Kimo runs or Livvitt runs and we can do a commander to see the configuration of the virtual
[05:10.000 --> 05:18.160]  machine from inside, something that usually the user doesn't see, it's hidden from the user but
[05:18.240 --> 05:25.840]  this is done just to show you, when we create with Livvitt a virtual machine even if we don't
[05:25.840 --> 05:31.840]  pass the information it will automatically create a MAC addresses for each nick and it will create also
[05:34.160 --> 05:40.720]  PCI addresses, it's something done by Livvitt automatically if we don't specify anything,
[05:40.720 --> 05:45.520]  so we can see that the MAC addresses correspond with the MAC address inside the guest
[05:46.400 --> 05:52.320]  and the PCI address in this case it depends on operation system that you run inside of it,
[05:52.320 --> 05:59.280]  for example this one I think it's Fedora, so Fedora gives us this eth0 stuff but it also gives us
[05:59.280 --> 06:06.080]  some alternative name which was calculated in this case based on the PCI address, the problem with
[06:06.640 --> 06:11.920]  we can, the problem that we cannot identify this to the original configuration is that
[06:12.720 --> 06:20.000]  if we look here we never specified anything, so this is we will need to do to connect to the
[06:20.000 --> 06:27.600]  pod and check what it has and then it's not practical, so it doesn't help me much, so the
[06:27.600 --> 06:34.320]  first thing that we could do is to specify the MAC address in the configuration, if we specify
[06:34.320 --> 06:42.960]  specific MAC address this MAC address is going to be placed inside what we saw Livvitt in the
[06:42.960 --> 06:49.840]  configuration, this is what Kuvert will do and then we can see the MAC address inside the guest,
[06:49.840 --> 06:57.520]  the problem with this one is that we cannot, we will need to use, we cannot use the same MAC address
[06:57.520 --> 07:02.240]  for each interface right even between virtual machines because then they will collide and will
[07:02.240 --> 07:09.440]  have no network, so this is not so good solution and we should, we need to find some other
[07:11.600 --> 07:16.560]  better solution and by the way this also collides the, in Kuvert for example we have a
[07:17.920 --> 07:24.720]  MAC pool which automatically, I mean it's an option but it allocates MAC addresses to
[07:24.720 --> 07:33.040]  interfaces so they will not collide, so we will not have a case where MAC address was defined twice.
[07:35.280 --> 07:42.960]  So the better solution for all of this is to use something that Linux has started working
[07:43.840 --> 07:48.720]  exposed like I think it's a lot of years ago, like 10 years maybe if I don't know,
[07:49.280 --> 07:58.240]  it's called predictable network device names, instead of using the ETH and this is the last one,
[07:59.040 --> 08:08.000]  we can decode the name of the interface based on the something called an ACPI device index,
[08:08.000 --> 08:14.560]  we'll talk about it soon, based either or by the PCI address of the device, so if we specify the
[08:14.560 --> 08:21.200]  PCI address of the device when we define the interface it will go the operation system,
[08:21.200 --> 08:27.120]  if it uses system D and things like that it can create the interface based on this name.
[08:29.600 --> 08:36.640]  So this is a, I'm showing you here what we can do, the ACPI index is the parameter that we can
[08:36.640 --> 08:45.040]  set inside the definition of the virtual machine and it will go, it will create the,
[08:45.040 --> 08:51.520]  it will pass it to Livid and Livid will create the domain, the VM and then we will see it
[08:52.480 --> 09:01.520]  with this name, it starts with ENO and then the ID that we set here, but even if the operation
[09:01.520 --> 09:08.000]  system does not know to do it, because if you don't use system D I think it will not do that,
[09:08.000 --> 09:14.880]  someone needs to know to name the interface correctly, you can still go to, I don't have,
[09:14.880 --> 09:22.240]  I cannot show you now because it's not my laptop, but you can do a CIS bus, you can go on the bus
[09:22.240 --> 09:30.080]  of the PCI address and the last one will be an ACPI index value, so you can read it from there.
[09:32.080 --> 09:39.440]  Now the other option, this is, by the way this is the, I guess the best option if you can do it.
[09:40.800 --> 09:49.120]  The second best one is to define a PCI address, specific PCI address when you define the interface,
[09:49.680 --> 09:54.720]  it's a bit harder just because you need to know which PCI address to use and you need to manage it,
[09:54.720 --> 10:00.480]  so if you create 10 interfaces you don't want them to collide and you don't want them to collide
[10:00.480 --> 10:06.880]  with other devices of your virtual machine like, I don't know, a sound device or something else,
[10:06.880 --> 10:13.200]  so this is a bit harder, but you can do it and if you set that one the name of the interface
[10:13.200 --> 10:22.320]  will be created using E&P and then the first number is the bus number, this is this one here
[10:23.040 --> 10:26.320]  and the slot is this one.
[10:30.880 --> 10:37.920]  Yeah, but there is one problem with all of this, what I just said is that
[10:38.880 --> 10:44.560]  I don't know if you ever try to use a virtual machine from the cloud that you downloaded,
[10:44.560 --> 10:50.880]  one of the problems that all the images that are created for us Fedora ones, the Centos ones,
[10:52.400 --> 10:58.080]  Ubuntu ones, all of them have something they expect to have only one interface,
[10:58.960 --> 11:04.080]  so they are configured in a way, so they will not use all of these schemes, so they will,
[11:04.080 --> 11:11.360]  they want, I mean, if you want to have this scheme or these options, you just cannot have it,
[11:11.360 --> 11:17.920]  it disables them in purpose and the reason is because they are saying, if I want to run an
[11:17.920 --> 11:24.240]  application inside the guest, I want it to be, to know always that it is ETH0, I don't want it to
[11:24.240 --> 11:30.880]  give me a name that is random, that I cannot control, so if someone wants to use these naming
[11:30.880 --> 11:37.120]  schemes, they need to go to the VM, prepare an image or they need to tweak the existing image
[11:37.120 --> 11:47.040]  and enable this predictable naming. The last option, which is a bit more complicated,
[11:47.040 --> 11:55.840]  but it gives us more options, is we can have a tag on the interface, specify a tag and it will
[11:55.840 --> 12:01.840]  use something that was invented in OpenStack actually, that's called device role tagging
[12:02.720 --> 12:10.160]  and what this one does, it prepares the information, like it reads, when we set tag for them,
[12:10.160 --> 12:15.440]  you will see that we will get, we'll get this information, it doesn't touch the interfaces,
[12:15.520 --> 12:24.800]  it doesn't touch the interfaces, it just mounts inside the guest data, which is this one for example,
[12:25.440 --> 12:32.800]  and this data is the one that was read from Livid configuration, so it reads,
[12:32.800 --> 12:41.040]  if I put FOSSDEM as a tag, then what Kuvert is doing, it reads the Livid configuration, checks
[12:41.040 --> 12:48.960]  what is the, it reads the address of the PCI, the MAC address and puts the tag and a potential
[12:48.960 --> 12:55.920]  application or guest inside the, inside the guest, they can read this file and
[12:58.080 --> 13:04.720]  decide which network to connect to. This is, we could do much more interesting stuff with this one,
[13:05.680 --> 13:11.520]  although it's not, it's less standardized because using the name of the NIC sounds to me at least more,
[13:14.320 --> 13:20.480]  using the simple solutions or more standard one, this one is, you need to learn about this protocol,
[13:20.480 --> 13:28.000]  so you need to mount it and you need to read it and decode it, but you can do things like here,
[13:28.080 --> 13:36.320]  we could tag different devices like the NUMA device and some other peripheral device
[13:36.320 --> 13:43.600]  and then tag them on the same tag and then use this information to do for the application
[13:43.600 --> 13:50.240]  inside of it to use smart things, like for example, an easy way to run an application
[13:50.240 --> 13:54.640]  and use the devices that are on the same NUMA, that's one example you could do.
[13:55.600 --> 14:02.800]  I don't, I cannot do the demo, but if someone wants to look how, what they need to configure
[14:02.800 --> 14:08.880]  in the virtual machine, the guest, so the naming will be not ETHN, then please come to me.
[14:11.280 --> 14:19.760]  All the art is for my kids, so I must write it down, that's it I guess, any questions?
[14:25.360 --> 14:27.760]  No, yes.
[14:46.960 --> 14:52.960]  Yes, you'll need to use the PCI, I guess, or maybe there is a, oh sorry, I need to repeat the question.
[14:53.120 --> 15:00.960]  So, yeah, we were asked about what to do when we use the guest that is ARM, right, using ARM
[15:00.960 --> 15:05.920]  and the ACPI index is not available, so yes, in this case you must use the PCI,
[15:06.560 --> 15:14.720]  but if we have maybe other, other identifiers, maybe you can use them. There is one identifier
[15:14.720 --> 15:19.920]  that I didn't say here, I didn't talk about it, it's very similar to the ACPI index, but it's a
[15:19.920 --> 15:26.960]  register on the, on the PCI, so we can, we can use that if you want, but I think
[15:27.600 --> 15:30.000]  Livid or Kimo is not supporting that here.
[15:32.400 --> 15:35.840]  Yes. Any more questions? Last question? Yes.
[15:42.320 --> 15:49.520]  So, ACPI I think index, sorry, I'm not good at repeating, the question was what about
[15:49.520 --> 15:57.920]  operations that are not Linux? It doesn't exist, but the real answer is that ACPI index, I think
[15:57.920 --> 16:05.040]  it's supposed to be generic, I mean it's part of the, it's like a standard of the ACPI, so if,
[16:05.040 --> 16:13.280]  for example, Windows or some embedded thing can read the device, then it can fetch the information,
[16:14.000 --> 16:20.560]  the ACPI index information, and they can always use the PCI address, and if there is something,
[16:21.360 --> 16:27.920]  if there is, if you, the fact with the tag, for example, that is universal, if you can mount
[16:27.920 --> 16:33.920]  something inside the guest, and like this one is working using cloud in it. So,
[16:35.520 --> 16:40.240]  if we don't have time, so if someone has questions, please come to me, I'll stay here,
[16:40.240 --> 16:47.840]  or outside, I'll stay here. Thank you.