about the new added attributes "check" and "type" for interface mac element

2020-10-20 Thread Yalan Zhang
Hi all,

I have done some tests for the new attributes "check" and "type", could you
please help to have a check?  And I have some questions about the patch,
please help to have a look, Thank you!

The questions:
1. in step 4 below, the error message should be updated:
Actual results:
XML error: invalid mac address **check** value: 'next'. Valid values are
"generated" and "static".
expected results:
XML error: invalid mac address **type** value: 'next'. Valid values are
"generated" and "static".

2. I have checked the vmware OUI definition and found this:
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.networking.doc/GUID-1B6A280E-0C77-4775-8F84-4B3F40673178.html
it says the VMware OUI is 00:50:56, not 00:0c:29 in the patches.  Am I
missing something?

3. Could you please tell more about the user story? as I can not understand
the scenario when " it will ignore all the checks libvirt does about the
origin of the MAC address(whether or not it's in a VMWare OUI) and forward
the original one to the ESX server telling it not to check it either". Does
it happen when we try to transform a kvm guest to a vmware guest?

4. How to test it as a libvirt QE? Are the test scenarios below enough
without ESX env?


Test steps:

1. Start vm with different configuration with mac in "00:0c:29" range:
# virsh dumpxml rhel | grep /interface -B12
...

  
  
  
  


  
  
  
  


  
  
  
  


  
  
  
  


# virsh start rhel
Domain rhel started

2. login guest and check the interfaces:
# ip addr
...
2: enp5s0:  mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 00:0c:29:e7:9b:cb brd ff:ff:ff:ff:ff:ff
inet 192.168.122.142/24 brd 192.168.122.255 scope global dynamic
noprefixroute enp5s0
   valid_lft 3584sec preferred_lft 3584sec
inet6 fe80::351c:686a:863e:4a7f/64 scope link noprefixroute
   valid_lft forever preferred_lft forever
3: enp11s0:  mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 00:0c:29:3b:e0:50 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.202/24 brd 192.168.122.255 scope global dynamic
noprefixroute enp11s0
   valid_lft 3584sec preferred_lft 3584sec
inet6 fe80::2b79:4675:6c59:6822/64 scope link noprefixroute
   valid_lft forever preferred_lft forever
4: enp12s0:  mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 00:0c:29:73:f6:dc brd ff:ff:ff:ff:ff:ff
inet 192.168.122.33/24 brd 192.168.122.255 scope global dynamic
noprefixroute enp12s0
   valid_lft 3584sec preferred_lft 3584sec
inet6 fe80::e43d:555:ba85:4030/64 scope link noprefixroute
   valid_lft forever preferred_lft forever
5: enp13s0:  mtu 1500 qdisc fq_codel state
UP group default qlen 1000
link/ether 00:0c:29:aa:dc:6c brd ff:ff:ff:ff:ff:ff
inet 192.168.122.161/24 brd 192.168.122.255 scope global dynamic
noprefixroute enp13s0
   valid_lft 3584sec preferred_lft 3584sec
inet6 fe80::f32d:e2e8:9c8b:47fd/64 scope link noprefixroute
   valid_lft forever preferred_lft forever


3. start vm without the "check" and "type" attributes, and check the live
xml do not include these attributes, either.
 # virsh start vm1
virshDomain vm1 started
# virsh dumpxml vm1 | grep /interface -B8


  
  
  
  
  
  


4. negative test:
Set "" in virsh edit
# virsh edit vm1
error: XML document failed to validate against schema: Unable to validate
doc against /usr/share/libvirt/schemas/domain.rng
Extra element devices in interleave
Element domain failed to validate content

Failed. Try again? [y,n,i,f,?]:   > press 'i'
error: XML error: invalid mac address check value: 'next'. Valid values are
"generated" and "static".
Failed. Try again? [y,n,f,?]:


---
Best Regards,
Yalan Zhang
IRC: yalzhang


Re: possible bug in efi detection for guest

2020-10-20 Thread daggs
Greetings Michal,

> Sent: Tuesday, October 20, 2020 at 3:40 PM
> From: "Michal Prívozník" 
> To: "daggs" , libvirt-users@redhat.com
> Subject: Re: possible bug in efi detection for guest
> 
> IIRC you're using gentoo, which is what I happen to have too :-)
> And looking into my system I can see this file:
> 
>/usr/share/qemu/firmware/50-edk2-x86_64-secure.json
> 
> which defines this pair:
> 
> {
>  "mapping": {
>  "device": "flash",
>  "executable": {
>  "filename": "/usr/share/qemu/edk2-x86_64-secure-code.fd",
>  "format": "raw"
>  },
>  "nvram-template": {
>  "filename": "/usr/share/qemu/edk2-i386-vars.fd",
>  "format": "raw"
>  }
>  },
> }
> 
> 
> I'm not sure if this is a bug though. The NVRAM has a defined structure 
> and possibly is 32/64bit agnostic (on Intel at least).
> 
> Michal
> 
> 

maybe so, I need to check on the AMD system to verify if it the same.

thanks for the info,

Dagg.




Re: possible bug in efi detection for guest

2020-10-20 Thread Michal Prívozník

On 10/20/20 11:39 AM, daggs wrote:

Greetings All,

following a suggestion I got here on how to properly boot uefi-q35 guest, I 
found an weird config in the xml.
this is what I see when I run virsh edit streamer-vm-q35:

   hvm
   


when I run virsh dumpxml streamer-vm-q35, I get this:

   hvm
   /usr/share/qemu/edk2-x86_64-secure-code.fd
   /var/lib/libvirt/qemu/nvram/streamer-vm-q35_VARS.fd
   


question is, why the nvram template is /usr/share/qemu/edk2-i386-vars.fd and 
not /usr/share/qemu/edk2-x86_64-code.fd (file exists) as the system is x64?



IIRC you're using gentoo, which is what I happen to have too :-)
And looking into my system I can see this file:

  /usr/share/qemu/firmware/50-edk2-x86_64-secure.json

which defines this pair:

{
"mapping": {
"device": "flash",
"executable": {
"filename": "/usr/share/qemu/edk2-x86_64-secure-code.fd",
"format": "raw"
},
"nvram-template": {
"filename": "/usr/share/qemu/edk2-i386-vars.fd",
"format": "raw"
}
},
}


I'm not sure if this is a bug though. The NVRAM has a defined structure 
and possibly is 32/64bit agnostic (on Intel at least).


Michal



possible bug in efi detection for guest

2020-10-20 Thread daggs
Greetings All,

following a suggestion I got here on how to properly boot uefi-q35 guest, I 
found an weird config in the xml.
this is what I see when I run virsh edit streamer-vm-q35:

  hvm
  


when I run virsh dumpxml streamer-vm-q35, I get this:

  hvm
  /usr/share/qemu/edk2-x86_64-secure-code.fd
  /var/lib/libvirt/qemu/nvram/streamer-vm-q35_VARS.fd
  


question is, why the nvram template is /usr/share/qemu/edk2-i386-vars.fd and 
not /usr/share/qemu/edk2-x86_64-code.fd (file exists) as the system is x64?

Thanks

Dagg.