Re: [Xen-users] help please - running a guest from an iSCSI disk ? getting more diagnostics than "cannot make domain: -3" ? how to make domain0 "privileged" ?

[Jason Vas Dias <jason.vas.dias@xxxxxxxxx>]

Hi Casey - many thanks for your informative response ! - I've now got
it working ,
with a number of caveats / gotchas, detailed below:

On Thu, Feb 21, 2013 at 9:30 PM, Casey DeLorme <cdelorme@xxxxxxxxx> wrote:
>
> Hello Jason,
>
> Looking at your configuration, was the kernel built to be PV Compatible
> (http://sanifool.wordpress.com/2013/01/09/booting-up-a-domu-on-xen-4-2/).
>
Yes,  the configuration arguments of the latest ArchLinux kernel (
3.7.9-1-ARCH) check out for Xen .

> The disk line looks fine provided you wanted to pass the whole disk to your
> PVM (including it's partition table etc).  Also if you have it mounted while
> trying to launch the PVM that may throw warnings or errors.
>
> Is it possible you are missing the bootloader
> (http://xenbits.xen.org/docs/4.2-testing/man/xl.cfg.5.html)?
>

Yes, that was confusing - I first gave xl just
'kernel="/boot/vmlinuz..." , but then xl complained
it couldn't find the kernel, so I mounted the iSCSI share and gave xl
the full path to the kernel ;  but then
I saw your post and specified the "bootloader="pygrub"' setting, which
did not work until the fix
for this bug is built into libxl :
 Bug 1844 - xl coredumps whenever any "bootloader=" setting is used in
an xl.cfg file

Having fixed that, then I came up against a number of disk issues -
No setting for the disk 'vdev' field seemed to have any effect - ie.
sda , sda6, hda, sdc (the real device name) -
 the guest OS could not see that device.
Happily, with the dracut 'rdshell' argument supported by the guest OS,
I was able to get it into initramfs debug mode,
and saw the disk on /dev/xvdc  -  this appears to be the only usable
setting for the root= kernel argument - it is now
booting from this.  Perhaps this is just because I'm using the default
initramfs file and did not build one with the extra devices ?

> I don't believe it would affect your ability to launch the PVM, but the I am
> unfamiliar with your vif device model, and the mac address isn't in the
> suggested Xen range
> (http://xenbits.xen.org/docs/4.2-testing/misc/xl-network-configuration.html).
>

Yes, I should have read that document more closely - the setting that works is
    vif=["bridge=eth0"]

Then, with the default 'peth0' bridge created by default on ArchLinux, I get :
# brctl show
bridge name     bridge id               STP enabled     interfaces
eth0            8000.00093d130d57       no              peth0

          vif22.0

>
> If you are looking for more detailed diagnostics, you might check that the
> xen-debug kernel flag is set (and rebuild your ramdisk or kernel).
>
>
> Logging must vary by distribution as I almost never see non-kernel software
> log its errors to dmesg (/var/log/messages), but most will place logs into
> the same directory and organize them by file or folder.  In Xen's case it
> uses your toolstacks command xl dmesg (/var/logs/xen/).
>

Yes, but my point was that xl should not silently fail because of the
errata-121 issue without
telling the user - perhaps, if xl finds domain creation failed, it
could automatically do its dmesg stuff
and dump the Xen log messages to stderr ?

Also, in many cases when domain creation failed because of the above
issues, xl returned a 0 exit status -
it really should be returning >0 in these cases.

> ---
>
>
> On Thu, Feb 21, 2013 at 2:24 PM, Jason Vas Dias <jason.vas.dias@xxxxxxxxx>
> wrote:
>>
>> I'm beginning to conclude that Xen is not of sufficient code quality
>> to be useful.
>>
>> Firstly,  my 'xl create' command returns a 0 exit status, meaning
>> success, but yet no domain
>> is created or can be attached to or listed with 'xl list' :
>>
>> # xl create my_domain.cfg
>> Parsing config from my_domain.cfg
>> Daemon running with PID 1436
>> # echo $?
>> 0
>> # xl list
>> Name                                        ID   Mem VCPUs      State
>> Time(s)
>> Domain-0                                     0  1024     2     r-----
>> 35.5
>>
>> This appears to be due to this error message in 'xl dmesg' output :
>>
>> (XEN) Dom5 may compromise security on this CPU.
>> (XEN) traps.c:2584:d5 Domain attempted WRMSR 00000000c0010004 from
>> 0x0000000000000000 to 0x000000000000abcd.
>>
>> From reading the source, the traps.c message appears to indicate an
>> error condition, but you would not know this from the log message.
>>
> Have you checked all of the log files in /var/logs/xen/?
>
> Pretty sure that so long as the configuration itself doesn't contain
> syntactical errors and the command to qemu goes through that xl will assume
> it did its job.
>
> Is it possible xl create is launching the domains just fine (hence code 0),
> and they are failing at a different stage (eg qemu during boot due to
> configuration problems)?

But then xl should not be returning '0' .

>
>> Anyone know how to avoid this unhandled WRMSR ?
>>
>> Code that silently ignores and does not report error conditions does
>> not get my vote of confidence.
>>
>> Can anyone convince me that Xen is of sufficient quality to be used ?
>>
> Plenty of well known companies are using Xen, but I don't believe they are
> using the very latest stable release (4.2.1).  AFAIK 4.2.1 is not available
> as a package in any stable operating systems yet.  Stable release of code
> does not guarantee it will be compatible without plenty of configuration
> based on your choice of Dom0.
>
OK - I prefer to use latest available versions of everything so at
least I know all
known bugs are fixed, and I can help find new bugs.

> However I am under the assumption that you are not using it for production
> purposes given your choices (Xen 4.2.1 and ArchLinux don't exactly point to
> concerns with stability or desirable ease of operation as a priority).  If
> that is the case then as a personal user I can say that I have had great
> success using Xen 4.2 on Debain Wheezy for several months now.  However I
> have not dabbled in many of the areas you are (such as iSCSI, PVM's and
> programmatic domain control).
>
> However, even with my limited experience, I can easily conclude that because
> Xen can be used for such a wide variety of purposes it becomes that much
> harder to ensure functionality as factors that can influence success tend to
> cover a wide range (host hardware, Xen version, installed packages and
> package versions, Dom0 distro and version, etc).
>
>
> Hope these answers will help you identify the problem.
>
> ~Casey

I'm trying to use Xen for our testing server - in a "semi-production"
/ backend environment -
where we produce software that claims to run on @30 different OS-es,
and we don't have
30 physical servers, I'm setting up one server to be able to boot each
different supported OS
with Xen, for testing purposes.  Now at least I've got one working ...
only 30 more to go !

Thank You & Regards,
Jason

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