Re: Set hostname of guest during installation time

2020-05-05 Thread Michal Privoznik

On 5/5/20 11:25 AM, john doe wrote:

On 5/5/2020 10:41 AM, Michal Privoznik wrote:

On 5/5/20 9:26 AM, john doe wrote:

On 5/5/2020 8:29 AM, Michal Privoznik wrote:
Because interface type='bridge' and type='network' are not the same. 
The

libvirt_guest plugin needs a list of MAC addresses because it tries to
find a match across libvirt domain name -> list of domain's MAC
addresses -> list of leases. And whenever a domain is started, all its
interfaces with type='network' will notify the corresponding network 
and

the code that handles libvirt networks will dump the MAC address into a
file for the NSS plugin to use. But, if plain type='bridge' is used 
then

all that is done is that the TAP is plugged into the bridge (which
ensures the connectivity), but does not notify the network which in 
turn

means that the MAC dumping code is not run and hence the NSS plugin
won't find a match.



I don't understand why the network can not be notified, could it be a
feature request?


No. interface type='bridge' exists exactly for the reasons that users
want libvirt just to plug TAP device into a bridge they manage. And they
don't want libvirt to touch the bridge in any other way.




Is there a reason why you are using interface type='bridge' with the
default network?



I'm just starting with libvirt, so I could be missing something.

Yes, I don't need libvirt touching iptables at all.

In other words, is there a way to be able to use libvirt_guest without
having libvirt interacting with iptables.


I'm not quite sure how to achieve NAT then - do you insert the NAT rules
yourself?


Yes, my frontent to iptables will do that.



If it is so, then what you may do is to change the type of the
default network to 'open' and then use interface type='network' from the
domain.



Thank you, I'll need to look into that.

Is there a way to do that with virt-install?


Let me check the man page for you.

--network network=my_libvirt_virtual_net









Also, from (1):

"virsh net-dhcp-leases $network
where $network iterates through
all running network..."

If I understand correctly, the below should list all running network:

$ virsh net-dhcp-leases $network
error: command 'net-dhcp-leases' requires  option


This lists DHCP leases for given network. To list all running networks
you can use 'virsh net-list'.



I would suggest rephrasing the above to something along the lines of:

"virsh net-dhcp-leases $network, where '$network' is to be supstituted
by the desired network (E.G, 'default') or use virsh net-list to list
all available network."


Actually, the whole statement (copied verbatim from the webpage) is:

   The NSS module then merely consults the list trying to find the match.
   Users can view the list themselves:

   virsh net-dhcp-leases $network

   where $network iterates through all running networks.


'$network iterates through all running networks.' I don't understand
what 'all networks' refers to?


Just like there can be multiple domains running there can be multiple 
networks.





Maybe I'm assuming too much, but this doesn't say that net-dhcp-leases
will print all running networks. The way I read this is: The NSS module
then merely does equivalent of iterating over every running network and
executing 'net-dhcp-leases' and trying to find the match.

I thought that using shell variables in a documentation for an UNIX-like
command is well understood, but maybe I am wrong.



That is the first time that I see this syntax being used, simply adding
somewhere that when an example for a command is shown like so, this
should be substituted.


Our docs are kept in a repository. In this specific example it is 
docs/nss.html.in:


https://gitlab.com/libvirt/libvirt/-/blob/master/docs/nss.html.in

If you feel like our docs are misleading, please post a patch.

Michal



Re: Set hostname of guest during installation time

2020-05-05 Thread john doe

On 5/5/2020 10:41 AM, Michal Privoznik wrote:

On 5/5/20 9:26 AM, john doe wrote:

On 5/5/2020 8:29 AM, Michal Privoznik wrote:

Because interface type='bridge' and type='network' are not the same. The
libvirt_guest plugin needs a list of MAC addresses because it tries to
find a match across libvirt domain name -> list of domain's MAC
addresses -> list of leases. And whenever a domain is started, all its
interfaces with type='network' will notify the corresponding network and
the code that handles libvirt networks will dump the MAC address into a
file for the NSS plugin to use. But, if plain type='bridge' is used then
all that is done is that the TAP is plugged into the bridge (which
ensures the connectivity), but does not notify the network which in turn
means that the MAC dumping code is not run and hence the NSS plugin
won't find a match.



I don't understand why the network can not be notified, could it be a
feature request?


No. interface type='bridge' exists exactly for the reasons that users
want libvirt just to plug TAP device into a bridge they manage. And they
don't want libvirt to touch the bridge in any other way.




Is there a reason why you are using interface type='bridge' with the
default network?



I'm just starting with libvirt, so I could be missing something.

Yes, I don't need libvirt touching iptables at all.

In other words, is there a way to be able to use libvirt_guest without
having libvirt interacting with iptables.


I'm not quite sure how to achieve NAT then - do you insert the NAT rules
yourself?


Yes, my frontent to iptables will do that.



If it is so, then what you may do is to change the type of the
default network to 'open' and then use interface type='network' from the
domain.



Thank you, I'll need to look into that.

Is there a way to do that with virt-install?







Also, from (1):

"virsh net-dhcp-leases $network
where $network iterates through
all running network..."

If I understand correctly, the below should list all running network:

$ virsh net-dhcp-leases $network
error: command 'net-dhcp-leases' requires  option


This lists DHCP leases for given network. To list all running networks
you can use 'virsh net-list'.



I would suggest rephrasing the above to something along the lines of:

"virsh net-dhcp-leases $network, where '$network' is to be supstituted
by the desired network (E.G, 'default') or use virsh net-list to list
all available network."


Actually, the whole statement (copied verbatim from the webpage) is:

   The NSS module then merely consults the list trying to find the match.
   Users can view the list themselves:

   virsh net-dhcp-leases $network

   where $network iterates through all running networks.


'$network iterates through all running networks.' I don't understand
what 'all networks' refers to?


Maybe I'm assuming too much, but this doesn't say that net-dhcp-leases
will print all running networks. The way I read this is: The NSS module
then merely does equivalent of iterating over every running network and
executing 'net-dhcp-leases' and trying to find the match.

I thought that using shell variables in a documentation for an UNIX-like
command is well understood, but maybe I am wrong.



That is the first time that I see this syntax being used, simply adding
somewhere that when an example for a command is shown like so, this
should be substituted.

--
John Doe




Re: Set hostname of guest during installation time

2020-05-05 Thread Michal Privoznik

On 5/5/20 9:26 AM, john doe wrote:

On 5/5/2020 8:29 AM, Michal Privoznik wrote:

Because interface type='bridge' and type='network' are not the same. The
libvirt_guest plugin needs a list of MAC addresses because it tries to
find a match across libvirt domain name -> list of domain's MAC
addresses -> list of leases. And whenever a domain is started, all its
interfaces with type='network' will notify the corresponding network and
the code that handles libvirt networks will dump the MAC address into a
file for the NSS plugin to use. But, if plain type='bridge' is used then
all that is done is that the TAP is plugged into the bridge (which
ensures the connectivity), but does not notify the network which in turn
means that the MAC dumping code is not run and hence the NSS plugin
won't find a match.



I don't understand why the network can not be notified, could it be a
feature request?


No. interface type='bridge' exists exactly for the reasons that users 
want libvirt just to plug TAP device into a bridge they manage. And they 
don't want libvirt to touch the bridge in any other way.





Is there a reason why you are using interface type='bridge' with the
default network?



I'm just starting with libvirt, so I could be missing something.

Yes, I don't need libvirt touching iptables at all.

In other words, is there a way to be able to use libvirt_guest without
having libvirt interacting with iptables.


I'm not quite sure how to achieve NAT then - do you insert the NAT rules 
yourself? If it is so, then what you may do is to change the type of the 
default network to 'open' and then use interface type='network' from the 
domain.








Also, from (1):

"virsh net-dhcp-leases $network
where $network iterates through
all running network..."

If I understand correctly, the below should list all running network:

$ virsh net-dhcp-leases $network
error: command 'net-dhcp-leases' requires  option


This lists DHCP leases for given network. To list all running networks
you can use 'virsh net-list'.



I would suggest rephrasing the above to something along the lines of:

"virsh net-dhcp-leases $network, where '$network' is to be supstituted
by the desired network (E.G, 'default') or use virsh net-list to list
all available network."


Actually, the whole statement (copied verbatim from the webpage) is:

  The NSS module then merely consults the list trying to find the match.
  Users can view the list themselves:

  virsh net-dhcp-leases $network

  where $network iterates through all running networks.

Maybe I'm assuming too much, but this doesn't say that net-dhcp-leases 
will print all running networks. The way I read this is: The NSS module 
then merely does equivalent of iterating over every running network and 
executing 'net-dhcp-leases' and trying to find the match.


I thought that using shell variables in a documentation for an UNIX-like 
command is well understood, but maybe I am wrong.


Michal



Re: Set hostname of guest during installation time

2020-05-05 Thread john doe

On 5/5/2020 8:29 AM, Michal Privoznik wrote:

On 5/5/20 8:11 AM, john doe wrote:

On 3/30/2020 4:10 PM, Michal Prívozník wrote:

On 30. 3. 2020 15:26, john doe wrote:

On 3/30/2020 1:20 PM, Andrea Bolognani wrote:

On Mon, 2020-03-30 at 12:04 +0200, Michal Prívozník wrote:

On 27. 3. 2020 20:49, john doe wrote:

If my understanding is correct, using 'try06' or 'debian' should
do the
same thing?


Yes, that is the idea. However, these plugins were not introduced
at the
same time. I think that especially Debian has delayed libvirt_guest
plugin. You can check if both plugins exist:

ls /usr/lib64/libnss_libvirt*

/usr/lib64/libnss_libvirt_guest.so.2
/usr/lib64/libnss_libvirt.so.2


Note that paths are different in Debian-based distros, so the correct
ones in this case are actually

   /lib/x86_64-linux-gnu/libnss_libvirt.so.2
   /lib/x86_64-linux-gnu/libnss_libvirt_guest.so.2



I have upgraded that Buster host to Bullseye, so I have now a 6...
version.
I have also the above two modules.

I'm still not able to use 'libvirt_guest' though:

--- Guest output (try06):

root@try06:~# cat /etc/hostname
try06

--- Host output (host):

root@host:# grep hosts: /etc/ns*
hosts: libvirt_guest
root@host:# virsh net-dhcp-leases default
  Expiry Time   MAC address Protocol   IP address
    Hostname   Client ID or DUID
-

  2020-03-30 16:03:41   52:54:00:d4:e6:f0   ipv4 192.168.122.137/24
   -  -


root@host:# getent hosts try06; echo $?
2


What am I missing?


Hold on. 'libvirt_guest' NSS plugin is supposed to translate libvirt
names to IP addresses. For instance:

   virsh start myDomain; ssh myDomain

The 'libvirt' NSS plugin is supposed to translate hostnames as sent by
guests to IP addresses. These two can be viewed as the following:

libvirt_guest: virsh domifaddr --source lease $dom
   libvirt: virsh net-dhcp-leases $net | grep $hostname

And this is where it gets interesting. In your previous e-mails,
net-dhcp-leases (aka 'libvirt' plugin) worked because the guest did send
hostname when doing DHCP. Now it doesn't (see '-' under 'Hostname' in
the output). Therefore, the 'libvirt' NSS plugin won't work.

And 'libvirt_guest' translates names of guests as seen by libvirt, i.e.
names you pass to virsh commands. These are unrelated to '/etc/hostname'
within guest. But hopefully, you haven't renamed your guest since then
and it is still named 'try06', that is virsh list --all produces 'try06'
in the list. If this is all true, can you share the output of:

   strace $(which getent) hosts try06




Thanks to the friendly feedback/support from Michal Privoznik and Andrea
Bolognani, I managed to get it working with the below command:

virt-install --name=try06 --pxe --os-variant=debian10 --network
network=default

What I think I mist while trying to implement the recommendation given
in here is that, if you change the network by doing 'virsh edit default'
the name of the interface in the guest might also change.

I don't understand why libvirt_guest won't work if a network bridge is
used?


Because interface type='bridge' and type='network' are not the same. The
libvirt_guest plugin needs a list of MAC addresses because it tries to
find a match across libvirt domain name -> list of domain's MAC
addresses -> list of leases. And whenever a domain is started, all its
interfaces with type='network' will notify the corresponding network and
the code that handles libvirt networks will dump the MAC address into a
file for the NSS plugin to use. But, if plain type='bridge' is used then
all that is done is that the TAP is plugged into the bridge (which
ensures the connectivity), but does not notify the network which in turn
means that the MAC dumping code is not run and hence the NSS plugin
won't find a match.



I don't understand why the network can not be notified, could it be a
feature request?


Is there a reason why you are using interface type='bridge' with the
default network?



I'm just starting with libvirt, so I could be missing something.

Yes, I don't need libvirt touching iptables at all.

In other words, is there a way to be able to use libvirt_guest without
having libvirt interacting with iptables.





Also, from (1):

"virsh net-dhcp-leases $network
where $network iterates through
all running network..."

If I understand correctly, the below should list all running network:

$ virsh net-dhcp-leases $network
error: command 'net-dhcp-leases' requires  option


This lists DHCP leases for given network. To list all running networks
you can use 'virsh net-list'.



I would suggest rephrasing the above to something along the lines of:

"virsh net-dhcp-leases $network, where '$network' is to be supstituted
by the desired network (E.G, 'default') or use virsh net-list to list
all available network."




In my case, I substituted '$network' by 'default'.


It doesn't look like you did, 

Re: Set hostname of guest during installation time

2020-05-05 Thread Michal Privoznik

On 5/5/20 8:11 AM, john doe wrote:

On 3/30/2020 4:10 PM, Michal Prívozník wrote:

On 30. 3. 2020 15:26, john doe wrote:

On 3/30/2020 1:20 PM, Andrea Bolognani wrote:

On Mon, 2020-03-30 at 12:04 +0200, Michal Prívozník wrote:

On 27. 3. 2020 20:49, john doe wrote:
If my understanding is correct, using 'try06' or 'debian' should 
do the

same thing?


Yes, that is the idea. However, these plugins were not introduced 
at the

same time. I think that especially Debian has delayed libvirt_guest
plugin. You can check if both plugins exist:

ls /usr/lib64/libnss_libvirt*

/usr/lib64/libnss_libvirt_guest.so.2
/usr/lib64/libnss_libvirt.so.2


Note that paths are different in Debian-based distros, so the correct
ones in this case are actually

   /lib/x86_64-linux-gnu/libnss_libvirt.so.2
   /lib/x86_64-linux-gnu/libnss_libvirt_guest.so.2



I have upgraded that Buster host to Bullseye, so I have now a 6... 
version.

I have also the above two modules.

I'm still not able to use 'libvirt_guest' though:

--- Guest output (try06):

root@try06:~# cat /etc/hostname
try06

--- Host output (host):

root@host:# grep hosts: /etc/ns*
hosts: libvirt_guest
root@host:# virsh net-dhcp-leases default
  Expiry Time   MAC address Protocol   IP address
    Hostname   Client ID or DUID
- 

  2020-03-30 16:03:41   52:54:00:d4:e6:f0   ipv4   
192.168.122.137/24

   -  -


root@host:# getent hosts try06; echo $?
2


What am I missing?


Hold on. 'libvirt_guest' NSS plugin is supposed to translate libvirt
names to IP addresses. For instance:

   virsh start myDomain; ssh myDomain

The 'libvirt' NSS plugin is supposed to translate hostnames as sent by
guests to IP addresses. These two can be viewed as the following:

libvirt_guest: virsh domifaddr --source lease $dom
   libvirt: virsh net-dhcp-leases $net | grep $hostname

And this is where it gets interesting. In your previous e-mails,
net-dhcp-leases (aka 'libvirt' plugin) worked because the guest did send
hostname when doing DHCP. Now it doesn't (see '-' under 'Hostname' in
the output). Therefore, the 'libvirt' NSS plugin won't work.

And 'libvirt_guest' translates names of guests as seen by libvirt, i.e.
names you pass to virsh commands. These are unrelated to '/etc/hostname'
within guest. But hopefully, you haven't renamed your guest since then
and it is still named 'try06', that is virsh list --all produces 'try06'
in the list. If this is all true, can you share the output of:

   strace $(which getent) hosts try06




Thanks to the friendly feedback/support from Michal Privoznik and Andrea
Bolognani, I managed to get it working with the below command:

virt-install --name=try06 --pxe --os-variant=debian10 --network
network=default

What I think I mist while trying to implement the recommendation given
in here is that, if you change the network by doing 'virsh edit default'
the name of the interface in the guest might also change.

I don't understand why libvirt_guest won't work if a network bridge is 
used?


Because interface type='bridge' and type='network' are not the same. The 
libvirt_guest plugin needs a list of MAC addresses because it tries to 
find a match across libvirt domain name -> list of domain's MAC 
addresses -> list of leases. And whenever a domain is started, all its 
interfaces with type='network' will notify the corresponding network and 
the code that handles libvirt networks will dump the MAC address into a 
file for the NSS plugin to use. But, if plain type='bridge' is used then 
all that is done is that the TAP is plugged into the bridge (which 
ensures the connectivity), but does not notify the network which in turn 
means that the MAC dumping code is not run and hence the NSS plugin 
won't find a match.


Is there a reason why you are using interface type='bridge' with the 
default network?






Also, from (1):

"virsh net-dhcp-leases $network
where $network iterates through
all running network..."

If I understand correctly, the below should list all running network:

$ virsh net-dhcp-leases $network
error: command 'net-dhcp-leases' requires  option


This lists DHCP leases for given network. To list all running networks 
you can use 'virsh net-list'.





In my case, I substituted '$network' by 'default'.


It doesn't look like you did, otherwise you would either get leases or 
an error that there is no network named "default".


# virsh net-dhcp-leases
error: command 'net-dhcp-leases' requires  option
# virsh net-dhcp-leases ""
error: Failed to get option 'network': Option argument is empty

# virsh net-dhcp-leases default
 Expiry Time   MAC address Protocol   IP address 
 Hostname   Client ID or DUID

--
 2020-05-05 09:01:11   52:54:00:a4:6f:91   ipv4   192.168.122.3/24 
 fedora 

Re: Set hostname of guest during installation time

2020-05-05 Thread john doe

On 3/30/2020 4:10 PM, Michal Prívozník wrote:

On 30. 3. 2020 15:26, john doe wrote:

On 3/30/2020 1:20 PM, Andrea Bolognani wrote:

On Mon, 2020-03-30 at 12:04 +0200, Michal Prívozník wrote:

On 27. 3. 2020 20:49, john doe wrote:

If my understanding is correct, using 'try06' or 'debian' should do the
same thing?


Yes, that is the idea. However, these plugins were not introduced at the
same time. I think that especially Debian has delayed libvirt_guest
plugin. You can check if both plugins exist:

ls /usr/lib64/libnss_libvirt*

/usr/lib64/libnss_libvirt_guest.so.2
/usr/lib64/libnss_libvirt.so.2


Note that paths are different in Debian-based distros, so the correct
ones in this case are actually

   /lib/x86_64-linux-gnu/libnss_libvirt.so.2
   /lib/x86_64-linux-gnu/libnss_libvirt_guest.so.2



I have upgraded that Buster host to Bullseye, so I have now a 6... version.
I have also the above two modules.

I'm still not able to use 'libvirt_guest' though:

--- Guest output (try06):

root@try06:~# cat /etc/hostname
try06

--- Host output (host):

root@host:# grep hosts: /etc/ns*
hosts: libvirt_guest
root@host:# virsh net-dhcp-leases default
  Expiry Time   MAC address Protocol   IP address
Hostname   Client ID or DUID
-
  2020-03-30 16:03:41   52:54:00:d4:e6:f0   ipv4   192.168.122.137/24
   -  -


root@host:# getent hosts try06; echo $?
2


What am I missing?


Hold on. 'libvirt_guest' NSS plugin is supposed to translate libvirt
names to IP addresses. For instance:

   virsh start myDomain; ssh myDomain

The 'libvirt' NSS plugin is supposed to translate hostnames as sent by
guests to IP addresses. These two can be viewed as the following:

libvirt_guest: virsh domifaddr --source lease $dom
   libvirt: virsh net-dhcp-leases $net | grep $hostname

And this is where it gets interesting. In your previous e-mails,
net-dhcp-leases (aka 'libvirt' plugin) worked because the guest did send
hostname when doing DHCP. Now it doesn't (see '-' under 'Hostname' in
the output). Therefore, the 'libvirt' NSS plugin won't work.

And 'libvirt_guest' translates names of guests as seen by libvirt, i.e.
names you pass to virsh commands. These are unrelated to '/etc/hostname'
within guest. But hopefully, you haven't renamed your guest since then
and it is still named 'try06', that is virsh list --all produces 'try06'
in the list. If this is all true, can you share the output of:

   strace $(which getent) hosts try06




Thanks to the friendly feedback/support from Michal Privoznik and Andrea
Bolognani, I managed to get it working with the below command:

virt-install --name=try06 --pxe --os-variant=debian10 --network
network=default

What I think I mist while trying to implement the recommendation given
in here is that, if you change the network by doing 'virsh edit default'
the name of the interface in the guest might also change.

I don't understand why libvirt_guest won't work if a network bridge is used?



Also, from (1):

"virsh net-dhcp-leases $network
where $network iterates through
all running network..."

If I understand correctly, the below should list all running network:

$ virsh net-dhcp-leases $network
error: command 'net-dhcp-leases' requires  option


In my case, I substituted '$network' by 'default'.


1)  https://libvirt.org/nss.html#Internals


--
John Doe