Re: Encrypting boot partition Libvirt not showing the OS booting up
On 10/12/2020 11:53 AM, john doe wrote:
On 10/12/2020 11:37 AM, Peter Krempa wrote:
On Mon, Oct 12, 2020 at 11:27:20 +0200, john doe wrote:
Hi, thank you for your answer, I'm sending this privatly as you asked for private information. Can I ask you to keep those information private?
On 10/12/2020 10:29 AM, Peter Krempa wrote:
On Mon, Oct 12, 2020 at 10:03:15 +0200, john doe wrote:
Hi,
I have installed Debian Buster with encrypted LVM so apon installation my root partition is encrypted. So far so good but as soon as I encrypt the boot partition, after reboot the OS won't start. If I start the drive directly with qemu, it works but it looks like Libvirt is somehow not able to deel with it.
This is not enough information to diagnose the problem.
We'll need the following:
1) Did you encrypt the partition using the debian installer
No, I did it after installation following the instructions at (1).
2) what vm XML you used: a) during installation
The domain xml file was created by virt-install with the following command: $ virsh destroy try01; virsh undefine try01; time virt-install --name=try01 --ram=1024 --noreboot --cpuset=auto --cpu host --vcpus=1,maxvcpus=4 --disk=path=/mnt/usbkey01/machines/try/try01,size=6 --graphic none --pxe --os-variant=debian10 --network bridge=br0,mac=0e:35:32:84:c3:f3 --filesystem type=mount,mode=mapped,source=/mnt/usbkey01/public,target=public_dir
b) when trying to finally boot the vm
Attached as 'try01.xml' obtained by doing 'virsh dumpxml try01 > try01.xml'.
3) what qemu command line you've used at the point you claim it worked
qemu-system-x86_64 -drive file=/mnt/usbkey01/machines/try/try01 -m 1024 -boot c -accel kvm -machine q35 -nographic
4) what is the error/final state when the VM fails to boot with libvirt
After having encrypted the boot partition:
$virsh console try01 root@0e-35-32-84-c3-f3:# [ 208.513259] watchdog: watchdog0: watchdog did not stop! [ 208.855971] reboot: Restarting system
$ qemu-system-x86_64 -drive file=/mnt/usbkey01/machines/try/try01 -m 1024 -boot c -accel kvm -machine q35 -nographic SeaBIOS (version 1.12.0-1)
iPXE (http://ipxe.org) 00:02.0 C980 PCI2.10 PnP PMM+3FF8FE80+3FECFE80 C980
Booting from Hard Disk... Attempting to decrypt master key... Enter passphrase for hd0,msdos1 (43a322dfc8ba4628b80afc66d49642a7):
As you can see above, if I invoked qemu directly, I get prompted for the boot passthrase but I'm not getting it when using libvirt.
Okay, so the root cause ... or "problem" here is that you don't see the console via 'virsh console' after the guest OS rebooted.
My suspicion according to the VM XML is that the VM restart triggered a restart of the qemu process and thus our internal handler of the console passthrough disconnected.
Please try a "virsh destroy $VM" if the VM is running/stuck waiting for the password without actually showing it and then start it using
virsh start --console $VM
This will start it and connect to the console immediately.
Please report your findings, we might want to discuss what happens when a console is connected and the guest uses a setting of:
<on_reboot>restart</on_reboot>
when the VM is rebooted.
Still no luck:
$ virsh destroy try01; virsh start --console try01 error: Failed to destroy domain try01 error: Requested operation is not valid: domain is not running
Domain try01 started Connected to domain try01 Escape character is ^]
I did not modify anything during the time I sent my answer and seeing yours.
I sent privately the requested xml file to 'Peter Krempa <pkrempa@redhat.com>'. Peter Krempa 's privately answered me back suggesting to add the following in the domain xml file: <bios useserial='yes'/> under <os> such as ... <os> <type arch='x86_64' machine='pc-q35-3.1'>hvm</type> <boot dev='hd'/> <bios useserial='yes'/> </os> This does not help at all and still give the output sent previously. -- John Doe
On 10/12/20 2:14 PM, john doe wrote:
<snip/>
I sent privately the requested xml file to 'Peter Krempa <pkrempa@redhat.com>'. Peter Krempa 's privately answered me back suggesting to add the following in the domain xml file:
Solving things privately doesn't help the community.
<bios useserial='yes'/> under <os>
such as ...
<os> <type arch='x86_64' machine='pc-q35-3.1'>hvm</type> <boot dev='hd'/> <bios useserial='yes'/> </os>
Try adding: <loader type='rom'>/usr/share/seabios/bios.bin</loader> to <os/> so that qemu actually uses SGA bios. Michal
On Mon, Oct 12, 2020 at 16:05:43 +0200, Michal Privoznik wrote:
On 10/12/20 2:14 PM, john doe wrote:
<snip/>
I sent privately the requested xml file to 'Peter Krempa <pkrempa@redhat.com>'. Peter Krempa 's privately answered me back suggesting to add the following in the domain xml file:
Solving things privately doesn't help the community.
Additionally it doesn't help solving the problem, since it's now opaque to others what the problem might be.
<bios useserial='yes'/> under <os>
I've suggested this as the outputs I've got privately hinted that the console (as in virsh console) didn't get to asking for the password, while the manually-started-qemu did. Thus the problem actually doesn't have to do with encryption or wahatver, but the console doesn't plainly work.
such as ...
<os> <type arch='x86_64' machine='pc-q35-3.1'>hvm</type> <boot dev='hd'/> <bios useserial='yes'/> </os>
Try adding:
<loader type='rom'>/usr/share/seabios/bios.bin</loader>
to <os/> so that qemu actually uses SGA bios.
Michal
On 10/12/2020 4:09 PM, Peter Krempa wrote:
On Mon, Oct 12, 2020 at 16:05:43 +0200, Michal Privoznik wrote:
On 10/12/20 2:14 PM, john doe wrote:
<snip/>
I sent privately the requested xml file to 'Peter Krempa <pkrempa@redhat.com>'. Peter Krempa 's privately answered me back suggesting to add the following in the domain xml file:
Solving things privately doesn't help the community.
Additionally it doesn't help solving the problem, since it's now opaque to others what the problem might be.
<bios useserial='yes'/> under <os>
I've suggested this as the outputs I've got privately hinted that the console (as in virsh console) didn't get to asking for the password, while the manually-started-qemu did.
Thus the problem actually doesn't have to do with encryption or wahatver, but the console doesn't plainly work.
such as ...
  <os>     <type arch='x86_64' machine='pc-q35-3.1'>hvm</type>     <boot dev='hd'/>     <bios useserial='yes'/>   </os>
Try adding:
<loader type='rom'>/usr/share/seabios/bios.bin</loader>
to <os/> so that qemu actually uses SGA bios.
Michal
Done but to no avail. I realy appriciate the help I'm getting in hear, thank you. -- John Doe
On 10/12/20 4:27 PM, john doe wrote:
On 10/12/2020 4:09 PM, Peter Krempa wrote:
On Mon, Oct 12, 2020 at 16:05:43 +0200, Michal Privoznik wrote:
On 10/12/20 2:14 PM, john doe wrote:
<snip/>
I sent privately the requested xml file to 'Peter Krempa <pkrempa@redhat.com>'. Peter Krempa 's privately answered me back suggesting to add the following in the domain xml file:
Solving things privately doesn't help the community.
Additionally it doesn't help solving the problem, since it's now opaque to others what the problem might be.
<bios useserial='yes'/> under <os>
I've suggested this as the outputs I've got privately hinted that the console (as in virsh console) didn't get to asking for the password, while the manually-started-qemu did.
Thus the problem actually doesn't have to do with encryption or wahatver, but the console doesn't plainly work.
such as ...
  <os>     <type arch='x86_64' machine='pc-q35-3.1'>hvm</type>     <boot dev='hd'/>     <bios useserial='yes'/>   </os>
Try adding:
<loader type='rom'>/usr/share/seabios/bios.bin</loader>
Darn, this should have been sgabios: /usr/share/sgabios/sgabios.bin but if your seabios is new enough (v1.11.0 and newer) then this is not needed as seabios itself is capable of serial interface. And looking at earlier e-mails in the thread you have v1.12.0-1 you you're good and don't need to add <loader/> at all. But honestly, I don't know why you are not getting the console. Could it be that you are getting the console and the qemu is waiting for your input, i.e. what happens if you type in the password? Michal
On 10/12/2020 5:14 PM, Michal Privoznik wrote:
On 10/12/20 4:27 PM, john doe wrote:
On 10/12/2020 4:09 PM, Peter Krempa wrote:
On Mon, Oct 12, 2020 at 16:05:43 +0200, Michal Privoznik wrote:
On 10/12/20 2:14 PM, john doe wrote:
<snip/>
I sent privately the requested xml file to 'Peter Krempa <pkrempa@redhat.com>'. Peter Krempa 's privately answered me back suggesting to add the following in the domain xml file:
Solving things privately doesn't help the community.
Additionally it doesn't help solving the problem, since it's now opaque to others what the problem might be.
<bios useserial='yes'/> under <os>
I've suggested this as the outputs I've got privately hinted that the console (as in virsh console) didn't get to asking for the password, while the manually-started-qemu did.
Thus the problem actually doesn't have to do with encryption or wahatver, but the console doesn't plainly work.
such as ...
  <os>     <type arch='x86_64' machine='pc-q35-3.1'>hvm</type>     <boot dev='hd'/>     <bios useserial='yes'/>   </os>
Try adding:
<loader type='rom'>/usr/share/seabios/bios.bin</loader>
Darn, this should have been sgabios: /usr/share/sgabios/sgabios.bin but if your seabios is new enough (v1.11.0 and newer) then this is not needed as seabios itself is capable of serial interface. And looking at earlier e-mails in the thread you have v1.12.0-1 you you're good and don't need to add <loader/> at all.
But honestly, I don't know why you are not getting the console. Could it be that you are getting the console and the qemu is waiting for your input, i.e. what happens if you type in the password?
Nothing happened at all if I try to type the password. Yes, so am I , I'm totaly lost on why it does not work. How can I find the command libvirt is passing to qemu? Are you at least able to reproduce the issue (Debian Buster for host and guest)? -- John Doe
On 10/12/20 1:10 PM, john doe wrote:
On 10/12/2020 5:14 PM, Michal Privoznik wrote:
On 10/12/20 4:27 PM, john doe wrote:
On 10/12/2020 4:09 PM, Peter Krempa wrote:
On Mon, Oct 12, 2020 at 16:05:43 +0200, Michal Privoznik wrote:
On 10/12/20 2:14 PM, john doe wrote:
> <snip/>
I sent privately the requested xml file to 'Peter Krempa <pkrempa@redhat.com>'. Peter Krempa 's privately answered me back suggesting to add the following in the domain xml file:
Solving things privately doesn't help the community.
Additionally it doesn't help solving the problem, since it's now opaque to others what the problem might be.
<bios useserial='yes'/> under <os>
I've suggested this as the outputs I've got privately hinted that the console (as in virsh console) didn't get to asking for the password, while the manually-started-qemu did.
Thus the problem actually doesn't have to do with encryption or wahatver, but the console doesn't plainly work.
such as ...
  <os>     <type arch='x86_64' machine='pc-q35-3.1'>hvm</type>     <boot dev='hd'/>     <bios useserial='yes'/>   </os>
Try adding:
<loader type='rom'>/usr/share/seabios/bios.bin</loader>
Darn, this should have been sgabios: /usr/share/sgabios/sgabios.bin but if your seabios is new enough (v1.11.0 and newer) then this is not needed as seabios itself is capable of serial interface. And looking at earlier e-mails in the thread you have v1.12.0-1 you you're good and don't need to add <loader/> at all.
But honestly, I don't know why you are not getting the console. Could it be that you are getting the console and the qemu is waiting for your input, i.e. what happens if you type in the password?
Nothing happened at all if I try to type the password. Yes, so am I , I'm totaly lost on why it does not work.
How can I find the command libvirt is passing to qemu?
The qemu command issued by libvirt can be found at the end of /etc/libvirt/qemu/${guestname}.log
Are you at least able to reproduce the issue (Debian Buster for host and guest)?
-- John Doe
On 10/13/2020 3:30 AM, Laine Stump wrote:
On 10/12/20 1:10 PM, john doe wrote:
On 10/12/2020 5:14 PM, Michal Privoznik wrote:
On 10/12/20 4:27 PM, john doe wrote:
On 10/12/2020 4:09 PM, Peter Krempa wrote:
On Mon, Oct 12, 2020 at 16:05:43 +0200, Michal Privoznik wrote:
On 10/12/20 2:14 PM, john doe wrote: >> <snip/> > > I sent privately the requested xml file to 'Peter Krempa > <pkrempa@redhat.com>'. > Peter Krempa 's privately answered me back suggesting to add the > following in the domain xml file:
Solving things privately doesn't help the community.
Additionally it doesn't help solving the problem, since it's now opaque to others what the problem might be.
> > <bios useserial='yes'/> under <os>
I've suggested this as the outputs I've got privately hinted that the console (as in virsh console) didn't get to asking for the password, while the manually-started-qemu did.
Thus the problem actually doesn't have to do with encryption or wahatver, but the console doesn't plainly work.
> > such as ... > > Â Â <os> > Â Â Â Â <type arch='x86_64' machine='pc-q35-3.1'>hvm</type> > Â Â Â Â <boot dev='hd'/> > Â Â Â Â <bios useserial='yes'/> > Â Â </os> >
Try adding:
<loader type='rom'>/usr/share/seabios/bios.bin</loader>
Darn, this should have been sgabios: /usr/share/sgabios/sgabios.bin but if your seabios is new enough (v1.11.0 and newer) then this is not needed as seabios itself is capable of serial interface. And looking at earlier e-mails in the thread you have v1.12.0-1 you you're good and don't need to add <loader/> at all.
But honestly, I don't know why you are not getting the console. Could it be that you are getting the console and the qemu is waiting for your input, i.e. what happens if you type in the password?
Nothing happened at all if I try to type the password. Yes, so am I , I'm totaly lost on why it does not work.
How can I find the command libvirt is passing to qemu?
The qemu command issued by libvirt can be found at the end of /etc/libvirt/qemu/${guestname}.log
Thank you, I have now isolated the command generated by libvirt. Starting this command from a script, a vnc server is started. Is libvirt internally using vnc connection? -- John Doe
On 10/13/2020 8:50 AM, john doe wrote:
On 10/13/2020 3:30 AM, Laine Stump wrote:
On 10/12/20 1:10 PM, john doe wrote:
On 10/12/2020 5:14 PM, Michal Privoznik wrote:
On 10/12/20 4:27 PM, john doe wrote:
On 10/12/2020 4:09 PM, Peter Krempa wrote:
On Mon, Oct 12, 2020 at 16:05:43 +0200, Michal Privoznik wrote: > On 10/12/20 2:14 PM, john doe wrote: >>> <snip/> >> >> I sent privately the requested xml file to 'Peter Krempa >> <pkrempa@redhat.com>'. >> Peter Krempa 's privately answered me back suggesting to add the >> following in the domain xml file: > > Solving things privately doesn't help the community.
Additionally it doesn't help solving the problem, since it's now opaque to others what the problem might be.
>> >> <bios useserial='yes'/> under <os>
I've suggested this as the outputs I've got privately hinted that the console (as in virsh console) didn't get to asking for the password, while the manually-started-qemu did.
Thus the problem actually doesn't have to do with encryption or wahatver, but the console doesn't plainly work.
>> >> such as ... >> >> Â Â <os> >> Â Â Â Â <type arch='x86_64' machine='pc-q35-3.1'>hvm</type> >> Â Â Â Â <boot dev='hd'/> >> Â Â Â Â <bios useserial='yes'/> >> Â Â </os> >> > > Try adding: > > <loader type='rom'>/usr/share/seabios/bios.bin</loader>
Darn, this should have been sgabios: /usr/share/sgabios/sgabios.bin but if your seabios is new enough (v1.11.0 and newer) then this is not needed as seabios itself is capable of serial interface. And looking at earlier e-mails in the thread you have v1.12.0-1 you you're good and don't need to add <loader/> at all.
But honestly, I don't know why you are not getting the console. Could it be that you are getting the console and the qemu is waiting for your input, i.e. what happens if you type in the password?
Nothing happened at all if I try to type the password. Yes, so am I , I'm totaly lost on why it does not work.
How can I find the command libvirt is passing to qemu?
The qemu command issued by libvirt can be found at the end of /etc/libvirt/qemu/${guestname}.log
Thank you, I have now isolated the command generated by libvirt. Starting this command from a script, a vnc server is started.
Is libvirt internally using vnc connection?
It looks like the issue is that the libvirt command pass to qemu is using '-display none' where it should be '-nographic'. -- John Doe
On Tue, Oct 13, 2020 at 10:40:11AM +0200, john doe wrote:
On 10/13/2020 8:50 AM, john doe wrote:
On 10/13/2020 3:30 AM, Laine Stump wrote:
On 10/12/20 1:10 PM, john doe wrote:
On 10/12/2020 5:14 PM, Michal Privoznik wrote:
On 10/12/20 4:27 PM, john doe wrote:
On 10/12/2020 4:09 PM, Peter Krempa wrote: > On Mon, Oct 12, 2020 at 16:05:43 +0200, Michal Privoznik wrote: > > On 10/12/20 2:14 PM, john doe wrote: > > > > <snip/> > > > > > > I sent privately the requested xml file to 'Peter Krempa > > > <pkrempa@redhat.com>'. > > > Peter Krempa 's privately answered me back suggesting to add the > > > following in the domain xml file: > > > > Solving things privately doesn't help the community. > > Additionally it doesn't help solving the problem, since it's now > opaque > to others what the problem might be. > > > > > > > <bios useserial='yes'/> under <os> > > I've suggested this as the outputs I've got privately hinted that the > console (as in virsh console) didn't get to asking for the password, > while the manually-started-qemu did. > > Thus the problem actually doesn't have to do with encryption or > wahatver, but the console doesn't plainly work. > > > > > > > such as ... > > > > > > Â Â <os> > > > Â Â Â Â <type arch='x86_64' machine='pc-q35-3.1'>hvm</type> > > > Â Â Â Â <boot dev='hd'/> > > > Â Â Â Â <bios useserial='yes'/> > > > Â Â </os> > > > > > > > Try adding: > > > > <loader type='rom'>/usr/share/seabios/bios.bin</loader>
Darn, this should have been sgabios: /usr/share/sgabios/sgabios.bin but if your seabios is new enough (v1.11.0 and newer) then this is not needed as seabios itself is capable of serial interface. And looking at earlier e-mails in the thread you have v1.12.0-1 you you're good and don't need to add <loader/> at all.
But honestly, I don't know why you are not getting the console. Could it be that you are getting the console and the qemu is waiting for your input, i.e. what happens if you type in the password?
Nothing happened at all if I try to type the password. Yes, so am I , I'm totaly lost on why it does not work.
How can I find the command libvirt is passing to qemu?
The qemu command issued by libvirt can be found at the end of /etc/libvirt/qemu/${guestname}.log
Thank you, I have now isolated the command generated by libvirt. Starting this command from a script, a vnc server is started.
Is libvirt internally using vnc connection?
It looks like the issue is that the libvirt command pass to qemu is using '-display none' where it should be '-nographic'.
No, using "-display none" is correct to disable any graphical display in QEMU. -nographic is an old discouraged syntax which has many side effects, beyond disabling graphical display it mess with serial port config. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Tue, Oct 13, 2020 at 10:40:11 +0200, john doe wrote:
On 10/13/2020 8:50 AM, john doe wrote:
[...]
Thank you, I have now isolated the command generated by libvirt. Starting this command from a script, a vnc server is started.
Is libvirt internally using vnc connection?
It looks like the issue is that the libvirt command pass to qemu is using '-display none' where it should be '-nographic'.
That is deliberate: commit 7a97676b968bcdf60fb987afe6308bc0b4ab9cd3 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Tue Jul 5 14:35:28 2016 +0200 qemu: generate -display none This is preferrable to -nographic which (in addition to disabling graphics output) redirects the serial port to stdio and on OpenBIOS enables the firmware's serial console. We don't want to use stdio serial port at all, but rather explicitly defined ones exposed internally such as: <serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <target type='serial' port='0'/> </console> I've verified that once I add the suggested useserial attribute: <os> <type arch='x86_64' machine='pc-i440fx-2.9'>hvm</type> <bootmenu enable='yes'/> <bios useserial='yes'/> </os> to one of my VMs I can see the console when started via virsh start --console: $ virsh start --console upstream Domain upstream started Connected to domain upstream Escape character is ^] (Ctrl + ]) iPXE (http://ipxe.org) 00:03.0 C100 PCI2.10 PnP PMM+3E7835A0+3E6E35A0 C100 iPXE (http://ipxe.org) 00:08.0 C200 PCI2.10 PnP PMM+3E6D25A0 3E6E35A0 C200 Press ESC for boot menu.
On 10/13/2020 10:58 AM, Peter Krempa wrote:
On Tue, Oct 13, 2020 at 10:40:11 +0200, john doe wrote:
On 10/13/2020 8:50 AM, john doe wrote:
[...]
Thank you, I have now isolated the command generated by libvirt. Starting this command from a script, a vnc server is started.
Is libvirt internally using vnc connection?
It looks like the issue is that the libvirt command pass to qemu is using '-display none' where it should be '-nographic'.
That is deliberate:
commit 7a97676b968bcdf60fb987afe6308bc0b4ab9cd3 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Tue Jul 5 14:35:28 2016 +0200
qemu: generate -display none
This is preferrable to -nographic which (in addition to disabling graphics output) redirects the serial port to stdio and on OpenBIOS enables the firmware's serial console.
We don't want to use stdio serial port at all, but rather explicitly defined ones exposed internally such as:
<serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <target type='serial' port='0'/> </console>
I've verified that once I add the suggested useserial attribute:
<os> <type arch='x86_64' machine='pc-i440fx-2.9'>hvm</type> <bootmenu enable='yes'/> <bios useserial='yes'/> </os>
to one of my VMs I can see the console when started via virsh start --console:
$ virsh start --console upstream Domain upstream started Connected to domain upstream Escape character is ^] (Ctrl + ])
iPXE (http://ipxe.org) 00:03.0 C100 PCI2.10 PnP PMM+3E7835A0+3E6E35A0 C100
iPXE (http://ipxe.org) 00:08.0 C200 PCI2.10 PnP PMM+3E6D25A0 3E6E35A0 C200
Press ESC for boot menu.
To summerise: After having installed the vm with virt-install, if you encrypt the boot partition, you may need to add the below two lines in the os section of the domain xml: <bootmenu enable='yes'/> <bios useserial='yes'/> Then start the guest with the below command: virsh start $vm --console I was able to find the log file in the directory '/var/log/libvirt/qemu'. A big thank you for all the help: - Peter Krempa - Daniel P. Berrangé - Laine Stump - Michal Privoznik Much appriciated. -- John Doe
On 10/13/2020 12:06 PM, john doe wrote:
On 10/13/2020 10:58 AM, Peter Krempa wrote:
On Tue, Oct 13, 2020 at 10:40:11 +0200, john doe wrote:
On 10/13/2020 8:50 AM, john doe wrote:
[...]
Thank you, I have now isolated the command generated by libvirt. Starting this command from a script, a vnc server is started.
Is libvirt internally using vnc connection?
It looks like the issue is that the libvirt command pass to qemu is using '-display none' where it should be '-nographic'.
That is deliberate:
commit 7a97676b968bcdf60fb987afe6308bc0b4ab9cd3 Author: Paolo Bonzini <pbonzini@redhat.com> Date: Tue Jul 5 14:35:28 2016 +0200
qemu: generate -display none
This is preferrable to -nographic which (in addition to disabling graphics output) redirects the serial port to stdio and on OpenBIOS enables the firmware's serial console.
We don't want to use stdio serial port at all, but rather explicitly defined ones exposed internally such as:
<serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <target type='serial' port='0'/> </console>
I've verified that once I add the suggested useserial attribute:
<os> <type arch='x86_64' machine='pc-i440fx-2.9'>hvm</type> <bootmenu enable='yes'/> <bios useserial='yes'/> </os>
to one of my VMs I can see the console when started via virsh start --console:
$ virsh start --console upstream Domain upstream started Connected to domain upstream Escape character is ^] (Ctrl + ])
iPXE (http://ipxe.org) 00:03.0 C100 PCI2.10 PnP PMM+3E7835A0+3E6E35A0 C100
iPXE (http://ipxe.org) 00:08.0 C200 PCI2.10 PnP PMM+3E6D25A0 3E6E35A0 C200
Press ESC for boot menu.
To summerise:
After having installed the vm with virt-install, if you encrypt the boot partition, you may need to add the below two lines in the os section of the domain xml:
<bootmenu enable='yes'/> <bios useserial='yes'/>
Then start the guest with the below command:
virsh start $vm --console
I also had to install the 'sgabios' package. -- John Doe
participants (5)
-
Daniel P. Berrangé -
john doe -
Laine Stump -
Michal Privoznik -
Peter Krempa