[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] Xen-users Digest, Vol 111, Issue 7


  • To: xen-users@xxxxxxxxxxxxx
  • From: PersuationEquationliasaon <r.stredicke@xxxxxxxxx>
  • Date: Fri, 09 May 2014 22:57:31 +0000
  • Delivery-date: Mon, 12 May 2014 02:08:02 +0000
  • Importance: normal
  • List-id: Xen user discussion <xen-users.lists.xen.org>




From my Android phone on T-Mobile. The first nationwide 4G network.



-------- Mensaje original --------
De: xen-users-request@xxxxxxxxxxxxx
Fecha: 05/08/2014 12:00 p.m. (GMT+00:00)
Para: xen-users@xxxxxxxxxxxxx
Asunto: Xen-users Digest, Vol 111, Issue 7


Send Xen-users mailing list submissions to
xen-users@xxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-users
or, via email, send a message with subject or body 'help' to
xen-users-request@xxxxxxxxxxxxx

You can reach the person managing the list at
xen-users-owner@xxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Xen-users digest..."


Today's Topics:

   1. Question about the USB Passthrough in Xen (Meng Xu)
   2. Re: Can't stop MD array after destroying domain (Egor Medvedev)
   3. Re: ucode=-1: did anybody have success? (Konrad Rzeszutek Wilk)
   4. Re: Question about the USB Passthrough in Xen
      (Alexandre Kouznetsov)
   5. Re: (pv)hvm, upstream qemu 1.7.1 (Stefano Stabellini)
   6. Re: Difference between primary and secondary VGA pass through
      (H. Sieger)
   7. xendomains migrate exclude (Torsten Lehmann)
   8. Re: xendomains migrate exclude (Ian Campbell)
   9. Re: Can't stop MD array after destroying domain (Ian Campbell)


----------------------------------------------------------------------

Message: 1
Date: Wed, 7 May 2014 09:05:27 -0400
From: Meng Xu <xumengpanda@xxxxxxxxx>
To: xen-users@xxxxxxxxxxxxx
Subject: [Xen-users] Question about the USB Passthrough in Xen
Message-ID:
<CAENZ-+ktJfEmoR_HmMSf211es0=O4wULQ61T5dXjmnNd5A8ujA@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

Hi,

I'm trying to use the joystick (like the joystick used for XBox 360) in the
guest domain in Xen.
I followed the instructions on Xen's website of the USB passthrough, (
http://wiki.xen.org/wiki/Xen_USB_Passthrough), but still cannot see the
joystick device in the guest domain.
(Because the joystick device is not listed in the output of command
'lspci', I think I cannot use the PCI passthrough  to achieve it?)

I'm very confused why the joystick device is not created in the guest
domain after I followed the instruction on
http://wiki.xen.org/wiki/Xen_USB_Passthrough. I didn't see any error report
but cannot use the joystick in guest domain.

My question is:
Did I miss something?

Below is my configuration and what I did to configure the system:
(My Xen version is Xen 4.3.0)

#?lsusb
Bus 001 Device 002: ID 8087:8008 Intel Corp.
Bus 002 Device 002: ID 8087:8000 Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 046d:c077 Logitech, Inc.
Bus 001 Device 004: ID 8564:4000
*Bus 001 Device 008: ID 046d:c21f Logitech, Inc. F710 Wireless Gamepad
[XInput Mode]*
Bus 002 Device 003: ID 413c:2107 Dell Computer Corp.

(I want to use the device "Logitech, Inc. F710 Wireless Gamepad [XInput
Mode]" in the guest domain)

#lspci | grep -i USB
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB xHCI (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB EHCI #2 (rev 04)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset
Family USB EHCI #1 (rev 04)

My ?
?guest domain 1's configuration file dom1.cfg:
?
name="dom1"
memory=1024
vcpu=4
disk=['file:/
?guestImages/dom1.img,xvda,w']
vif=['bridge=xenbr0']
usb=1
usbdevice=['joystick','host:1.8','host:046d:c21f']
?bootloader = "pygrub"?


?After I use `xl create dom1.cfg`,  no /dev/input/js0 was created in the
guest domain 1.
(I have the /dev/input/js0 in dom0.)
(I also tried to use usbdevice=['tablet','host:1.8','host:046d:c21f'] as
shown in xen's website and still couldn't see /dev/input/js0 in guest
domain 1.)

Please let me know if you need any further information. I really appreciate
any of your help!

Thank you very much for your help and attention in this question!

Best,

Meng

-----------
Meng Xu
PhD Student in Computer and Information Science
University of Pennsylvania
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xen.org/archives/html/xen-users/attachments/20140507/4e9f148a/attachment.html>

------------------------------

Message: 2
Date: Wed, 7 May 2014 17:20:45 +0400
From: Egor Medvedev <methodx@xxxxxxxxxx>
To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Cc: xen-users@xxxxxxxxxxxxx
Subject: Re: [Xen-users] Can't stop MD array after destroying domain
Message-ID:
<CAK4NFoGQxz3p2Rko=Cj5n5E4u2zbziMJqejNqLdK=k8LG2AVdQ@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8

Hello, Ian.
Thanks for your reply.

I use xen 4.3.2. There are no device-model processes working with
domain i mentioned in example.
I can see (null) domain in vm list:
==
(null)                                      53     0    14     --psrd  104770.2
==
Tried to unpause domain. Nothing happens.
This is /var/log/xen/ info for this domain:
==
Waiting for domain server1 (domid 53) to die [pid 14588]
Domain 53 has shut down, reason code 1 0x1
Action for shutdown reason code 1 is restart
Domain 53 needs to be cleaned up: destroying the domain
libxl: error: libxl_device.c:894:device_backend_callback: unable to
remove device with path /local/domain/0/backend/vbd/53/51712
libxl: error: libxl_device.c:894:device_backend_callback: unable to
remove device with path /local/domain/0/backend/vif/53/0
libxl: error: libxl.c:1449:devices_destroy_cb: libxl__devices_destroy
failed for 53
==
Here is config file:
==
name='"{vps_name}"'
kernel='"/var/storage/kernel/{os_file}/{os_version}/kernel-{os_bits}"'
ramdisk='"/var/storage/kernel/ramdisk-{os_bits}"'
vif='["mac=00:16:3e:{mac},ip={ip_list}"]'
<loop disk>disk='["{vbd_proto}:{vbd_path}{user_id}-{vbd_num},xvd{vbd_char},w"]'</loop
disk>
memory={memory}
maxmem={memory_max}
vcpus={cpu_count}
maxvcpus={maxvcpus}
cpu_cap={cpu_cap}
cpu_weight={cpu_weight}
vfb='["type=vnc,vnclisten=0.0.0.0,vncpasswd={vnc_pass}"]'
extra='"(hd0,0)/boot/grub/menu.lst root=/dev/xvda1
uos_net={ip}:{gateway}:{netmask}:{vps} uos_ns=8.8.8.8
uos_mem={memory}:{memory_max}:{memhold}:1:1 uos_stats={dc_cc_host}
root_size={root_size} selinux=1 enforcing=0 iommu=off swiotlb=off
earlyprintk=xen console=hvc0"'



cpuid='"host,x2apic=0,aes=0,xsave=0,avx=0"'
device_model_version='"qemu-xen"'
device_model_override='"/usr/bin/qemu-system-x86_64"'
==

On Tue, May 6, 2014 at 12:45 PM, Ian Campbell <Ian.Campbell@xxxxxxxxxx> wrote:
> On Mon, 2014-05-05 at 18:25 +0400, Egor Medvedev wrote:
>> Hello.
>>
>>
>> I have a problem with MD array after destroying guest machine using xl
>> toolstack.
>> Sometimes I can get an error:
>> ==
>> libxl: error: libxl_device.c:894:device_backend_callback: unable to
>> remove device with path /local/domain/0/backend/vbd/53/51712
>> libxl: error: libxl_device.c:894:device_backend_callback: unable to
>> remove device with path /local/domain/0/backend/vif/53/0
>> libxl: error: libxl.c:1449:devices_destroy_cb: libxl__devices_destroy
>> failed for 53
>> ==
>> When trying to stop array, system considers it being used by another
>> process.
>> We use dm multipath for block devices. After destroying domain, it is
>> also impossible to remove dm.
>
> Which version of Xen is this with?
>
> Is there a device model process still running?
>
> Does "xl list" still show the domain?
>
> Can you post the full logs of xl destroy please, along with any relevant
> logs from under /var/log/xen and your guest config file. Please can you
> also post the output of "xenstore-ls -fp".
>
> Ian.
>
>



--
Best regards,
Egor
http://aylium.net



------------------------------

Message: 3
Date: Wed, 7 May 2014 09:50:30 -0400
From: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Cc: xen-users@xxxxxxxxxxxxxxxxxxx, Sven K?hler
<sven.koehler@xxxxxxxxx>
Subject: Re: [Xen-users] ucode=-1: did anybody have success?
Message-ID: <20140507135030.GD12826@xxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=iso-8859-1

On Wed, May 07, 2014 at 09:53:23AM +0100, Ian Campbell wrote:
> On Wed, 2014-05-07 at 09:34 +0100, Ian Campbell wrote:
> > CCing Konrad who I think knows how all this stuff goes...
>
> FYO it seems like it got posted twice and there is a small thread on the
> other one at
> http://lists.xen.org/archives/html/xen-users/2014-05/msg00052.html
>

To add that, you can do:

cat /lib/firmware/intel-ucode/* > /boot/microcode.bin

and use the GRUB stanza like 'Atom2' had mentioned.


> Ian.
>
> >
> > On Mon, 2014-05-05 at 10:52 +0300, Sven K?hler wrote:
> > > Hi,
> > >
> > > did anybody use Xen's ucode option successfully?
> > > I'm trying to update the microcode before dom0 starts, since my dom0
> > > doesn't have the xen microcode driver. I'm using a vanilla 3.12.x kernel
> > > from kernel.org and to the best of my knowledge, the xen microcode
> > > kernel driver didn't make it upstream yet, i.e., it's only in konrad's tree.
> > >
> > > So I probably want ucode=-1. The documentation is speaking of a CPU
> > > microcode update BLOB. So all I need is to make the microcode BLOB the
> > > last module in grub, right? But: BLOB in which format?
> > >
> > > Well, on my system the microcode exists in two formats:
> > > - /lib/firmware/microcode.dat (not sure what the format is, it's
> > > definitely not cpio based, as would be needed for ucode=scan)
> > > - many single files in /lib/firmware/intel-ucode/
> > >
> > >
> > > Which line in grub would be correct? I guess it isn't
> > >   module /lib/firmware/microcode.dat
> > > or
> > >   module /lib/firmware/intel-ucode/<somefile>
> > > by any chance?
> > >
> > > Now the documentation of ucode goes one to talk to about some file
> > > called kernel/x86/microcode/GenuineIntel.bin. But it only talks about it
> > > in combination with ucode=scan. A wild guess could be, that this file is
> > > identical to microcode.dat. Another wild guess could be, that this file
> > > is something I have to download from intel, and this is also the file I
> > > have to use as a module in case I'm using ucode=-1 instead of ucode=-1.
> > >
> > > So could somebody who did all the research and experimenting show his
> > > working configuration to me?
> > >
> > > I think I tried microcode.dat once, and it didn't seem to work.
> > > I haven't tried a file from /lib/firmware/intel-ucode/ as I only have
> > > one production system and my test system is a VM where microcode updates
> > > are not possible.
> > >
> > >
> > > Regards,
> > >   Sven
> > >
> > >
> > > _______________________________________________
> > > Xen-users mailing list
> > > Xen-users@xxxxxxxxxxxxx
> > > http://lists.xen.org/xen-users
> >
> >
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-users
>
>



------------------------------

Message: 4
Date: Wed, 07 May 2014 10:23:06 -0500
From: Alexandre Kouznetsov <alk@xxxxxxxxxx>
To: xen-users@xxxxxxxxxxxxx
Subject: Re: [Xen-users] Question about the USB Passthrough in Xen
Message-ID: <536A4FDA.3030008@xxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8; format=flowed

Hello.

El 07/05/14 08:05, Meng Xu escribi?:
> (Because the joystick device is not listed in the output of command
> 'lspci', I think I cannot use the PCI passthrough  to achieve it?)
No, unless you passthrugh the whole PCI device that is your USB controller.

> [...]
> ?After I use `xl create dom1.cfg`,  no /dev/input/js0 was created in the
> guest domain 1.
> (I have the /dev/input/js0 in dom0.)
> (I also tried to use usbdevice=['tablet','host:1.8','host:046d:c21f'] as
> shown in xen's website and still couldn't see /dev/input/js0 in guest
> domain 1.)
What does lsusb in the guest domain says, after you attach the USB
device to it?

Have you tried to hot-plug it instead of specifying in the config file?

Greetings.

--
Alexandre Kouznetsov




------------------------------

Message: 5
Date: Wed, 7 May 2014 17:55:25 +0100
From: Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>
To: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
Cc: Anthony Perard <anthony.perard@xxxxxxxxxx>,
xen-users@xxxxxxxxxxxxx, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxx>, Jacek Konieczny <jajcus@xxxxxxxxxx>
Subject: Re: [Xen-users] (pv)hvm, upstream qemu 1.7.1
Message-ID:
<alpine.DEB.2.02.1405071754330.14596@xxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"

On Mon, 14 Apr 2014, Ian Campbell wrote:
> Anthony, Stefano: Any idea what this issue is?
>
> On Fri, 2014-04-11 at 21:44 +0200, Jacek Konieczny wrote:
> > Hi,
> >
> > I wanted to try running a PVHVM linux VM under Xen 4.4.0, using upstream
> > qemu 1.7.1.
> >
> > I have prepared a system image, which I can successfully run in the
> > following modes:
> > - PV
> > ? PVH (using fixes from Xen 4.4 git branch to prevent Xen lock-up on the
> >   domU shutdown)
> > - PVHVM, using device_model_version="qemu-xen-traditional"
> >
> > What does not work is (PV)HVM with device_model_version="qemu-xen". My
> > Xen is compiled with '--with-system-qemu=...' and uses the system
> > qemu-system-x86_64 binary, which is qemu 1.7.1.
> >
> > This is supposed to work, according to
> > http://wiki.xen.org/wiki/QEMU_Upstream.

Sorry for the late reply.
If you compile qemu-system-i386 instead of qemu-system-x86_64, does that
work for you?



> > The domain won't start. Or, rather, it crashes/reboots immediately (I
> > have stopped this with the 'on_reboot/on_crash' settings).
> > There is little interesting in the logs, except the one error in 'xl
> > dmesg':
> >
> > (XEN) io.c:204:d58 MMIO emulation failed @ 0008:ffff34d1: 10 89 f9 1e 04
> > 83 ff ff 06 02
> >
> >
> > The config file ('pvhtest.cfg'):
> >
> > memory = 256
> > vcpus = 1
> > name = "pvhtest"
> > vif = [ 'mac=02:00:0f:ff:00:1E, bridge=xenbr0']
> > disk = [ 'phy:/dev/vg/pvhtest,hda,w' ]
> > #bootloader = 'pygrub'
> > #pvh = 1
> > builder = 'hvm'
> > xen_platform_pci=1
> > boot="c"
> > paused = 1
> > pae=1
> > acpi=1
> > apic=1
> > stdvga=0
> > vnc=1
> > vncdisplay=1
> > vncpasswd="dupa"
> > serial='pty'
> >
> > on_reboot   = 'preserve'
> > on_crash    = 'preserve'
> > device_model_version="qemu-xen"
> >
> > The start command:
> >
> > # xl -v create pvhtest.cfg
> > Parsing config from pvhtest.cfg
> > libxl: detail: libxl_dom.c:195:numa_place_domain: NUMA placement
> > candidate with 1 nodes, 4 cpus and 14117 KB free selected
> > xc: detail: elf_parse_binary: phdr: paddr=0x100000 memsz=0x9ef68
> > xc: detail: elf_parse_binary: memory: 0x100000 -> 0x19ef68
> > xc: detail: VIRTUAL MEMORY ARRANGEMENT:
> >   Loader:        0000000000100000->000000000019ef68
> >   Modules:       0000000000000000->0000000000000000
> >   TOTAL:         0000000000000000->000000000f800000
> >   ENTRY ADDRESS: 0000000000100620
> > xc: detail: PHYSICAL MEMORY ALLOCATION:
> >   4KB PAGES: 0x0000000000000200
> >   2MB PAGES: 0x000000000000007b
> >   1GB PAGES: 0x0000000000000000
> > xc: detail: elf_load_binary: phdr 0 at 0x7fd78ab46000 -> 0x7fd78abdbded
> >
> > logs:
> >
> > qemu-dm-pvhtest.log:
> >
> > char device redirected to /dev/pts/4 (label serial0)
> >
> > xl-pvhtest.log:
> >
> > Waiting for domain pvhtest (domid 59) to die [pid 4914]
> > Domain 59 has shut down, reason code 1 0x1
> > Action for shutdown reason code 1 is preserve
> > Done. Exiting now
> >
> > xl dmesg:
> >
> > (XEN) io.c:204:d58 MMIO emulation failed @ 0008:ffff34d1: 10 89 f9 1e 04
> > 83 ff ff 06 02
> >
> >
> > What is going wrong here? How do I debug that?
> >
> > Greets,
> > Jacek
> >
> > _______________________________________________
> > Xen-users mailing list
> > Xen-users@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-users
>
>

------------------------------

Message: 6
Date: Wed, 7 May 2014 19:56:11 -0700 (PDT)
From: "H. Sieger" <powerhouse.linux@xxxxxxxxx>
To: "Daniel E. Shub" <daniel.shub@xxxxxxxxxxxxxxxx>,
"xen-users@xxxxxxxxxxxxx" <xen-users@xxxxxxxxxxxxx>
Subject: Re: [Xen-users] Difference between primary and secondary VGA
pass through
Message-ID:
<1399517771.72479.YahooMailNeo@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

An update about primary passthrough: I managed to get primary passthrough working with KVM and a AMD Radeon HD 7770 running Windows 7 Pro 64bit in the guest (with the AMD driver) and it does shorten the guest boot time. Other than that I can't say that KVM performs any better or worse than Xen, except that some benchmark applications such as Passmark PerformanceTest failed to run and caused a BSOD under KVM. Only in SAFEMODE was I able to run Passmark, but I haven't tried yet a solution that was offered to me.
While the benefits of primary passthrough for the user may be minor (shortened boot time), I do believe that this should be a development goal as the process becomes more predictable (the moment you boot the guest you see its output on the guest screen, exactly like booting on bare metal).
On Friday, May 2, 2014 10:08 AM, H. Sieger <powerhouse.linux@xxxxxxxxx> wrote:

Well, I've recently gave KVM a try and saw primary passthrough working in my setup - that was until I installed the AMD driver in Windows after which the guest didn't boot anymore/blue screen .

I believe primary passthrough can shorten the boot time of the guest, but other than that I wouldn't break my head over that.
On Thursday, May 1, 2014 2:48 PM, Daniel E. Shub <daniel.shub@xxxxxxxxxxxxxxxx> wrote:

On Thursday 01 May 2014 11:50:34 Gordan Bobic wrote:
> On 2014-05-01 11:34, Daniel E. Shub wrote:
> > I posted this question over at
> > http://unix.stackexchange.com/questions/123510/differences-between-primary
> > -and-secondary-vga-pass-through-in-virtualization but didn't get an answer
> > so I
> > thought I would try here ...
> >
> > From the wiki I think I understand why passing a VGA adapter through is
> > more
> > difficult than passing a standard PCI device through and to some extent
> > why
> > passing a VGA adapter through as the primary device is more difficult
> > than
> > passing it through as a secondary device. What I m confused about is
> > what are
> > the advantages of passing a VGA adapter through as the primary device
> > as
> > opposed to the secondary device?
>
> The only advantage of passing the interface as primary (and FWIW I have
> never actually seen this work) is that in that case you get to see the
> SeaBIOS POST screen and the domU OS boot progress before it loads the
> GPU
> driver. Other than that, I am not aware of any advantage.
>
> Gordan
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxx
> http://lists.xen.org/xen-users

If that is true, it seems like people are doing a lot of work for not too many
advantages. So much of the information on the web about VGA pass through is
confusing at best and often just wrong.

Dan
This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it.?  Please do not use, copy or disclose the information contained in this message or in any attachment.? Any views or opinions expressed by the author of this email do not necessarily reflect the views
of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.






_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xen.org/archives/html/xen-users/attachments/20140507/d1d9a7b3/attachment.html>

------------------------------

Message: 7
Date: Thu, 8 May 2014 12:31:24 +0200
From: "Torsten Lehmann" <tlehmann@xxxxxxxxxxxxx>
To: xen-users@xxxxxxxxxxxxx
Subject: [Xen-users] xendomains migrate exclude
Message-ID:
<52653a9a09e5ce4c777f7b0c9f514e4e.squirrel@xxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain;charset=iso-8859-1

Hallo,

I use 2 xen-hosts and 1 SAN
with configured XENDOMAINS_MIGRATE (/etc/default/xendomains)

The migration on shutdown works.
But I do not want to be migrated 1 VM.

Howto exclude a VM from XENDOMAINS_MIGRATE?

I looked into  /etc/init.d/xendomains, but found no corresponding lines.

Any ideas?

- xen4.0, managed VM, toolstack: xm

Regards Torsten




------------------------------

Message: 8
Date: Thu, 8 May 2014 12:30:42 +0100
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
To: Torsten Lehmann <tlehmann@xxxxxxxxxxxxx>
Cc: xen-users@xxxxxxxxxxxxx
Subject: Re: [Xen-users] xendomains migrate exclude
Message-ID: <1399548642.9513.70.camel@xxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"

On Thu, 2014-05-08 at 12:31 +0200, Torsten Lehmann wrote:
> Hallo,
>
> I use 2 xen-hosts and 1 SAN
> with configured XENDOMAINS_MIGRATE (/etc/default/xendomains)
>
> The migration on shutdown works.
> But I do not want to be migrated 1 VM.
>
> Howto exclude a VM from XENDOMAINS_MIGRATE?
>
> I looked into  /etc/init.d/xendomains, but found no corresponding lines.
>
> Any ideas?

You will almost certainly have to patch the script I think. If you can
do it in a generic way (e.g. with a list of domains which shouldn't be
migrated) then please consider posting your modifications upstream
(http://wiki.xen.org/wiki/Submitting_Xen_Patches)...

> - xen4.0, managed VM, toolstack: xm

... although I'm afraid they would have to be based on something far
more recent.

Ian.




------------------------------

Message: 9
Date: Thu, 8 May 2014 12:47:18 +0100
From: Ian Campbell <Ian.Campbell@xxxxxxxxxx>
To: Egor Medvedev <methodx@xxxxxxxxxx>
Cc: xen-users@xxxxxxxxxxxxx
Subject: Re: [Xen-users] Can't stop MD array after destroying domain
Message-ID: <1399549638.9513.78.camel@xxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="UTF-8"

On Wed, 2014-05-07 at 17:20 +0400, Egor Medvedev wrote:
> Hello, Ian.
> Thanks for your reply.
>
> I use xen 4.3.2. There are no device-model processes working with
> domain i mentioned in example.

You mean after the destroy? or even at run time there are no device
models? (You use vfb so the latter would surprise me)

> I can see (null) domain in vm list:
> ==
> (null)                                      53     0    14     --psrd  104770.2
> ==
> Tried to unpause domain. Nothing happens.

And I suppose "xl destroy 53" fails too?

What does "xl -vvv destroy 53" say?

> This is /var/log/xen/ info for this domain:
> ==
> Waiting for domain server1 (domid 53) to die [pid 14588]
> Domain 53 has shut down, reason code 1 0x1
> Action for shutdown reason code 1 is restart
> Domain 53 needs to be cleaned up: destroying the domain
> libxl: error: libxl_device.c:894:device_backend_callback: unable to
> remove device with path /local/domain/0/backend/vbd/53/51712
> libxl: error: libxl_device.c:894:device_backend_callback: unable to
> remove device with path /local/domain/0/backend/vif/53/0
> libxl: error: libxl.c:1449:devices_destroy_cb: libxl__devices_destroy
> failed for 53

Interesting. What does the "xenstore-ls -fp" log I asked for earlier
say?

> <loop disk>disk='["{vbd_proto}:{vbd_path}{user_id}-{vbd_num},xvd{vbd_char},w"]'</loop
> disk>

I suppose this is some sort of metatool macro language. What does this
actually expand to?

Ian.




------------------------------

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users


End of Xen-users Digest, Vol 111, Issue 7
*****************************************
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.