Set hostname of guest during installation time
Hi, I would like to set the hostname when installing a guest, with the below command the hostname is not set to 'try06' in the guest: virt-install --name=try06 --graphic none --pxe --network bridge=virbr0 How can I set the hostname of the guest during installation time? I realy appriciate the support I'm getting in here, I'm fairly new to libvirt. -- John Doe
On 27. 3. 2020 14:57, john doe wrote:
Hi,
I would like to set the hostname when installing a guest, with the below command the hostname is not set to 'try06' in the guest:
virt-install --name=try06 --graphic none --pxe --network bridge=virbr0
This is the name of the guest registered in libvirt. I don't think that virt-install has wired up setting hostname, but it looks like it can do it. I mean, use --name for both libvirt name and guest hostname. Michal
On 27. 3. 2020 16:48, Michal Prívozník wrote:
On 27. 3. 2020 14:57, john doe wrote:
Hi,
I would like to set the hostname when installing a guest, with the below command the hostname is not set to 'try06' in the guest:
virt-install --name=try06 --graphic none --pxe --network bridge=virbr0
This is the name of the guest registered in libvirt. I don't think that virt-install has wired up setting hostname, but it looks like it can do it. I mean, use --name for both libvirt name and guest hostname.
On the other hand, users might want to set it to something else. So we really should have a separate argument for that. Anyway, I've reported it to virt-install developers: https://github.com/virt-manager/virt-manager/issues/94 Michal
On 3/27/2020 5:13 PM, Michal Prívozník wrote:
On 27. 3. 2020 16:48, Michal Prívozník wrote:
On 27. 3. 2020 14:57, john doe wrote:
Hi,
I would like to set the hostname when installing a guest, with the below command the hostname is not set to 'try06' in the guest:
virt-install --name=try06 --graphic none --pxe --network bridge=virbr0
This is the name of the guest registered in libvirt. I don't think that virt-install has wired up setting hostname, but it looks like it can do it. I mean, use --name for both libvirt name and guest hostname.
On the other hand, users might want to set it to something else. So we really should have a separate argument for that. Anyway, I've reported it to virt-install developers:
Many thanks for your answer and for passing it along. I agree, an option to trigger this behavior is best. After executing the above command and before the hostname step, the following workaround seems to work: $ virsh net-dhcp-leases default Expiry Time MAC address Protocol IP address Hostname Client ID or DUID ----------------------------------------------------------------------------------------------------------------------------------------------- 2020-03-27 18:03:36 52:54:00:9d:d1:e7 ipv4 192.168.122.45/24 - ff:00:9d:d1:e7:00:01:00:01:26:10:e0:58:52:54:00:9d:d1:e7 $ virsh net-update default add ip-dhcp-host "<host mac='52:54:00:9d:d1:e7' name='try06' ip='192.168.122.45'/>" What I am not sure about is how to predetermine the MAC address of the guest before starting the installer? Is there a predictable/better way to go about this? Again thanks for opening a ticket on my behalf and for your answer, much appriciated. -- John Doe
On 27. 3. 2020 17:23, john doe wrote:
On 3/27/2020 5:13 PM, Michal Prívozník wrote:
On 27. 3. 2020 16:48, Michal Prívozník wrote:
On 27. 3. 2020 14:57, john doe wrote:
Hi,
I would like to set the hostname when installing a guest, with the below command the hostname is not set to 'try06' in the guest:
virt-install --name=try06 --graphic none --pxe --network bridge=virbr0
This is the name of the guest registered in libvirt. I don't think that virt-install has wired up setting hostname, but it looks like it can do it. I mean, use --name for both libvirt name and guest hostname.
On the other hand, users might want to set it to something else. So we really should have a separate argument for that. Anyway, I've reported it to virt-install developers:
Many thanks for your answer and for passing it along.
I agree, an option to trigger this behavior is best.
After executing the above command and before the hostname step, the following workaround seems to work:
$ virsh net-dhcp-leases default Expiry Time MAC address Protocol IP address Hostname Client ID or DUID ----------------------------------------------------------------------------------------------------------------------------------------------- 2020-03-27 18:03:36 52:54:00:9d:d1:e7 ipv4 192.168.122.45/24 - ff:00:9d:d1:e7:00:01:00:01:26:10:e0:58:52:54:00:9d:d1:e7
$ virsh net-update default add ip-dhcp-host "<host mac='52:54:00:9d:d1:e7' name='try06' ip='192.168.122.45'/>"
What I am not sure about is how to predetermine the MAC address of the guest before starting the installer?
You can switch the steps and generate a MAC address yourself, then update the network and then specify it on virt-install cmd line. Or even better, do not bother with any of this and use libvirt-nss plugin: https://libvirt.org/nss.html Michal
On 3/27/2020 5:28 PM, Michal Prívozník wrote:
On 27. 3. 2020 17:23, john doe wrote:
On 3/27/2020 5:13 PM, Michal Prívozník wrote:
On 27. 3. 2020 16:48, Michal Prívozník wrote:
On 27. 3. 2020 14:57, john doe wrote:
Hi,
I would like to set the hostname when installing a guest, with the below command the hostname is not set to 'try06' in the guest:
virt-install --name=try06 --graphic none --pxe --network bridge=virbr0
This is the name of the guest registered in libvirt. I don't think that virt-install has wired up setting hostname, but it looks like it can do it. I mean, use --name for both libvirt name and guest hostname.
On the other hand, users might want to set it to something else. So we really should have a separate argument for that. Anyway, I've reported it to virt-install developers:
Many thanks for your answer and for passing it along.
I agree, an option to trigger this behavior is best.
After executing the above command and before the hostname step, the following workaround seems to work:
$ virsh net-dhcp-leases default Expiry Time MAC address Protocol IP address Hostname Client ID or DUID ----------------------------------------------------------------------------------------------------------------------------------------------- 2020-03-27 18:03:36 52:54:00:9d:d1:e7 ipv4 192.168.122.45/24 - ff:00:9d:d1:e7:00:01:00:01:26:10:e0:58:52:54:00:9d:d1:e7
$ virsh net-update default add ip-dhcp-host "<host mac='52:54:00:9d:d1:e7' name='try06' ip='192.168.122.45'/>"
What I am not sure about is how to predetermine the MAC address of the guest before starting the installer?
You can switch the steps and generate a MAC address yourself, then update the network and then specify it on virt-install cmd line.
Or even better, do not bother with any of this and use libvirt-nss plugin:
Okay, I have installed the pluging, do you mind explaning how this should work?: $ grep host /etc/ns* hosts: files libvirt_guest dns If I'm correct, following your example, I should be able to do: $ host try06 What am I missing. Thanks again for your help. -- John Doe
On 27. 3. 2020 19:23, john doe wrote:
Okay, I have installed the pluging, do you mind explaning how this should work?:
$ grep host /etc/ns* hosts: files libvirt_guest dns
If I'm correct, following your example, I should be able to do:
$ host try06
What am I missing.
'host' does DNS directly, regardless of nsswitch.conf. That's not how majority of SW work. Try: getent hosts try06 or: ssh try06 The majority will use gethostbyname() which will consult the nsswitch.conf and use modules defined there. In your case, the /etc/hosts will be consulted first, then libvirt_guest and DNS is used only if everything else failed. You can verify that 'host' does DNS directly by trying a hostname from /etc/hosts. It will give an error even though getent won't. Michal
On 3/27/2020 7:36 PM, Michal Prívozník wrote:
On 27. 3. 2020 19:23, john doe wrote:
Okay, I have installed the pluging, do you mind explaning how this should work?:
$ grep host /etc/ns* hosts: files libvirt_guest dns
If I'm correct, following your example, I should be able to do:
$ host try06
What am I missing.
'host' does DNS directly, regardless of nsswitch.conf. That's not how majority of SW work. Try:
getent hosts try06
or:
ssh try06
The majority will use gethostbyname() which will consult the nsswitch.conf and use modules defined there. In your case, the /etc/hosts will be consulted first, then libvirt_guest and DNS is used only if everything else failed. You can verify that 'host' does DNS directly by trying a hostname from /etc/hosts. It will give an error even though getent won't.
Michal
Thanks for the explanation but it does not seem to work: $ getent hosts try06; echo $? 2 Using 'libvirt' or libvirt_guest' one or the other or both does not change the above, for testing purposes the line 'hosts: ...' has only libvirt modules. It is also not working for SSH. Testing this on Debian Buster (10) ('libnss-libvirt is already the newest version (5.0.0-4+deb10u1)'). Your help is appriciated. -- John Doe
On 3/27/2020 8:29 PM, john doe wrote:
On 3/27/2020 7:36 PM, Michal Prívozník wrote:
On 27. 3. 2020 19:23, john doe wrote:
Okay, I have installed the pluging, do you mind explaning how this should work?:
$ grep host /etc/ns* hosts: files libvirt_guest dns
If I'm correct, following your example, I should be able to do:
$ host try06
What am I missing.
'host' does DNS directly, regardless of nsswitch.conf. That's not how majority of SW work. Try:
getent hosts try06
or:
ssh try06
The majority will use gethostbyname() which will consult the nsswitch.conf and use modules defined there. In your case, the /etc/hosts will be consulted first, then libvirt_guest and DNS is used only if everything else failed. You can verify that 'host' does DNS directly by trying a hostname from /etc/hosts. It will give an error even though getent won't.
Michal
Thanks for the explanation but it does not seem to work:
$ getent hosts try06; echo $? 2
Using 'libvirt' or libvirt_guest' one or the other or both does not change the above, for testing purposes the line 'hosts: ...' has only libvirt modules.
It is also not working for SSH.
Testing this on Debian Buster (10) ('libnss-libvirt is already the newest version (5.0.0-4+deb10u1)').
Your help is appriciated.
With some more testing: $ grep hosts: /etc/ns* hosts: file libvirt libvirt_guest dns $ virsh net-dhcp-leases default Expiry Time MAC address Protocol IP address Hostname Client ID or DUID ------------------------------------------------------------------------------------------------------------------------------------------------ 2020-03-27 21:40:49 52:54:00:d4:e6:f0 ipv4 192.168.122.137/24 debian ff:00:d4:e6:f0:00:01:00:01:26:11:0b:0c:52:54:00:d4:e6:f0 $ getent hosts try06 $ getent hosts debian 192.168.122.137 debian If my understanding is correct, using 'try06' or 'debian' should do the same thing? -- John Doe
On 27. 3. 2020 20:49, john doe wrote:
On 3/27/2020 8:29 PM, john doe wrote:
On 3/27/2020 7:36 PM, Michal Prívozník wrote:
On 27. 3. 2020 19:23, john doe wrote:
Okay, I have installed the pluging, do you mind explaning how this should work?:
$ grep host /etc/ns* hosts: files libvirt_guest dns
If I'm correct, following your example, I should be able to do:
$ host try06
What am I missing.
'host' does DNS directly, regardless of nsswitch.conf. That's not how majority of SW work. Try:
getent hosts try06
or:
ssh try06
The majority will use gethostbyname() which will consult the nsswitch.conf and use modules defined there. In your case, the /etc/hosts will be consulted first, then libvirt_guest and DNS is used only if everything else failed. You can verify that 'host' does DNS directly by trying a hostname from /etc/hosts. It will give an error even though getent won't.
Michal
Thanks for the explanation but it does not seem to work:
$ getent hosts try06; echo $? 2
Using 'libvirt' or libvirt_guest' one or the other or both does not change the above, for testing purposes the line 'hosts: ...' has only libvirt modules.
It is also not working for SSH.
Testing this on Debian Buster (10) ('libnss-libvirt is already the newest version (5.0.0-4+deb10u1)').
Your help is appriciated.
With some more testing:
$ grep hosts: /etc/ns* hosts: file libvirt libvirt_guest dns
$ virsh net-dhcp-leases default Expiry Time MAC address Protocol IP address Hostname Client ID or DUID ------------------------------------------------------------------------------------------------------------------------------------------------ 2020-03-27 21:40:49 52:54:00:d4:e6:f0 ipv4 192.168.122.137/24 debian ff:00:d4:e6:f0:00:01:00:01:26:11:0b:0c:52:54:00:d4:e6:f0
$ getent hosts try06 $ getent hosts debian 192.168.122.137 debian
So 'libvirt' plugin is working and 'libvirt_guest' is not.
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 I was told that in Debian, 5.2.0 is the first package to have both NSS plugins. Michal
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 -- Andrea Bolognani / Red Hat / Virtualization
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? Thanks to both of you for your help: Andrea Bolognani <abologna@redhat.com> Michal Prívozník <mprivozn@redhat.com> -- John Doe
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 Michal
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 <network> option In my case, I substituted '$network' by 'default'. 1) https://libvirt.org/nss.html#Internals -- John Doe
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 <network> 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 <network> 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 01:52:54:00:a4:6f:91 Michal
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 <network> 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, 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 <network> 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 01:52:54:00:a4:6f:91
Thanks for this. -- John Doe
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 <network> 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
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 <network> 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
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 <network> 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
On 5/5/2020 11:37 AM, Michal Privoznik wrote:
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:
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.
In my case, I changed the below mode from 'nat' to 'open'.
$ virsh net-edit default <forward mode='open'/>
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
I missunderstood in which file I had to do that change, see above.
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 <network> 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.
Fair enough, it already makes better sense now that I get that 'virsh' stands for 'virtual shell'! :) Looks like I'm getting closer to where I wonna go, thanks again for your support and all the help I got in here. -- John Doe
On 3/27/2020 5:13 PM, Michal Prívozník wrote:
On 27. 3. 2020 16:48, Michal Prívozník wrote:
On 27. 3. 2020 14:57, john doe wrote:
Hi,
I would like to set the hostname when installing a guest, with the below command the hostname is not set to 'try06' in the guest:
virt-install --name=try06 --graphic none --pxe --network bridge=virbr0
This is the name of the guest registered in libvirt. I don't think that virt-install has wired up setting hostname, but it looks like it can do it. I mean, use --name for both libvirt name and guest hostname.
On the other hand, users might want to set it to something else. So we really should have a separate argument for that. Anyway, I've reported it to virt-install developers:
Hi, This bug is now RFI, is there anything that I can do to move it along? Will this option be of any help if installing a VM using PXE? -- John Doe
On 10/19/20 5:59 PM, john doe wrote:
On 3/27/2020 5:13 PM, Michal Prívozník wrote:
On 27. 3. 2020 16:48, Michal Prívozník wrote:
On 27. 3. 2020 14:57, john doe wrote:
Hi,
I would like to set the hostname when installing a guest, with the below command the hostname is not set to 'try06' in the guest:
virt-install --name=try06 --graphic none --pxe --network bridge=virbr0
This is the name of the guest registered in libvirt. I don't think that virt-install has wired up setting hostname, but it looks like it can do it. I mean, use --name for both libvirt name and guest hostname.
On the other hand, users might want to set it to something else. So we really should have a separate argument for that. Anyway, I've reported it to virt-install developers:
Hi,
This bug is now RFI, is there anything that I can do to move it along?
I believe that virt-manager developers are swamped with some other work, so writing up patches looks like your best bet.
Will this option be of any help if installing a VM using PXE?
Yeah, I don't think that installation method gets in the way. Michal
On 10/19/2020 6:03 PM, Michal Prívozník wrote:
On 10/19/20 5:59 PM, john doe wrote:
On 3/27/2020 5:13 PM, Michal Prívozník wrote:
On 27. 3. 2020 16:48, Michal Prívozník wrote:
On 27. 3. 2020 14:57, john doe wrote:
Hi,
I would like to set the hostname when installing a guest, with the below command the hostname is not set to 'try06' in the guest:
virt-install --name=try06 --graphic none --pxe --network bridge=virbr0
This is the name of the guest registered in libvirt. I don't think that virt-install has wired up setting hostname, but it looks like it can do it. I mean, use --name for both libvirt name and guest hostname.
On the other hand, users might want to set it to something else. So we really should have a separate argument for that. Anyway, I've reported it to virt-install developers:
Hi,
This bug is now RFI, is there anything that I can do to move it along?
Sadly, I don't speak python. I install my guests using pxe, the guest are connected to a bridge on the host. Everytime I install a new guest, I first need to access the dhcp server to set the hostname with the corresponding mac address. In the meantime, is there an other approach that would let me install and set the guest's hostname on the same machine? In other words, how can I set the hostname when using a bridge on the host where virt-install is used.
I believe that virt-manager developers are swamped with some other work, so writing up patches looks like your best bet.
Will this option be of any help if installing a VM using PXE?
Yeah, I don't think that installation method gets in the way.
I'm looking forward to be able to take advantage of this option to set the hostname while using pxe. -- John Doe
On Fri, 2020-03-27 at 16:48 +0100, Michal Prívozník wrote:
On 27. 3. 2020 14:57, john doe wrote:
Hi,
I would like to set the hostname when installing a guest, with the below command the hostname is not set to 'try06' in the guest:
virt-install --name=try06 --graphic none --pxe --network bridge=virbr0
This is the name of the guest registered in libvirt. I don't think that virt-install has wired up setting hostname, but it looks like it can do it. I mean, use --name for both libvirt name and guest hostname.
Note that, while virt-install might be modified to automatically set the hostname in cases where it has full control of the installation process (--unattended), in the general case the user is performing the installation steps themselves in the context of the guest and virt-install has no way of knowing, or influencing, what happens there. -- Andrea Bolognani / Red Hat / Virtualization
On 3/27/2020 5:29 PM, Andrea Bolognani wrote:
On Fri, 2020-03-27 at 16:48 +0100, Michal Prívozník wrote:
On 27. 3. 2020 14:57, john doe wrote:
Hi,
I would like to set the hostname when installing a guest, with the below command the hostname is not set to 'try06' in the guest:
virt-install --name=try06 --graphic none --pxe --network bridge=virbr0
This is the name of the guest registered in libvirt. I don't think that virt-install has wired up setting hostname, but it looks like it can do it. I mean, use --name for both libvirt name and guest hostname.
Note that, while virt-install might be modified to automatically set the hostname in cases where it has full control of the installation process (--unattended), in the general case the user is performing the installation steps themselves in the context of the guest and virt-install has no way of knowing, or influencing, what happens there.
No argument there, in my case I'm doing a full unattended installation! :) Thanks for the (--unattended) hint, will look into that and thanks to Michal Prívozník for 'libvirt-nss plugin'. -- John Doe
participants (4)
-
Andrea Bolognani -
john doe -
Michal Privoznik -
Michal Prívozník