> I''m new to Xen and I read the documentation in detail.
Thanks for taking the trouble to read the docs - it''s a big help!
> But sometimes, asking a question to an experienced user help to avoid
> mistake.
Yep.
> So far, I can understand that Xen gives me theses advantages:
> - Security (one domU get hacked, the others are relatively safe)
> - High availability (if one node die, the other node can start the
> domU and restore the service)
> - Performance (live migration if one node is too busy)
Yep, yep, yep.
At some stage you might want to consider using the restartable driver domains
functionality to provide robustness against driver bugs, create a virtual
DMZ, etc but that''s another issue - you probably don''t want to
use this if
you''re just starting out. (and I''m not sure how well
restartability of device
drivers works right now - it needs to be automated in any case).
> - To perform live migration, I need to filesystem to be present on
> both server. I would use NFS ROOT. Is it recommended? If not, what is
> the best solution (iSCSI is not an option here)? Note that the Apache
> server will have high load during the day... and the documentation
> says "Note that the Linux NFS root implementation is known to have
> stability problems under high load (this is not a Xen-specific
> problem), so this configuration may not be appropriate for critical
> servers."
You could use NBD, all you have to do is specify the NBD server in the domain
config file - there''s a script to automatically connect to an eNBD
server in
dom0. Or you could set up iSCSI and arrange to have the block device
available at the same device node on both systems so that the device could be
found after migration. Or you could use a SAN if you have the money ;-)
In all these cases, the fact that the block device is on the network is hidden
by dom0, so the domU doesn''t even need to know about it.
> - What happend with the SWAP partition during migration? If I
> understand correctly, my root filesystem is on NFS so there is no
> problem. But how handle the SWAP partition for live migration?
Either apply the swapping to NFS patches (if they''re not in mainline
yet) or
provide a network block device to swap to. I''d recommend the latter on
the
grounds that swapping to NFS is liable to have more stability problems -
especially under high load. That''s an educated guess btw ;-)
> - "xm save" save only the CPU and memory state? It does not
include
> the root fs nor swap partition?
Just the CPU and memory state.
> - I use a 3wares RAID card. I guess the dom0 needs to have custom
> kernel to support the card. Does the domU kernel also need the raid
> card module?
No. The real block and net devices are entirely abstracted away - you can
change the underlying devices and the domU won''t know about it.
> - Bonus question :) If I have a SSL server on Xen signed by Comodo or
> Verisign, does the certificate still valid when I migrate the domU to
> another node?
I don''t see why it wouldn''t be...
Oh and by the way: migration can break if the CPUs on the different machines
have different capabilities (e.g. if the kernel booted with 3DNow
instructions and you migrate it to a machne that doesn''t have them).
If your
machines have the same CPU it''s not a problem.
Cheers,
Mark
--
Dave: Just a question. What use is a unicyle with no seat? And no pedals!
Mark: To answer a question with a question: What use is a skateboard?
Dave: Skateboards have wheels.
Mark: My wheel has a wheel!
_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users