[libvirt-users] virsh edit problems
I've got a problem where I can't access my console (well, I can', but I can't type in a password), which I don't think is a libvirt issue but any help or commentary is certainly welcome http://thread.gmane.org/gmane.comp.emulators.kvm.devel/79561 , and I'm trying to debug it by trying out different console/serial options in my .xml file, and I can't change them. What I have now: <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> No matter what I change, whether I use "virsh edit" or edit the files directly, even with libvirt off, as soon as libvirt notices (i.e. when I turn it back on) my changes get blown away and it ends up looking just like the above. Even as simple a thing as changing the port number, or removing the console, or adding a second serial... all gone. Oh, wait, that's not quite true; adding a second serial *does* work. But nothing else I've tried does. What I'm actually trying to do is copy the docs http://libvirt.org/formatdomain.html#elementsConsole more closely and specify my own source paths; I'm worried that the serial and the console are somehow ending up in the same place and maybe that's causing my problem? What I've been trying to do is something like: <serial type='pty'> <source path='/dev/pts/3'/> <target port='0'/> </serial> <console type='pty'> <source path='/dev/pts/4'/> <target port='0'/> </console> And it just won't stick. Maybe that's not even my problem, but it's not showing any errors, and it's annoying me and I'd like to understand why. -Robin
On 09/26/2011 02:30 PM, Robin Lee Powell wrote:
What I have now:
<serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console>
That's correct for the persistent config.
No matter what I change, whether I use "virsh edit"
Good.
or edit the files directly,
Don't do that. It won't work, and you risk corrupting things by going behind libvirt's back.
even with libvirt off, as soon as libvirt notices (i.e. when I turn it back on) my changes get blown away and it ends up looking just like the above. Even as simple a thing as changing the port number, or removing the console, or adding a second serial... all gone.
That's an indication that the things you are adding are not essential to the persistent config. 'virsh edit' prunes your input back into the xml essential to what libvirt needed, so if your edits didn't stick, then they weren't making a difference.
Oh, wait, that's not quite true; adding a second serial *does* work. But nothing else I've tried does.
What I'm actually trying to do is copy the docs http://libvirt.org/formatdomain.html#elementsConsole more closely and specify my own source paths; I'm worried that the serial and the console are somehow ending up in the same place and maybe that's causing my problem?
What I've been trying to do is something like:
<serial type='pty'> <source path='/dev/pts/3'/> <target port='0'/> </serial>
Ah - maybe I can explain that issue. For pty devices, <source path=.../> is computed at runtime, once libvirt has actually allocated a pty from the host (which pty gets allocated depends on what else has been going on in your host prior to starting your guest). Since the pty allocated is dependent on various runtime factors, there is no way to pre-allocate a fixed pty value - so this <source> element is something that 'virsh dumpxml' outputs to show you which pty libvirt allocated, but where you have no control (and no need to control) which pty to attempt to allocate. And libvirt is merely stripping the unused <source> from your persistent config because it doesn't make sense in a persistent context.
<console type='pty'> <source path='/dev/pts/4'/> <target port='0'/> </console>
And it just won't stick. Maybe that's not even my problem, but it's not showing any errors, and it's annoying me and I'd like to understand why.
Hopefully my explanation helps, but feel free to ask more questions as needed. Perhaps this is a case of me answering your stated question rather than your implied question (that is, I answered why <source> is disappearing, but not how to get a console to your guest working in the first place). -- Eric Blake eblake@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
On Mon, Sep 26, 2011 at 02:40:23PM -0600, Eric Blake wrote:
On 09/26/2011 02:30 PM, Robin Lee Powell wrote:
What I've been trying to do is something like:
<serial type='pty'> <source path='/dev/pts/3'/> <target port='0'/> </serial>
Ah - maybe I can explain that issue. For pty devices, <source path=.../> is computed at runtime, once libvirt has actually allocated a pty from the host (which pty gets allocated depends on what else has been going on in your host prior to starting your guest). Since the pty allocated is dependent on various runtime factors, there is no way to pre-allocate a fixed pty value - so this <source> element is something that 'virsh dumpxml' outputs to show you which pty libvirt allocated, but where you have no control (and no need to control) which pty to attempt to allocate. And libvirt is merely stripping the unused <source> from your persistent config because it doesn't make sense in a persistent context.
<console type='pty'> <source path='/dev/pts/4'/> <target port='0'/> </console>
And it just won't stick. Maybe that's not even my problem, but it's not showing any errors, and it's annoying me and I'd like to understand why.
Hopefully my explanation helps, but feel free to ask more questions as needed. Perhaps this is a case of me answering your stated question rather than your implied question (that is, I answered why <source> is disappearing, but not how to get a console to your guest working in the first place).
Yes, well, that's completely fair, and I appreciate the explanation. :) If other people are having configs like mine and it's working, then that's not the problem, I guess. I was worried because only one pts is being allocated, according to the log, so I'm worried that it's not making the right allocation. But yeah, if you want to help with the actual problem (the link to the kvm mailing list explains it), feel free. :D -Robin
participants (2)
-
Eric Blake -
Robin Lee Powell