Guest shutdown problems
by Christian Axelsson
Hello
I have a problem shutting down xen guests. Using xm shutdown guests get
shut down but gets stuck in state '---s-d' or sometimes '------'.
When trying to clone a domain when in this state (my original purpose of
the whole operation) I'll get the error:
[root@hydra virtinst--devel]# ./virt-clone -o minimal -n new_img -f
/var/lib/xen/images/new_img.img
ERROR: virDomainGetXMLDesc() failed failed Xen syscall
xenDaemonDomainDumpXMLByID failed to find this domain -490299505
The same errors occurs when for example trying to attach to the console
using virsh.
I have tried to use 'xm destroy' to kill the guest the hard way but it
has no effect - the state remains unchanged. I have also tried this on a
few different guest installations with the same result. A thing worth
noting is that the output from 'xm list --long' differs, I've attached
the out put pre boot, after boot and after shutdown. Note how all the
devices in the guests are missing after shutdown.
Both the hosts and the guests are fedora 8 installations.
Regards,
Christian Axelsson
smiler(a)lanil.mine.nu
[?1034h(domain
(domid 0)
(on_crash restart)
(uuid 00000000-0000-0000-0000-000000000000)
(bootloader_args )
(vcpus 2)
(name Domain-0)
(on_poweroff destroy)
(on_reboot restart)
(bootloader )
(maxmem 16777215)
(memory 1491)
(shadow_memory 0)
(cpu_weight 256)
(cpu_cap 0)
(features )
(on_xend_start ignore)
(on_xend_stop ignore)
(cpu_time 1644.84369405)
(online_vcpus 2)
(image (linux (kernel )))
(status 2)
(state r-----)
)
(domain
(domid 2)
(on_crash restart)
(uuid a7638797-e237-3891-5e64-390f828238ca)
(bootloader_args )
(vcpus 1)
(name minimal)
(on_poweroff destroy)
(on_reboot restart)
(bootloader /usr/bin/pygrub)
(maxmem 512)
(memory 512)
(shadow_memory 0)
(cpu_weight 256)
(cpu_cap 0)
(features )
(on_xend_start ignore)
(on_xend_stop ignore)
(start_time 1206360333.14)
(cpu_time 9.753408915)
(online_vcpus 1)
(image
(linux
(kernel )
(notes
(FEATURES
'writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel'
)
(VIRT_BASE 18446744071562067968)
(GUEST_VERSION 2.6)
(PADDR_OFFSET 18446744071562067968)
(GUEST_OS linux)
(HYPERCALL_PAGE 18446744071564189696)
(LOADER generic)
(SUSPEND_CANCEL 1)
(ENTRY 18446744071564165120)
(XEN_VERSION xen-3.0)
)
)
)
(status 2)
(state -b----)
(store_mfn 196619)
(console_mfn 196618)
(device
(vif
(bridge xenbr0)
(mac 00:16:3e:3f:93:b8)
(script vif-bridge)
(uuid 94afd732-920b-2e0b-b3d5-e79174754a80)
(backend 0)
)
)
(device
(vbd
(uname file:/var/lib/xen/images/minimal.img)
(uuid 8f4f4da3-5f8a-3fee-28e8-41dc49e876cd)
(mode w)
(dev xvda:disk)
(backend 0)
(bootable 1)
)
)
(device
(console
(protocol vt100)
(location 2)
(uuid 0046f2d3-058b-d524-9273-f1dac2ca950b)
)
)
)
[?1034h(domain
(domid 0)
(on_crash restart)
(uuid 00000000-0000-0000-0000-000000000000)
(bootloader_args )
(vcpus 2)
(name Domain-0)
(on_poweroff destroy)
(on_reboot restart)
(bootloader )
(maxmem 16777215)
(memory 1491)
(shadow_memory 0)
(cpu_weight 256)
(cpu_cap 0)
(features )
(on_xend_start ignore)
(on_xend_stop ignore)
(cpu_time 1648.92600832)
(online_vcpus 2)
(image (linux (kernel )))
(status 2)
(state r-----)
)
(domain
(domid 2)
(on_crash restart)
(uuid a7638797-e237-3891-5e64-390f828238ca)
(bootloader_args )
(vcpus 1)
(name minimal)
(on_poweroff destroy)
(on_reboot restart)
(bootloader /usr/bin/pygrub)
(maxmem 512)
(memory 512)
(shadow_memory 0)
(cpu_weight 256)
(cpu_cap 0)
(features )
(on_xend_start ignore)
(on_xend_stop ignore)
(start_time 1206360333.14)
(cpu_time 13.048743365)
(online_vcpus 1)
(image
(linux
(kernel )
(notes
(FEATURES
'writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel'
)
(VIRT_BASE 18446744071562067968)
(GUEST_VERSION 2.6)
(PADDR_OFFSET 18446744071562067968)
(GUEST_OS linux)
(HYPERCALL_PAGE 18446744071564189696)
(LOADER generic)
(SUSPEND_CANCEL 1)
(ENTRY 18446744071564165120)
(XEN_VERSION xen-3.0)
)
)
)
(status 0)
(state ---s-d)
(store_mfn 196619)
(console_mfn 196618)
)
[?1034h(domain
(domid 0)
(on_crash restart)
(uuid 00000000-0000-0000-0000-000000000000)
(bootloader_args )
(vcpus 2)
(name Domain-0)
(on_poweroff destroy)
(on_reboot restart)
(bootloader )
(maxmem 16777215)
(memory 1491)
(shadow_memory 0)
(cpu_weight 256)
(cpu_cap 0)
(features )
(on_xend_start ignore)
(on_xend_stop ignore)
(cpu_time 1635.21430615)
(online_vcpus 2)
(image (linux (kernel )))
(status 2)
(state r-----)
)
(domain
(on_crash restart)
(uuid a7638797-e237-3891-5e64-390f828238ca)
(bootloader_args )
(vcpus 1)
(name minimal)
(on_poweroff destroy)
(on_reboot restart)
(bootloader /usr/bin/pygrub)
(maxmem 512)
(memory 512)
(shadow_memory 0)
(cpu_weight 256)
(cpu_cap 0)
(features )
(on_xend_start ignore)
(on_xend_stop ignore)
(start_time 1206309092.82)
(cpu_time 0.0)
(image
(linux
(kernel )
(notes
(FEATURES
'writable_page_tables|writable_descriptor_tables|auto_translated_physmap|pae_pgdir_above_4gb|supervisor_mode_kernel'
)
(VIRT_BASE 18446744071562067968)
(GUEST_VERSION 2.6)
(PADDR_OFFSET 18446744071562067968)
(GUEST_OS linux)
(HYPERCALL_PAGE 18446744071564189696)
(LOADER generic)
(SUSPEND_CANCEL 1)
(ENTRY 18446744071564165120)
(XEN_VERSION xen-3.0)
)
)
)
(status 0)
(device
(vif
(bridge xenbr0)
(mac 00:16:3e:3f:93:b8)
(backend 0)
(uuid 94afd732-920b-2e0b-b3d5-e79174754a80)
(script vif-bridge)
)
)
(device
(vbd
(uuid 8f4f4da3-5f8a-3fee-28e8-41dc49e876cd)
(bootable 1)
(driver paravirtualised)
(dev xvda:disk)
(uname file:/var/lib/xen/images/minimal.img)
(mode w)
(backend 0)
)
)
(device
(console
(protocol vt100)
(location 2)
(uuid 0046f2d3-058b-d524-9273-f1dac2ca950b)
)
)
)
15 years
Cannot start HVM DomU
by Robert Locke
This has newly started, so I am presuming that it is perhaps related to
some recently updated package on F8 in say the last week or so.
I have a WindowsXP DomU that when I try to start from virt-manager gives
the following error:
Error starting domain: virDomainCreate() failed POST operation failed:
(xend.err 'int argument required')
Details shows:
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/engine.py", line 472, in
run_domain
vm.startup()
File "/usr/share/virt-manager/virtManager/domain.py", line 379, in
startup
self.vm.create()
File "/usr/lib/python2.5/site-packages/libvirt.py", line 240, in
create
if ret == -1: raise libvirtError ('virDomainCreate() failed',
dom=self)
libvirtError: virDomainCreate() failed POST operation failed: (xend.err
'int argument required')
I have no idea what other information to supply or where to particularly
find it since this has generally "just worked" for the occasional
running of a Windows instance that I have needed for the last several
months.
Thanks for any help,
--Rob
15 years, 9 months
RE: [Fedora-xen] Strange mouse issue (F7 & F8 xen kernel with vncviewer running)
by Dustin Henning
I spoke too soon... I just tried krdc and the same thing happened
before I could even try to connect to anything with it (or even determine if
it supports vnc, I don't remember). This is a quad core, and I have, in all
instances, confirmed that each of the four vcpus in dom0 is tied to a
different core. Additionally, I have never had more than one DomU per core
on top of Dom0 using each core. Finally, in this latest instance, only one
DomU was doing anything, and it could not have been using but 100% of one
core, so the other three were, for lack of a better word, bored.
-----Original Message-----
From: fedora-xen-bounces(a)redhat.com [mailto:fedora-xen-bounces@redhat.com]
On Behalf Of Dustin Henning
Sent: Friday, May 30, 2008 16:48
To: fedora-xen(a)redhat.com
Subject: [Fedora-xen] Strange mouse issue (F7 & F8 xen kernel with vncviewer
running)
I have been experiencing this (rather strange) issue for as long as
I have been a member of this group, and I am curious as to whether anyone
else has experienced it. The mouse will continue on in the direction I am
moving it after I stop, change direction, or even suddenly reverse
direction. Once this happens, the mouse inevitably ends up in one of the
four corners of the screen, and will eventually stop trying to travel in
that direction, at which point I can control it again. It seems like
hitting some keys may cause this to happen sooner. The keys I most often go
for are Esc, Alt, Ctrl, Super, Alt+F1, Arrows. Which keys usually depends
on what is up in the vncviewer window, where I don't want to issue the wrong
command to whatever client I may be working with. I have made the following
observations regarding this behavior, though I can't say with absolute
certainty that they are all 100% accurate and/or consistent:
-keyboard and mouse are PS/2
-in all instances, hvm guests were running, consuming as much as 5
out of 8 GiB of memory on this machine
-never experienced in standard kernel on F7 or F8 (even with
multiple kvm guests and vncviewers running, though not to consume 5 of 8
GiB)
-originally, in F7, vncviewer may not have been running every time
it happened
-now, in F8, vncviewer has definitely been running every time it
happened, but not necessarily connected to anything
-same issue was previously experienced on another machine with less
memory (and less guests) on F7
Is this a known issue of any sort? It has recently occurred to me
that I should try a different client, and I will do that at some point, but
I figured it wouldn't hurt to see if there have been any other similar
experiences out there in the meantime. Thanks,
Dustin
--
Fedora-xen mailing list
Fedora-xen(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-xen
15 years, 11 months
Strange mouse issue (F7 & F8 xen kernel with vncviewer running)
by Dustin Henning
I have been experiencing this (rather strange) issue for as long as
I have been a member of this group, and I am curious as to whether anyone
else has experienced it. The mouse will continue on in the direction I am
moving it after I stop, change direction, or even suddenly reverse
direction. Once this happens, the mouse inevitably ends up in one of the
four corners of the screen, and will eventually stop trying to travel in
that direction, at which point I can control it again. It seems like
hitting some keys may cause this to happen sooner. The keys I most often go
for are Esc, Alt, Ctrl, Super, Alt+F1, Arrows. Which keys usually depends
on what is up in the vncviewer window, where I don't want to issue the wrong
command to whatever client I may be working with. I have made the following
observations regarding this behavior, though I can't say with absolute
certainty that they are all 100% accurate and/or consistent:
-keyboard and mouse are PS/2
-in all instances, hvm guests were running, consuming as much as 5
out of 8 GiB of memory on this machine
-never experienced in standard kernel on F7 or F8 (even with
multiple kvm guests and vncviewers running, though not to consume 5 of 8
GiB)
-originally, in F7, vncviewer may not have been running every time
it happened
-now, in F8, vncviewer has definitely been running every time it
happened, but not necessarily connected to anything
-same issue was previously experienced on another machine with less
memory (and less guests) on F7
Is this a known issue of any sort? It has recently occurred to me
that I should try a different client, and I will do that at some point, but
I figured it wouldn't hurt to see if there have been any other similar
experiences out there in the meantime. Thanks,
Dustin
15 years, 11 months
Xen Documentation
by Gastón Keller
Hello, everybody. I have been struggling with Xen's documentation
lately, not finding where to look for accurate and up-to-date info. I
remember having read in this list months ago someone saying that the
documentation was quite outdated. For example, the xm command _delete_
does not appear in the man pages and many guides still do reference to
the guest's config files being stored at /etc/xen (two days ago I
discovered that now Xen works in a different way).
My objective is not only to learn how to use Xen, but understand how
it works. I'm doing my best looking for info in the net and going
through docs in the Xen Wiki, but I might be missing something in my
search. Therefore, I would really appreciate if someone could point me
to some documentation I should read, or whatever else you could think
of.
Thanks,
Gaston
--
La única verdad es la realidad.
15 years, 11 months
Re: [Fedora-xen] Xen Documentation
by Emre Erenoglu
I totally share your view. :) I'm in the same condition.
Emre
On Fri, May 30, 2008 at 2:12 PM, Dustin Henning <Dustin.Henning(a)prd-inc.com>
wrote:
> Emre,
> As you may already know, I still use the config files in /etc/xen
> and don't mess with the virsh stuff. It all certainly worked fine in F7,
> and though I haven't fully tested, it appears that it all works fine in F8
> as well. I use them for one, because I learned with them, and for two,
> because in the little time I have spent messing with the gui tools, I
> haven't found near as much control. That isn't to say that more can be done
> with the old way, but instead to say that I can do more with the old way. I
> don't know if there are any plans to deprecate that stuff, but I hope that
> if there ever are, news makes the list before I end up on a version where I
> have no clue how to do anything!
> Dustin
>
> From: fedora-xen-bounces(a)redhat.com [mailto:fedora-xen-bounces@redhat.com]
> On Behalf Of Emre ERENOGLU
> Sent: Friday, May 30, 2008 04:30
> To: Gastón Keller
> Cc: fedora-xen(a)redhat.com
> Subject: Re: [Fedora-xen] Xen Documentation
>
> Hmm,
> On Fri, May 30, 2008 at 2:06 AM, Gastón Keller <gastonkeller(a)gmail.com>
> wrote:
> On Thu, May 29, 2008 at 7:53 PM, Emre ERENOGLU <erenoglu(a)gmail.com> wrote:
> > Hi Gaston,
> >
> > It's true that some documentation is outdated. However, for the
> "/etc/xen"
> > isssue, my custom Xen 3.2 setup still stores ( and I do store there also)
> my
> > config files there.
> >
> > Maybe what you're saying is "Fedora Specific" which I could understand as
> > it's fedora mailing list.
> _The Fedora team has followed the Xensource model and begun to store
> all VM configuration details in a database, referred to as xenstore._
> Source:
> http://enterpriselinuxlog.blogs.techtarget.com/2007/06/07/fedora-7-xen-fi...
>
> OK, I didn't know that. However, I find this xenstore thing a bit
> complicated.
>
> Then, you might be right. I interpreted it was a modification from
> Xen, not from Fedora (previously introduced by Xensource).
>
> So, what is the advantage behind this movement?
>
> I think it's managegability.
>
>
> Thanks,
> Gaston
>
> However, I never found the flexibility and control
> > in the Fedora way of Xen implementation (all those xml stuff etc.). most
> > probably, I'm wrong :)
> >
> > Emre
> >
> > On Thu, May 29, 2008 at 9:22 PM, Gastón Keller <gastonkeller(a)gmail.com>
> > wrote:
> >>
> >> Hello, everybody. I have been struggling with Xen's documentation
> >> lately, not finding where to look for accurate and up-to-date info. I
> >> remember having read in this list months ago someone saying that the
> >> documentation was quite outdated. For example, the xm command _delete_
> >> does not appear in the man pages and many guides still do reference to
> >> the guest's config files being stored at /etc/xen (two days ago I
> >> discovered that now Xen works in a different way).
> >>
> >> My objective is not only to learn how to use Xen, but understand how
> >> it works. I'm doing my best looking for info in the net and going
> >> through docs in the Xen Wiki, but I might be missing something in my
> >> search. Therefore, I would really appreciate if someone could point me
> >> to some documentation I should read, or whatever else you could think
> >> of.
> >>
> >> Thanks,
> >> Gaston
> >>
> >> --
> >> La única verdad es la realidad.
> >>
> >> --
> >> Fedora-xen mailing list
> >> Fedora-xen(a)redhat.com
> >> https://www.redhat.com/mailman/listinfo/fedora-xen
> >
> >
> >
> > --
> > Emre
>
>
> --
> La única verdad es la realidad.
>
>
>
> --
> Emre
>
>
>
--
Emre
15 years, 11 months
RE: [Fedora-xen] HVM DomU on F9?
by Dustin Henning
For anyone who might have been following this thread, I accidentally
forgot to add fedora-xen to the recipient list before sending my last reply.
It is below, along with a response from Avi. I updated my F8 box, and sure
enough, kvm-60 was installed. I thought I had just done that and kvm-55 was
where it stopped, but I must be crazy or something. Also, I got the gplpv
drivers by James Harper installed and functional as of version 0.9.2 (I had
no luck with 0.9.0 or any prior version). That said, I probably won't go
any further with my quest for kvm, at least not in the near future. The
stdvga emulation kvm uses (or at least used on kvm-47) was nice with the
standard vesa drivers referenced on the kvm site (went higher than
1024x768), and those drivers don't work for the stdvga=1 option in xen, but
I think the potential performance gain from the multiple paravirtual drivers
will be more important for me. Also, as I didn't follow up on it, I did try
to install CentOS 5.1 on this machine and it does not support the network
card, so I am on Fedora 8 as originally recommended by Emre.
Dustin
-----Original Message-----
From: Avi Kivity [mailto:avi@qumranet.com]
Sent: Friday, May 30, 2008 03:13
To: Dustin.Henning(a)prd-inc.com
Subject: Re: [Fedora-xen] HVM DomU on F9?
[please use the list for questions like this]
Dustin Henning wrote:
> It doesn't look like F8 is likely to get up to kvm-58 either.
F8 is up to kvm-60.
> I
> prefer to stick with the Fedora repositories for the machine I am working
> with, as I don't want to run into compatibility issues on account of some
> future update. However, I want to try to use the network driver, as I am
> hopeful that it might make an apache application I am running perform
> better. It is also possible that I really need disk drivers for that.
> Would compiling a newer version of kvm on Fedora 8 be risky (in terms of
> interoperability problems after some future update)?
No.
> Also, assuming the
> answer to that is no, do I need to remove any certain packages first to
make
> sure they don't update and overwrite it?
No. Do a ./configure --prefix=/opt/kvm-69 and all files will be placed
there.
> Finally, on the Fedora repo
> versions of KVM for F7 and F8, I can't create a VM with 2 GiB of RAM. Was
> this a known kvm bug at some point (or worse, is it still?), or could it
be
> a problem with Fedora (I can do this fine in xen)? Thanks,
>
For more than 2GB of RAM in a guest, you need a 64-bit hypervisor.
Large guest support was added in kvm-47 (2TB guests were booted).
--
Do not meddle in the internals of kernels, for they are subtle and quick to
panic.
15 years, 11 months
configure: error: GRUB requires a working absolute objcopy; upgrade your binutils
by Dustin Henning
I hope this isn't off topic since the bug I am trying to resolve only
affects the xen kernel...
I am trying to compile grub on Fedora 8 because I need to apply the patch
for bug 250299.
First, I downloaded and installed
http://mirrors.kernel.org/fedora/releases/8/Fedora/source/SRPMS/grub-0.97...
Next, I extracted the included grub-0.97.tar.gz to /usr/src/
At this point, if I run configure, I will get the error mentioned in the
subject, as follows:
[CODE]checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... gcc
checking for gcc... (cached) gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking dependency style of gcc... (cached) gcc3
checking for ranlib... ranlib
checking whether optimization for size works... yes
checking whether gcc has -fno-stack-protector... yes
checking whether -Wundef works... yes
checking whether -falign-loops works... yes
checking for objcopy... objcopy
checking if C symbols get an underscore after compilation... no
checking whether objcopy works for absolute addresses... no
configure: error: GRUB requires a working absolute objcopy; upgrade your
binutils[/CODE]
However, I am running binutils 2.17.50.0.18 which is the latest in the
fedora repo, so I cannot upgrade, and I do not know how to downgrade.
I saw another issue where this same error was happening, and someone
suggested downloading ftp://alpha.gnu.org/gnu/grub/grub-0.97.tar.gz and
using it.
I tried this and determined that that is the exact file included in the srpm
I had downloaded, and the error still surfaces when I try it.
Additionally, if I apply the included grub-fedora-8.patch, the configure
file disappears. I can get it from the tar again, but I will still get the
same error, so while I need to know how I am supposed to compile after
applying that patch (which I apply before the patch for the aforementioned
bug), but that point is moot until I can determine how to fix this binutils
issue.
15 years, 11 months
